Update for DMXSerial2 the DMX RDM library for Arduino

IT’s some months ago since I released the first version of DMXSerial2. Now there is an update with some fixes and some more complete functionality.

First of all thanks to Simon Newton who shared the link to a copy of the RDM standard E1.20. A download is available at http://tsp.plasa.org/freestandards. “Now there are no more excuses for not complying with the standard” – he writes and I will try to do so.

In the update you can the following additions:

• The serial port definitions now also support Arduino MEGA 2560 (port 0 and 1) and Arduino Leonardo (port 1) boards.
• I registered my own manufacurer id, now #0987 for mathertel.de.
• There is a functionality that creates random device ids in the code. If a board once has started to work the device id will be stored into the eeprom and will remain there even when new software is uploaded.
• I added the required RDM parameters SOFTWARE_VERSION_LABEL and SUPPORTED_PARAMETERS to comply with the standard.
• Finally I removed some DMX-only specific code and did some simplifications and memory optimizations.
• The initialization data for the library is now combined into a new structure.

It was an easy job to register a manufacturer id to myself as explained on http://tsp.plasa.org/tsp/working_groups/CP/mfctrIDs.php. Feel free to use my manufacturer id yourself if you promise only to use it for experiments and never to put a real device that leaves your hands.
If you plan for more please request your own manufacturer id and adjust the _devID definition to use it.

You can find the new version of the library now on http://www.mathertel.de/Arduino/DMXSerial2.aspx.

I will update the text of this site in the next days.

Arduino Shield for NRF24L01+

Here is the picture of a brand new Arduino Shield for the NRF24L01 on top of an Arduino UNO:

It’s the first version and it works :-) so I finally soldered a transceiver directly onto it.

Signal layout

The signals for the SPI bus come from the ICSP connector to make it compatible to Arduino boards that do not have the classic ATmega328 (2009, UNO) but use other processor ICs like Leonardo, Mega. Here the MIIS, MOSI and SCK signals are not D12,D11 and D9. Using the ICSP connector is compatible.

The CSN and CE signals can be connected to pin D7 and D8 by using little solder drops on top of the shield that you can see on the right. Using these 2 pins because they do not conflict with other cards I use (Ethernet, SDCard). Initialize the RF24 radio class by using:

RF24 radio(7,8);

If other pins must be used, the 2 solder pads can be kept open and some wires can be used to pass the signals.

The IRQ signal is available on pin D3 the same way, but I don’t use it yet.

The rest of the shield has a permanent breadboard layout for small robust implementations.

In the back you can see another connector for I2C bus that I use to connect other hardware like LCD panels.

Prototypes:

Before I had 2 versions in place that I made. The first one was a “flying” transmitter that was perfect for finding the right pins and setup. The second one is sitting on top of an DMX shield.

See also:

Hints on using NRF24L01+ with Arduino

This is a first version of a NRF24L01 shield, especially the breadboard it not perfect. I ordered more than I need so if you are working on a NRF24L01 project and like to have one – let me know. (first come first serve)

Update for the DMXSerial library

There is a significant update for the DMXSerial library on my web site that enables programming DMX devices on ARDUINO MEGA boards and ARDUINO Leonardo boards using the DMXSerial library.

The original library was written for Arduino 2009 and Arduino UNO boards that use the ATmega328 or ATmega168 chip. These chips only have a single Universal Synchronous and Asynchronous serial Receiver and Transmitter (USART) a.k.a. the Serial port in the Arduino environment. The DMXSerial library uses this port for sending or receiving DMX signals.

This conflicts a little bit with the usage of the programming mode the Arduino offers through then USB ports or serial interfaces but it is possible to build compatible DMX shields that don’t interfere with this usage if done right. The DMXShield is an example of this.

Arduino Leonardo

The Arduino Leonardo board uses a chip that has a USB 2.0 port available in addition to the USART. Therefore the “Serial” port is routed through the USB port that behaves like a serial port device and not the built-in USART. If you like to address the real Serial port you have to go with the Serial1.

