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.
For some reason the Arduino Uno R3 (but not my earlier / original Uno)
needs a longer delay after reset. I haven't investigated the cause
yet, but increasing device.open.portdelay to > 1700ms seems to fix it.
Bump to 2000 just to be safe in all cases. This should fix the Uno R3
issues that have been reported a couple of times now.
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.
Set clock speed to 16MHz. Hopefully this value works fine with the
client since the previous 100MHz was not the actual clockspeed anyway.
Also, adjust the device.open.portdelay to 1500ms. People can test
their own device for the fastest value, but this should be a safer
default for most people and hopefully eliminates som frustration for
first time users.
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.
Correct long standing bug in the device profiles on github where the data was being reversed by the client due to the reverseOrder setting. The sketch returns the data in the sampled order, but the client appears to expect it reversed, so the sense of the setting is backwards. Data is in the correct order based on a simple test program, even though the setting is "wrong". Invert the comment as well. Also increase the delay on the Mega as it doesn't always respond fast enough. Patches from scottp.
The Arduino Mega 2560 is now supported in addition to the regular
Arduino. The Mega supports 8 channels and 7k samples. The ols.profile-*
files are device profiles for the alternative SUMP client. 'AGLA' =
Arduino 'AGLAM' = Arduino Mega
Change to using an array of bytes instead of integers. Retune
timing loops now that each sample is not doing a 16 bit update.
We can now record 1024 samples easily.
