Show Posts
Pages: [1] 2 3 ... 8
1  Products / Arduino Yún / Re: Connect yun mini usb with yun USB A does not work. on: January 21, 2014, 04:00:09 pm
You can ignore that message.
It only means the USB device is just a simple serial line, not a modem.
If you connect the Yun to a linux pc, the pc will give the same error message, but you can of coarse perfectly communicate with it.
2  Products / Arduino Yún / Re: Use Yun bridge without a Yun? on: October 17, 2013, 03:20:10 pm
Ok, I did a git pull and ran from there.

Note that the overloaded function SerialBridgeClass::begin(int baud) in the new code is wrong, the baud rate must be an unsigned long for baudrates like 115200 to work. Adding just an optional baud argument like in my code snippet works also and is backward compatible too.

I observed not behavioural differences. On the Leonardo it works a bit faster than on the Duemilanove. As said, I will  try to figure out where the latencies come from. Does this run smoothly on the Yun?

3  Products / Arduino Yún / Re: Use Yun bridge without a Yun? on: October 16, 2013, 03:31:06 pm
I would not be surprised if the developers used a regular arduino and a pc to develop the bridge.

I gave it a try with a Duemilanove (I have no Uno) and a Leonardo.

When compiled for the Leonardo, the bridge library uses Serial1 (the uart), so you have to hook up a serial to usb converter to the tx (1) and rx (0) pins. Communication with the bridge goes via this extra converter. But the upside is that you have Serial free for println debugging.

When compiled for the Duemilanove, the bridge library automatically uses Serial, so communication goes via the (only) usb cable.

