[isrperf.txt]

Bill Grundmann's Blog (http://billgrundmann.wordpress.com/2009/03/02/the-overhead-of-arduino-interrupts/) has a nice discussion of interrupt overhead on AVR 168. I ran a simple DUE sketch with pin 13 tied to pin 2 to measure number of cycles (systick) to enter and exit an interrupt ISR using standard attachInterrupt() ISR and a version where I modified the core ISR handler. I ran similar sketches on maple and teensy3. The results are in isrperf.txt and the DUE sketch is isrperf.ino at the following github site

https://github.com/manitou48/DUEZoo

[IRtest]

As a proof of concept, I developed a simple sketch to test basic components of IRremote services on DUE.  I used PWM on pin 6 to drive an IR LED (38kHz to 40kHz), and used timer 1 (TC1 channel 0) to sample the input every 50us from an IR receiver  (Sharp GP1UX311QS).  The main logic for parsing the TV remote signals is from Ken Shirriff's IRremotelib.  The sketch actually can receive its own transmits. The sketch is in the directory IRtest at
  https://github.com/manitou48/DUEZoo

It is left as an exercise for the reader to add the DUE changes to  Ken's IRremote lib 
 
Ken's lib   http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html

Paul's IRremote support on teensy (including ARM teensy 3.0)
  http://www.pjrc.com/teensy/td_libs_IRremote.html

An earlier port to ARM Maple
  https://github.com/manitou48/maple-IRremote
 

I don't think DMA is being utilized in DUE TWI functions. As noted in the ADC PDC example in this thread, somewhere there needs to be code that is setting the PDC address and byte-count registers for the DMA transfer.  I think your interrupted print, only shows that a TWI interrupt occurred after a byte transfer.  DMA can send many bytes, requiring only one interrupt when all of the bytes have been transferred.

Though the Maple and DUE share the ARM CPU architecture, the peripheral architecture (I2C, DMA, etc) are radically different.  So my maple I2C DMA code would not be very enlightening.  Eventually, I may make a github page for some of my maple hacks...

[I2Cperf.txt]

Ooops, 100 Khz read column for DUE I2C test above is wrong.  It has been corrected, current performance results are  in I2Cperf.txt at

  https://github.com/manitou48/DUEZoo

Are you really using DMA?  I don't see any reference to PDC. Is your test just allowing the I2C lib to run in the background, with its interrupt handler transmitting each byte??

 I just hacked a version of i2c for the Maple to use DMA -- no significant speed advantages, but presumably the CPU could do something else while the I2C transfer is ongoing.  DMA for the I2C write was straightforward, but on the maple , DMA for the I2C read was a bit more tricky (at least for me), having DMA receive the first n-2 bytes, and then letting the I2C driver manage the last two bytes so it could handle NACK and start/stop.  I only tested with an I2C EEPROM.

From the schematic/bom
   Y1,12MHz KX-7 20pF     CRYSTAL-3.2-2.5           CRYSTAL-3.2-2.5  probably 30ppm
   Y2,32.768Khz,RESONATOR_EPSON_FC_145,RESONATOR_EPSON_FC_145   20ppm 12.5pf

I did some frequency checks using NTP-host and/or GPS pps, see

  https://github.com/manitou48/crystals

I'll be interested in your progress.  All I can offer  are SPI+DMA sketches based on SdFat stuff and a memory-to-memory DMA sketch, see

https://github.com/manitou48/DUEZoo

(I am actually messing with DMA+I2C on maple ... not much progress)

I'm still searching for  part number or data sheet or specs (ppm) for the DUE 12MHz crystal .....  The eagle files bill of material just says crystal oscillator.

On further review, the DUE schematic says Y1,12MHz KX-7 20pF -- google says that might have 30ppm accuracy. 

I'll go with that unless someone knows better.

Buyer beware.  I have a working nano from gravitech, but ordered an "Arduinno nano 3.0" from amazon.  After a few weeks, it arrived from shenzheng, china.  It ran a few sketches, but after an hour it no longer worked.  Multimeter showed only 0.015v on Vin? (running from USB), and initially 5v (pin 27) showed 4.8v, but now it shows only 2.6v and the USB is no longer recognized by PC.   sigh.  you get what you pay for. 

Others I see have complained about Amazon selling units as Arduino, when they are in fact clones.

The HC pins can source/sink  15/9 ma.  The LC pins only provide 6/3 ma.  See the "pin out diagram", the first thread in the DUE forum, for which pins are HC.  If you want to drive your LED at 20ma, you'll need a transistor or IC

Just for the record, I ran some W5200 tests on the DUE with SPI and SPI+DMA, maple and DUE results are in wizperf.txt at
      https://github.com/manitou48/DUEZoo

Does Due have a tone() function yet?  If so, please output an infinite duration 15 kHz tone on a pin during the test.

I believe the tone functions are still not ported.

I'm not sure what this has to do with onewire thread, but I have a proof-of-concept tone(), see tone1.ino in
    https://github.com/manitou48/DUEZoo

 

Though read_bit() seemed to be working, I modified it as well to match the maple version.  The two sketches seemed to work with the slimmer version.  NO delay(1)'s required.

Code:

uint8_t OneWire::read_bit(void)
{
IO_REG_TYPE mask=bitmask;
volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
uint8_t r;

DIRECT_MODE_OUTPUT(reg, mask);
DIRECT_WRITE_LOW(reg, mask);
delayMicroseconds(5);
DIRECT_MODE_INPUT(reg, mask); // let pin float, pull up will raise
delayMicroseconds(5);
r = DIRECT_READ(reg, mask);
delayMicroseconds(60);
return r;
}

I rewrote  write_bit() in OneWire.cpp to match (more or less) what was working on the maple.  This seems to work for me without any delay(1);!  Works on both the little ds18b20 sketch and the Examples>OneWire>DS18x20_temperature.

Code:

void OneWire::write_bit(uint8_t v)
{
IO_REG_TYPE mask=bitmask;
volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;

if (v & 1) {
// noInterrupts();
DIRECT_MODE_OUTPUT(reg, mask); // drive output low
DIRECT_WRITE_LOW(reg, mask);
delayMicroseconds(5);
// DIRECT_WRITE_HIGH(reg, mask); // drive output high
DIRECT_MODE_INPUT(reg, mask); // let pin float, pull up will raise
delayMicroseconds(60);
//interrupts();
} else {
//noInterrupts();
DIRECT_MODE_OUTPUT(reg, mask); // drive output low
DIRECT_WRITE_LOW(reg, mask);
delayMicroseconds(60);
DIRECT_MODE_INPUT(reg, mask); // let pin float, pull up will raise
//DIRECT_WRITE_HIGH(reg, mask); // drive output high
//interrupts();
}
delayMicroseconds(10); // 10uSec recovery time
}

Has anyone found a solid way (preferably in sketch) to modify the output PWM frequency?  Also changing variant.h from 1k to what ever you want isnt working for me.  Changing it and saving doesn't change the output frequency.

Daniel

You have to restart the IDE if you make changes to the underlying libraries as they are compiled only once for the sketch "to save time".  

you might look at PWMC_ConfigureClocks()