Show Posts
Pages: 1 2 [3] 4 5
31  Products / Arduino Due / Re: DUE ethernet performance on W5200 with SPI and SPI+DMA on: December 30, 2012, 08:49:46 pm
I've added the SPI+DMA w5200 Ethernet results to git link below.  With DMA and SPI clock at 28 MHz, one gets nearly 16 million bits/second, about 3 times the SPI-only performance.  The file w5100.cpp.dma1 is the modified version of w5100.cpp that supports w5200 and DMA+SPI.  Results are in wizperf.txt at

DMA code is modified from fat16lib's SD work.
32  Products / Arduino Due / Re: Tone function does not work with Arduino Due in arduino-1.5.1r2 on: December 29, 2012, 12:30:41 pm
If you want to build your own, a proof-of-concept sketch for Tone can be found at,136500.msg1029238.html#msg1029238
33  Products / Arduino Due / DUE ethernet performance on W5200 with SPI and SPI+DMA on: December 26, 2012, 09:18:25 am
Most of the older Ethernet shields have the wiznet w5100  chip.  I have a wiznet WIZ820io with the newer w5200 chip. The w5200 has 32KB of buffers (vs 16KB on w5100), and will run at up to 33.3mbs (megabits/second) over SPI (0.3mbs on w5100).  I added the support mods for the W5200 to w5100.cpp and w5100.h in  hardware/arduino/sam/libraries/Ethernet/utility/.  There is also a minor/optional modification to Ethernet.h. Those updated files and early performance results (wizperf.txt) can be found at

Simple UDP tests included 8-byte echo latency (microseconds), UDP 1000-byte packet sends from DUE, and lossless receive rate for 1000-byte UDP packets.  The wiznet chip devotes 2048 bytes to each send and receive buffer (per socket).  UDP is a lossy protocol.  TCP will typically be slower, but it is reliable and adapts to available bandwidth.

Results include tests on the UNO and maple.  On the maple and DUE, one can test SPI+DMA. The wiznet site only guarantees 33.3mbs SPI performance for the W5200.  I got reliable results at SPI speeds of 28MHz, but errors at 42MHz.  The DMA network tests for the DUE are still in progress and will be posted later on this thread at the git URL above.
34  Products / Arduino Due / Re: using DMA for memory-to-memory on: December 22, 2012, 03:56:43 pm
Ah, thanks.  Those changes do speed things up.  I made another sketch, mem2mem2.ino, to test DUEling memcpy's.  I added DMA interrupt to sketch and altered the DMA memcpy32() to run asynchronously.  I then let the DMA memcpy battle with the library memcpy() by starting up the DMA memcpy32() and immediately starting up the library memcpy(), operating on two separate src/dst 1024 32-bit word vectors.

The DMA copy won the DUEl, finishing first in 34us, and the memcpy() took 80us, total elapsed time 82us.  Using SRAM1 for one of the src/dst pairs, resulted in the DMA running in 33us and the memcpy() took 60us, with total elapsed time of 70us.

For the maple, the memcpy() finished first (64us) and the DMA took 122us.

I don't know what magic the DUE MATRIX might provide...

mem2mem2.ino can be found in my DUEZoo
35  Products / Arduino Due / using DMA for memory-to-memory on: December 21, 2012, 04:59:40 pm
You can do a memory-to-memory transfer under control of the DUE DMA, though I'm not sure why you'd want to because memcpy() is faster!  Here is simple sketch that compares a DMA memcpy (called memcpy32()) and memset (memset32()) to the library memcpy/memset and a for-loop (dst=src) for 32-bit words.

Earlier, did the same thing on a maple (72Mhz), here are times in microseconds for 1000 32-bit words

               maple    DUE  
       loop     269    132            for loop
       memcpy32  93     68         DMA
       memcpy    62     56
       memset32  94     69         DMA
       memset    38     41

Looking at the dis-assembled memcpy()  for the DUE sketch, you get an unrolled loop (64) of
and  version 1.20 of newlib actually has an ARM memcpy.S that has an unrolled loop with
36  Products / Arduino Due / TinyGPS with EM-406A working, pps frequency check on: December 20, 2012, 02:23:54 pm
I got TinyGPS (v12) to work with DUE.   GPS EM-406A is 5v, but spec and scope show TX and pps output are only 2.85v, so no need for level converters.  For IDE 1.5 to see the TinyGPS library I had to rename Examples/ to examples/.  All three examples worked, replaced SoftwareSerial with Serial1, and for static_test sketch I had to neuter the PROGMEM stuff.