As suggested elsewhere in this forum I added the possibility to start the bridge with a specified baudrate. In Bridge.h I made this change:
class SerialBridgeClass : public BridgeClass {
  void begin(unsigned long baud = 250000) {
I feel more comfortable with 115200 as baudrate, so in the ConsoleRead sketch:

Upload e.g. the ConsoleRead sketch to the Duemilanove, Leonardo....

The bridge library does not set the baud rate, so you should do that yourself:
stty -F /dev/ttyUSB0 115200

Get the YunBrigde source from Arduino's git hub repository.

The avr on the Yun fires up the bridge on linino by itself, but for experimentation on the pc you can just start it manually. e.g. for the Duemilanove:
python </dev/ttyUSB0 >/dev/ttyUSB0

The bridge  will try to run the scripst /usr/bin/blink-start and /usr/bin/blink-stop. You might comment this out in, but I just installed two dummy scripts on my pc and made them executable:
echo "$0" 1>&2

In the scripts, make sure not to echo stuff (for debugging) on stdout because it will be sent to the arduino, messing up the bridge communictaion. That is what the 1>&2 is for: it makes sure echo's output ends up on stderr. Likewise if you want to do 'printf debugging' from the python scripts, don't use print, but use:
from sys import stderr
stderr.write("some string\n").

The arduino may kick out the  python script by sending it the 'XXXXX' command. Just start it again or ignore the command in

Now, in another terminal window, say telnet localhost 6571 and you should see 'Hi, what's your name?'

I did not yet manage to make it run smoothly though. If I type my name, it takes several seconds till I see 'Hi peter! Nice to meet you!'
It looks as if for every send from the arduino to the pc, there is a latency of a second or so. I want to figure out where this comes from...I have no Yun, so I don't know whether it runs smoother on a Yun. I see no reason why it would. On the Yun, there is no usb to serial converter involved but that should not be a bottle neck?. Maybe I did not yet find the magic stty settings?.
4  Products / Arduino Yún / Re: Statically linking C++ programs in Linino on: October 04, 2013, 04:14:17 pm
Long time ago I had to do the same thing, on a much different platform. There may be more sophisticated solutions, but I simply renamed the* files, such that the linker does not find them. The linker will fallback to linking statically against the corresponding .a files. Other libs will still be linked dynamically,   

Are you sure this still is relevant? I have no Yun so I don't know whether all packages you install ends up in the flash or on the micro sd card. If you can put it on the micro sd, I would just use On the other hand, I built linino and searched for elf images needing libstdc++, there are indeed only a few that do.
5  Products / Arduino Yún / Re: Connecting a arduino to Linino on: September 17, 2013, 03:02:56 pm
Is an udev rule needed for this? (Don't know for the yun). But if one is needed, it must match the vid/pid and module name of the duemilanove's ftdi:
BUS=="usb", SYSFS{idVendor}=="0403", SYSFS{idProduct}=="6001", RUN+="/sbin/modprobe ftdi_sio"
6  Products / Arduino Due / Re: atmega16u2 bootloader not working on: September 03, 2013, 03:37:56 pm
To verify whether the flash content is identical to the that of a given hex file you can use avrdude:
specify the given hex file, and as memory operation specify v for verify, like this:
... -U flash:v:path_to_hex_file.hex:i

This avoids the problem that avrdude writes the hex file with a different record length compared to the hex file produced by building the bootloader.

That said, if anyone can suggest a good (linux) utility to convert intel hex to binary, I would be interested. (so you could just compare two differently formatted hex files).
7  Products / Arduino Due / Suggestions for SPI api on: June 24, 2013, 03:36:33 pm
I noticed one is working on the SPI api's. I thought this is the moment to post some remarks.

1. Both SPI begin() api's, reset the data mode, bit order and divider to their defaults. This invalidates any previous calls to setDataMode(), setBitOrder() and setClockDivider(). The doc does not state that you should call these setters after begin(), and that would be counter intuitive too. Also there is avr code out there that calls the setters before begin(). Better would be to have begin() set data mode and friends from the values recorded in the mode[], ... data fields. (and initialize these correctly).
2. I find the following a bit counter intuitive:
static const uint8_t SS   = BOARD_SPI_SS0;

I relate the names MISO, MOSI and SCK to SS and therefore I would expect that e.g. SPI.setBitorder(SS, order) is the as SPI.setBitOrder(order), which is not the case.

I would suggest this:
static const uint8_t SS0   = BOARD_SPI_SS0;
static const uint8_t SS  = BOARD_SPI_DEFAULT_SS ;
(I know it would break some sketches, but now it can still be changed)
3. What about two macro's:
for sam:
#define SPI_CLOCK_MIN 1
#define SPI_CLOCK_MAX 255
for avr:

Nothing world shocking but a sketch that just wants to be conservative could use SPI_CLOCK_MAX ant that would compile for sam and avr.

8  Products / Arduino Due / Re: Data loss when sending to native USB port (SerialUSB) on: June 16, 2013, 04:17:35 pm
Did you replace the three files  Stimmer attached to his post?
9  Using Arduino / Microcontrollers / Re: Comparing crunching power or serial troughput of Uno and Micro boards on: June 14, 2013, 04:12:38 pm
Interesting, I did not know the max baudrate is that high, but it is indeed ok with the datasheet.

Time is easily lost if at some point in the chain the arrival of data is not noticed soon enough or not forwarded immediately.
This can be anywhere in the chain: pc -> 16u2 usb -> 16u2 uart -> 328 uart (HardwareSerial.cpp) -> sketch -> 328 uart -> 16u2 uart -> 16u2 usb -> pc

The 328p uart (HardwareSerial.cpp) parts looks ok to me.
The sketch: do you use flush() when sending? Do you use write()?
I would certainly also check out the 16u2 firmware.

What transfer rates do you achieve with my sketch, at 1M baud? Even for this one directional test the chain is already rather long.

I don't have an Uno but can do tests with my Due.
Maybe post your test?
10  Using Arduino / Microcontrollers / Re: Comparing crunching power or serial troughput of Uno and Micro boards on: June 14, 2013, 01:17:53 pm
I think there are errors in the sketch you uploaded because it doesn't make use of the parameter chunk_size.
Doooooh! Thanks for pointing this out. I edited the post to correct the sketch.

10 bytes per msec is 10,000 per second which, I think, is about what one would expect at 115200 baud.
Sure. That is normal for an Uno, its uart is the limit. But this thread is about the difference in throughput between a classic arduino and one with native usb (Leonardo, Micro, ... Teensy).

though I want to send and receive data.
Ok, but I first want to check out the send path, the receive part  (of coarse)  follows a completely different code path.

11  Using Arduino / Microcontrollers / Re: Comparing crunching power or serial troughput of Uno and Micro boards on: June 13, 2013, 03:57:21 pm
I wonder how usb serial port speed compares to the teensy implementation, which is completely different.
Would a teensy owner care to run the test sketch below on a teensy?

Or can I run a sketch comiled for teensy2.0 on my leonardo? Since this sketch needs only the usb controller, no other pins ... I thought this should work and uploaded the hex file as is to my Leo. The sketch seems not to run, well the device is not enumerated...

Here is the sketch. On a Leo it prints results like this:

Leonardo, chunk size 16, sent 4096 bytes in 84 millis (46)KBpsec
Leonardo, chunk size 64, sent 4096 bytes in 74 millis (53)KBpsec

#define DATA_SIZE  4096

void setup() {
 //Initialize serial and wait for port to open:
  while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only

void loop() {
  Serial.println("*** HEADER ***");

#ifdef __AVR_ATmega32U4__
  static const char model[] = "Teensy 2.0";
  static const char model[] = "Leonardo";
  static const char model[] = "not an atmega32u4";

void test(unsigned int chunk_size) {
  unsigned long t0, t1;
  unsigned int i;
  t0 = millis();
  for (i=0; i<(DATA_SIZE/chunk_size); i++) {
    unsigned char j;
    for (j='!'; j < '!' + chunk_size - 1; j++)
  t1 = millis();
  Serial.print(", chunk size ");
  Serial.print(", sent ");
  Serial.print(" bytes in ");
  Serial.print(" millis (");
  Serial.print(  ((DATA_SIZE / (t1 - t0))  * 1000u) / 1024u );

12  Using Arduino / Microcontrollers / Re: Due as ISP Programmer for Leonardo/AtMega32u4 on: June 11, 2013, 03:59:16 pm
Allow me to come up with a solution for what was once the subject of this thread: "Due as ISP Programmer for Leonardo/AtMega32u4":
13  Using Arduino / Microcontrollers / Re: ArduinoISP on Arduino DUE on: June 11, 2013, 03:48:12 pm
It works pretty stable now. I have an ArduinoISP sketch that runs out of the box on the Due. There is a mini howto here:
14  Using Arduino / Microcontrollers / Re: Comparing crunching power or serial troughput of Uno and Micro boards on: June 10, 2013, 04:09:16 pm
I did some measurements with a (borrowed) usb analyzer. I took the ASCIITable example, changed the baudrate to 115200, compiled it with ide 1.0.5 and uploaded it to a Duemilanove and a Leonardo. (It is a pity I don't have an Uno). 

The dataflow looks like this:

The Duemilanove sends 4974 bytes in 368 msec (13.52KBps). About every msec ~14 bytes get sent.
(The duemilanove has to send more data because the ftdi protocol sends two bytes protocol header upon every chunk of data. So the 14 bytes are only 12 bytes useful payload)

The Leonardo sends 4224 bytes in 151 msec (27.14KBps). About every msec ~30 bytes get sent.

So the native USB is indeed faster, but not spectacularly and nohere near the theoretical upperbound of 12Mbps. 

But actually I expected even worse, I noticed the code in CDC.cpp sends out one byte at a time, but fortunately the lower level puts the single bytes into the hw fifo. When the fifo is full, it gets send out as one chunk over USB.

The chunks are 64 bytes (max packet size) (not 256). No idea why I see only 30 bytes. Will do a test sending out 1 byte in loop to avoid effects/delays imposed by formatting code...

More importantly the fifo is flushed only once per frame of1 msec. The analyzer shows that the host is polling ~75 times more for new data during the rest of the frame...  I think this is the first place to look for improvements
15  Using Arduino / Microcontrollers / Re: Comparing crunching power or serial troughput of Uno and Micro boards on: June 07, 2013, 02:50:06 pm
On the other hand, using the micro's native USB there is no real uart in the game that is normally the bottleneck.

I think the core's implementation for sending from the arduino is simple but not optimized. WIth a little tweaking I expect this can be made much faster than the classic uart.

Can you tell us how at what pace data becomes available, and how many bytes it are? Then with a simple sketch we could measure performance difference real uart versus virtual com port over native usb.

Pages: [1] 2 3 ... 8