But if you look at the hardware and the registers directly the USART0 still exists but the definitions for addressing the registers have changed (for example USART_RX_vect is now USART0_RX_vect). Therefore some adjustments had to be done.

With this board you can write debugging information to the Serial port in your sketch for debugging or data exchange purpose. So maybe a DMX diagnostic sketch can profit from that.

Arduino MEGA 2560

When using the chip on the Arduino MEGA 2560 board you have more than one USART available and maybe you wish to use port 1 instead of port 0. This can be done by enabling the definitions for port1 in the library just uncomment the line

#define DMX_USE_PORT1

ATmega8 boards

I added the definitions of boards based on the ATmega8 too for experimental purpose. If you find problems with these boards, leave me a note please.

Thanks to Bob Lynas to support me.

Available

The updated version is available on my site at: http://www.mathertel.de/Arduino/DMXSerial.aspx.

Using the SPI bus with Ethernet, SD-card and NRF24L01 and other slave devices together

I currently work on an project using the popular NRF24L01 module where I came across the question how to avoid conflicts of new designs and existing Arduino boards.
The problem when using the W5100 based Ethernet shield including the  SD Card adapter and the NRF24L01 Modules together with a Arduino UNO board is that all of them are using the same SPI bus for the data transfer to the chips. Here is an overview of how to make them work all together.
Here the master is always the same ATMEGA328 chip on the Arduino board and the 3 chips are slave devices.

The SPI bus concept

A brief explanation of the SPI bus can be found on wikipedia. See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
The SPI bus needs 4 signals to work:
SCK or SCLK (serial clock) The clock signal that sets the tempo for any data transfer. This signal is generated by the master chip.
On the Arduino Uno this signal is available on pin 13 and ICSP 3.
MISO (master input, slave output) This signal line transfers the data from a slave device to the master chip.
On the Arduino Uno this signal is available on pin 12 and ICSP 1.
MOSI (master output, slave input) This signal line transfers the data from the master to the slave devices.
On the Arduino Uno this signal is available on pin 11 and ICSP 4.
SS or CSN (Slave Select) This signal makes a slave active by selecting it with a low signal.
On the Arduino Uno this signal has to be discussed…
Remark: The signal lines SCK, MOSI and MISO are also available on the ICSP header, see below.
The signal lines SCK, MOSI and MISO can permanently remain connected to all participating chips. However the Slave Select signal has to be different for every device.

Advantages in using the ICSP header

The SPI signals on an Arduino Mega board are not available on the pins 10, 11, 12 and 13 because this board uses another processor. But because programming an ATMEGA chip through the ICSP is internally also using the SPI interface, the signals are available on the ICSP header too. With the Arduino Ethernet Shield Version 06 the design has changed so that the SPI signals are not taken from the pins 11, 12 and 13 but from the pins ISP 4, 1 and 3. If you use an Arduino UNO or 2009 however these pins are connected on the main board.  When designing new shields for Standard and MEGA boards with SPI usage I recommended using the ICSP header like the Ethernet Shield does.

Pin 10

The Arduino pin 10, also labeled SS, also known as PB2 for ATMEGA328, is used by ATMEL to indicate whether the processor is used as an SPI master or slaver device. That pin 10 must remain an output or the SPI hardware will go into 'slave' mode.
Using this pin 10 for example on the Ethernet Shield is fine, but if you use other SPI slave devices, keep in mind to no use this pin for input purpose – better don’t use it to avoid conflicts.

Using multiple SPI bus slave devices

When using multiple slave devices on the same SPI bus there is no principle problem with the lines SCK, MOSI and MISO. Because every slave device needs its own slave select signal there are conflicts using the available Arduino pins. When you stack multiple ARDUINO shields on a single Arduino board you may also have conflicts with other pins the shield uses so you have to take care of other conflicts too. Here are some common pin usages:

Arduino Shield	Salve device	Arduino Pin
Ethernet version 01	W5100 chip Slave Select	10
Ethernet version 06	W5100 chip Slave Select	10
Ethernet version 06	SD card Slave Select	4

Using a NRF24L01 radio module

In different samples where the NRF24L01 radio is using the Arduino pin 9 for SS and using pin 8 for the Chip Enable signal but also 8 and 7 is used in same samples. There is no standard definition right now and therefore you have to tell the NRF24L01 library what signals to use for Slave Select and Chip Enable.
I personally recommend using 7 for Chip Enable and 8 for Slave Select because the pin 9 is one of the possible PWM output pins. When designing new Shields these pins assignments should be changeable in any way, just to be friendly to other shields… and having the chance to settle conflicts.

More Readings:

Design of the Arduino Ethernet Shield: http://arduino.cc/en/Main/ArduinoEthernetShield

Using the SD-Slot on the EthernetShield with Hardware SPI: http://playground.arduino.cc//Main/EthernetShieldSDHardwareSPIMod General tutorial: http://tronixstuff.wordpress.com/  About the NRF24L01: http://playground.arduino.cc/InterfacingWithHardware/Nrf24L01

Important DMXSerial Library update

Thank to Jonathan L for this brilliant work on fixing some timing conditions with the sending side of the DMXSerial library.

From his comment:

I'm sure the existing timings (81us break) are pretty much fine with almost all DMX inputs, even though the spec says that the transmitted break time needs to be >= 92 us with MAB >= 12 us.   Nonetheless I was motivated to fix it to be as close to 100 us/12us as I could, as this is what is transmitted by most of the commercial DMX units I've seen.

The real issue would be if you ran this on a faster processor, in which case the timings would break when the interrupt service routine became faster than the byte time.  I was running this on 16 MHz Atmega 328.  Most of the ISR is spent doing the long division inside DMXSerialBaud(): I replaced it with a compile-time calculation of the prescaler value, and this results in trashing the last data byte and the break.  You can see the results in attached timing23.png.

Happily all is fixed by the changes, although the code is a bit more complex.

I studied the changes to the routines and I understand h did everything. It's all well commented and I like his programming style too. I loaded it into a project I have done some months ago and it works fine.

I personally haven't used much the sending part of the library. The last projects were lighting systems that are controlled by DMX used the receiving part only and I found it reliable but he fixed a buffer bug in this too.

The DMX spot PCBs finally arrived

After 2 weeks of waiting the first shipment of the PCB board finally arrived.

I can not wait to soldering the parts together.

My first impression is that the arrangement of the components fits well. If I find out that the circuit works as intended, I'll publish the Eagle files on my website.

DMX Spot project

The aim of this project is to build a small PCB board for RGB LED installations and to use the DMX protocol for controlling.

I build this board because I want to have a permanent and robust solution for light installations and I like to release my Arduino board for other projects.

Also, when using a standard Arduino board there are many components built in that are not used at all. For a simple DMX solution the ATMEGA 168 that was used in older Arduino versions is powerful enough and still provides enough memory for complex programs. So all you can find on this board are the minimum components for a 3 channel DMX receiver and the components to drive LEDs with a voltage around 12 volts or higher.

Because I started with an Arduino board many characteristics of the Arduino design remain:

• The processor can be a Atmel ATMEGA168 or ATMEGA328.
• The clock speed is 16 MHz.
• The surrounding elements like the capacitors have the same values.
• The software implementation uses the Arduino environment.
• I can reuse all the source code I have written so far for my Arduino.

The additional parts compared to the Arduino board are the chips of the communication interface that is able to receive DMX signals including an isolation and 3 Mosfet chips for driving LEDs.

The board uses only standard through-hole soldering components allowing an easy building for hobbyists like me.

Here are some pictures of the Arduino assembly and from my first prototype.

There where several problems with the first version so I had to patch some wires and add some components on the back. Not good enough to be published.