Aidan Walton / SGTL5000 Featured

Library to control and transfer data from NXP SGTL5000. As used on the Teensy Audio Shield. It uses DMA to transfer I2S FIFO data.

The Library now supports dual codecs. Allowing all 4 channels of the Teensy I2S interface to RX and TX data to separate SGTL5000 devices.

The ISR routines that handles pointer swaps for double buffering has been fully coded in assembler to reduce overhead and now takes < 800nS per FIFO transfer when using all 4 channels.

Support added for all typical sample rates and system Clock speeds of 96Mhz or 120Mhz.

Pause and Resume functions added to allow quick and simple suppression of IRQs and stream halting and restart. This required software triggered IRQ, in order to ensure accurate word sync control.

Diff: sgtl5000.h

Revision:
12:9ce7f3828c6a
Parent:
11:392c09372ae1
Child:
13:83c2aaf4a338
--- a/sgtl5000.h	Wed Sep 27 10:39:01 2017 +0000
+++ b/sgtl5000.h	Wed Sep 27 10:59:09 2017 +0000
@@ -137,6 +137,16 @@
             The class is wrapped in the SGTL5000 namespace to avoid collisions with statics needed by the ISRs. Only the CODEC using CTRL_ADR0_CS = 0 can be used to manage 
             the I2S setup and data flow, such as sample_rate, attach, start, stop etc. If a second CODEC is available then its data flow is locked to the 1st,
             TX & RX FIFO buffers of both CODECs will be synchronised and only one DMA channel is used to TX data to both codecs and one DMA channel to RX data from both codecs.
+            
+            In SYNC mode FIFO buffers depths are synchronised to bring DMA transfers as close as possible to each other. After both TX & RX DMA transfers are complete, user code is called. 
+            Therefore, please note, there will always be a minimum delay of 1 I2S sample between TX & RX DMA transfers.  In most circumstances this is irrelevant, but needs to be considered.
+            For example; if the codecs run at 48KHz, and a FIFO depth of 8 samples is implemented. User code will be called every 83.3uS. At the end of this 83.3uS period there will be a short period
+            equal to the length of time needed to transfer 1 channel sample (@48Khz this will be (1/48000)/2 = 10.42uS + the time required to swap pointers ~ 800nS. Therefore ~ 11.3uS).
+            During this period just before user code is called again, the data in the transfer buffers should not be read or written. It is suggested that upon entry into user code, all TX data is first written out
+            followed by processing of RX data, which must complete in less than (83.3 - 11.3 = 72uS). If the sample rate changes this period changes, getting shorter as the sample rate increases.
+            However the pointer swaps take a fixed time, dependent only on system core clock frequency.
+            If this behaviour needs to ber avoided, run the TX & RX streams independently. However this then increases the overhead associated with IRQs and the user will need to 
+            manage synchronisation between TX & RX streams.
 
     @param  i2c_sda             i2c Serial data pin (D18 Teensy 3.2 header / PTB3 MK20DX256)
     @param  i2c_scl             i2c Serial clock pin (D19 Teensy 3.2 header / PTB2 MK20DX256)