Can this stack with audio class driver fit inside BF memory?
I know that in the past this was not possible, but hoping some improvements have been made in the interim.
I have recently used the USB stack on BF547 custom hardware. If I remember correctly, the USB libraries require about 60,000 bytes, with an additional several thousand bytes of heap. We placed USB support in SDRAM.
can you list the stack services you required in your build? HID, audio, mass storage, etc?
We only used bulk endpoints for what amounts to a bi-directional, message-based communications channel. We only have requirements for low latency on messages carrying less than 20,000 bytes per second.
I'm sorry, but the only improvement to the memory footprint we have made is to remove the debug and logging code for the release build libraries. This was done for Update 8 of VisualDSP++ 5.0.
I have done some research and the following figures represent:
(a) building release mode, optimizing for size, (and turning off assembler annotations - not sure if this saves anything!)
(b) reducing the static memory requirement of the USB stack with the following settings in adi_usb_core.h:
#define USB_MAX_DEVICES 1 #define USB_MAX_CONFIGURATIONS 1 #define USB_MAX_INTERFACES 3 #define USB_MAX_ENDPOINTS 8 #define USB_MAX_STRINGS 4
(c) Removing all superfluous driver modules from libdrv and libusb.
(d) changing the sample usb audio app to
(i) reduce the adi_ssl_Init requirements to:
#define ADI_SSL_INT_NUM_SECONDARY_HANDLERS (6) // number of secondary interrupt handlers #define ADI_SSL_DCB_NUM_SERVERS (1) // number of DCB servers #define ADI_SSL_DMA_NUM_CHANNELS (2) // number of DMA channels #define ADI_SSL_FLAG_NUM_CALLBACKS (0) // number of flag callbacks #define ADI_SSL_SEM_NUM_SEMAPHORES (0) // number of semaphores #define ADI_SSL_DEV_NUM_DEVICES (5) // number of device drivers
(ii) reduce the DAC buffer size to that of a single multiple of the USB buffer.
The stats for each relevant module in the build are:
The Map XML file shows a total of 135,402 bytes with 15,228 in external memory, 6,198 bytes of this coming from liibio and libc.
In my estimation the above represents the best we can do with the current software release for 16 bit, 48kHz, stereo. A reduction of the USB and driver code by 9,030 bytes is required to remove some of its code from external memory, but then 6,198 bytes of libio & libc code still needs to be reduced as well!
Modifying the core to remove superfluous (for USB audio app) code for host mode operations, removes adi_usb_otg.doj from the build and reduces the adi_usb_core.doj footprint by 44 bytes (not huge!). The L3 requirement is 11,720 bytes including libio, libc and libusb code.
The upshot of all this, Tim, is that it would take some major effort to reduce this further.
I believe my response has comprehensively answered Tim's question.
Ok, the Audio class driver can be reduced in size from 8,148 to 7,668 bytes by reducing array bounds to the minimum required for the default configuration of PCM record/playback.
Retrieving data ...