Open Lighting Embedded
Open Lighting Embedded (OLE) is an open source DMX512 / RDM stack for PIC32 microcontrollers. The software is developed as part of the Open Lighting Project.
The OLE User Manual describes how to use an OLE device.
The OLE Developer Documentation, is targeted towards people who want to know more about the platform and how to modify it.
The OLE codebase is licensed under the LGPL.
The unit-testing code & mocks are licenced under the GPL.
The hardware designs and the documentation is licensed under the Creative Commons BY-SA.
├── Bootloader # The DFU bootloader │ └── firmware │ ├── Bootloader.X # Bootloader MPLAB X project │ ├── src # Bootloader source code ├── boardcfg # Software configuration for each board ├── common # Common code shared between the bootloader and application. ├── firmware # The main DMX/RDM application │ ├── ja-rule.X │ └── src ├── linker # linker scripts for the bootloader & application ├── tests # Unit tests │ ├── harmony # The mock Harmony modules │ ├── include # Test headers │ ├── mocks # Module mocks. │ ├── sim # A simple PIC32 simulator │ └── tests # The unittests ├── tools # tools to upgrade the firmware on the device. └── user_manual # The user manual
The firmware/ja-rule.X project can be opened in MPLAB X.
To run the unit tests, you'll need:
gmock / gtest should not be installed system-wide, see https://code.google.com/p/googletest/wiki/FAQ for the reasons.
The install-gmock.sh helper script will download and build gmock & gtest in the local directory.
Once gmock has been built, run:
autoreconf -i ./configure make make check
PLASA Identifiers & UIDs
The code by default uses the Open Lighting PLASA ID (0x7a70). This range is owned by the Open Lighting Project and at this time we do not sub-license ranges to anyone else. You may not ship product with the Open Lighting PLASA ID.
Per https://wiki.openlighting.org/index.php/Open_Lighting_Allocations the UIDs 7a70:fffffe00 to 7a70:fffffefe may be used for development (in house) purposes.
A bulk-in transfer with a full 512 bytes of DMX data takes < 1ms on my mac laptop. Given this, I felt that a simple request / response model with a double buffer would suffice.
For DMX / RDM messages, the response message is sent when the transceiver completes the transaction, so the host received positive acknowledgement.