chipKIT® Development Platform

Inspired by Arduino™

MAX32 data transfer speeds (serial/SPI/UART)

Created Tue, 17 Dec 2013 05:08:00 +0000 by mitchjp

mitchjp

Tue, 17 Dec 2013 05:08:00 +0000

Hi everyone,

I have purchased a max32 and will be using it essentially as a data logger for some sensors. The sensors have a high sample rate and so i need to achieve a high data transfer rate.

I have not received the sensors in the mail yet but have the board and am testing with data rates.

I will have one sensor on the SPI port, one on a UART port and one which is just a shaft encoder so it only needs to be hooked up to a counter.

I have my board plugged in and am communicating with MATLAB via the serial connection. First question is:

Once I put the baud rate up past 230kb/s I get some problems with timeouts and the data generally doesn't transfer. I thought with the spec of the chip I could acheive better data rates than that. I assume i can achieve much higher on SPI. Is it possible to use SPI over USB? Or is it possible to set the baud a lot higher over serial?

Next question I just want some reassurance. The Max32 acts as a data logger in the sense it interacts with digital sensors, stores data to SD card and also transfers via bluetooth to a PC where the data will be used. Do you guys think it will have enough power to sample the sensors around 1kHz and still be able to transfer the data?

Any other hints would be great! Got a few days till the sensors get here so just doing some research.

EmbeddedMan

Wed, 18 Dec 2013 20:12:53 +0000

There are instructions on this forum somewhere (I can't remember where, but I wrote them!) on how to get 2Mbps out of the FTDI chip on the Uno32 or Max32. And it's rock_solid. I had a client use this method for data logging over long periods and he had no glitches.

Note that if you use 'real' USB (Max32 with extra USB header, or Fubarino SD or Fubarino Mini, etc.) you get even faster transfer rates.

*Brian

mitchjp

Wed, 18 Dec 2013 23:54:59 +0000

The worst thing is I am pretty sure i remember reading it a while ago when I was looking at the board....

Oh well. Let the search begin!

mitchjp

Thu, 19 Dec 2013 00:14:03 +0000

Okay, so I found the thread you mentioned but it's already done in the mpide I have!

Which makes me think it's matlab not liking a big baud. Oh well!

Thanks anyway

EmbeddedMan

Thu, 19 Dec 2013 15:05:53 +0000

That doesn't seem right to me. Matlab shouldn't care what the baud rate is - that's handled by the USB sub-system and more directly by the FTDI chip on the MAX32 board. If you've modified your FTDI driver to accept the 2Mb rate, and you set up your sketch to use the 2Mb rate for serial I/O, all of the bytes should flow perfectly into your computer no problem.

Now if Matlab is not able to keep up with the (correct) bytes coming in from the FTDI chip, then it's time to get a faster computer! ;-)

Maybe writing a simple program on the PC to just watch the data coming in and verify that it is correct, and then write a simple sketch to send the numbers 0 through 255 and make sure every byte is received properly would confirm if the problem is in Matlab or not.

*Brian

mitchjp

Thu, 19 Dec 2013 21:41:57 +0000

Hmm Ok. I'll give that a shot this morning and let you know. The computer is not bad! i5, 4GB of ram etc etc. So I'll try work it out.

Thanks mate!

pito

Sun, 29 Dec 2013 17:40:25 +0000

With 80MHz clocked pic32mx the best (and only higher) uart's baudrate speed values are like 2500 or 1000 or 500 or 250 etc. [kilobits/sec]. The baudrate divisor is calculated as peripheral_bus_frequency/16/baudrate...

The uart baud rates have to match quite precisely (source<->destination) - within max 2% with higher speeds, afaik..

For example 921600baud leads to 5.43 - quite off to be safe.. The 5 gives you 1Mbit though. For example 2Mbits/s leads to 2.5 - also way off.. The uart will work at 2500kilobits/sec in reality with 2 (the divisor is an integer), or 1666kilobits/sec when rounded to 3.

For "typical" baud rates like 57k6, 115k2, 230k4, 430k6, 921k6.. you need a better crystal values (so called baudrate crystals), as the pic32mx does not have a "fractional uart baudrate generator" (all newer chips does), a pity :(

majenko

Sun, 29 Dec 2013 17:59:40 +0000

With 80MHz clocked pic32mx the best (and only higher) uart's baudrate speed values are like 2500 or 1000 or 500 or 250 etc. [kilobits/sec]. The baudrate divisor is calculated as peripheral_bus_frequency/16/baudrate... The uart baud rates have to match quite precisely (source<->destination). For example 921600baud leads to 5.43 - quite off to be safe.. The 5 gives you 1Mbit though. For example 2Mbits/s leads to 2.5 - also way off.. The uart will work at 2500kilobits/sec in reality with 2 (the divisor is an integer), or 1666kilobits/sec when rounded to 3. For "typical" baud rates like 57k6, 115k2, 230k4, 430k6, 921k6.. you need a better crystal values (so called baudrate crystals), as the pic32mx does not have a "fractional uart baudrate generator" (all newer chips does), a pity :(

You're forgetting BRGH...

With BRGH set to 1 the divisor is (peripheral_bus_frequency/4/baudrate)-1, and the HardwareSerial automatically uses it if the baud rate is greater than 200,000.

With that, the divisor at 2Mb is 80,000,000/4/2,000,000 - 1 = 9 That's an exact number...

pito

Sun, 29 Dec 2013 18:03:04 +0000

Ok, thanks! I've forgot the BRGH.. Surprised we have got it :roll:

mitchjp

Fri, 10 Jan 2014 05:59:15 +0000

Sorry for inactivity on the post!

So then if I say let the divisor be 20, i get baud of 952380.

This is pretty close to 921k. Off by only 3 percent.

Should i get ok data transfer?

I am playing with it but am getting weird results. I am using a bluetooth thing which can only accept standard bauds up to 921k. So I have it on 921k and on the arduino begin serial at 921k and it sends back everytime i send it a letter. (Theres a relfect code on the board). But what it sends back is consistly bumped up by 128. So if i send 'a' which is ascii 97 i'll get back 225. which is an a with the acute accent.

Thought I was getting jibberish but it is consistently offset by this amount...

ChristopheDupriez

Fri, 10 Jan 2014 10:14:02 +0000

Could it be one participant in the chain adding a parity bit? i.e. being configured as 7bits data, even (or odd) parity?

Jacob Christ

Wed, 12 Feb 2014 18:27:53 +0000

But what it sends back is consistly bumped up by 128. So if i send 'a' which is ascii 97 i'll get back 225. which is an a with the acute accent. Thought I was getting jibberish but it is consistently offset by this amount...

There are 10 bits in every 8 bit transmission: start -> 8 data bits -> stop.

The start bit is always zero, the stop bit is always one.

The 3% error stacks up, so by time you get to the 10th bit your at 30% assuming both clocks are perfect.

Serial UART data is sent LSB first and if the stop bit comes early (due to too great a difference in bit rates) it would be interpreted as a logic 1 and the idle line would look like the missing stop bit.

Try heating up one board with a hair dryer or a heat gun (at a distance) to raise the temperature 10C or 15C. See if the problem gets better or worse. Then let the board cool and do the same to the other to see if the problem gets better or worse. Heating a board will cause its clock frequency to shift a bit which may make the problem better or worse depending on if its getting closer or further from the other boards clock rate.

Also, you could try to send 225, because the MSB is 1 (same as the stop) I bet you get no errors.

Jacob