ESP32 Forum

I am writing driver for custom UART data.
The frame of the data is 22 bit long for a byte, the speed of it is 19200 baud.
I try this code: https://github.com/naffej/esp32-rmt-uart, original it is for standard UART with no parity bit.

I will modified it but from the docs: https://docs.espressif.com/projects/esp ... mt-symbols RMT Symbols only can use with 15 bit data.

So it is possible to make it work with 22 bit data. I have no experience with RMT, something like use 2 symbols to send 1 byte of data. I wonder the same with receive the data.

I try to modified code above but the RX seem not OK, it is not receiver origin data and always show warning:
```
E rmt(legacy): RMT RX BUFFER FULL
```
I have successful write the driver using GPT timer (bit-bang) but it is not stable, data missing and error frequently, that why I want to try new solution.

With the RMT you'd need to encode individual bits into RMT items, as each item defines only one pulse (of variable length) of the signal. You'll need at least one RMT item for every transition from a 1 bit to a 0 bit or vice versa. (0b111111... can be represented as one RMT item, 0b101010... takes one RMT item for every two bits &c.)
When receiving, you have to decode bits from the pulse timings you get from the RMT.

With the RMT you'd need to encode individual bits into RMT items, as each item defines only one pulse (of variable length) of the signal. You'll need at least one RMT item for every transition from a 1 bit to a 0 bit or vice versa. (0b111111... can be represented as one RMT item, 0b101010... takes one RMT item for every two bits &c.)
When receiving, you have to decode bits from the pulse timings you get from the RMT.

I have successful with send the data with old driver, but not with receive it. The longest frame I receive with RMT RX is 16 bytes, the code base on the above github repo, I am not try new RMT driver yet. They encode 8 bit data to 22 bit. Each message contains 24 bytes so it is 3728 bit in 1.1 ms, It may not handle well by RMT.

For the Homebus they encode 8 bit data to 22 bit.

Yes, it's serial 8E1, bit-stuffed x2.

Each message contains 24 bytes so it is 3728 bit in 1.1 ms

Huh?
24 bytes x 22 'bits'/byte = 528 'bits'
At 19200 'bits'/s, that's 27.5ms per message.

To receive a full message in one go via the RMT, you'd need a (DMA) buffer of (528x4)/2 = 1056 bytes. Shouldn't be a problem.
Decoding the pulse lengths from the RMT into bits would be a little excercise; small clock deviations between devices will occur, so some oversampling and a bit of 'fuzziness' in the decoding routine may be called for.

For the Homebus they encode 8 bit data to 22 bit.

Yes, it's serial 8E1, bit-stuffed x2.

Each message contains 24 bytes so it is 3728 bit in 1.1 ms

Huh?
24 bytes x 22 'bits'/byte = 528 'bits'
At 19200 'bits'/s, that's 27.5ms per message.

To receive a full message in one go via the RMT, you'd need a (DMA) buffer of (528x4)/2 = 1056 bytes. Shouldn't be a problem.
Decoding the pulse lengths from the RMT into bits would be a little excercise; small clock deviations between devices will occur, so some oversampling and a bit of 'fuzziness' in the decoding routine may be called for.

Yes, I missed count.
I try to set buffer too but the reading data always 16 bytes with buffer 1024 or 2048, the device send 24 bytes data, it must receive 66 bytes but it not ( 1 byte in uint8_t encode to uint32_t and send in 22bit MSB), with debug the level0 always zero, so it may have problem with sampling like you said. In the driver I use clk_div = 80, mean sample 1 us for 52us pulse.

Hi It depends very much on the chip used
--esp32 - total 8 channels (512*2 = 1024 bits ) by 64*2 = 128 bits - for tx/rx - 0 channel tx = 128 bits, 1 channel rx = 7*128 = 896 bits ( uses memory from 1 to 7 channels )
--esp32s2 - total 4 channels (256*2) by 64*2 = 128 bits - for tx/rx - 0 channel tx = 128 bits, 1 channel rx = 3*128 = 384 bits ( uses memory from 1 to 3 channels )
--esp32s3 - total 8 channels (384*2) at 48*2 = 96 bits - for tx/rx - 0 channel tx = 96 bits, 1 channel rx = 7*96 = 672 bits ( uses memory from 1 to 7 channels ), for s3 you can use DMA mode on channels 3(tx) and 7(rx) - then the parcel length limits are limited by the DMA buffer, i.e. almost unlimited
--esp32c3 - total 4 channels (192*2) 48*2 = 96 bits - for tx/rx - 0 channel tx = 96 bits, 1 channel rx = 3*96 = 284 bits ( uses memory from 1 to 3 channels )
If the protocol as I correctly understood 22 bits * 24 = 528 bits continuously, followed by a pause of at least 22 bits , then
- the best choice - esp32s3 in DMA mode to receive (use a new driver)
- should work - esp32s3.

