onewire_bus: using fixed mem_block_symbols for RMT RX (IEC-498)

[lukecyca]

Checklist

• Component contains License
• Component contains README.md
• Component contains idf_component.yml file with url field defined
• Component was added to upload job
• Component was added to build job
• Optional: Component contains unit tests
• CI passing

Change description

Currently the onewire_bus component uses the RMT peripheral, and configures mem_block_symbols to 80 in some cases. This works for a simple example, but it prevents us from making good use of the other RMT channels, because it uses more memory than the nominal per-channel amount (64 on ESP32 and ESP32S2, 48 on others).

With this change, we allocate every RMT channel using the nominal number of symbols for that system (64 or 48). If the application requests reading more bytes than that, we read them in chunks.

I have tested this with ds18b20, in both single configurations (one sensor on the bus, with no address specified) and in dual configuration (two sensors on the bus, enumerated).

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Pull request overview

This PR modifies the onewire_bus RMT implementation to use fixed (nominal) mem_block_symbols for the RMT RX channel instead of scaling based on max_rx_bytes. When reading more bytes than fit in one memory block, data is read in chunks.

Changes:

• Replace dynamic RMT RX memory block sizing with the fixed per-channel default (48 or 64 symbols), reading data in chunks when needed.
• Update onewire_rmt_decode_data to accept a start_bit offset instead of a buffer size, enabling chunked decoding.
• Fix a typo: "weather" → "whether" in a comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[lukecyca]

@suda-morris @Kainarx just wondering if there's anything you require from me to move this forward. Thanks!

[Kainarx]

Hi, @lukecyca Thank you for your contribution. Could you please only apply this modification to chips esp32 and esp32s2? Other chips support ping-pong reception and do not require multiple calls to the reception function.

[lukecyca]

@Kainarx I have made the changes as you suggest. Thanks!