Andreas
December 1, 2019, 12:40am
1
Continuing the discussion from Reading the HX711 using SPI :
Introduction
This component includes two methods of bus access - delay-driven GPIO and RMT-driven slots. The original implementation used CPU delays to construct the 1-Wire read/write timeslots however this proved to be too unreliable. A second method, using the ESP32’s RMT peripheral, results in very accurate read/write timeslots and more reliable operation.
Therefore I highly recommend that you use the RMT driver. The GPIO driver should be considered deprecated.
– GitHub - DavidAntliff/esp32-owb: Maxim One Wire Bus driver for ESP32.
Andreas
December 1, 2019, 12:42am
2
State of the onion of RMT library support for MicroPython
Pycom MicroPython
It looks like Pycom MicroPython already supports it out of the box.
https://docs.pycom.io/tutorials/all/rmt/
Genuine MicroPython
Matt Trentini is actively working on an ESP32 RMT Implementation for Genuine MicroPython, see also https://forum.micropython.org/viewtopic.php?f=18&t=7135#p40635 .
LoBo MicroPython
See also
Matt’s PR received some more tidying and further development during the past few days.
micropython:master
← mattytrentini:esp32_rmt
opened 12:50AM - 05 Oct 19 UTC
This is the start of a MicroPython implementation for [RMT](https://docs.espress… if.com/projects/esp-idf/en/latest/api-reference/peripherals/rmt.html) on the ESP32.
RMT allows accurate (down to 12.5ns) sending and receiving of pulses. This implementation currently only provides transmit features and there are some limitations:
- ~~Blocking only~~ (`send_pulses` is now non-blocking)
- ~~Non-blocking is _possible_ but increases complexity~~
- ~~May need some help looking at how to implement the ISR and pass that back as an optional callback...~~
- ~~Looping is not exposed (it's possible to loop a pattern indefinitely)~~
-~~_Requires_ non-blocking~~
- Carrier features - selecting a base frequency that can be modulated - is not yet provided
- Idle level is not configurable
- Only one memory block per channel
(Update: non-blocking and looping have been implemented)
I'd be curious which of these features is _most_ important to people.
The short-term intent is to allow this to be used to provide a solid NeoPixel implementation. On the ESP32 it's difficult to make toggle pins accurately enough since the operating system periodically interrupts. The RMT provides accurate timing independent of the OS.
Note that [FastLED](https://github.com/FastLED/FastLED), a popular C library for controlling Neopixels, [successfully uses RMT](https://github.com/FastLED/FastLED) for the ESP32 implementation.
Basic usage:
```python
>>> import esp32
>>> from machine import Pin
>>> r = esp32.RMT(1, pin=Pin(18), clock_div=80)
>>> r
RMT(channel=1, pin=18, clock_div=80)
>>> r.send_pulses((100, 2000, 100, 4000), start=0) # Send 0 for 100*1e-06s, 1 for 2000*1e-06s etc
```
The length of the buffer is restricted only by available memory.
Managing resources is not-quite-right yet (once an RMT channel has been allocated it isn't deintialised on soft boot) but I expect to address that soon.
From [PyCom's RMT documentation](https://docs.pycom.io/tutorials/all/rmt/) (take care not to inspect their implementation since it's an incompatible license) they appear to offer _three_ different ways to configure a tx buffer. The second model is similar to the one implemented here. Which, if any, of the others would be of most use?
For reference there are a few related issues:
#5117
#5157
#3453
Although this RMT implementation isn't complete yet I think it is in a _useful_ state and I thought it worthwhile to submit and gather feedback for the future direction.
poesel
June 22, 2020, 8:55pm
4
FYI the RMT driver is in uPy 1.12 and its working. It would be ideal for the HX711 driver but the problem is that there is no way to get the state of the clock pin when using the RMT driver (at least I haven’t found one). But that is necessary to synchronize with the data pin.