Note that later chips have 'ping-pong mode' - they can fire an interrupt when the buffer is half-empty (or half-full) allowing the CPU to refill it on the fly. This also allows for nearly unlimited data, given the buffer needs to be refilled slowly enough to account for interrupt latency.

Also worth noting: When receiving, the RMT will return one (32-bit) item only for every 0->1 or 1->0 transition (edge) it detects. So the number of items you get depends on the data received (0b1010... -> two items, 0b1110... -> one item, &c.).

Hi It depends very much on the chip used
--esp32 - total 8 channels (512*2 = 1024 bits ) by 64*2 = 128 bits - for tx/rx - 0 channel tx = 128 bits, 1 channel rx = 7*128 = 896 bits ( uses memory from 1 to 7 channels )
--esp32s2 - total 4 channels (256*2) by 64*2 = 128 bits - for tx/rx - 0 channel tx = 128 bits, 1 channel rx = 3*128 = 384 bits ( uses memory from 1 to 3 channels )
--esp32s3 - total 8 channels (384*2) at 48*2 = 96 bits - for tx/rx - 0 channel tx = 96 bits, 1 channel rx = 7*96 = 672 bits ( uses memory from 1 to 7 channels ), for s3 you can use DMA mode on channels 3(tx) and 7(rx) - then the parcel length limits are limited by the DMA buffer, i.e. almost unlimited
--esp32c3 - total 4 channels (192*2) 48*2 = 96 bits - for tx/rx - 0 channel tx = 96 bits, 1 channel rx = 3*96 = 284 bits ( uses memory from 1 to 3 channels )
If the protocol as I correctly understood 22 bits * 24 = 528 bits continuously, followed by a pause of at least 22 bits , then
- the best choice - esp32s3 in DMA mode to receive (use a new driver)
- should work - esp32s3.

Your information interesting, I am using ESP32, from your information it can handle 896 bits for RX and ESP32S3 can handle RX 672 bits but it can be use DMA so unlimited. But my 1 message contain only 528 bits so at least I can receive all the data send, this protocol match UART but instead off 11 bit data for 1 start, 1 stop, 1 parity, 8 bit for data, it also include 11 bit in 1 to balance the DC, so each byte send in 22 bit data, but the old driver only receive 16 bytes and some seconds later 4 bytes, so maximum it can receive is 20 bytes. So the things write in the docs may not accurate, because RMT mostly use for IR data, and they not long like my data.

Note that later chips have 'ping-pong mode' - they can fire an interrupt when the buffer is half-empty (or half-full) allowing the CPU to refill it on the fly. This also allows for nearly unlimited data, given the buffer needs to be refilled slowly enough to account for interrupt latency.

It seem like old driver not enough speed to sample the data in RX mode, it is 528 bits but it only read 16 bytes like i said above, I will try new RMT to see it work.

Also worth noting: When receiving, the RMT will return one (32-bit) item only for every 0->1 or 1->0 transition (edge) it detects. So the number of items you get depends on the data received (0b1010... -> two items, 0b1110... -> one item, &c.).

I don't understand what you mean, the data send in 22 bit for each byte, for example it send:

```
00155557 00155ff7 001d5f5f 00155557 00155557 0015f557 001dd57f 001557ff 00155557 0015575f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
```
But receive only this raw data:
```
55 aa 55 80 57 e8 55 aa 55 aa f5 aa 77 fa 55 ff 55 aa 55 eb
```
I don't know why. the TX work fine.

```
00155557 00155ff7 001d5f5f 00155557 00155557 0015f557 001dd57f 001557ff 00155557 0015575f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
```
But receive only this raw data:
```
55 aa 55 80 57 e8 55 aa 55 aa f5 aa 77 fa 55 ff 55 aa 55 eb
```
I don't know why. the TX work fine.

1) You're receiving 10x22 'bits', but decoding it to 20 bytes. Make sure you ignore/remove the stuffing bits.
2) Make sure you also remove the parity bits from the decoded data.