Please implement RMT in ESP32!

[0wwafa]

RMT is one of the most useful functions of ESP32.
It allows to send or receive pulses at precise periods.
It's a killer feature and incredibly is not supported in circuitpython.

In micropython it is supported only for sending but not for receiving.

It's a shame.

[dhalbert]

We use RMT for pulseio: https://docs.circuitpython.org/en/latest/shared-bindings/pulseio/index.html

[0wwafa]

@dhalbert great! I missed that! but using pulse io, how can I continuously get pulses (until there are no pulses for 10 seconds)?

What I need is an array of pulse lengths (possibly at 80Mhz or 160Mhz sampling rate/accuracy).

From the other end I receive pulses. I need to collect them all until there are no more pulses for a few seconds (end of transmission).

It's not clear how to do that from the docs.

[dhalbert]

The example gives a sample pulse train with the specified durations. To remove the superimposed carrier, you would set the duty cycle to max (65535). But there's a bug on Espressif we haven't yet addressed: #6799.

[0wwafa]

The example gives a sample pulse train with the specified durations. To remove the superimposed carrier, you would set the duty cycle to max (65535). But there's a bug on Espressif we haven't yet addressed: #6799.

@dhalbert I need the opposite! I need to measure the length of incoming pulses (continously and at high speed)

[dhalbert]

Use pulseio.PulseIn.

[0wwafa]

@dhalbert

Use pulseio.PulseIn.

From what I understand, pulseio.PulseIn has a maxlength..
pulseio.PulseIn(pin: microcontroller.Pin, maxlen: int = 2, *, idle_state: bool = False)

So for getting all pulses let's say for 20 minutes I should set a length read pulses, store them and read again... by doing so I will miss pulses.

What can I use and how to get the full stream of pulse lengths until the data is finished (a few minutes normally) ?

[dhalbert]

This sounds likes hundreds of millions of pulses at the proposed rate. Where are these pulses coming from? This sounds a like a logic analyzer application.

[0wwafa]

This sounds likes hundreds of millions of pulses at the proposed rate. Where are these pulses coming from? This sounds a like a logic analyzer application.

Yes. Sort of. They come from the tape port of a commodore 64.

For example, this works:

 [int(machine.time_pulse_us(machine.Pin(13), 0))>>2 for x in range(100)]

[14, 32, 65, 97, 130, 4, 16, 32, 65, 97, 130, 10, 16, 32, 64, 97, 129, 6, 16, 32, 64, 97, 130, 10, 16, 32, 65, 97, 130, 10, 16, 32, 65, 97, 130, 10, 16, 32, 65, 97, 130, 10, 16, 32, 65, 97, 129, 10, 16, 32, 65, 97, 129, 10, 16, 32, 65, 97, 130, 10, 16, 32, 65, 97, 130, 10, 16, 32, 65, 97, 129, 10, 16, 32, 64, 97, 129, 10, 16, 32, 65, 97, 130, 10, 16, 32, 65, 97, 130, 10, 16, 32, 64, 97, 129, 10, 16, 32, 65, 97]

But that gives me 2 problems:

1. it's not accurate (pulses should be 10,16,32,64,96,128)
2. I can't store it in ram (ram is too small) and if I add any code to that it will lose pulses.

A pulse length streaming would be fantastic (like RMT).
I'd hate to have to rewrite everything in pure C.

[dhalbert]

Seems like there are several existing projects for this, for instance, https://github.com/sweetlilmre/tapuino, that you could adapt code from, if you need to go that way. I see from Wikipedia the basic data rate is about 300bps, and the signal transitions out of the port are no more than about 1 MHz. Also a bit of analog circuitry at the tape output could make things easier, it appears, and reduce the sampling requirements.

[0wwafa]

Seems like there are several existing projects for this, for instance, https://github.com/sweetlilmre/tapuino, that you could adapt code from, if you need to go that way. I see from Wikipedia the basic data rate is about 300bps, and the signal transitions out of the port are no more than about 1 MHz. Also a bit of analog circuitry at the tape output could make things easier, it appears, and reduce the sampling requirements.

I know about that. And it's not exactly what I want to do.. also, the data rate is WAY higher.. the cpu works at 985248 Hz and it can produce a square (ora PWM) wave at a minimum of around 123khz. I coded programs for c64 that can transfer data at over 20 kilobit/s. The story is long. anyway I wanted an "easy" and cheap way to transfer data to and from the c64 on the tape port (at those speeds) and to do so I need a precision of about 8 cpu cycles or less.

As an experiment I used an ft232r in bitbang mode and it worked beautifully even though a little imprecise (I can get +/- 16-20 cpu cycles which is fine for most things but I want something more precise).

Since I have a couple of ESP32, I wanted to try with those. I am afraid I will have to use C and i sincerely hate the bloated idf ide and toolchain.

P.S.
Since the esp32 is 5v tolerant, the example you see above worked without anything in between the esp32 and the c64.
Unfortunately it seems that [micro/circuit] python is too slow for that. The best solution would be to be able to use assembly from inside micropython (or mpy-cross) and create a small routine to count the pulses and spit out the timings as a stream.

In other words: we need a logic analyzer streaming data as fast as possible. That would be the base also of other projects involving the commodore 64 or other vintage devices (devices that were so great that even modern computers can't keep up synchronously).

That's my personal challenge.

The problems:

1. any further code inside the timing routine will make it imprecise.
2. can't store the array in ram (not enough space) it should be a ring buffer or a double buffer
3. precision of 2 / 4 cpu cycles is required (by me)

The solution(s):

1. since I already coded a working program (in C) using ft232, I can adapt it for esp32.
   the program will have 2 threads one for cpu, one sampling in a double buffer and the other one counting and sending the timings out on an uart port at 921600/460800.

2. a python program, the problem is that in python you can use only one cpu and the overhead is huge.

3. a mixed python / assembly or python / c program (not sure if one cpu is enough,

Thanks for your interest, @dhalbert.

[0wwafa]

@dhalbert any idea how to have a stable stream of pulse lengths? In every test I continue missing pulses...
but [int(machine.time_pulse_us(machine.Pin(13), 0))>>2 for x in range(100)] gives the kind of results I want.

P.S.
I don't understand why the pulse length reports is 4 times bigger than it really is. (hence the >>2).
It looks like it's measuring with a clock of 4 mhz?