Interfacing

now yet

d let

as

DHC

ulate

s,

I suggest you look into using a FIFO.

I can't find PIC32F795F512L, but the PIC32MX795F512H has only 16 A2D channels. So, you can't do 32 channels w/o external MUX.

Hi,

But

1. How big should be the memory size of the FIFO and its deay etac.
2. The number of pins needed to interface the data and address buses.
3. How will the FIFO be interfaced to the SD Card?

Any advice!

Jess

The SDHC card needs SPI interface. How can I interface to FIFO?

Sure, thanks. lets say 16 channels. Now still what would be the good solution and will the idea behind my calculations is right? jess

Should be fine. The only potential problem is pushing all these data via bluetooth. How do you determine what data to push? If you can push all of them to the PC, why have the SD card? If not, the SD card will get full eventually, even for 4G.

SD CARD wil keep the copy of the data in case if the user needs it on the device. So, my calculation looks good. Do I not need a FIFO etc to do this. I did not understand your question " How do you determine that what data to push? Yes but it will take at least two hours to get that sd card filled. Please also adivce that how can I take account of SDC ARD delays into account.

jess

I have not done the calculation that when the SDCard will get full but I can tell it will record maore than rwo hours. The user might need a on board recording capability too thats why I kept a SDHC card on the board. I did not understand the question about "what data to push"? So, do I need a FIFO? Do my calcualtions look right? How can I take bluetooth2.1 and SDHC card delays into account in my calculations or selecting the micro? Is the idea dividing the RAM good?

jess

I don't think hard FIFO will make much difference. You have 128K RAM to make a soft FIFO anyway. Bluetooth (basically serial port) will be the bottleneck. 256 Hz of 16 channels at 16 bits would be around 65K bits/sec. I am currently pushing data from a PIC24 to PC at 19.2K serial, but getting too much soft error beyond that. I will take a look at PIC32 next, but not expected to get more than 56K.

May be bluetooth 3.0 can make a difference. I have not seen its specs yet. Right now the plan is to use SDHC (Class 6 ) which has data rate of 6MB/s ( the one that I am planning to use) and Bluetooth that has data rate 2.1Mbit / sec or 250 Kilo bytes / sec. According to calculation 256Hz of 16 channels at 16 bits would be around 65K bits per second which is much lower that the bluetooth data rate. Why are you getting the error in tranmission?

Can you advice how to include the SDHC card and bluetooth delays into my calculations. How can I include worst case timing scenarios? And how did you measure the 19.2K data rate plus how can measure the data rate of SDHC card once it gets interfaced to the PIC32 and data starts streaming between the two. Thanks

PIC32 data sheet is as follows

jess

But the PIC will not be able to handle the high data rate.

Because serial protocol is error prone. Retries in transmissions end up slowing it down more.

SDHC should not be a problem.

Bluetooth will be limited by the underlying serial port.

I am sending at 19.2K baud from a 32MHz PIC24 to a 16MHz AVR. Hopefully, 80MHz PIC32 can do better.

I think PIC32 can go up to 56K baud.

Hi,

I have chosen

1. Transcend 4GB micro SHDC card.
2. PIC32F795F512L, 80MHz processor with 128K RAM. ( I do not know yet that this micro will be suitable for my application)

My PIC will be getting 16 bit of samples at 256 Hz from an ADC from 30 different channels which the microprocessor has to write into the SDHC card. The ADC will continuously sample the data. The same microprocessor will also be transmitting the same data via Bluetooth

2.1 to a PC. I figured that for one ADC channel (256 x 16 x 1 second = 4096 or 4K) 4Kbits of memory is required (So, for 32 channels 32 x 4k = 120K) Is this calculation correct? . I know that SDHC cards have their delays and communication problems etc which make them a little slower.

The problem is that I have to write the continuous coming ADC data into the RAM and from there continuously writing it to the microSD Card until it gets full . So, the problems are as follows

