DMX library for the Teensy and questions about embedded developer wishes

  • 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:

    1. Can change the refresh rate.
    2. Can change the transmitted packet size.
    3. (soon) Can be able to provide custom responses to non-zero (alternate) start codes.
    4. 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.
    5. 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

    Approved the thread.