Is it possible to capture 64kbps of data (SOLVED)

[benoitstjean]

I know this might sound far-fetched but is it possible to capture 64kbit of data per second on a PIC18F4620 without using the serial port (64kbps is not a typical serial transfer rate anyways)?

Here's the setup: I have a PIC18F4620 tied to a 16.384MHz crystal. I use this crystal because it lets me output a perfect 128kHz PWM. That rate cannot be done with a 20MHz or 24MHz as far as I know based on calculations.

The PIC is interfaced over I2C to a Texas Instruments TLV320AIC3204 audio CODEC. The CODEC requires a bit clock (BCLK) for bit timing with the I2S data bus so my PIC provides the BCLK pin of 128kHz. The reason being that providing it 128kHz will make the I2S data out as 8 bits only, which is what I want. The sampling is 8kHz therefore 8bit @ 8kHz = 64kbps.

In return, the 3204 outputs an 8kHz WCLK (word clock) which is high when the left channel is present and low when the right channel is present. In my case, I will read only one channel in order to have 64kbps (mono audio) therefore I need only to sample 8 bits of data during the high (or low) period of the WCLK.

This is where it gets tricky. As much as the PIC is providing the 128kHz bit clock to the CODEC, the PIC itself must also "know" each of the PWM pulse states (high or low) as it must count certain amount of pulses for the data on the I2S bus. So on each BCLK tick, I must read a data bit from the I2S bus.

I also tied an SD card to the PIC and they talk over SPI. I just want to use the SD card as a temporary buffer.

So far, as stated in a previous post of mine, I tested the interrupt on change on PIN B4 and I was able to get about 21 kHz max before the data starts to be corrupted.

To re-cap:

- PIC provides PWM of 128kHz to AIC3204 CODEC on bit-clock input;
- AIC3204 CODEC provides an 8kHz clock for left (high) right (low) channels;
- PIC must "know" how to sync itself with the I2S data channel by 'reading' the data bits on the I2S bus every time the WCLK pin is high (left) AND during that high period, sample the state of the data channel every time there's a BCLK falling-edge;

So, any idea on how I could achieve this? And one last thing, I currently don't have the setup to use any non-DIP PIC such as PIC24/PIC32/dsPIC.

[FvM]

I think there two (or three) options:
- using SPI interface
- using external shift register
- running the capture action exclusively in a loop with disabled interrupts

[benoitstjean]

Thank. I'm currently doing option 3. That's what I'm testing right now. I'll post the results.

[bkamen]

As a side note: the SPI module on the PIC24 series comes with all sorts of features perfect for what you are doing.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[bkamen]

Also, the PIC 8bit series does have a Synchronous mode for some of the devices in the UART (which is why the manuals actually refer to them as EUSARTs).

You can program the BRG for the UARTs to any rate you want... but the synchronous mode is the real item of interest.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[benoitstjean]

Thank you, that sounds interesting. But given CCS's very poor documentation (sorry but the documentation IS terrible), can I use some CCS functions to use the EUSART?

The other thing is I must take into consideration is that I must time my incoming data with the L-to-H transitions on the 128 kHz bit-clock signal. Each tick is one bit of data - 64K ticks for the left channel, 64K ticks for the right channel for a total of 128khz. The incoming data is L-R-L-R-L-R.

Then I have the word-clock which indicates to me when the incoming data is for the left channel (high) or the right channel (low)... And THEN I have my data on the data channel. And also, it is important to time the data properly because the data is level-based - on each bit-clock L-to-H transition, that's where I must read the data level.

If you think the EUSART can still work for this, can you give me more details? I will look in the datasheets but I personally find it always better when someone who's used it before can explain.

Word clock: --------_________--------_________ @ 8kHz (62.5us high for left, 62.5us low for right)
Bit clock: -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ @ 128 kHz for bit clocking
Data: -___--_____--____--_----_-___-__-----_-_-_ @ 8 bits per word-clock level

Take for granted that the lines above all have their edges aligned (if I had the Courrier New font, I could align everything). This is a bit what I'm up against...

Thanks,

Benoit

[bkamen]

[asmboy]

BTW: is your "capture" a burst, with a time ON and OFF?

or is it steady ??

Can you SUSPEND the incoming data and implement source flow control?


Potentially this is two different kind of problem.
If it is steady - the problem is much worse than short bursts of say a sec ON and 10 sec or more OFF.

[benoitstjean]

To bkamen:

Well, first, these microcontrollers are very complex devices. I do have the datahseets and I am going through them, but there's so many pieces to the puzzle that asking for help is just to make my life easier. As I stated "I will look in the datasheets but I personally find it always better when someone who's used it before can explain."... so, I *will* look in the datasheets BUT if someone can help as opposed to reading a static piece of text that cannot answer all of my questions, then that help is greatly appreciated.

Second, I never said that I was hoping that CCS would explain how the PIC works. That is not what I said. I *know* that CCS is *just* the compiler. However, that *compiler* comes with an API manual that *should* explain how to use the said compiler functions but unfortunately the documentation is incomplete and confusing. Good example - why is it that lots of people don't understand how to use the PWM? Honestly, it's VERY easy to use and VERY easy to setup.... But, because the documentation is poorly written, then people have questions... There are three lines of code to setup the PWM but CCS doesn't do its job well in detailing how easy it is to set it up *using its own code*.

Yes, reading the Microchip documentation *will* explain how to use the PWM, but, for someone who is not familiar with the registers and such and is only used to using the C compiler, you'd expect the documentation to show an example on how to use the compiler code to setup the PWM, don't you think? As much as you follow the links in the documentation, it's not very clearly explained how to use the compiler's built-in functions to setup a simple PWM, don't you think?

If I buy a car and have questions regarding how to add oil to the engine, I'd expect it to be written in the car's manual in clear details hoping that I wouldn't be re-directed to the engine's manufacturer to learn how each valve is oiled while the engine is running etc. I just want to add oil!

And third, I've being working with PICs for quite a long time and made some pretty cool stuff with them (SMS communicator over a GSM modem, alarm system with phone interface, network communicator with ethernet device and the list goes on...)... At this point, I am trying to do stuff I've never done before and all I am doing is asking for help.

[benoitstjean]

[bkamen]

[benoitstjean]

So, now using a PIC24HJ128GP306 and a 38.4MHz crystal, I can READ and WRITE (including the instruction and address overhead for both operations) to an SRAM 23LC1024 over SPI in 28.0625us (from the time CS goes low before the write command to the time CS goes high after the READ command). I guess I can consider this part solved for now.

I haven't merged my audio sampling code with the memory access code yet but I believe it should work.

[bkamen]

[benoitstjean]

I am using external SRAM because it has 1MBit (131071 bytes).

And DMA was my next step. There's code for DMA in CCS though so do you say that CCS doesn't really make direct support of it?



Ben

[bkamen]