Max data rate from PSI to uart to USB COM port

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

i am using one ATMEGA3209(master) to read 32x other ATMEGAS(slaves), each with its own SS pin, with all Atmegas runnign at 20 MHz.

I read the slaves via SPI and then the master Atmega compiles a packet of 800 Bytes(each slave sends 25Bytes per read) and sends it out via UART to a serial to USB cable from FTDI(384 KBps), as many times per second as possible.

I am running SPI on f_cpu/4(which should give me 610 KBps) and UART at 921600 bps (112 KB/s). 

At the moment i am receiving on COM port 67 KBps, using Tera Term software, so around 84 packets/reads per second. I realize there is also some time wasted while the MASTER sets SS lane of each individual and while slave responds.

 

Now i wish to reach around 250-400 packets/reads per second(200-320 KBps) which should be possible with SPI, but not with serial connection, so i will change the MASTER mcu from Atmega3209 to a SAM D21 (runnign at 48MHz), so then  the D21 will read all slaves via SPI and then output data via USB peripheral (at max 1464 KBps) to PC directly. And if i also push the SPI speed a little, while sacrificing data integrity, i may increase packets per second greatly.

The ultimate solution would be to also change all slaves to D21 in which case i could use 50-100% faster SPI and achive up to 1000 packets per second (800 KBps).

 

Anyone has any other advice how to increase the data throughput? With the D21 as master and AtMega3209 as slaves, the bottleneck looks to be on the SPI.  

Thanks in advance for your opinions :D (and yes i know 32 atmega slaves is a lot :P )

 

Update1: After checking SAM D21 prices and power consumption, i decided i will change all Atmegas to SAM D21 runnig at 48MHz and have around 15% lower power consumption and having much higher data throughput.

This topic has a solution.

Last Edited: Tue. Sep 10, 2019 - 12:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I’d be rethinking the architecture, before trying to up the datarate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you be a little more specific please? By architecture you mean design or you mean AVR vs ARM?

Last Edited: Tue. Sep 10, 2019 - 06:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you know that the FTDI cable isn't limiting the throughput?

Also, TeraTerm may limit the transfer rate.

 

Have you written a test program having the ATMEGA3209 stream a fixed string to the cable,

and if so, did you get the 384 KBps? 

 

What kind of flow control (if any) is used between the ATMEGA3209 and the cable?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The cpu architecture is irrelevant.  The architecture of your hardware would seem to create more problems than it solves. Why have 30+ slaves? Then there's the problem of signal integrity with the spi and the associated loads. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

thanks for idea, i will set the atmega to output continuous stream and test max speed i can reach. No control is being used, since data is not that critical and one missing/corrupted byte here and there is not a big problem. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hardware is designed as best as it can be at this point, i also consulted with high speed communication PCB designer specialist and we did many tweaks, also checked every load capacitance, had all the hardware checked in controlled environment and hardware is running at 100%. All MISO and SCK lines look picture perfect on oscilloscope, sharp edges, no overshoots.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now i did as you suggested, using test program on MASTER, just outputting continuous stream of same byte over and over again, and got to 108 KBps, which is almost max baud rate. So now i see i lose around 30% of baud due to time it takes to read all SPI slaves. So with all MCUs being replaced by SAM D21 running at 48MHz, which will increase SPI speed from 5MHz to 12MHz and also enabling fast swtihcing times, tte final speed will be around the desired one :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Klemko wrote:
which will increase SPI speed from 5MHz to 12MHz
But you said the thirty slaves were 20MHz ATmegas? Can a 20MHz AVR really run the SPI at 12MHz ?? I thought the theoretical speed limit on SPI was F_CPU/4 which would be 5MHz.

 

So how does changing the core CPU from AVR to ARM help?

 

As Kartman said above this whole architecture appears to be flawed. You can't just tweak small parts of it and expect miracles, it seems to me the entire system needs to be redesigned and the use of thirty slaves sounds very suspicious - couldn't whatever it is they are doing (presumably reading loads of IO) be conglomerated into fewer, higher pin count chips? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck99 wrote:
How do you know that the FTDI cable isn't limiting the throughput?

