current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Arduino Stack Exchange is a question and answer site for developers of open-source hardware and software that is compatible with Arduino. It's 100% free, no registration required.
up vote 0 down vote favorite

I've been communicating with a teensy arduino over USB using pySerial--which has been simple, but slow. With simple write commands from Python and a corresponding read command on the teensy, I can only achieve 200kHz transfer rates. I'm hoping to get over 1MHz at least, but I don't see a path towards that rate.

Are Ethernet shields capable of augmenting for rates over the MHz range? How can I get faster data transfer rates between my computer and arduino? I'm mainly interested in one-way communications (computer directs teensy).

share|improve this question
    
You can't communicate faster than the MCU can respond. –  Ignacio Vazquez-Abrams Aug 18 at 23:32
    
@ignacio what is the MCU? –  nick_name Aug 18 at 23:34
    
With simple write commands from Python and a corresponding read command on the teensy, I can only achieve 200kHz transfer rates. - is this serial comms we are talking about? What are you planning to do with the Teensy that it needs to be told to do something at 1 MHz? –  Nick Gammon Aug 19 at 0:17
    
I'm configuring hundreds of analog nodes over SPI buses. –  nick_name Aug 19 at 1:32
    
@nick_name the MCU is the microcontroller unit. The brain. That black square-shaped plastic thing on the Teensy with all the little legs. On the Teensy 3.1 it's the MK20DX256, part of the Freescale K20 series, if you need to know. It can run at up to 96MHz (on the Teensy), so receiving data at speeds in MHz+ won't be a problem. –  CharlieHanson Aug 20 at 23:13

2 Answers 2

up vote 3 down vote accepted

The fastest means of communicating with the Arduino is SPI. Ethernet shields use that (as do SD cards). It's quite fast, but it has limits. The fastest the SPI clock can go is the CPU (MCU) clock rate divided by 2 (per bit), that is one byte every 16 CPU clock cycles. There is also an overhead of a couple of clock cycles between bytes, so you can reckon on 888,888 bytes absolute maximum (ie. about 868 kHz) on an Arduino running at 16 MHz.

However that's just throwing the data away. It needs to be stored somewhere, compared to something, acted upon. That all takes clock cycles.

That is for the 16 MHz Arduinos. The Teensy 3.1 apparently runs at 72 MHz which is somewhat faster. I haven't timed SPI on that, presumably you can get a faster transmission rate, but I suspect that the ARM processors also take more instructions to do the same thing, so the 72 MHz might not be quite as fast as it looks.

Then you have the issue of how fast you can get data in and out of the Ethernet card, and how fast you can do whatever-it-is you want to do with it, in the processor.

share|improve this answer
    
Thank you for the detailed response! Right, so an Ethernet shield using an SPI interface is going to be best then. I'm curious--does the Ethernet transmission protocol that would link the computer and arduino support these rates, or would I be bottlenecked there? –  nick_name Aug 19 at 1:34
1  
I can't really answer that. It would depend on the Ethernet card, the library driving the card, quite possibly what your router can handle, and what the PC Ethernet card can handle. Plus, of course, the speed of communication between the Arduino and the Ethernet card, and how much time you spend doing something with the data once you get it. –  Nick Gammon Aug 19 at 2:58
up vote 1 down vote

First of all, khz and mhz are not data transfer rates. They are frequencies - "something per second" - did you mean kilobits/second or kilobytes/second (both, confusingly, abbreviated to kbps by various people).

If you have not already done so, you can specify a bitrate for your communications - serial.begin takes a parameter which specifies the speed - most example seem to use 9600 bits/second, you can crank this all the way up to 115,200 bits/second - 12 times the speed. I don't know if this will work with a Teensy, and/or USB. You will probably at least need to specify this in your terminal program and/or pySerial.

I wonder what you are doing that requires 1Mbyte/second communication with an Arduino, and if you can do that a little smarter?

At that rate, the 64kbytes of memory can be filled up in 1/16th of a second.

You can get a faster "information transfer" by increasing the information density - for example, the English word "True" takes up 4 characters = 32 bits , but a logical true value only takes up 1 bit.

If you are processing the data on the Arduino, at 1mbyte/second, you have 72 instructions to do something with that byte before the next one is there - not much time.

You could increase the data rate by pushing the data in in parallel, using multiple pins - e.g. 32 bits in parallel, one on each of 32 pins, one data point per cycle. There would be no practical way to assimilate data at that speed.

If you are sending this from a PC, perhaps some of the data could be processed on the PC before sending?

Another option would be to divide the work over multiple Teensies, with the PC combining the work - e.g. if you have temperature sensors that output 4 byte values, you want to read 250 of them at a rate of 1000 samples per second (= total of 1mbyte/second), then you might be able to run 25 Teensies, each sampling 10 sensors, and each pushing data at 40kbytes/second, rather than one running at 1mbyte/second.

Quite frankly, these are all fairly contrived examples - most sensors can't be read that quickly; even an Arduino's analog read is limited to 10,000 reads per second - if you do nothing else. This produces 100 kbits/second, or 20kbytes per second (each 10-bit read is returned as two bytes, with the remaining 6 bits being 0).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.