1
\$\begingroup\$

I am trying to figure out how to achieve the master-slave configuration shown below.

The aim is to individually address an array of 150mA LEDs, driven by the IS31FL3265A PWM driver. For this specific application, I am tying the driver's outputs in groups of 3 to achieve the desired current. The IS31FL3265A supports 16 different slave addresses, but those need to be hardware-configured and are limited in number.

I am hence thinking of another possible solution, where my controller addresses a series of microcontrollers with configurable addresses (could be simple AVR processors?) on an RS-485 bus.

I would like the microcontrollers to all run the same software, but their unique ID should be configurable (increase/decrease) through two buttons on the PCB hosting them. In turn, they should communicate through I2C with the LED drivers to dictate which LEDs will light up at any given time. My master controller (the Teknic ClearCore) only supports RS-232 serial communication, so I presume I will need some kind of converter to achieve long-distance multi-node communication.

Could anyone help me understand how I could achieve such a configuration? What components are needed and what details should I take into consideration when trying to build this? What protocols are required to ensure communication between all the parts involved? Is there just a better and more straightforward way to make this work?

Thanks in advance!

enter image description here

\$\endgroup\$
6
  • 2
    \$\begingroup\$ It looks like you are basically re-inventing DMX512? \$\endgroup\$
    – Justme
    Jan 21 at 18:29
  • \$\begingroup\$ You need better specs and don't choose a board before the specs osram.com/ds/dali_pcu.jsp \$\endgroup\$
    – Tony Stewart EE75
    Jan 21 at 18:31
  • \$\begingroup\$ how many LEDs are in the array? ... note: count an RGB led as three \$\endgroup\$
    – jsotola
    Jan 21 at 18:36
  • \$\begingroup\$ @jsotola there will be about 100 LEDs, and they are white ones not RGB \$\endgroup\$
    – user11271728
    Jan 22 at 10:00
  • \$\begingroup\$ Why use RS485 bus? Is there a great distance between each LED cluster that drives you to use it? What is the distance? \$\endgroup\$
    – icodeplenty
    Jan 22 at 14:46

3 Answers 3

Reset to default
2
\$\begingroup\$

Since you are using RS485, you must deal with the bi-directional communications nature of this interface. I assume you were not intending to use dual RS232/RS485 converters, which would require many more wires since RS485 needs two wire pairs each. A better diagram to represent your network is this:

enter image description here

Each MCU must control its RS485 chip so that it is normally in receive mode. As you stated, their unique ID would allow each MCU to understand the Controller packet is intended for it, and only then allowed to drive data on the bus when requested. This implies that the Controller packets have a well defined protocol that includes the MCU ID as well as command/data.

I suggest you look at the SDLC protocol (or its cousin protocol HDLC). You only need a small subset of it. This protocol implements a command/data packet between a bus master (your Controller) and slave devices (MCUs). The protocol arbitrates when the slave devices can drive the bus, which solves this issue.

\$\endgroup\$
6
  • \$\begingroup\$ Thanks very much for the detailed reply and for updating the diagram. Could you recommend a simple MCU to get this up and running? Something that can easily be put onto a PCB and doesn't include too many unneeded features (was thinking maybe an ATTiny)? Also any ideas as to how to set up individual IDs for each of them? \$\endgroup\$
    – user11271728
    Jan 24 at 11:02
  • \$\begingroup\$ Any lightweight microcontroller, such as the ATtiny or classic ATmega328P would work fine. I recommend making it easy and go with Arduino based approach. There are HDLC libraries out there. Maybe an overkill for what you are doing, but don't underestimate the complexity of the bidirectional communications (such as the need for timeouts to handle bad communication events). \$\endgroup\$
    – icodeplenty
    Jan 24 at 16:21
  • \$\begingroup\$ Thanks for the clarification! Is bidirectional communication strictly necessary for this application and if so why? \$\endgroup\$
    – user11271728
    Jan 24 at 16:28
  • \$\begingroup\$ The RS485 bus is where the bidirectional communications is implied. Each RS485 chip can receive and drive the same two wires that make up the bus, unlike RS232 that uses separate RX and TX wires. So for RS485 interfaces, each device must control when it drives (sends data) onto the bus to avoid conflicts, unlike RS232. \$\endgroup\$
    – icodeplenty
    Jan 24 at 19:44
  • \$\begingroup\$ That's understood, but can't the RS485 transceivers be hardwired to always receive? That way I shouldn't be worrying about switching direction at any point. Or is there any reason why I would want the slaves to be able to transmit as well? \$\endgroup\$
    – user11271728
    Jan 25 at 10:10
1
\$\begingroup\$

Your network strategy is fine. Multidrop RS485 can be implemented with only a single pair of wires. The master device will send addressed instructions to the slaves, which will be configured to always receive. You can create a setup where slaves transmit replies to matching master messages. You will want to implement a checksum or CRC to verify message integrity before issuing a slave reply.