Good point, but genuine FTDI chips can do 921600 bps.

 

Chuck99 wrote:
Also, TeraTerm may limit the transfer rate

Also worth checking - though I wouldn't have thought it should be a problem ...

 

The PC itself may also be a limiting factor ...

 

But, as others have said, the issues may be more fundamental ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, i managed to solder an D21 to the pads of MASTER, with a bit of resoldering and manua lfixes, now with using the native USB output on the SAM D21 i am achieving around 400KBps with at least 98% data integrity, which results to around 450 packets/read per second. I am really happy with this, but i wil lstill design new PCB with all MCUS being SAM D21 to make it even better, while also reducing power consumption a bit :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You’ve passed two stop signs.... it takes 3 steps for a f-cup.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what is f-cup? cant find anything on google but some stuff about bra sizes :P

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Good point, but genuine FTDI chips can do 921600 bps.
MaxLinear USB UART exceed that.

awneil wrote:
The PC itself may also be a limiting factor ...
PC's OS is a factor though reasonable.

 


https://www.avrfreaks.net/forum/ftdi-and-prolificonly-two-games-town#comment-1753446

USB UARTs - MaxLinear

C code for Teensy: USB Serial

[bottom]

Transmit Bandwidth Benchmark

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also without changing anything on hardware part, when reading and logging COM port with Tera term i got 80kBps and reading identical stuff with Terminal window from Atmel studio i got 180KBps. Sooooooo now i will jsut plug in ttl to usb cable into usb port and will read actual data rate with osciloscope.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Klemko wrote:

Ok, i managed to solder an D21 to the pads of MASTER, with a bit of resoldering and manua lfixes, now with using the native USB output on the SAM D21 i am achieving around 400KBps with at least 98% data integrity, which results to around 450 packets/read per second. I am really happy with this, but i wil lstill design new PCB with all MCUS being SAM D21 to make it even better, while also reducing power consumption a bit :D

 

This not a solution....more like throwing a Ferrari V-8 into a YUGO.  Sure it works, but for how long?

 

Are these 'slaves' scattered about a factory floor or are they all on one PC board?  Can you provide the datasheet so we can maybe provide a better solution to you?

 

 

Kartman wrote:
You’ve passed two stop signs.... it takes 3 steps for a f-cup.

I too, am very curious about this one as well. cool  I have an idea what it means....but better to hear it from the author

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Tue. Sep 10, 2019 - 03:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Y'all do know what FUBAR means? Extrapolate.

 

