I cannot understand strange thing. May be somebody can explain…
My suggestion - slow imp ADC and that is strange for Cortex.
I have connected together Pin1 and Pin5 and input number of pulses.Active pulse is LOW. Pulse width ~ 80microseconds, min time between pulses ~ 200 microseconds - variable.
I count pulses by two methods: via PULSE_COUNTER (Pin1) and by increment +1 (Pin5).
Below are the piece of code:
local adcS=0;
local adcavr=0;
local count = 0;
local countR = 1;
The imp’s ADC is 2 megasamples, but squirrel is an interpreted language and as such isn’t very fast here - the ARM is having to interpret bytecode etc in the loop which is relatively slow.
The sampler will collect samples into a buffer at a frequency you select, and then you can post-process them afterwards when your code speed is not affecting timing.
@Hugo, thanks! Expanding from 12 bits to 16 bits definitely take a while.
And I suppose that some part of WiFi communication also are provided by ARM processor.
I cannot use Sampler due to not fixed sampling rate. Sampling rate are swinging.
May be is possible to change sampling rate on the fly - reconfigure sampler pin after each sample?
Or exclude conversion from 12 to 16 bits? Final result must be in one byte format after about 1000 - 2000 samples. In this case 16 bit sampling isn’t very necessary.
Or …you mention ways to speed up sampling…
You could always turn on A-law compression (set the sampler to audio mode) which compresses down to a byte - this may work for your application if you’re just looking for transitions.
Still trying to understand what you’re really doing here though. Pulse counting? Pulse width measurement?
Out of interest, what is it you’ve got the imp connected to here? It looks from your code as if what you really need is a pin-triggered sampler, where the ADC conversions are triggered by a rising edge on a different pin. If so, then the hardware is in theory capable of doing that – but how highly we prioritised a new feature which exposed that to Squirrel would depend, quite frankly, on how many people we thought might need it.
@peter. Yes - pin triggered ADC or Sampler.
The best is to have a Interrupt as we known in micro controllers. imp haven’t interrupts while Cortex inside definitely have.
Interrupts are needed in a lot of cases - most common is electric motor encoder.
Interrupts and possibility to exchange data between imp directly in to the same wireless LAN is what I would like to have in imp…
Applying code: function strobe() { local pinState = hardware.pin1.read(); if(pinState == 1) { local ad = hardware.pin9.read(); adc += ad; count += 1; } } hardware.pin1.configure(DIGITAL_IN, strobe); hardware.pin9.configure(ANALOG_IN);
min strobe impulse length on Pin 1 is about 0.28 milliseconds.
To long to apply imp ADC for MEMS gyroscopes or accelerometers.
So the question is - how increase overall ADC converting speed in shown above function?
Or this is a imp bug?
function strobe() {
if (p1r() == 1) { adc += p9r(); count ++; }
}`
…because the interpreter isn’t needing to find the hardware object, then the pin9 object, then the read object every time. It also isn’t needlessly assigning things to local variables when it only refers to them once, etc.
It might be faster to use locals:
`local p1r = hardware.pin1.read.bindenv(hardware.pin1);
local p9r = hardware.pin9.read.bindenv(hardware.pin9);
function strobe() {
if (p1r() == 1) { adc += p9r(); count ++; }
}`
…although it might not. It depends a bit on what the rest of the code looks like, so it’s worth timing both variants if you need the fastest.