I wrote some DMX code that runs on the Teensy, here: TeensyDMX.
My next major commit will be providing the ability to add custom responders that respond to any specific start code, for example RDM or those specified in Annex D of ANSI E1.11. To test this, I've implemented an RDM responder, because I believe a great way to test your own code is to use it.
I believe my API is complete, but I wanted to know what sorts of things embedded developers might find useful in a DMX (or RDM) API that's not designed as a complete project, but to be incorporated as a building block into a system.
Right now, it:
- Can change the refresh rate.
- Can change the transmitted packet size.
- (soon) Can be able to provide custom responses to non-zero (alternate) start codes.
- Has a goal of being a very simple but very capable API. For example, there's no need to remember to call some update method in loop(), just set or retrieve channels as you need.
- Does its own serial port management via ISR's; all data goes directly into the DMX buffers for reading or writing. No buffers to manage by the developer.
Also, what are your RDM needs? Right now, I have these implemented (plus all the required ones) with what I believe is a simple API for filling in, for example, your own sensors or manufacturer-specific commands:
COMMS_STATUS, DEFAULT_SLOT_VALUE, DEVICE_LABEL, DEVICE_MODEL_DESCRIPTION, DMX_PERSONALITY, DMX_PERSONALITY_DESCRIPTION, MANUFACTURER_LABEL, PRODUCT_DETAIL_ID_LIST, REAL_TIME_CLOCK, RECORD_SENSORS, RESET_DEVICE, SENSOR_DEFINITION, SENSOR_VALUE, SLOT_DESCRIPTION, and SLOT_INFO.
Right now, I'm just doing this for fun because I like to "exercise" by writing protocol things, so this may not be a fruitful endeavour. I'm just trying to take the pulse of the needs of those trying to build embedded DMX-based systems.
JPK
