Go Down

Topic: microcontrollers for RS485 (Read 5237 times) previous topic - next topic


Jun 11, 2012, 07:19 pm Last Edit: Jun 11, 2012, 07:41 pm by inoukdemers Reason: 1
Hello everyone,

I posted something a week ago on a new project I'm working on: 8 QRD1114 optical sensors spread out in a room, all linking back to the Arduino (and then sending serial data to Max/MSP software on the computer). Connecting the Arduino to a MAX485 chip, I could convert RS485 incoming sensor data (running through about 50 feet of cable) to TTL for the Arduino.

From what I've read, the best setup would be to daisy-chain all the sensors to MAX485, with each sensor communicating back to MAX485 through to its own microcontroller. Each microcontroller would need its own address. The projects I've seen online seem to use Arduinos at all nodes, but for me this would be too expensive. Can anyone recommend some small, inexpensive uC's for the job? They would have to work with RS485, be relatively easy to program, and be able to have an address assigned to them (maybe they all do the latter, I'm new to this).

Maybe ATtiny85? Apprently those are programmable with Arduino. Maybe I could even hook up 3 or 4 sensor inputs to one of those.

The sensors would be used for coin drop purposes, running at about 9600 baud, so the Arduino would need to monitor the sensors continuously (receive mode only).

Thanks for your help!


A simple Arduino (not a pre-built one as the UNO but a "self-made") cost you about $5 plus about $4 for the MAX485. Your whole network of sensors cost you less then a hundred bucks then including your main Arduino.

And who told you that you must have RS485 to connect them? 15m of cable shouldn't be a big problem with a standard TTL signal if you include some error correction into your software. So you could use a simple two wire signal (I2C) with a low signal rate.


Pylon, thanks for the reply.

If possible, to save time I'd like to avoid making my own Arduino; also, chips like the ATTiny go for about $2.50 -  call me cheap ;-)

Maybe there are chips that send TTL, but because the site for the installation is in a museum in Germany, I'd like to err on the side of caution and use something that can handle longer distances, just in case.

I'd read about I2C - seems that was designed more for "on board" lengths, with power being supplied individually at each node?


I don't see your price calculation. The amount of work to make an ATtiny work is about the same as an ATmega328 (ok, maybe a cap and a resistor less) and the ATmega costs about a dollar more. Think about how much time you need to optimize your code to live with the smaller memory (and less pins probably) and you wanted to have spent that dollar.

I wouldn't use I2C itself (it's about 10 times faster than what you need) but build it with standard digital IO pins. Usually I2C has one set of pull-ups per bus, power distribution is separate.

Coding Badly

Can anyone recommend some small, inexpensive uC's for the job?  ... The sensors would be used for coin drop purposes, running at about 9600 baud, so the Arduino would need to monitor the sensors continuously (receive mode only).

Your "job" description is inadequate.  At this point, it's impossible to tell if a per-sensor microcontroller is even necessary.

Generally, what works best is for you to describe what you want to accomplish starting from the user's perspective.  What you've described is only from the designer's perspective.  In other words, you have yet to tell us what problem you are trying to solve but instead told us what you think the solution is.


Coding Badly,

I had described the project just as you say in my previous post; this time I was trying to narrow things down, because the range of answers I got the last time around was starting to get bewildering...!

In a nutshell, the installation involves participants dropping coins into 8 boxes distributed around the museum space. The coins fall inside the boxes, hitting a platform that tilts, which falls in line with the QRD1114 sensor. I want my Max/MSP software to listen continuously for each time the sensor signals cross a threshold, which acts as a control mechanism for the audio events over the loudspeakers. I'm estimating the total distance covered by the boxes will be 25-50 feet.

Pylon seems to suggest I hook up the sensors to DIY Arduinos (using the ATMega 328) so they can act as I2C slaves to the Arduino master.
The question of whether these should be hooked up on a per-sensor basis, given the fact that the boxes are spaced out, is one I'm open to hearing answers on. Maybe I could break it down to 4 sensors for each ATMega or something. I'm not sure what is meant by "building I2C" with digital pins, unless that means making a simple 2-wire connection between an Arduino and an I2C slave.

Just trying to find a simple, cost-effective solution, since the bulk of the project will be in the Max/MSP patch. I appreciate the input!

Coding Badly

I do appreciate your willingness to re-describe your project but a link probably would have been sufficient (hint, hint).   ;)


Hey, I'm a generous guy ;-) Besides, I was dealing with other issues before, so I figured a new description was in order.

Any thoughts?

Coding Badly

Jun 11, 2012, 11:29 pm Last Edit: Jun 11, 2012, 11:31 pm by Coding Badly Reason: 1
Any thoughts?

Lots.  Some even relevant.   :D

I2C may work.  However, 25-50 foot distance introduces some potential problems.  Examples...

How will the "remote nodes" be powered?  I2C requires a common ground.  Will that work with your power supply plan?

Will the communication cable run near any high voltage?  Or does an electrician decide?

Will you be using appropriate cable?  Do you know what cable the I2C specification requires for that distance (I don't).

This is a quote from someone who claims to have used I2C extensively, "If you are talking about distances longer than about 2m I strongly recommend against using plain TTL signals."

Some reference material that may help...
Philips 82B715 bus extender

RS-485 will work.  It was specifically designed for what you are trying to do.

It's a question of money, time, and risk.  Obviously, using I2C directly is going to require less hardware (no RS-485 converter).  But, you will have to research and apply the constraints to ensure it works.  And, if you make a mistake, there is a high probability that the system will be plagued with problems.  Were I in your shoes, I would most definitely use RS-485.

Coding Badly

For the microcontroller, I believe an ATtiny2313 (or its bigger brother the ATtiny4313) is a good choice -IF- the RS-485 converter communicates with the microcontroller via serial.

If the RS-485 converter communicates with the microcontroller via SPI or I2C then (nearly) any AVR processor will work.

What you really need is a 1-Wire latching input but I don't think Maxim makes such a thing.


Ah! I breathe a sigh of relief.

I did indeed read about I2C, but seeing that the maximum capacitance is 400 pF gave me pause. For a cat5 cable running at say 13 pF/ft, that wouldn't get me beyond about 30 feet. I could use shielded Cat5/6, but that wouldn't change the distance limitation.

So it's back to RS485, it seems. So far I see three sites that use the ATtiny2313 with Arduino via MAX485. Thanks CB!


Jun 15, 2012, 02:25 am Last Edit: Jun 15, 2012, 02:31 am by woganaga Reason: 1
It looks like the collector/emitter on the sensor can take up to 30V according to the datasheet.  I would try something like this, hopefully someone with more expertise could chime in.  

Basically use telephone or intercom cable (4 conductors), 2 for the LED and 2 for the sensor collector/emitter.  Run the sensor circuit at 12V rather than TTL levels.

RS485 network of uC's seems like overkill for transmitting the state of a sensor that is only sensing a low or high state and the switch time is relatively long.

Interested to hear how it turns out!


I don't know if this is still relevant or not, but Yourduino sells a 10-pack of MAX485's for $2

Go Up