Show Posts
Pages: 1 2 [3] 4 5 6
31  Products / Arduino Due / Re: OneWire in Due on: January 10, 2013, 01:29:21 pm
my select() in OneWire.cpp follows.  I'll let you be master of your library source.  thanks

Code:
void OneWire::select( uint8_t rom[8])
{
    int i;

    write(0x55);           // Choose ROM
    delay(1); // thd

    for( i = 0; i < 8; i++) {
        write(rom[i]);
        delay(1);  // thd
    }
}


32  Products / Arduino Due / Re: OneWire in Due on: January 10, 2013, 01:12:36 pm
your sketch, seemed to work consistently with or without delay(1);

the Examples was bad every other query without the delay(1) using ds.skip()

I got Examples to work by adding delay(1) between every write in the select() function in OneWire.cpp,
and no delay(1) in the Examples sketch

I had also tried delayMicroseconds in select() with no luck, so I switched to delay(1); but presumably something
shorter than a millisecond might work ... sort of hit and miss.
33  Products / Arduino Due / Re: OneWire in Due on: January 10, 2013, 12:43:27 pm
I tested your lib and sketch on linux with IDE 1.5.1 (didn't compile with 1.5).  I edited OneWire.h as suggested.  Sketch worked.  Also tested with no   delay(1);  -- still worked.

I tested the Examples>OneWire>DS18x20_Temperature.  It would work if I replaced ds.select(addr); with ds.skip();  With delay(1);'s it worked each query.  With no delay(1); every other query would return Data with FFs

Code:
    ROM = 28 86 42 5B 3 0 0 84
        Chip = DS18B20
        Data = 1 82 1 4B 46 7F FF E 10 70  CRC=70
        Temperature = 24.12 Celsius, 75.43 Fahrenheit
        No more addresses.


In a later experiment, I got the Example to work by adding delay(1);'s in the ds.select() function  in OneWire.cpp
34  Products / Arduino Due / Re: unconnected SPI performance -- library vs DMA on: January 01, 2013, 05:13:15 pm
I added performance results for the DUE's "extended" SPI mode.  For the unconnected tests, the extended mode is faster than the older SPI  API.  See  SPIperf.txt on the git site below

   https://github.com/manitou48/DUEZoo
35  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

   https://github.com/manitou48/DUEZoo

DMA code is modified from fat16lib's SD work.
36  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
  http://arduino.cc/forum/index.php/topic,136500.msg1029238.html#msg1029238
37  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
   
     https://github.com/manitou48/DUEZoo

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.
38  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

  https://github.com/manitou48/DUEZoo
 
39  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.
  http://pastebin.com/UR9DvzKB

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

Code:
               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
ldr.w
str.w
and  version 1.20 of newlib actually has an ARM memcpy.S that has an unrolled loop with
ldrd
strd
 
40  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

   https://github.com/manitou48/crystals
   
41  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.
42  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.
43  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.

Code:

  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
44  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

Code:
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).
45  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
  https://github.com/manitou48/crystals
Pages: 1 2 [3] 4 5 6