Utilising JaRule code

[peternewman]

Possibly a bit of an involved one, but have you considered utilising some of the JaRule codebase
https://github.com/OpenLightingProject/ja-rule/blob/master/firmware/src/rdm_util.h

Even bits like the JaRule protocol stuff look like they should just work standalone:
https://github.com/OpenLightingProject/ja-rule/blob/master/firmware/src/stream_decoder.c

For example it's only this bit you'd need to change to use your other USB library:
https://github.com/OpenLightingProject/ja-rule/blob/0e4bf7bd6e944222f1b64996c93c3ac87a607de5/firmware/src/usb_transport.c#L378-L387

I may be being very naive here, but it looks fairly promising.

It's always struck me when contributing to Arduino and Teensy DMX/RDM libraries that once you've got an array of bytes off the line the code is nearly identical!

[kripton]

Indeed, good note. I actually didn't dig too deep into the firmware's source code since the docs at https://docs.openlighting.org/ole/doc/latest/md_doxygen_message-format.html#message-transport were talking about certain conditions triggering interrupts on the Microchip-side that just don't happen on the RP2040.
However, looking at how the JaRule's code does de-fragmentation (https://github.com/OpenLightingProject/ja-rule/blob/master/firmware/src/stream_decoder.c#L129) and how it's currently implemented for the RP2040 (https://github.com/OpenLightingProject/rp2040-dongle/blob/08e6e144c32b5bf002fd0e936cf510dbeb2a6162/src/jaruleproto.c#L107), there is much less copying stuff around in the latter implementation.

Handling the "serial port" part, especially for RDM will also differ a lots since there just are no 8 UARTs on the RP2040 and there will be a lot of juggling code around the PIO state machines.

But in general I do agree that we should try to re-use as much as possible of what's already there and proven to be working 👍

[peternewman]

triggering interrupts on the Microchip-side that just don't happen on the RP2040.

You mean the RP2040 just doesn't generate the interrupt?

Handling the "serial port" part, especially for RDM will also differ a lots since there just are no 8 UARTs on the RP2040 and there will be a lot of juggling code around the PIO state machines.

Yeah, although hopefully that's just the lower layers of the interface need changing/writing.

But in general I do agree that we should try to re-use as much as possible of what's already there and proven to be working

👍

[kripton]

I'm not sure if it doesn't generate the interrupt at all. I assume that the tinyUSB-library abstracts that for us. When I read the JaRule-docs back then, I thought that the "Zero-Length-Transfer" is explicit and needed for that specific protocol to work.

Meanwhile I've learned that the Zero-Length-Transfer is on the USB level and is implicitly done by the USB stacks. So I assume that we don't need to handle those low levels. And in the ja-rule branch it actually works (meaning that without changes to OLA's jarule-code (except making it multi-universe capable) the data can go in both ways), so should be fine for now.