1. I write the specified amount of data to the SD Card. SD Card let the microprocessor write the data but takes some delay to do it and then also keeps the microprocessor waits for the acknowledge signal for some times. The delay is unknown or big enough that my RAM gets full with the continuously coming ADC data and micro started losing the real data and overwriting or generates an error message or something. Plus if a user on the PC side also generates some command to the microprocessor to do something else via Bluetooth. I forgot to tell the microprocessor is also sending the same data to the PC via Bluetooth 2.1 too.

So, far I came up with the idea to keep the RAM as big as possible. I know that my C code will also reside there and the data will also reside there. I might have to divide the RAM in three sections, C- code, Bluetooth and SDHC Card. I guess the my questions are as follows

1. If bigger RAM is the solution, than how big. How can I calculate the size that I need.
2. How can I make the Bluetooth and SDHC card data rate, delays, microprocessor clock and other important parameters( which I do not know yet) be the part of my calculations?

Any idea, suggestion or advice is welcome. ========================================================

resolution*rate*channels is the minimum sustained data rate you must have. For your case this is 16*256*30 ~= 125khz. No matter what code, devices, or transfer methods this is the minimum.

Since there is overhead in transferring the data you must calculate the cycles required to transfer one bit from one channel and then multiply that by the above number. viz., the above number assumes that it takes exactly 1 cycle to transfer the data.

I believe it will take at least 10 cycles(approximately) to transfer a bit which means you'll it will require ~ 1Mhz cpu. I would imagine an 80Mhz processor would be fine and give you a bit of headroom to work with(depending on the adc protocol it might not be enough but it's always easy to parallel to give the throughput you need).

As far as memory goes, you have to store those bits somewhere. In your example it is ~125kbits per second which you calculated correctly.

This is the minimum amount of ram you need. Anything over this may not be helpful depending on your method.

Because it will take around 1M cycles to receive the adc data it will also take about 1M cycles to transmit(really depends on protocols and such but I'm estimating).

The problem is you cannot receive 1 second of data then transmit 1 second because that will introduce a delay of 1s into the receiving end. You must interleave the transmitting and receiving so that there are no samples dropped(and you must decide how bad of an problem that might cause).

Alternatively you could have a dedicated receiving circuit and dedicated transmitting circuit. This may be a problem if the memory cannot be simultaneously read and written. (you can get two port memory for this)

If a delay is ok for the transmission(e.g., it doesn't have to be real time) you can double your memory and have the receiving end write to one memory bank while the transmission is reading from the other. This solves the problem but introduces a delay of how ever long it takes to fill up a memory bank(125kbits would take 1 second but you could subdivide and simply swap bank quicker but up to a limit).

There are many factors involved and one of the biggest is the cost. What you want to do is not a terribly difficult task... it depends on how well you want to do it...

Your pic should easily be able to handle the transmitting and receiving but if there are any stalls or errors in the stream then you might have some big issues. You could, for example, use ERC's to fix this or resend the data but it costs cycles to compute.

What you have to realize is that you must have a fast enough system so that the you can send the bits faster than you can receiving them. If you don't you just end up piling up bits or having to drop them to keep up. If dropping bits or errors in the stream are bad(fatal without recovery) then you have some real work ahead). If it's not a critical application(no one is going to die or lose money on it) then it should be a relatively easy task).

rate

I must agree, it won't be able to bit-bang two serial ports that fast. Dedicated serial port chips seem to be called for.

It is more the RF link that adds most of the retry, but it won't take = much error rate to hit the max data rate on the Bluetooth. Not all of the protocol time slots are available for steaming.

Sit down and work out just what the write protocol and timing is, and = from there what the CPU load is to setup addresses and transfer data. How much, and how little can you write a one time?

Only if you are bit-banging it. Hardware ports for 230 kbit/s should not be all that hard to find.

=46or one serial port at a time i expect.

I think PIC32 can go up to 56K baud. How did you calculate that it can only do 56K baud.

Probably looked at the program sequence involved, added up the time taken to execute each step, and realised that they took something like

19usec in total.

This obviously depends on the clock rate available and attainable, and clever programming can make a difference - which is to say that a bad choice of operations can make the execution time appreciably longer than the best possible choice.

-- Bill Sloman, Nijmegen