Hi Folks,

I have a microcontroller-based project that I could sure use some guidance on. I have had extremely limited (that is to say, 'almost no') exposure to the universe of ICs available, so I'm having some trouble picking the right tools for my task.

In a nutshell: My microcontroller device must talk to a *remote* device (that I will build) in order to (a) obtain the open/closed status of 16-32 (16 is typical but must plan for 32) microswitches and (b) fire 8-16 (again lower number typical) devices with a 12V signal to their input pins. So I'm looking at 32+16=48 IOs. Remote means 5-30 feet.

Would be pretty straightforward except for some requirements:

1. Communication with the remote device *must* be via RS485 to accommodate a future '485 device that will be installed. Except for returning the status of the switches the remote does not need to send any data.

2. The 'master' and remote must be connected with no more than one eight conductor ethernet cable.

3. I must send 12VDC and ground down that cable.

4. Cheap is good but not an overriding concern. This will be a limited-deployment device with at most 1000 units placed. An extra buck or two won't preclude a potential solution.

So...

I have 4 wires used with power, ground, 485+ and 485- and thus have 4 left for 'whatever'. I'd love to use one of those to power the remote so I don't need a power supply (down from 12V) on the remote.

Again not having had much experience my inclination is to just throw the smallest, cheapest microcontroller (probably a smallish PIC16) that has a USART into the remote along with a 485 tranceiver. Then use 74HC165s to get the status of the switches and 74HC595s (with compound transistors) to fire the devices. I think this would work but my concern is that the part count seems a bit ridiculous (a uC and 6 ICs not counting the 485 to do a phenomenally simple task).

Another approach would be to use a uC on the remote that has enough IOs to handle all 48 items.

Something in the middle would be to use a somewhat smaller uC and multiplex the IOs, perhaps with something from the 4000 family.

And then there is the possibility (how remote I don't know) that I could get away with not using a uC at all - instead expanding 3 or all 4 of those extra inputs and using the 485 lines to clock in/out data (low speed is ok) to/from the other chips from the master. Other factors aside, this would be ok because the 485 lines are really just there in case we move to a different device that uses 485 and will eliminate the 48 IOs (reading and firing all over 485). This sounds cool but my gut feeling is that I'd just be replacing the uC with a few simpler chips and increasing both the part count and complexity of the device.

Can someone help me think this through or suggest something different?

Thanks!

One small point of clarification after reading another guy's closed stun gun thread: The devices I am "firing" are solenoid locks, not missiles, bombs, stun guns, pyrotechnics or employees! They have integral switches to indicate the locked/unlocked status of the lock.

 

Sounds like you could get away with using a really teeny tiny PIC, an RS-485 transceiver and some shift registers or serial input driver chips- cheap and cheerful.

Use half-duplex, (only 2 wires) set the idle line bias voltage with 3 fixed resistors on one end.

If you are driving something mechanical, it probably doesn't need to be super fast?

Use the UART in the chip, bit bang the serial to the shift registers.

The hardest part is designing the serial protocol so you don't get angry with yourself down the road when you need a new function.

 

I don't quite get your whole system, but for adding I/O to a PIC there exists "INPUT/OUTPUT EXPANDER" chips, basically a serial (I2C or perhaps SPI too) device (so they need 2-3 pins off your PIC) that control 8 or 16 lines per chip (and up to 16 chips) as extra I/O lines.

However, I've always found it easier and cheaper to get all my I/O off the main PIC, so I would get whatever device necessary "to use a uC on the remote that has enough IOs to handle all 48 items."

 

If I were doing this I'd use one wire pair for communication, and all the others for +12V and Gnd so as to minimize the voltage drop in the wires. Then I'd have a regulator for 5V out at the remote end, and I'd know that it really was 5V. And I'd activate/read the external I/O lines via SPI from the processor, in other words shift registers (74HC595 or 74HC165). But you can get "power shift registers" that can drive solenoids directly, so you can reduce the chip count if you use them.

 

Ok, guys thanks for the input.

So it sounds like either using a tiny PIC with the '165s and '595s -or- a single PIC with enough IOs will be reasonably sane.

FWIW, I am not driving the locks directly. I will be providing constant power (12V) but the firing signal is no more than 25mA for 20-30 ms and the lock just does its thing by itself after that. @John, Good point on using the extra wires for power and ground.

 

Over many years, I've implemented various systems using all of these approaches/options at various times and in various combinations.. Each comes with trade-offs but here's a distillation of what has worked the best for us.

Use on-card regulation for each of your remotes. Double up power and ground on any unused wires. When pinning the connector, make sure a mis-inserted cable (RJ45 on backwards and the like) won't fry your system.

Use RS485 for reliable medium haul comms. If you are contemplating adding a commercial RS485 slave, its protocol will have a lot to do with what your current one will be. If you are going to develop that slave as well, you can do what you want.

A 2 wire RS485 master to many slaves is easy enough to implement but you must define a protocol to sort out the communications. I've used a variant of Access.Bus for years and it's a good starting place. Basically, you want the master to send out a slave address, messageID or OpCode, length if variable length data is used, the data itself, a checksum or CRC to validate the message. I also add the sender's address and start/stop framing characters for robustness and future-proofing. Once the addressed slave processes the message it sends an ACK (or NAK if something is wrong) and the bus is free for the next master message. Only addressed slaves are allowed on the bus. Bla bla but you get the idea. Don't forget the importance of sanity checks on the comms. Slave message received in time? No slaves responding?

If you only have one slave, a 4 wire RS485 makes the protocol easier (full duplex). Multiple slaves will still require some sort of protocol.

If you keep your data packets in ASCII, it becomes trivial to monitor bus transactions with an RS485-RS232 converter and a PC. Avoid raw binary in the data unless you provide escape sequences to prevent confusion between data and message fiducials, CRCs etc.

Use a hardware UART running under interrupts for both TX and RX and provide large buffers for each to keep life pleasant.

My personal view on adding I/O is to scroll down the list of available processors to get one with the on-board I/O that you need. It only looks more expensive until you consider the parts cost and PCB real estate required for the extra chips not to mention more PNs on the BOM. I've used shift regs, I2C IO expanders and the lot over the years. Sometimes you have to. With any new designs, I buy parts with sufficient I/O from the get go. 'nuff said.

If you are considering an 8 bit PIC, go with the 18F. Any perceived cost savings that you are getting with 16F are largely illusionary. Why go lower end and pay the price in reduced performance, memory and ease of use?

I've used both C and assembler to do this sort of thing. I prefer assembler but have products in the field chugging away doing RS485 in C.

YMMV but that's how I would do it.

Haven't I seen you on VAF??

 

If you are considering an 8 bit PIC, go with the 18F. Any perceived cost savings that you are getting with 16F are largely illusionary. Why go lower end and pay the price in reduced performance, memory and ease of use?

very good advice.

And while you are at it, throw all your old LM324's in the trash too.

 

Hello,

sounds like an SPI based I/O expansion(maybe opto isolated) would be an option to interface to an industrial like environment. An application of this kind you find with the iC-JX here: http://www.ichaus.biz/wp1_mcu_interface and the DS here: http://www.ichaus.biz/product/iC-JX . An example PCB: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=9556&sid=a98d84943f7db20dd53348135d463765

Enjoy your electronic design work!