6 and 7 not playing ball, probably due to the way that the packets work
(used a single 750 buffer rather than a split 375 buffer).
Former-commit-id: c7f46c21c2ebced512361204b68f890ef3eff9f2
Finally got it. The bin was using the .dlls from Qt 5.6, but the .exe
was compiled with 5.7. It was some kind of timing error??
Just needed to redeploy using windeployqt.
Former-commit-id: 48c38ed9907000ed876e96acef804736aa134b81
Looks like TRFCNT is going haywire when the exe is run outside of the
IDE. The fact that it occasionally initialises close to 750 is
irrelevant.
Former-commit-id: e26f5396b90d2a1289ff1eeccafd76a04e779b20
Changed a 750 to a 250. Seems to stop it. Perhaps trying to get all
750 samples caused it to require 3 frames, creating a situation where
one could finish early?
Former-commit-id: 6da2a19b575705d61de5d940724aa77d9a0afca9
Finds the correct "magic numbers" automatically on launch. No longer
have to edit due to hot day.
Former-commit-id: c38c9eb07c02ebf9e13637c8988c55d1836cb5cc
Added a "nop" interrupt to ADCA.CH0's completion, to give the DMA
channels time to catch up.
Doesn't seem to have fixed the problem!
Former-commit-id: e78939ee41d6fceb58b67e6f43211d271cd52fca
Not sure how to strap to 12000. I started one, but it seemed to lose
the lock after a while and then drift into glitchland.
Former-commit-id: ee5cb540eb7fdb980ac18f8e5bc47882d72407e9
Code designed to pull code towards a CNT of 12000 pulls it towards 0.
Seems to be a long time before frame flips (30 seconds??), but they're
happening. The time spend there may be less periodic. Not sure,
haven't tested. Going to try and strap to 12000 instead. That's what
should be best, in theory.
Former-commit-id: cd1a0b582e42aca032a77ba61ba184f7492a2c11
Well, HUUUUGE amounts of temporal noise, but no frame flips. I'll go
test this out in the SW.
Former-commit-id: 09d259d39ab5b167fc3cb7186e767d6050f7ad11
No fine-grain control, though. On this particular board, tests look
like you've got the option between + 4% or -0.2%.
Former-commit-id: 58a256b564dbd39906fc4db2e20de0a4ca8c5706
Can enumerate over USB, but only when both sysclk and usbclk are running
from the 32MHz RC oscillator (DFLL'd up to 48MHz).
Good news is: no ASF! Jej!
Former-commit-id: 27dae72dd15a1773e10a10ae89c3d5e3cbc896fb
Manually toggling the CALA/CALB registers seemed to do nothing to the
timer. It was always off by 188. Always creeping up... Unless CALA
went to 0xff...!?!?
Former-commit-id: d97586cf182faba7282381e000dc622f2a503383
Bugs found recently:
- Trigger doesn't work on negative voltages (at least in MM mode).
- Double Sample Rate button won't de-trigger when CH1 scope is disabled.
Former-commit-id: 56f329a016
The error where every packet can become corrupt when you get a "bad
launch" seems more pronounced here. But it still succeeds enough times
to show that correct synchronisation could fix it.
Former-commit-id: 85b86af1ff
Although Logic Analyzer CH2 is faulty. Looks like it's been in the code
for months, though. Add that to the list of things to fix.
Former-commit-id: f76e8eb3a7
And found the bug from before; or at least the trigger. It seems to
only occur when the rear PCI USB port is used. Front hub or rear USB2
ports don't show issues at all.
Former-commit-id: 653891ca63
But will not respond until device has been connected at least once! On
a side note I found out how silly the saveState/loadState method in
genericUsbDriver was. It was always a better idea to just "poke" the
signals to ensure that it is reset in the same way that would happen
from GUI interactions.
Former-commit-id: 57c841f1d7
From the looks of things, anyway.
This fix came with a cost:
- All modes apart from 0 are broken.
- Randomly, the DMA write and USB read may access the same half of
isoBuf. This is determined on boot, and doesn't seem to desynchronise
and resynchronise over time.
The good news is that both of these have a fix. Give it another day of
coding...
Former-commit-id: 23741ceecb
Added triple endpoint support for the Desktop interface.
Should be possible to fix the one-packet-per-sample glitch easily, now.
Even if it isn't, the device now only needs to reserve 768 bytes/frame,
not 1023!!!!
Former-commit-id: 5769288a11
Have moved from one big (1023 byte) iso endpoint to 3x 256 byte ones.
This will fix the error where Labrador is picky about which port it's
connected to, and *should* fix the one-sample-per-packet error.
Former-commit-id: 880303ed09
Swapped an append to a replace with an ADT designed to return fast
pointers to char[] blocks.
Worked out that the one-corrupt-sample-per-packet bug was definitely not
fixed. I must have been looking at a 1kHz wave before.
Former-commit-id: d3054d9707
EspoTek