Add initial support for the Arduino Leonardo with the ATmega32U4 chip
based on patches provided by audio mixer on forum.arduino.cc. Tested
on a Leonardo R3.
This needs testing, but works well enough for the client to
communicate. The pins especially need to be verified.
Cleanup older notes from the README. Move the part about disabling
auto-reset to towards the end under ‘older notes’ and add a comment
about how it shouldn’t be necessary. Almost move the part about the
device profiles as they are builtin to ols-0.9.7 or newer.
Fixes issue #14 where I copied the preprocessor logic from a different
Mega related check and didn't fix up the elif. So samples from 512 -
1023 were always zero on the Mega.
Update to v0.12
Also move a couple more things under #ifdef DEBUG in an attempt to
reduce the code size for ATmega168.
It current doesn't fit in the '168 but maybe after some more tweaks.
Use unrolled loops to sample at 2MHz & 4MHz rates. Based on some
testing by Bob Davis (http://bobdavis321.blogspot.com)
The maximum with a 16MHz clock is 5.3333MHz (3 cycles per sample) but
sampling at that rate isn't very accurate. Accuracy is pretty good at
2MHz & 4MHz.
Triggers are more reliable on PORTB. I am working on fixing triggers
on PORTD, but I'm setting this back to original behavior (with a
#define USE_PORTD available) so this isn't broken for triggering.
Switch from PORTB to PORTD so that a full 6 channels can be used
without messing with the LED. Per suggestion in issue #7. I was
unable to find any issues with using PORTB. During initial development
I ran into some noise & stability issues but I believe those were
solved later via allowing the ports to settle prior to beginning
sampling.
This allows for 6 channels, starting with digital pin 2 (next to the
UART TX pin) and ending at digital pin 7.
The debug pin is now digital pin 8.
Support RLE mode for samples rates of 50Hz or less. Code from hhermsen
in issue #9.
This is a work in progress. Hopefully RLE can be added for higher
sample rates in the future.
The sample loop was not padded properly in the loop waiting for the
trigger to fire. As a result it was sampling at a much higher rate than
the post trigger sample rate. I've added some delays and padded it out
a bit, it needs further measurement, but is usable now.