You don't even need the TinyGPS lib to test the pulse-per-second output (1 microsecond accuracy).  I hooked the pps output to a DUE digital port and used attachInterrupt() (required IDE 1.5.1) witht a micros() timestamp, and used that to measure the clock frequency of the DUE.  The simple gpspps sketch and results can be viewed at
37  Products / Arduino Due / Re: Due and ethernet processing speed on: December 20, 2012, 09:57:50 am
Check the specs on the Ether device on your shield.  I assume it's the wiznet W5100, and its SPI speed will be the limiting factor. I have a standalone W5200 and its SPI speeds are better (see Maple results in my table in earlier post in this thread), though I had to hack in DMA/SPI to get the best results on the Maple.  (It's on my TODO list for DUE).  The processor on the DUE has a builtin in Ether controller, but you'll have to wait for another kind of Arduino board that breaks those Ether IOs out -- and then you will need a lot of code/memory to do the TCP/IP protocols ... which is why  the wiznet critters are attractive.
38  Products / Arduino Due / Re: Due and ethernet processing speed on: December 20, 2012, 09:17:00 am
I'm not familiar with the exact details of the shield you are using, but the W5100 ether module typically can buffer 3 or 4 1K byte packets at close to wire speeds, but  the interface to the UNO is via a much slower SPI, so if your SPI can't keep up, UDP packets will be dropped in the ether module.  If you want sustained, lossless UDP, you will have to throttle down your remote transmitting device to run at the much slower SPI speeds.  You can experiment with various delays between packets on your remote transmitter to see what works on your receiving Arduino.  TCP might be a better choice (just as slow or slower) but it adapts to available bandwidth and is reliable.
39  Products / Arduino Due / Re: DUE I2C speed on: December 20, 2012, 08:56:20 am
My tests of read/write on an I2C EEPROM are about the same for UNO and DUE at 100KHz and 400KHz.  Here are read/write times in microseconds for small block read/writes.


  arduino uno  100KHz    400KHz    DUE  100Khz      400Khz
Bytes   write   read    write  read    write read   write read (microseconds)
10       1340   1480    1112  1176      1197 3124    775   339
20       2340   2500     780   840      2104 3124    775   573
30       3360   3512     448   504      3014 3127    775   806
 maple      100KHz        400KHz
Bytes   write   read      write  read   (microseconds)
10       1193   1306        308   336
20       2095   2202        535   561
30       2997   3100        761   791

Beaglebone  I2C @ 100Khz
bytes   write   read   (microseconds)
10       1320   1669
20       2245   2559
30       3128   3374

 Raspberry Pi  I2C @ 100KHz
10       1268    1449
20       2185    2357
30       3074    3268

With the DUE, you have to restart the IDE if you modify library settings, e.g. TWI_CLOCK in  hardware/arduino/sam/libraries/Wire/Wire.h
40  Products / Arduino Due / Re: Due and ethernet processing speed on: December 20, 2012, 08:26:09 am
network speed will depend on the chip on the Ether shield and SPI speeds.  The older w5100 ethernet module doesn't have a burst read/write mode so software has to do extra SPI transfers for each byte transferred.  On the UNO, with SPI at 4MHz, I measured data rate of only 0.38mbs (megabits/second) for the W5100, whereas in burst mode (e.g. for w5200), I  got 2.6mbs. Running the SPI at 8 MHz, I got  .46/3.8 mbs (w5100/w5200).

For the leaflabs maple here are results for W5200, with different SPI speeds and using DMA with SPI

clock(MHz)          SPI       SPI+DMA
 1.125             .7 mbs        .9mbs
 2.25            1.3mbs         1.8
 4.5              1.6mbs         3.3
  9                1.9mbs         5.5
18                1.9mbs         7.8

I haven't had a chance to perform DUE  W5200 tests ....

UDP is capable of near wire speeds (for 10mbs and 100mbs ethers) from big-computer network controllers, but it can be an unreliable protocol over the Internet (packets can arrive out of order, duplicated, lost, or with errors).
41  Products / Arduino Due / Re: attachInterrupt on: December 19, 2012, 01:25:06 pm
Never mind, problem was with IDE 1.5, works with IDE 1.5.1 (though it didn't like my hardware/ folder).
So sketch is working now, and I can use EM-406A GPS pps to measure frequency of DUE clock/crystal and get measurements consistent with using an NTP host as frequency reference. The Sparkfun EM-406A operates at 5v, but specs and scope show TX and pps are at 2.8v so no level conversion needed.  Frequency results and various sketches at
42  Products / Arduino Due / attachInterrupt on: December 19, 2012, 12:58:22 pm
I have a 2.8v pulse (1us width) every second on pin 7 (I can see it on scope) and Maple and Uno version work, but
I get no hits in the interrupt handler on the DUE with the following sketch.  What am I missing?

// gpspps

volatile unsigned long us;
volatile int tick=0;

void handler() {
us = micros();

void setup() {

void loop() {
    static unsigned long prev = 0;
    unsigned long t;
    char str[32];
if (tick)  {
            t= us-prev;
            sprintf(str,"%ld us  %ld ppm",t,t-1000000);
43  Using Arduino / Microcontrollers / Re: Poor clock accuracy of UNO on: December 17, 2012, 04:15:59 pm
Here is another nice study of affect of temperature on crystal and resonator using GPS pps, fyi
44  Using Arduino / Microcontrollers / Re: Poor clock accuracy of UNO on: December 16, 2012, 06:10:34 pm
In the crystals.txt file in the git link below you will find some frequency measurements of crystals, resonators, and RC oscillators showing OSCCAL values over several chips and at different voltage levels.
45  Development / Other Hardware Development / Re: Resonator Vs Crystal Vs Internal Resonator on: December 16, 2012, 06:05:42 pm
In the crystals.txt file in the git link below you will find some frequency measurements for crystals, resonators, and RC oscillators, including variations on OSCCAL.
Pages: 1 2 [3] 4 5