Interest in DMX/RDM for Zephyr

[DaAwesomeP]

Hello!

Just want to gauge some interest for developing DMX and RDM libraries for the Zephyr RTOS. For those unfamiliar, Zephyr is a new-ish RTOS supported by the Linux foundation and lots of hardware manufacturers that focuses on hardware abstraction across many chips and architectures and long-term support. The advantage of Zephyr vs bare metal is that you get a proper RTOS with a real-time scheduler, network stack, hardware abstraction, memory protection, and peripheral support. It could potentially be be a successor to ja-rule that would not be limited to the PIC32 if there is enough interest. Personally, I could not see myself starting a brand new project today with a PIC32.

I would probably do this by mashing together some combination of ja-rule, rp2040-dmxsun, and DmxSerial2. I have a lot of samd21 that I will start with, but support for all features of the RP2040 is slowly but surely being added to Zephyr (including the PIO!). There is also growing support for the ESP32.

To start my goal is to make a simple platform for developing fully-compliant DMX/RDM light fixtures. The simplest would be some sort of dimmer or RGB device, but it would be awesome to eventually build a moving light off of it.

I have worked on protocol implementations before but never something on this scale, so if anyone else is interested then I would definitely like to work together! If this is something that the Open Lighting Project would be interested in (or similar on a different RTOS or platform), then that would also be good to know!

Best,
Perry

[DaAwesomeP]

