0
\$\begingroup\$

As per the DALI light-control standard protocol, DALI bus communication uses Asynchronous half-duplex(two-wire) serial communication. It uses Manchester coding at 1200 bits per second(baud). A DALI bus can have up to 64 slave devices in the network.

I am trying to implement DALI protocol on STM32E407 (as Master) and STM32F3Discovery board (as Slave). I am looking for some practical advice on implementing DALI communication.

I have a few basic questions about DALI communication:

Is DALI protocol itself is a byte transfer mechanism or is it a software level packet layer (like CAN)?

If DALI is a packet layer mechanism, which byte-level transfer mechanism will better suits for it?

If it is the popular asynchronous communication protocol UART(or USART), how good is UART(or USART) for multi-processor communication (for around 64 slave devices)?? and at micro-controller level, how much faster the serial interface (UART or USART) should be to "DALI 1200 baud rate" for efficient execution Manchester coding?

Thanks in advance!

\$\endgroup\$
0
\$\begingroup\$

DALI describes the physical layer, the protocol and the command set.

It is not really a UART type protocol (unless you had external manchester coding), and the usual way to implement is couple of opto isolators and a transistor plus some passives for the the physical layer (Which must be isolated) a timer or two generating interrupts plus a couple of pins with interrupt on change for the IO.

For transmit you set up a 2400Hz interrupt and generate the biphase in software in the ISR.

For receive you use the interrupt on change and a timer to write a simple state machine to extract the 24 bit (IIRC) messages).

The gotcha with DALI is the need for a random number generator for the auto discovery stuff, finding sufficient entropy in a device with no user IO can be a bit of a pain.

Note also that to be DALI compliant you need to hit the dimming curve for your luminare type fairly closely, and DALI uses a log curve (Unlike DMX).

\$\endgroup\$
  • \$\begingroup\$ This is very confusing as to which answer should I accept. All 3 answers correctly address my question. Mr.Martin gave some practical suggestions, Mr.DiBosco has given a very clear and simple answer and you have explained the exact communication mechanism. Somehow, I can relate to your answer more, so the Accept. Thanks! \$\endgroup\$ – charansai Nov 21 '17 at 12:29
1
\$\begingroup\$

DALI messages are commands (eg Off, Go To Scene 3), configuration commands (eg Set Min Level), queries (eg Query Min Level) or responses (eg Yes). Some commands, mainly the configuration commands, require bytes to be transferred because the message is too small to contain the command, addressing and data. So to set a min level, you have to transfer the required value to the DTR0 of the gear before you issue the Set Min Level command, and you have to send the Set Min Level command twice within 100ms. You can also read back the DTR0 value, and other DTR values (DTR1, DTR2).

It is not practical to use standard UARTs to transmit or receive DALI because of the Manchester coding and the bit and frame timing requirements.

Efficiency of bandwidth with 64 control gears is achieved by using group addressing. If you are interested in multiple masters, then you would need to implement the multimaster timing including collision detection, avoidance and recovery as specified in IEC 62386-103.

\$\endgroup\$
  • \$\begingroup\$ The wheel keeps being reinvented. I was working on stuff like this around 1980 \$\endgroup\$ – Dirk Bruere Nov 21 '17 at 10:35
1
\$\begingroup\$

DALI is an extremely simple two byte (16-bit) per message protocol , that is also quite complex and clever in its implementation. The master sends out messages over the network that all nodes receive and process (or ignore). Slaves can, but do not always, send [8-bit] replies back to the master.

You will quite happily be able to implement master and slave with your two devices, but you will need to make little hardware adapter boards as "transceivers" and a bus supply. There are lots of examples around. Atmel, Microchip and NXP all have very useful apps notes on this. An example of a transceiver that you need on each node is below.

enter image description here

You could definitely implement much faster comms with a UART and could do 64 nodes per network with no problem using RS485 and some protocol run upon it. However, speed is not the point here. Noise immunity and ease of wiring (including very flexible topology) are paramount - you can connect the wiring either way round with DALI. Something that is definitely not the case with RS485.

You cannot do Manchester encoding and decoding with UARTs, but it is fairly straightforward to bit bash it with a couple of GPIO pins.

\$\endgroup\$
  • \$\begingroup\$ This app note circuit, in common with others, does not have ramp control on the transmitter so may not meet the rise and fall time requirements under all (any) conditions. Also DALI-2 is bipolar but DALI-1 was commonly, but not always bipolar. \$\endgroup\$ – Martin Nov 21 '17 at 10:43
  • \$\begingroup\$ So, I have misunderstood the whole thing since a long time. I have actually already got two dali-clicks but was thinking for prototype model, I don't really need them and they are just for making DALI bus!! So, the entire DALI is software implemented with appropriate interrupts and timers! \$\endgroup\$ – charansai Nov 21 '17 at 11:49
  • \$\begingroup\$ @charansai, those clicks look like the hardware interface (or transceiver if you like); yes you need them or rather something like it. One per node (although, if I'm reading the datasheet correctly, it seems to supply one DALI power supply per click and you only need one per bus). The software is implemented by timers, interrupts and bit-bashing, yes. \$\endgroup\$ – DiBosco Nov 21 '17 at 11:56
  • \$\begingroup\$ @DiBosco the given supply pins are for hardware elements, we can either use 5v or 3.3v. The click just generates the bus (is just DALI PHY layer) and the DALI supply is to be provided externally. \$\endgroup\$ – charansai Nov 21 '17 at 12:03
  • \$\begingroup\$ @charansai I think we're talking about the same thing in a different way. Yes, it looks like the PHY/transceiver. What voltage you use on the processor side of the optos is, indeed, up to you. I think you have it sussed :) \$\endgroup\$ – DiBosco Nov 21 '17 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.