crzyrndm / rust-modbus-frame Goto Github PK

i.e. viewing the payload as something other than a bag of bytes.
Almost every consumer of the lib will be using some parts of the standard function set, lets not make them all write a "ReadHoldingRegisters(Command/Response)" and similar. Can also serve as examples for writing custom functions

Should at least have command/response pairs for all the standard functions up to 0x11 plus 0x43

Currently builder just dumps bytes into the provided buffer, meaning it panics if the buffer isn't large enough. Is this the wy to keep it? Alternatives?

Right now I'm leaning towards returning a Result<Frame, LengthError(u32)>, with the error case holding the required buffer length (i.e. *snprintf overflow style).

This is intended for no_std environments, memory consumption is important.

Set up the standard slave example to cross compile to ARMv7m and check: at several opt levels (0, 1, "s", maybe more)

• the FLASH consumption
• max stack usage (https://blog.japaric.io/stack-analysis/)

opt="s" should probably be part of CI but that can come later

RTU and ASCII are just different encodings of the same protocol. The intention was always to focus on RTU, but it would make sense for the RTU format to be the base and ASCII the extension

ASCII changes

• 1 byte LRC instead of 2 byte CRC
• bytes are hex encoded
• start (':') and end ('\r\n') delimiters

To support this

• frame::Frame type becomes encoding independent. The backing representation will be RTU (without CRC)
• Calculate LRC/CRC on demand only. Not placed in the frame by builder and not included in the "raw_bytes" method
• RTU decode probably needs a bit more separation to match what ASCII will need, even though it will basically be "dump bytes here"
• Iter impl for each encoding bytes. For RTU this will just be byte by byte, the ASCII iter will have to do a bit more

Speed really isn't a focus. This will mostly be about detecting major regressions before they become an issue.

The first cut is workable, but far from user friendly. Naming is a major issue, but I'm probably not particularly idiomatic in many places, and the lifetimes involved also make things slightly more awkward than I would like

A fully worked example for a standard RTU master and slave device (coils, inputs, input regs, holding regs, device ID) would help highlighting points of friction and showing improvement over time. Will also be helpful for benchmarking memory usage