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
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
Some CSV export features implemented - dump everything (in a stream -
750ksps!!) or just dump what's visible in screen. Stream doesn't dump
actual voltage readings but raw sample data.
Board software has been updated to fix DMAnot transmitting the correct
data for signal gen CH1 in modes 4 and 5
Former-commit-id: 7f40f04ef9
Mode 4 (Logic Analyzer CH1 and CH2) code has been rewritten and a
third(!!!) pause button has been added to allow pausing while scope is
diabled.
Two of them should disappear in the next commit. :)
Former-commit-id: 749bf8d4a7
Removed hardcoded link to C:/kfvcc in software - it can now be run from
any folder! Also changed some compilation settings to make it for
mass-produced hardware and actually-deployable software. (Shadow build
was causing an error).
Former-commit-id: 41d8fd61e1
EspoTek