Skip to content

Document ordering and count guarantees of read results - #206

Merged
jadamcrain merged 1 commit into
mainfrom
docs-read-ordering
Oct 16, 2026
Merged

jadamcrain merged 1 commit into
mainfrom
docs-read-ordering

Conversation

@jadamcrain

Copy link
Copy Markdown
Member

Addresses #197.

Modbus read responses contain only a byte count and the values in address order — there are no per-value addresses on the wire. The index in Indexed<T> (and bit_value/register_value in the bindings) is computed by the library from range.start as a convenience. This was never documented, which led users to defensively handle arbitrary orderings.

This PR documents that a successful read always returns exactly range.count values in ascending, contiguous address order starting at range.start, and that a response with too few or too many values fails the request.

  • Indexed<T>: canonical explanation; BitIterator/RegisterIterator link to it
  • Channel, CallbackSession, FfiChannel read_* methods: one-line guarantee + link
  • FFI schema: docs for bit_value/register_value, bit_read_callback/register_read_callback (also fixes a "reading reading" typo)
  • Guide: replaces the incorrect "if an error occurs, the iterator is empty" sentence

Docs only; no code changes.

Modbus read responses don't encode per-value addresses, so the index in
Indexed<T> (and bit_value/register_value in the bindings) is computed by
the library as a convenience. Document that successful reads always
return exactly range.count values in ascending, contiguous address order,
and fix the guide's incorrect claim that the iterator is empty on error.
@jadamcrain
jadamcrain merged commit dd18008 into main Oct 16, 2026
31 checks passed
@jadamcrain
jadamcrain deleted the docs-read-ordering branch October 16, 2026 00:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant