Vision RDM, Vision DMX & Vision DFU
Handle RDM
Receiving and transmitting RDM is done through "READ_RDM" and "WRITE_RDM". The fixture must always react to RDM commands, even if Vision is not the selected input source.
Use the "RX_RDM_IRQ" flag to detect new RDM frames.
Handle DMX
Receiving and transmitting DMX is done through "READ_DMX" and "WRITE_DMX". Whenever "Vision Protocol" is selected as input source you must read DMX Frames and react to them.
Use the "RX_DMX_IRQ" flag to detect new DMX frames. Maximum refresh rate is 20ms.
READ_DMX
This function must be used to derive input values for Vision as selected input source. The data stream is defined as the following:
| data[0] | data[1] | data[2] | data[3] | ... | data[512] |
|---|---|---|---|---|---|
| Vision Control Behavior | dmx[1] | dmx[2] | dmx[3] | ... | dmx[512] |
The first value is called Vision Control Behavior. It tells the fixture whether the current Vision DMX frame shall be handled as DMX Control or as App Control. Caution: Do not change internal fixture settings such as the saved DMX personality for display, RDM, or other protocols.
Vision Control Behavior == 0: DMX Control
If this value is 0, the fixture behaves like it is controlled by a normal DMX stream. Use the fixture's currently selected DMX settings, such as DMX start address, DMX personality, and other user-selected fixture settings.
Vision Control Behavior == 255: App Control
Use the defined App Control behavior described in the DMX chapter. Use fixed default settings, including DMX start address 1 and the required App Control DMX personality. For example, use a fixed color-mixing behavior such as RGB instead of switching between RGB, RGBW, RGBL, or similar modes based on user settings. Fixtures of the same type must behave consistently during App Control. Do not change saved settings in the display or for other protocols. RDM must still report the fixture's saved user settings. Apply these defaults only to the current Vision DMX frame.
This function is used that the app can control the fixture in a defined state without manipulating the settings of the fixture.
Vision Control Behavior > 0 && Vision Control Behavior < 255: Legacy DMX Control for Vision DMX Adapter only
Values 1-254 are legacy behavior for the Vision DMX Adapter only. They are still DMX Control, but for this Vision DMX frame only the fixture uses the DMX Personality with the same number. Do not change the fixture's saved DMX personality. For normal app integration, focus on 0 = DMX Control and 255 = App Control.
| Vision Control Behavior | Control behavior |
|---|---|
| 0 | DMX Control using the fixture's saved DMX settings |
| 1 | Legacy / Vision DMX Adapter only: DMX Control using DMX Personality 1 for this frame only |
| 2 | Legacy / Vision DMX Adapter only: DMX Control using DMX Personality 2 for this frame only |
| ... | ... |
| 255 | App Control using fixed App Control settings |
WRITE_DMX
This function should always be used, even if Vision is not the selected interface. Write the fixture's DMX input to this register. This can be used to diagnose the DMX input or to transmit the DMX frame over Vision. Select a useful refresh rate depending on the use case and the controller load. Use a maximum refresh rate of 20ms.
Handle DFU
A device firmware update is only defined through the SPI transmission. So the transmitted data has no specification at all. Its a raw byte stream. It is recommended that error checks are implemented in the file.
Handling a software update is done through READ_DFU and WRITE_DFU function. The following interrupt lines must be used to derive the state:
- DFU_START_IRQ
- DFU_PACKET_IRQ
- DFU_STOP_IRQ
Whenever a software update is triggered, the DFU_START_IRQ goes high.Then the fixture must get ready for receiving firmware. One of the following responses of the Fixture is required:
- 0x0: DFU_ACCEPT
- 0x1 – 0xFF: DFU_ABORT
A fixture responds by using WRITE_DFU function. The Timeout for the response is set to 20 seconds. Writing a response will disable the DFU_START_IRQ flag. After accepting the DFU, the Vision Controller starts to send firmware packets. Each packet has a unique id which is counted upwards. Length is variable up to 200Byte. Default length is 128 Byte. packetNr is stored in Big Endian, not Little Endian.
| data[0] | data[1] | data[2] | data[2] | ... | data[202] |
|---|---|---|---|---|---|
| packetNr | packetNr | data[0] | dmx[1] | ... | dmx[200] |
After reading the packet, the next packet will be transfered automatically. No extra response necessary. If there occurs an error it is possible to abort the DFU early by writing a response greater than 0 (0x1 – 0xFF).DFU is aborted if no packet is read for 30 seconds.After receiving the last packet, DFU_STOP_IRQ flag will go high in order to signal that all packets are transfered and DFU transmission is finished.Now a last response from the fixture is required. The response should be one of the following:
- 0x0: DFU_SUCCESS
- 0x1: DFU_ERROR_FLASH_ERASE
- 0x2: DFU_ERROR_NOT_IN_PROGRESS
- 0x3: DFU_ERROR_CORRUPTED_HEADER
- 0x4: DFU_ERROR_CORRUPTED_IMAGE
- 0x5: DFU_ERROR_INVALID_IMAGE_VERSION
- 0x6: DFU_ERROR_NO_PREAMBLE
- 0x7: DFU_ERROR_INVALID_FIXTURE_ID
- 0x8: DFU_ERROR_UNKNOWN
- 0x9: DFU_ERROR_SIGNATURE_NECESSARY_NOT_FOUND
- 0x0A: DFU_ERROR_PACKET_TIMEOUT
- 0x0B – 0xFF: Reserved
