esp32-owb icon indicating copy to clipboard operation
esp32-owb copied to clipboard

Depreciation message for rmt.h

Open klaus-liebler opened this issue 2 years ago • 21 comments

Hi David,

when compiling with idf5.0 (master branch), I get a depreciation message for rmt.h:

esp-idf/components/driver/deprecated/driver/rmt.h:18:2: warning: #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h" [-Wcpp]

Regards,

Klaus

klaus-liebler avatar Jun 09 '22 14:06 klaus-liebler

Hi Klaus, thanks for the report. I'll investigate switching over to the new driver when I move to IDF 5.0.

DavidAntliff avatar Jun 09 '22 21:06 DavidAntliff

On owb_rmt.c file: changing the rmt_set_pin function to rmt_set_gpio and adding a boolean 0 flag as a last parameter works for me. ( it was finding devices but not showing the readings temp, now it works just fine!)

edg2411 avatar Aug 01 '22 13:08 edg2411

I also applied that change locally. I was getting crashes when I tried addressing a 1wire device that was no longer connected (testing my error handling) and applying this change fixed these crashes.

paulfaid avatar Sep 12 '22 02:09 paulfaid

The IDF v5.0.1 build should be ok in master now (rmt_set_pin() -> rmt_set_gpio(..., 0). Thanks to @mjcross for fixing that up.

As for the driver/rmt.h deprecation - I will need to come back and address this another time, as it's a non-trivial change. I'm leaving this URL here for my own reference later: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/release-5.x/5.0/peripherals.html#rmt-driver

DavidAntliff avatar Mar 26 '23 21:03 DavidAntliff

Thanks for accepting the PR 👍 I've already been looking at the new RMT driver and I'll let you know how I get on. Also in case it's useful, my 1-Wire driver for the RPi Pico / RP2040 has just been merged into raspberrypi/pico-examples:develop.

mjcross avatar Mar 27 '23 07:03 mjcross

FYI, there is now an example for 1-wire (based on rmt peripheral) on esp-idf itself: https://github.com/espressif/esp-idf/tree/master/examples/peripherals/rmt/onewire_ds18b20

bbinet avatar Mar 27 '23 07:03 bbinet

FYI, there is now an example for 1-wire (based on rmt peripheral) on esp-idf itself

Ah! Many thanks for that - I'd looked for an Espressif example but couldn't see one

mjcross avatar Mar 27 '23 07:03 mjcross

Update: I’ve read the docs for the new driver/rmt and I think it is doable. Going to be a rewrite rather than a patch, but obviously keeping the same api. What do you think @DavidAntliff - are you happy for me to have a bash at it?

mjcross avatar Mar 27 '23 17:03 mjcross

@mjcross sure, if it's original code and it continues to work with the esp32-ds18b20 component (single, multiple & parasitic), and the associated example app, I'd be happy to consider merging such a PR. Thank you for offering.

It is interesting that Espressif now have their own OWB example, using RMT. The question of whether esp32-owb is still needed, in light of that, is worth asking. Although their example is coupled to the DS18B20, whereas this component is more general-purpose. That said I've never used it with anything other than a DS18B20.

DavidAntliff avatar Mar 27 '23 20:03 DavidAntliff

I asked myself the same question about whether esp-owb still has a place. IMHO whilst the Espressif example serves well as example code, it seems a bit over-engineered for everyday use. So yes, personally I’d say a slimmed down version has a place. Concerning the support for parasitic power by the way, is that implemented for both RMT and GPIO or just the latter? I haven’t looked in detail but I didn’t think it worked on RMT - but I could be completely wrong on that.

mjcross avatar Mar 27 '23 21:03 mjcross

By the way, when I said a ‘rewrite’ I was only proposing to replace the current owb_rmt.c and .h, leaving everything else the same (well that is the objective, anyhow) :-) I’ll carry on and see how far I get. 👍🏻

mjcross avatar Mar 27 '23 21:03 mjcross

Yes, the IDF example is probably less useful for integrators as it's designed for teaching, mostly. Anyway, having a choice is good. If you need to use the example to learn how to implement this, by all means, but please do try to keep the new code original. I know that can be difficult when both codebases are practically doing the same thing, but I also don't want to run into licensing issues.

To be frank I've never used the parasitic feature beyond writing the support for it, so I actually can't remember! I've just looked through the code and I can't see any indication that it's not designed to work with RMT, but perhaps there is an issue and it hasn't been brought up formally. If you have the ability to test this, please do, but if you can't let me know and I can rig something up and give it a go.

Copy that on "rewrite" - I understood you :)

Thanks again, I appreciate you taking an interest in this component and being a contributor. Happy to put a credit in the README once done, if you are OK with that.

DavidAntliff avatar Mar 27 '23 21:03 DavidAntliff

Completely agree on the importance of steering clear of licensing issues; and I’m fine with that. I wrote the Pico driver from scratch including the pesky ROM search code, so it’s pretty familiar turf apart from the RMT aspect. The new RMT driver is a bit involved but the documentation is pretty clear. One exception to that is the description of how to write your own Encoder, which I didn’t really follow ~ but I think the pre-rolled ones will do fine for what we need. I’ve never used the parasitic mode either (or come across anyone who has). I’ve definitely got the kit to try it at some point, but I’ll defer that until later. Will keep you posted as to progress.

mjcross avatar Mar 27 '23 22:03 mjcross

Shared a private repo with you @DavidAntliff, for the work in progress

mjcross avatar Mar 30 '23 16:03 mjcross

Basic framework done; OWB bus reset and slave detection are now working.

mjcross avatar Apr 02 '23 16:04 mjcross

Everything now seems to work fine so I'll start preparing a PR

mjcross avatar Apr 05 '23 15:04 mjcross

Now works with esp32-ds18b20-example:

  • fixed a simple bug in write_bits() that prevented it from sending single bits
  • spent way too long chasing what I thought was a buffer overflow, but turned out to be a Heisenbug related to me setting over-short device timeouts

Further testing underway, to be on the safe side

mjcross avatar Apr 06 '23 14:04 mjcross

@mjcross, I take it you are satisfied with the 0e1821c commit or is testing still ongoing?

NRollo avatar Jun 02 '23 18:06 NRollo

Yes I'm happy with it - in fact I've been using it in production for a few weeks now. If are OK with a simpler API then you might also find it useful to take a look at https://github.com/mjcross/esp32_onewire

mjcross avatar Jun 02 '23 18:06 mjcross

@mjcross Thanks for the information, the 'esp32_onewire' looks interesting, what is the differences between that and 'esp32-owb' (what would I miss compared to 'esp32-owb')?

NRollo avatar Jun 05 '23 08:06 NRollo

@NRollo You're welcome. They both use exactly the same code to talk to the bus, but esp32_onewire is a stripped down version that has a simpler API. It's designed for straightforward use-cases that don't need CRC checks or parasitic power.

If you compare the two examples esp32_onewire/main/main.c and DavidAntliff/esp32-ds18b20-example/main/app_main.c then I think you'll get the picture.

mjcross avatar Jun 05 '23 12:06 mjcross