About the jerky data transfer on the Duemilanove

When trying out serial transfer speeds a while back, I noticed the data flow on the Arduino Duemilanove to be “jerky” compared tho the Arduino Uno. This held true to other boards using the FTDI chip, too. Seems, like there is an explanation for it. I came across Jan Axelson’s book Serial Port Complete (2nd ed), where it says (on page 332) that there are two situations for slow data transfer:

The first occurs when sending only very little data as the FTDI chip likes to fill it’s buffer of 62 bytes before passing them on the USB-bus. (This USB-endpoint sends packets of 62 data and 2 status bytes.) The chip has a latency timer of 16 ms, after which it sends the data regardless of the buffer’s lower byte count. [Edit: the 64 byte packet size is for full-speed USB, but high-speed USB requires 512 byte packets. (p. 345)]

The second case probably explains my problem: When receiving data at 38.75 kbps or higher, the driver holds the data until it has received 4096 bytes (or it’s latency timer has timed out) before passing it to the application.

I assume that the Arduino UNO’s serial driver just moves smaller chunks of data at a time. (Judging by source code that is provided with the Arduino environment, the USB-serial is in UNO’s case programmed on the Atmega8U2 or Atmega16U2 using LUFA.)

The book also suggests reading this app. note. It describes a few methods to adjust some latency times and buffer sizes – in windows. It also says that modem status lines can be used to flush the (FTDI’s, I assume) buffer.


Google tech talk from a couple of years back

Just found a good tech talk by registering to the InvenSense site, thus getting access to the forums. (I’ve tried to register to their site before, but this time it finally worked.) The talk is a bit discouraging regarding the part about measuring position from acceleration.

EDIT: Euler angles and quaternions start at 35:30

Book recommendations

To get a better understanding about the I2C-bus, I’ve been reading Vincent Himpe’s Mastering the I2C bus. Excellent stuff and very praxis oriented. (Two thirds of the book is dedicated to various projects you could build. The project demo PCBs are available for purchase, but they aren’t exactly cheap. Nevertheless, the book by itself was definetly worth the purchase to me.)

I also bought Mastering surface mount technology by the same author. Its light reading and covers a plethora of various topics – not just SMT stuff. (I learned about it on the EEVblog. Check out the Dave’s quick first glance review of it. The review starts about 24 min into the video.)

Based on these books, I can’t help but recommend this LabWorX series by Elektor if practical advice is your thing. Currently they’ve only published these two. I can’t wait for the topics yet to come, like the SPI-bus. (I’ve yet to test the data transfer speed on that one.)

EDIT: Nowadays, I think the book “Mastering the I2C Bus” is a little misleading when it comes to the slave’s ability to slow the bus down. The book nearly completely fails to mention clock stretching. It’s not even in the index. Many other sources – including the documentation from NXP (on page 13) – declare that that’s the way to slow the bus down. Just a thing to keep in mind! It sure got me confused, but then again, that’s pretty easy to do.

Note to self: matrices

2-D Translation (moving in the x and y direction)

|      1 ;      0  ;     0 |
|      0 ;      1  ;     0 |
| xTrans ; yTrans  ;     1 |

2-D Scaling

| xScale ;      0 ;      0 |
|      0 ; yScale ;      0 |
|      0 ;      0 ;      1 |

2-D Rotation (around the z-axis)

|  cos( angle) ; -sin( angle) ;            0 |
|  sin( angle) ;  cos( angle) ;            0 |
|            0 ;            0 ;            1 |

All of the above 2-D operations combined into one 3×3 matrix

| xScale * cos( angle); xScale * -sin( angle); xscale * -sin(angle) |
| yScale * sin( angle);  yScale * cos( angle);                    0 |
|               xTrans;                yTrans;                    1 |

…according to a game dev book, anyway. Not that these would be important to the project. This last one, call it Q, however might very well be:

2*q[0]^2-1+2*q[1]^2; 2*q[1]*q[2]-2*q[0]*q[3]; 2*q[1]*q[3]+2*q[0]*q[2]
2*q[1]*q[2]+2*q[0]*q[3]; 2*q[0]^2-1+2*q[2]^2; 2*q[2]*q[3]-2*q[0}*q[1]
2*q[1]*q[3]-2*q[9]*q[2]; 2*q[2]*q[3]+2*q[0]*q[2]; 2*q[0]^2-1+2*q[3]^2

w = Q*v, where w and v are 3×1 matrices (vectors). So far, it’s just a “note to self”.


1 – I read a book about Arduino and embedded systems by David Russell. I’ts a nice introduction to embedded systems, C and the ATmega328. It does not cover the Arduino IDE at all, but rather introduces concepts, the C-language and the microcontroller with it’s features. I guess it’s worth reading and certainly beats studying only the uC’s datasheet. It doesn’t go into detail about the I2C and SPI busses, though.

2 – Also, learned (at the local hackerspace) that quaternions are turned into something more “real” by simply throwing them against suitable rotation matrices.. This needs to be looked into. Apparently it is done all the time in computer graphics programming.

3 – Learned that Seeed Studio also does PCB manufacturing. (Click on “services”.) Looks like I’ve got to teach myself to use Eagle after all. I just hate that messy component library system. It takes ages just to find a resistor. Well, as a newbie it does, anyway.

4 – Ordered a SMD rework station.

Serial speeds on the Arduino

In the case of having to send lots of data back to a PC, I tested an Arduino UNO (rev 1) for different serial speed setups. I used this simple program on the Arduino to send running counter values and a Processing sketch to read the values and report an error it would receive a value that was out of order. After reading a forum post, I was actually a bit amazed how fast the thing could go using the Atmega8U2 as the USB-serial port. So, I also did the same measurement for an older Arduino Duemilanove which uses the FTDI-chip as the USB-serial port. This was a like the previously mentioned forum post predicted as 230400 was the maximum speed. Also, the Duemilanove’s data rate seemed “jerky” at lower speeds (although the data on the 328’s TX pin seemed to flow evenly).

Arduino Duemilanove

  • 115200 OK
  • 230400 OK
  • 250000 Failed
  • 500000 Errors
  • 1000000 Errors

Arduino UNO (rev 1)

  • 115200 OK
  • 230400 OK
  • 250000 Failed
  • 500000 OK
  • 1000000 OK

It would be interesting to know what limits the Duemilanove’s performance. Wheter it’s in the software or the FTDI interface? The FTDI-chip itself should be capable of even faster speeds than 1Mbit/sec. Go figure.