(or maybe just replace the hyphen with a u ?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
'all do know what FUBAR means? Extrapolate.

 

Exactly, but with Kartman.....one should NEVER assume...Kinda like Lee

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
maybe just replace the hyphen with a u ?

doesn't that still leave a letter missing ... ?

 

cheeky

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Klemko wrote:
So now i see i lose around 30% of baud due to time it takes to read all SPI slaves.

 

So you are not sending chars to the UART when reading data from the SPI devices?

 

Another approach is to use a circular buffer for UART Tx chars and have an ISR feed chars from the buffer to the UART.

Each time you read data from a SPI slave you write the data to the Tx buffer.

This way the ISR is sending data to the UART while you're reading data from the next SPI slave.

 

Take a look at Lightweight Ring Buffer Library (Link) from abcminiuser.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Gents, I've probably come across a bit too harsh with Mr Klemko. Over my career, I've been involved in a number of major screwups - some of my own doing, of which I was 'johnny on the spot' that had to fix it. Through this, I've gathered a bit of a 'sixth sense' for things that look like they're not going to go quite to plan.

 

Whilst I don't know the details of what Mr Klemko is wanting to do, what rung warning bells for me was:

 

1. 30 slaves  

2. data rate issues

3. data rate issues over USB

4. going to a 'faster' processor to 'solve' the problem.

 

The first 'stop sign' for me was that the current design has data rate issues. I've lost count of the times where myself or others have pressed ahead with something that was , in retrospect, a bad idea. 

With USB especially when using usb->serial is there's a difference between aggregate data rate and burst data rate. Usually you're at the mercy of what Windows wants to do and the machinations of USB itself. So if the design requires a constant high data rate, you're probably not going to get what you want - you'll need some form of fifo greater than what the usb->serial chip will give you.

 

Next is 30 slaves - seems there's a fair overhead in managing these. Making everything faster probably want make this overhead any better. It's like managing 30 people - some may work, some may not, some may work faster than others etc. Firmware updates won't be trivial.

 

Cliff and I highlighted this - this is the second 'stop sign'. Whether it's the voice inside your head or others telling you - maybe it's the time to stop and reconsider exactly what you want and re-design.

 

When I've had to do an autopsy on a failed project I see the same causes repeated - 

1. a decision was made for what seems to be valid reasons

2. problems are found

3. an attempt to work around the problems creates more problems

4. rinse and repeat until you give up or you run out of time.

 

The 'reasons' are usually in order 'to save time'. The solution is to take what you learnt from the mistakes and do what you should've done in the first place. I've had to slap myself many times. Unfortunately this knowlege doesn't stop me from making mistakes, but hopefully I realise when I'm falling into a trap.

 

To solve the mystery - 'f-cup' is a double entendre. Say it quickly with the f as 'faaar' and you should get what I mean. The other interpretation has been noted by Mr Klemko.

 

As for the 'three steps'  - see above.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks you for these detailed response and clearing some stuff up.

 

To elaborate further what i am actually doing. All the slave are on 1 pcb (400x400mm, 6layers) and the PCB as a whole is measuring 450 to 950 parameters (digital, analog,...) according to what user connects.  All the parameters are highly time sensitive, so the easiest way of achieving that is by having multiples slaves, each measuring and time logging around 25 parameters on its own. I could use multiplexers or a similar solution, but since many of these parameters also require a lot of math and processing done, it is better to use several slaves for that.

The reason why i switched to SAM D21G18A as master is its ability to rearrange all the data it gets from salves into a sensible packet at a much higher rate then an atmega3209 and sends it out via USB. The reason i went with USB is its higher data rate and also an elimination of uart to usb cable or chip. 

The ONLY reason i am changing all the other slaves to SAM D21 is to reduce power consumption (atm it is around 0.5 A at 5 V, then it will be around 0.2 - 0.3 A).

At this point the data stream coming out of PCB is 405KBps to 810KBps, depending on what settings the user selects (project demand was 400KBps or more, with 720KBps max that will ever be needed).

 

The data on the PC side is loaded into custom developed application which was designed specifically for this project and is capable of receiving and processing up to 2MBps of data. The PCB itself was running for 2 days straight now while i was away and today i was happy to see only less then 0.2% of total received bytes corrupted :D 

 

And you are correct, software updates will be a hassle, that was one of reasons why at first i went with AtMega-0 series and its UPDI single wire interface, but now the software running on slaves is highly costum-able via the parameters that the master can set via SPI commands, so basically, only the MASTER will have to be update, which can be done via USB interface pretty easy.

Last Edited: Thu. Sep 12, 2019 - 08:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rather than spi, how about USB hub chips?
Two layer topology? Four groups of samd21 to a 4 port usb hub chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for great idea.  So i should connect 4 groups of 8 slaves, each to one 8-way usb hub chip and connenct those 4 usb hub chips to one hub which goes into my main? I am kinda worried about additional power consumption, need to do some datasheet diving to check what is on market :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What i was thinking is:
Usb->master-> spi 7 slaves
Times 4
This means less load on each spi bus and a higher aggregate data rate. Usb then becomes the limiting factor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahha so 4 masters, each reading 7 slaves, and one usb 4 port chip.  Really elegant solution.

 

At the moment i am pretty much finished with a PCB with 1 master(SAMD21) that has 4 SPI peripherals(8 slaves(also SAMD21) per 1 SPI) outputting to USB. 

After i get it assembled and tested, if i have to further data throughput, i will try your suggestion.

 

Thanks a lot :D