Device Serial Protocol

[Obsnold]

Hi Again!

I thought I'd make a new discussion here instead of adding to the old ones.

I've had a quick look at the notes and snis-device-io.h and was wondering if there is a formal definition of the serial protocol?

Also is it bi-directional? so can I send commands to make LEDs blink on the device?

[smcameron]

wondering if there is a formal definition of the serial protocol?

There is not. It's still a work in progress, and I made a little progress this past summer with the steering yoke, and I have all the parts 3d-printed for a NAVIGATION console (buttons, faders, etc.), just need to laser cut the parts for the cabinet and build it, then build the brains for it and wire it all together, then work on snis-device-io, but kind of got stalled again. Turns out the new TV that's at my hackerspace which replaced the old projection system when we moved this summer does not play well with SNIS for some reason, which kind of took the wind out of my sails a little bit.

There are probably things missing from snis-device-io.h, and I am pretty sure there are things in snis-device-io.h that are just placeholders (no code backs them in snis-client.c, or if you're lucky, there is code, but it is not well tested.) If you look in snis_client.c and search for the function "process_physical_device_io", you will see what is there.

There is also no provision in snis-device-io.h for the control panels to receive input from snis-client.c (e.g. to turn LEDs on or off, etc.) though obviously this is something I mean to add.

I haven't given a lot of thought as to how such an LED control interface should look. Off the top of my head, something like, there's some standard list of possible LEDs we make up for each console (how many? is 64 enough? 128?), and snis client sends some LED control opcode(s), followed by some 64 or 128 bit value to control which LEDs should be on or off... something like that. Maybe there should be some opcode for the console to tell snis-client which LEDs it has, or maybe just if it has any LEDs at all, so the LED control data could be compacted or omitted as makes sense, or so that if wiring mistakes are made in the LEDs or something like that, these could potentially be corrected by software mapping, and so that console builders don't necessarily have to adhere to some very strict LED numbering scheme.

Or maybe that's too complicated, and perhaps there should just be a strict LED numbering scheme.

Had not really planned on supporting RGB LEDs, barring some compelling use case.

[Obsnold]

Thanks for the info!

I'm going to try and put together some hardware and then I can at least do some testing of the existing interface.

Originally I was thinking of using a protocol like CANopen so I could have serial and network devices connected but that is probably more complicated than it needs to be.