MOD-IO improvement suggestion (firmware)

[lambda]

Hi,

since the i2c bus doesn't provide much in terms of error detection, it would help a lot if the firmware allowed reading back the relays state. At the moment the register always read a zero:

Code Select Expand

harald@debian:~$ sudo i2cset -y 1 0x58 0x10 0x01
harald@debian:~$ sudo i2cget -y 1 0x58 0x10
0x00
harald@debian:~$
So at the moment it's not possible to verify, whether the state was updated successfully. This would help with applications, where reliability is a concern.

best regards,
Harald

[JerkoNikolic]

Interesting suggestion. Might be useful for proper state tracking as well.
Currently the firmware is downloadable, but there's no repo to create a pull request. If we can get an official Olimex repo, I'd be willing to do the implementation.

That said, I'd bet there's a good reason why the firmware isn't on a public repo even though you can download the source to change as you will. Most likely that the reason is if you have a repo, people expect the updates to be merged into it and then the hardware updated. That creates cost and version disparity.
Introducing that change means adding it to the documentation, but then you get people asking why their board isn't reacting to that command or, if they figure out it's because of the version, why their board didn't come with the latest one.

[kyrk.5]

Some random toughs:
- Basically a single relay needs 1 bit of information and can provide 2 bits of information back. Obviously a relay can be on or off (1bit). This state can be read back, another bit. And also it can happen that the relay is switched off or on but in reality it did not switched. With some extra hardware schematic this state can be also read back.
- For normal application the simple write is enough. Just write it to the desired state and forget it. For a little bit more complexer application it would be intresting to read back the last written state. For example if the applicaton was reseted but the relay circuit not. Kind of a syncronization. Or maybe for bistable relay this would be also nice. Some even more complexer application that might involve safety might also want to read back if the relay was really switched. Often this is done trough the second contact of the relay.
- There could be even more complexer application that want also to ensure that not only the relay was switch but the output itself (on the connector or whatever interface the PCB have) is also at the proper level. However I think this is too far away from the relay to say that this information could also be included somehow. Moreover the output might require even complexer infos like how much voltage and current is there.
- Only a write interface makes the interface unreliable. If a bit is changed, then in the protocol itself is nothing there to recognize this. A readback provided could help to detect errors and take corrective action. Also a writing with a CRC could help to prevent noise change the state of the relay. However if the CRC is wrong, then nothing is written and the user wont notice this unless a readback is done. So I think the readback of the last written states is a very good feature. Then a CRC could be implemented too.

[LubOlimex]

Interesting suggestion. Might be useful for proper state tracking as well.
Currently the firmware is downloadable, but there's no repo to create a pull request. If we can get an official Olimex repo, I'd be willing to do the implementation.

That said, I'd bet there's a good reason why the firmware isn't on a public repo even though you can download the source to change as you will. Most likely that the reason is if you have a repo, people expect the updates to be merged into it and then the hardware updated. That creates cost and version disparity.
Introducing that change means adding it to the documentation, but then you get people asking why their board isn't reacting to that command or, if they figure out it's because of the version, why their board didn't come with the latest one.

The main reason for the firmware to be missing from GitHub is that it was written before we had public repos. MOD-IO is an open source software and hardware project. You are free to edit the firmware and put it in your repository. Improvements are welcome. Maybe even share a link here.

[lambda]

I understand, that there should be one big version update instead of incremental changes. So I sat down and came up with what I believe is a rather comprehensive list of backwards compatible reliability improvements:

• allow reading back of written values as described above
• introduce an ID (maybe version ID) register like many other boards have
• introduce a status register that allows enabling enhanced features
• Enhanced feature 1: Use unused bits for redundant information encoding. For example the upper 4 bits of the relays register would be the inverse of the lower 4 bits. In this mode to clear all relays you would send 0xF0 instead of 0x0. Invalid values would be ignored.
• enhanced feature 2: Add some timeout registers where relay states can be prepared for the case of communication timeouts. One such register would be enough to have the HW enter some kind of safe state. (Most commonly probably all relays off.) With several such registers you could also configure advanced features like power cycling the I2C master on timeouts which would be a cheap implementation of a HW watchdog.

Yes, I'm aware, that I can cook my own firmware and I appreciate that. However, if several people here agreed on a consistent set of features and maybe shared the implementation effort, this would be much preferable. Also if Olimex shows interest in adopting such changes officially, that would make working on that much more rewarding.