On second thought, maybe I should not look at rp2040-dmxsun since it is not LGPL. Still wrapping my head around how GPL and LPGL work for embedded device, and if LGPL even applies (because you basically don't dynamically link). If a goal is that people could make and sell embedded devices in industry, then maybe it should be LPGL, if that even applies to embedded. DmxSerial2 (BSD, which is Apache 2.0-compatible) I guess would make more sense for the use-case I am going for.

[Peter Newman]

Don't forget TeensyDmx too ( https://github.com/chrisstaite/TeensyDmx ).

The ja-rule stuff was only ever really aimed to be a controller (and to dummy/respond to some stuff too, but not really as part of a responder).

From what I've helped with the various other libraries in the past, abstracting the wire to byte array stuff would be useful and might allow more cross-platform use of the libraries than is currently available. It could also far improve the testing regime available as you could feed in lots of different input data easily, even as part of CI.

Really productising a library would be great, so someone could just populate a few structs and maybe even just add their own sensor and the library deals with all the RDM implementation detail would be great, I've tried to help that with some of the others but they aren't quite there yet.

I'm no expert on the licence stuff either unfortunately.

[DaAwesomeP]

Interesting, there appear to be two Teensy DMX implementations:

• https://github.com/chrisstaite/TeensyDmx
• https://github.com/ssilverman/TeensyDMX

I've gotten started on a library sort of how you describe: structs and functions for defining a DMX/RDM responder or controller. I'm currently working through the DMX parts, and then I'll throw it on GitHub and work on the RDM part. This library has no UART/hardware-specific parts at all and is just a parser/generator/state machine; it will definitely be easy to unit test and be very thorough with the E1.11 and related specifications. It would be sort of an unofficial and non-platform-specific "reference implementation."

After that I'll move on to making use of said library in a Zephyr module, which will just add the UART-specific and Zephyr-specific parts.

[Peter Newman]

Yeah unfortunately Shawn's one has a bit of a name-space clash with the earlier one. I think to further confuse things it might be the one that made in into the Arduino library manager first.

IMHO (and I'm probably biased), Shawn's one is lower level, whereas Chris' library is designed to make it easy to just write something that does what you need, and it tries to deal with a lot of the fiddly details in the background.

Your library sounds interesting. I don't know if an RDM controller is in scope too, but I tried to simplify some of that by auto-generating the basic PID methods for that using the OLA PID Definitions:
https://github.com/OpenLightingProject/rdm-app/blob/master/data/pid_data.py

[Jannis Achstetter]

Hi Perry,

Sounds like an interesting project to me :)

About the rp2040-dmxsun licensing: I actually just chose GPL-3 since I
think I saw some other projects on OpenLighting use that license and I
thought it makes things easier to stick with that. Personally, I don't
have a problem with re-licensing it as LGPL, MIT or Apache. Would need
the approval of all other contributors to the project (which is probably
just Peter Newman if I remember correctly).

Using a "real" RTOS for the dmxsun-project is something I have been
thinking about as well since all the tasks the board needs to do by now
(especially the wireless communications that can block one core for
quite some time) make it increasingly difficult to not make things break
at some point. Zephyr and FreeRTOS are currently the two major candidates.
However, be aware that "abstracting most hardware" and "making it
portable" can reduce you to a pretty narrow set of features. Of course
it would be awesome to have one common DMX+RDM
controller+responder-stack that just works everywhere. However, the
rp2040-dmxsun project does quite the opposite: It generates the 16 DMX
universes in a very special way and it also takes advantage of the
RP2040's possibility to control pretty much every aspect of the
TinyUSB-Stack. This way, it's possible to look to the USB Host as an CDC
NCM network device (web UI + ArtNet + E1.31) + CDC ACM serial port +
some other emulated protocols at the same time or configurable.
If all this is also possible with Zephyr (and has a good fallback for
boards/chips that don't support this functionality), count me in :)

And, yes, the rp2040-dmxsun is currently more planned as a controller.
DMX Input (without RDM) is planned/in progress but there hasn't been put
too much thought into making it work both ways / as a fixture.

@Peter Newman: Any thoughts about re-licensing the rp2040-dmxsun to a
more liberal license so people can take better advantage of it?

Jannis

Am 25.06.22 um 19:00 schrieb DaAwesomeP:

> --
> The Open Lighting Project: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en
> <https://groups.google.com/groups/opt_out?hl=en>
> ---
> You received this message because you are subscribed to the Google
> Groups "open-lighting" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to open-lightin...@googlegroups.com
> <mailto:open-lightin...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/open-lighting/f95ad1c5-8112-4220-a1e1-db3d52c2ceban%40googlegroups.com
> <https://groups.google.com/d/msgid/open-lighting/f95ad1c5-8112-4220-a1e1-db3d52c2ceban%40googlegroups.com?utm_medium=email&utm_source=footer>.

[DaAwesomeP]

Hi Jannis!

To be clear, I am not pushing for re-licensing; I was only explaining an issue I found. Changing the license is definitely your own (and the other contributors') decision to make, and I respect that. I have licensed some of my own projects as GPL as well, and I was just pointing out that in this particular case it would prevent someone from reusing the code in a firmware-based device (since you can't easily avoid static linking). If you are considering changing it, my recommendation would be Apache 2.0 or BSD 3-clause in this case, but please don't go off of my recommendation alone.

Specifically for the dmxsun project, I don't think Zephyr is quite ready yet on the RP2040. I have been tracking the issues/pulls on the Zephyr repo in relation to the RP2040, and support for all of the features is slowing being added: https://github.com/zephyrproject-rtos/zephyr/issues?q=label%3A%22platform%3A+Raspberry+Pi+Pico%22+ Unfortunately, the RPI foundation is not contributing to this effort (at least as far as I can tell), so it is definitely slow progress. Zephyr does support the PIO at the moment, but I don't think the USB stack is supported yet, which is an obvious deal-breaker for your project. I am extremely sure this support will eventually come, but not yet. However, once it is supported it would be under the same Zephyr USB stack that supports many more devices than the RP2040. It looks like they currently support CDC ECM and CDC EEM but not CDC NCM yet. ECM might work in place of NCM here, but I am not really familiar with these protocols or how dmxsun makes use o them. My personal opinion would just be to wait since I definitely prefer Zephyr to FreeRTOS for both approachability and easy of development. It is also easier to claim that it will always remain fully open as it is under the Linux Foundation and not Amazon (FreeRTOS).

When I sat down to start writing this library a few days ago, I took a step back and realized the first step was not to involve Zephyr at all but just to write some plain C. I'm going to start by writing some simple structs and state machines that do not make any assumptions about any hardware. I'm also thinking through a way to abstract out the timings too. This is something that maybe you would be able to take advantage of regardless of if you move to an RTOS or which RTOS you choose. I'm definitely not pushing for dmxsun to change implementation, though my goal is definitely to create a starting point for new projects and an option for existing projects.

The idea is that for a receiver/responder you just feed in DMX packets as you receive them (all of the data between the MAB and stop bits), and it will give you RDM response packets to send when necessary. It will also present a method to extract the current possibly-SIP-validated NULL START data from the state machine. For a controller/transmitter, it would give you the next packet and the time to send the next packet continuously while you also can feed in new DMX data or RDM requests as necessary. Each physical DMX port (input or output) would have one of these state machines, and you would just write the application code to connect and manipulate the data and RDM between them as you wish. This could definitely be expanded to support sACN and RDMNet as well and leave the user of the library to implement the actual networking stack as they see fit.

This way will also make it incredible easy to write tests and really build confidence that it is working to specification before I even touch any hardware or UART timing difficulties. I think this can be done in a way that is not closely-coupled to any specific hardware while still being performant enough (or at least with the minimal safe optimizations turned on to remove clearly needless function jumps).

I'm going to write a first draft of the DMX receiver and transmitter states/structs/functions, and then I'll throw it on GitHub. Then I'll move on to RDM. When I do get to Zephyr, I'll do it in a completely separate repo that makes use of this non-architecture-specific library.

Perry

[Peter Stuge]

DaAwesomeP wrote:
> I was just pointing out that in this particular case it would
> prevent someone from reusing the code in a firmware-based device
> (since you can't easily avoid static linking).

Just a note that GPL does not at all prevent such reuse, it just
requires derivative works (the larger project) to also use GPL.

That's very much intentional and projects can and do choose GPL
exactly because they want those terms, resulting in more works
with published source code that can be reused further. \o/


Kind regards

//Peter