interpreter speed @ESP32

Hi,

I am playing with an esp32 to copy codes from an infra-red controller.

I have been able to timestamp the signal edges and see how the 1's and 0's are encoded and reproduce it with the digitalPulse function.

I can also extract the bit sequence and reconstruct the signal (and avoiding the big timestamp tables).

So I have the timestamp table:

var times = [4.4,4.2,.64,1.6,.64,1.6,.69,1.6,.67,.45,.68,.44,.64,.43,.64,.44,.67,.45,.67,1.6,.64,1.6,.64,1.6,.67,.45,.64,.45,.67,.45,.67,.44,.67,.45,.69,1.54,.68,1.56,.64,.44,.64,1.56,.67,.46,.67,.45,.68,.44,.64,.44,.67,.45,.66,.46,.66,1.57,.64,.44,.68,1.56,.64,1.56,.67,1.57,.64,1.56,.64,46.74,4.6,4.42,.64,1.56,.69,1.56,.67,1.56,.69,.43,.69,.43,.64,.45,.68,.44,.68,.43,.69,1.55,.64,1.56,.64,1.57,.68,.45,.67,.42,.71,.42,.69,.43,.68,.45,.67,1.56,.64,1.56,.68,.44,.64,1.56,.69,.43,.64,.44,.64,.43,.69,.43,.64,.44,.67,.45,.67,1.6,.64,.44,.67,1.57,.67,1.6,.68,1.6,.64,1.6,.64];

Set my carrier with analogWrite().

Make the pulse train with digitalPulse() and the signal looks like the original controller on my scope.

Now, extracting the bits and trying to replay them.

var data = 0b111000001110000000011111;
  digitalPulse(D16, 0, 4.4);
  digitalPulse(D16, 1, 4.2);
  for (var i=23;i>=0;i--) {
    if (data&(1<<i)) {
      digitalPulse(D16, 0, .64);
      digitalPulse(D16, 1, 1.6);
    } else {
      digitalPulse(D16, 0, 0.64);
      digitalPulse(D16, 1, .43);
    }
  }

The first 4.4 and 4.2 pulses look good, the next ones take longer than expected. The whole train is like 50% bigger than the first one.

I believe that this is a limitation of the interpreter and I am stuck with the bit timestamp tables.

Is it correct?

I guess so...that is the reason @Gordon has enabled digital pulsing w/ arrays rather than a loop over an array and calling the pulse function for every single pulse (to overcome the time consuming and unpredictable timing of loop code interpretation).

If understanding correctly, you me find a solution in the following approach:

If time between sequences is not an issue for your application, you may use your condensed form of sequences to create an ephemeral long form just before sending out. With that approach the slowing down loop is out of the timing sensitive pulsing.

I'd like to let you know that filling times[] on the fly worked perfectly.

Thank you.

It's an odd one - on 'official' boards digitalPulse queues events into a hardware timer and is effectively asynchronous, plus execution speed seems about fast enough that your code should be ok.

On ESP8266 digitalPulse is synchronous so you have to use arrays, but there was some work done a few months ago to make it async on ESP32 as well - so as you say it probably just comes down to execution speed on ESP32 not being quite fast enough.

Even if you don't want to pack into an array, it's possible that changing:

  digitalPulse(D16, 0, 4.4);
  digitalPulse(D16, 1, 4.2);

to

  digitalPulse(D16, 0, [4.4,4.2]);

and so on would reduce the overhead enough that it'd work.

I did not try joining the calls inside the for loop that where the problem was.

Filling times[] on the fly could give me the best timing, I thought.