We think we have ironed out all the hardware issues in the two prototype generations. All production units should not have any hardware issues left.There are some experimental improvements that some people wanted to work on, particularly
- trying to replace the slow SSC with a parallel bus interface (with wait states) or the SD/MMC controller using glue logic in the FPGA
FPGA¶The FPGA currently only contains some basic code to forward samples from the ADC to the SSC of the sam3u. As the ADC clock rate is currently fixed, it needs to do some decimation.
- the decimation is currently simply dropping samples, i.e. no real decimation. It's important to fix this by having real decimation in the FPGA
The firmware currently is just a basic 'proof of concept' using a USB audio class device with 500 kSamples/sec. This is compliant with the USB audio class spec and works fine on Linux, but doesn't work with Windows or Mac :/
Besides the data transfer using USB audio, there is a command channel on the hardware UART. You definitely need a UART adapter + serial cable in order to use the firmware at this point. The idea is to move this interface to CDC-ACM providing a command line on a virtual serial port next to the USB audioWhat needs to be done on the firmware:
- add USB CDC-ACM next to the actual sample transfer (via USB Audio or otherwise) and make the command line accessible via CDC-ACM
- include multiple different sample rates into the USB control descriptor, allowing host applications to switch sample rates. The lowest sample rate should be 96 kHz, which will definitely pass through even the oldest/crappiest audio driver and through full-speed USB instead of high speed. higher baud rates should include at least 192 kHz and 1 MHz
- export multiple USB configurations that can be selected from the host PC. All of them should have CDC-ACM next to them
1. existing USB Audio
1. a custom interface that could actually be USB Audio (including iso transfers) without announcing USB Audio to the host, avoiding that Windows/Apple drivers bind on the device despite not supporting the high baudrates. A corresponding libusb driver will have to be written
1. a custom interface that uses bulk instead of isochronous transfers. Just to compare performance and to fight the bulk vs. ISO war...
- add a mode where samples (or rather: blocks of samples contained in one USB transfer) are time-stamped with a sample counter. Of course this will not work with the standard audio profile, only with options 2+3 above.
- include the sam3u chip-id as USB serial number (LaForge already has code for that in a different repository)
- power up the device with low clock frequency and all peripherals disabled, as we are only allowed to draw 100mA until the host has selected a configuration that indicates more (e.g. 500 mA). This is to avoid breaking any USB ports e.g. on a bus-powered hub.
Right now the DFU loader doesn't have the capability to flash itself (i.e. the DFU partition). It can only flash the application partition.
Also, there is no way how the flash-based FPGA can be updated yet. This is a bit tricky, as the FPGA image is larger than any of the two flash banks or the RAM inside the sam3u. Also, the FPGA vendor only provides some (soruce code to a) virtual machine + bytecode that runs inside that VM to do bit-banging and flash the FGPA.Thus, the TODO is:
- allow the DFU code to re-locate itself to memory entirely, permitting DFU-flashing of the DFU partition
- devise and implement a method how we can update the FPGA image via DFU or some other custom protocol over USB.
- write a libusb based driver for both the isochronous and the bulk transfer mode, with and without sample timestamping
- test that driver on a variety of windows variants as well as Linux, BSD and OS X
- put documentation into the wiki and work on a real user manual.