![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
benoitstjean
Joined: 30 Oct 2007 Posts: 553 Location: Ottawa, Ontario, Canada
|
Is it possible to capture 64kbps of data (SOLVED) |
Posted: Thu Aug 16, 2012 8:15 am |
|
|
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.
Last edited by benoitstjean on Fri Sep 21, 2012 10:37 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Thu Aug 16, 2012 12:15 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
benoitstjean
Joined: 30 Oct 2007 Posts: 553 Location: Ottawa, Ontario, Canada
|
|
Posted: Thu Aug 16, 2012 12:25 pm |
|
|
Thank. I'm currently doing option 3. That's what I'm testing right now. I'll post the results. |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Thu Aug 16, 2012 7:13 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Thu Aug 16, 2012 7:15 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
benoitstjean
Joined: 30 Oct 2007 Posts: 553 Location: Ottawa, Ontario, Canada
|
|
Posted: Fri Aug 17, 2012 6:37 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Fri Aug 17, 2012 11:02 am |
|
|
benoitstjean wrote: | 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?
|
You can't point to CCS to blame your lack of understanding how a PIC works when you're not reading the datasheet and familiar with the PIC families of Microcontrollers.
CCS is *just* the compiler. It doesn't teach you how to program (out of scope) and it doesn't teach you everything you need to know about how a particular (or family) of PIC operates or what features it has.
I suggest you find a PIC with an EUSART and read the datasheet... thoroughly.. then read it again like 5 or 6 more times.
You will see some places where CCS doesn't cover ever feature exactly as you might want to use it on a PIC. That's fine because if you were programming in C18, you'd find yourself with a lot fewer built-in functions available to you.
I always like to say, "when CCS doesn't have a function for it, you end up writing it just like you'd have to in C18 anyway".
Go read... come back and tell us what you were able to figure out.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Aug 17, 2012 11:20 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
benoitstjean
Joined: 30 Oct 2007 Posts: 553 Location: Ottawa, Ontario, Canada
|
|
Posted: Fri Aug 17, 2012 11:50 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
benoitstjean
Joined: 30 Oct 2007 Posts: 553 Location: Ottawa, Ontario, Canada
|
|
Posted: Fri Aug 17, 2012 12:04 pm |
|
|
asmboy wrote: | 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. |
Yes, it is steady. It's 64kbps audio from a Texas Instruments TLV320AIC3204 Codec. I think I might have to use higher-end devices. Interrupts aren't fast enough and I need to time my data with an 8kHz word clock (left = 1, right = 0), a 128kHz bit clock and the actual data, 8 bits. Each data bit is clocked on a bit-clock transition. The CODEC is working fine, the audio is awesome. But to store the digitized audio somewhere is a greater task than I expected.
At the moment, the interrupt-on-change on RB4 is used to time the word-clock since it's only 8kHz. In the interrupt routine, I can read the data pin based on the bit-clock's value, but only at low speeds, not sure how fast though. If I do it manually, where I have a wire that simulates the data and a wire that simulates the bit clock, I can "clock-in" any values I want and it works just by connecting/disconnecting wires from my proto-board. But when the bit-clock is at full 128kHz, then I think it's too fast (way too fast).
I think I'll have to start looking at upgrading my equipment unless someone has a suggestion for a solution... |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Fri Aug 17, 2012 4:13 pm |
|
|
benoitstjean wrote: |
I think I'll have to start looking at upgrading my equipment unless someone has a suggestion for a solution... |
As mentioned, a PIC24 would be perfect for what you want to do. It supports I2S modes of operation...
But let's look closely at your device (the PIC18F4620).
I'll assume it's receiving only.
So for that PIC, it does have a EUSART.
You would want Synchronous mode with external clock.
This is definitely an ISR based operation. I would have the ISR check on reception of a byte what level the right/left flag is set for and then put it in the right or left channel "bucket" accordingly.
Let's detour for a second... at 16KB/s we're talking a byte every 62.5uS. A rough estimate for that kind of datarate running the PIC at 40MHz (which comes back to 10MIPS if using the HSPLL), we're looking at 100nS per instruction and thus for every character you have 625 instructions.
625 instructions per byte. Now you have a reaaallly rough idea of how much code you can write. not much. heheh...
by comparison, a PIC24F would give you 16MIPS or roughly 1,000 instructions per byte.
I don't know everything you're doing with this -- but with 128Kb/s I can see the EUSART doing this ... but as for the rest of what you have going on, it may be a close race.
It's worth trying if your code is slim.
Cheers,
-Ben
EDIT: Read the section on the BRG for the EUSART... if the PIC is running 40MHz.. In a master mode, it could make the 128kb/s -- so if you're using it as a clock SLAVE, you should be good to go in terms of the EUSART handling it. _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
benoitstjean
Joined: 30 Oct 2007 Posts: 553 Location: Ottawa, Ontario, Canada
|
|
Posted: Fri Sep 21, 2012 10:36 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Fri Sep 21, 2012 12:18 pm |
|
|
benoitstjean wrote: | 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'm guessing you may or may not be underclocking the part which I think can run at 80MHz. Via the PLL circuit, you can ramp up the part to do what you want. So if 38.4MHz is just something convenient you had around (but is a multiple of what you need), that's fine. Just keep in mind that without using the PLL, you're essentially getting CLK/2 = MIPS. So right now, you're getting around 19.2MIPS out of a 40MIPS part.
This base clock speed also affects your peripheral bus. I'm not sure why you need external RAM now that you have 16K available but since you're still using the external RAM, SPI clock speed is related to overall clock speed.
Lastly, and this one is important, DMA could be immensely useful here. CCS doesn't really make direct support of it -- but it does some really neat things and you should make sure to read about the DMA controller built into these PIC's.
Between DMA, ISR's and what you're doing, there's no reason you shouldn't be able to accomplish this with that PIC.
Cheers,
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
benoitstjean
Joined: 30 Oct 2007 Posts: 553 Location: Ottawa, Ontario, Canada
|
|
Posted: Fri Sep 21, 2012 12:27 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Fri Sep 21, 2012 12:34 pm |
|
|
benoitstjean wrote: | 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?
|
Right -- CCS doesn't make direct support for it. (that I've seen yet).
You can't turn on SPI with a CCS function that includes any support for DMA. It's strictly "roll your own" -- which isn't hard anyway.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|