I strongly recommend using a microcontroller which can detect when its UART rx line is idle, and to frame groups of bytes with a minimum of one bytes worth of idle/delay between them. Most UART handlers are written to expect groupings of bytes with predefined size, and will become permanently misaligned if errors are injected (dropped bytes, etc.). A good example of such a UART is on STM32 devices, but I believe this is a fairly common feature for UART peripherals to have. You'll almost certainly need to write your own handler to perform this framing logic.

RS232 to RS485 should be pretty straightforward; it is just a matter of hooking the UART sides of a RS232 and RS485 transceiver together. You might want to make some considerations about how to manage the DE/RE logic depending on your application. I believe it's possible to implement automatic direction control with a minimum of external circuitry, as described in this TI whitepaper.

\$\endgroup\$
5
  • \$\begingroup\$ What do you mean with "using a microcontroller which can detect when its UART rx line is idle" and why is that important? Could an ATtiny85 be a suitable candidate? \$\endgroup\$
    – user11271728
    Jan 24 at 16:03
  • \$\begingroup\$ I strongly recommend against using an attiny85 for this, as it doesn't even have a proper USART peripheral. STM32 (huge family, all have very good/fully featured USART peripherals) and MSP430 are two examples I know of that have this feature specifically. If you want to use a microcontroller that doesn't have an IDLE detection feature, you can pretty easily write one yourself using only one additional timer peripheral. \$\endgroup\$
    – Ocanath
    Jan 24 at 18:19
  • \$\begingroup\$ Thanks for the clarification. My goal is also ease of implementation, and I don't know if all the extra needed steps to initialise an STM32 or MSP430 would be worth it. Anything more than 8-bit seems wasteful for this application, but correct me if I am wrong. Granted the ATTiny85 is a bad choice due to the lack of USART, the ATtiny202 has one and can be configured as I2C master to speak to the LED driver. Would there be any counterindications against using it or a simple ATmega328P like icodeplenty suggested? \$\endgroup\$
    – user11271728
    Jan 25 at 12:35
  • \$\begingroup\$ microcontroller price is not a direct function of compute value. An ATtiny85 is a bit less than twice the cost of an STM32F0 with fully featured UART. Honestly, the only reason to use an ATtiny for this is if you already bought it. \$\endgroup\$
    – Ocanath
    Jan 26 at 3:00
  • \$\begingroup\$ When I said wasteful I didn’t mean it in the monetary sense of the word. I thought the ATmega or ATTiny would have saved me implementation time compared to an STM32, which can be quite a bit more complicated to set up \$\endgroup\$
    – user11271728
    Jan 26 at 7:47
0
\$\begingroup\$

What kind of distances are you working with? Are you committed to using the Teknic ClearCore as your controller? RS485 is a wonderful standard; very good for reliable long distance connections, but it does have a bit more overhead compared to I2C. I think you will find things a lot simpler if you can stick with I2C. You can use a couple rotary selector switches, such as this one, to set the I2C addresses on the IS31FL3265A chips. if you need to attach more than 16 IS31FL3265As, you can use an I2C multiplexer to split the bus. The Teknic ClearCore is a pretty slick piece of hardware, but it is a pity that it does not have an I2C interface, at least not one that is documented. You could still use it with an I2C bus, but you will need an RS232 to I2C bridge.

\$\endgroup\$
4
  • \$\begingroup\$ Yes, unfortunately for this specific project I am bound to using the Teknic ClearCore, which has been pretty reliable and satisfactory so far. Distance wise I won’t be going over 5m, but it’s crucial that the integrity of the signals is preserved throughout. In terms of RS232 to I2C, how practical would that be and what specific hardware is required? \$\endgroup\$
    – user11271728
    Jan 23 at 21:06
  • \$\begingroup\$ I've been using I2C for over 5 years. It has some very attractive features (addressability, two wires, cheap, ubiquitous support on microcontrollers). However I can say unequivocally that I will never, ever use it again for communication between devices that aren't both on the same PCB. There are too many little details (open drain, software and hardware that considers the 'happy path only' which lead to terrible robustness to errors) that cause it to be unreliable or just permanently break until a device reset. \$\endgroup\$
    – Ocanath
    Jan 24 at 18:16
  • 1
    \$\begingroup\$ The ClearCore COM ports have a 5V UART mode, which can make things a lot easier when converting to RS485. It may be possible to use the RTS pin on the COM port to manage the DE and RE pins. \$\endgroup\$
    – Chris Bulliner
    Jan 25 at 8:22
  • 1
    \$\begingroup\$ Modbus RTU or Modbus ASCII are good protocols for use over RS485. The Modbus specifications can be found here. They also contain some suggestions on connectors and cables. \$\endgroup\$
    – Chris Bulliner
    Jan 25 at 8:27

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.