Hi,
I just published my new driver library for the NXP SGTL5000 codec. It uses DMA to transfer audio data over I2S from and to the codec which is used by Teensy Audio shield. The codec has many built in DSP functions which can all be controlled and configured using I2C, a full definition file for the codec command registers is included. The codec supports rates from 8Kb/s up to 96Kpbs. However it will and does function at 192Kb/s, so I added this unofficial sampling rate to the available options. I have tried carefully to absolutely minimize any overhead in the code as it handles the codec IRQs, however as it's using DMA, the bulk of the work is invisible to the CPU. I have measured using a uS timer the IRQ and it takes less than 1uS. So this gives users code a goodly length of time to run some DSP functions.
TX and RX can be configured independently or in a synchronous mode. Synchronous being more efficient as only a single IRQ needs to be serviced by the driver for both the RX & TX FIFO demands. Each data direction requires a DMA channel, so if you only wish to send data out to the codec or recieve from the codec a single DMA channel is enough.
DMA TCDs are configured to use scatter and gather mode, which is how double buffering is handled automatically by the DMA controller. I2S FIFO depths can be chosen to adjust latency and IRQ/Callback periods. Using pointers in the user code DSP functions can process incoming/outgoing data without any need to copy data blocks by the CPU. More time for MAC operations of course.
Users code can use callbacks or IRQs as desired. The code is I hope well documented.
Enjoy.
Aidan
Hi, I just published my new driver library for the NXP SGTL5000 codec. It uses DMA to transfer audio data over I2S from and to the codec which is used by Teensy Audio shield. The codec has many built in DSP functions which can all be controlled and configured using I2C, a full definition file for the codec command registers is included. The codec supports rates from 8Kb/s up to 96Kpbs. However it will and does function at 192Kb/s, so I added this unofficial sampling rate to the available options. I have tried carefully to absolutely minimize any overhead in the code as it handles the codec IRQs, however as it's using DMA, the bulk of the work is invisible to the CPU. I have measured using a uS timer the IRQ and it takes less than 1uS. So this gives users code a goodly length of time to run some DSP functions.
TX and RX can be configured independently or in a synchronous mode. Synchronous being more efficient as only a single IRQ needs to be serviced by the driver for both the RX & TX FIFO demands. Each data direction requires a DMA channel, so if you only wish to send data out to the codec or recieve from the codec a single DMA channel is enough.
DMA TCDs are configured to use scatter and gather mode, which is how double buffering is handled automatically by the DMA controller. I2S FIFO depths can be chosen to adjust latency and IRQ/Callback periods. Using pointers in the user code DSP functions can process incoming/outgoing data without any need to copy data blocks by the CPU. More time for MAC operations of course.
Users code can use callbacks or IRQs as desired. The code is I hope well documented.
Enjoy. Aidan