5
\$\begingroup\$

I've got a task in which I need to connect 5 or more ucontrollers to one PC for the purpose of sending data which will be stored in the PC. The conditions are as follows:

  • The ucs in question are PIC 16F877As; each one of them is part of a system that keeps track of the number of screws used(as of now), powered by constant DCV from plugs so power is not an issue.
  • the data being sent are just numbers; the current number of screws used
  • the environment is that of a factory assembly line; the screw counters are used in the line and the env is generally noisy
  • the data received by the PC is to be stored in a table; I figured i can take care of this part later
  • the distance between each PIC is about 2-3 meters; the PC is at the end of the line, about 10 meters, the link between the PIC and PC can either be physical or wireless, although I prefer wireless as it is more hassle free(I think...), although robustness of data sent is priority
  • as usual, the system must be made to be as cheap as possible without sacrificing reliability

I've successfully connected a PIC to PC using RS-232 so I know enough that you can't easily connect all 5 of the PICs directly to one PC using RS; too troublesome and distance issues. What I'm thinking is something like a hub; the 5 PICs connect to a master PIC which in return gets whatever data from the 5 PICs and sends them to the PC. I've read some stuff about I2C and I think that's doable enough. I've also looked up on wireless solutions like XBee; I got SKKCA from Cytron but I dunno how to make it handle many-to-one data communications.

Anyone got better ideas on how am I can pull this off in the least painful, cheap way possible? This entire project is a one-man show so I'd rather keep things simple and inexpensive.

\$\endgroup\$
  • \$\begingroup\$ Have you tried RS485? It's got better noise immunity than RS232 and it's multidrop. \$\endgroup\$ – Jason S Sep 7 '11 at 12:05
  • 1
    \$\begingroup\$ Maybe you just want a multiple serial port adapter? moxa.com/product/UPort_1610-16.htm \$\endgroup\$ – kenny Sep 8 '11 at 12:41
  • \$\begingroup\$ I don't think the RS-232 connection can be maintained at the distances of 5 meters or more, but the device itself is nice. Also, I'm stuck halfway around the world so while I can order it, it's gonna take too long and too expensive. \$\endgroup\$ – Sodrohu Sep 9 '11 at 11:22
  • 2
    \$\begingroup\$ RS232 can communicate at those distances, especially if you don't use a high baud rate. Given what I think your discussing, it doesn't seem like a lot of data so, a slow baud rate (e.g. 2400) can go a long way. lammertbies.nl/comm/info/RS-232_specs.html \$\endgroup\$ – kenny Sep 9 '11 at 12:04
  • \$\begingroup\$ @kenny - For 10m, a slow baud rate shouldn't be necessary. According to your linked page, 2400 baud should be able to run 3,000 feet. \$\endgroup\$ – Kevin Vermeer Sep 27 '11 at 20:15
10
\$\begingroup\$

I don't know how stuck you are on the 16F877A, but that's a poor choice for something like this. Think of the 16 series as being only for special situations, like high volume where a little lower price matters, extra low power, or small physical size. You have none of these issues, and the 16F877A is a old general purpose part anyway.

I would use something like a 18F4580, which has a CAN transceiver built in. Your application is just crying out for CAN. It is a differential bus, so has good noise immunity. Your distances can easily be handled even at the maximum rate of 1 Mbit/s. RS-485 as others have mentioned is differential too, but it stops at the electrical spec. You have to design your own protocol on top of that, considering collisions, retries, arbitration, bit errors, etc. This is of course doable, but there are a lot more little gotchas that aren't probably apparent to you at first glance. There are a lot ways to get this wrong, and most people do, at least the first time.

With CAN, all that is defined in the standard and implemented in the hardware. You send a message, and it just shows up at the other nodes. Multiple nodes trying to transmit at the same time is handled automatically. there is a defined arbitration scheme that the hardware CAN peripherals implement, with automatic retry until the message gets thru. Each message also contains a 16 bit CRC, which is again generated and checked in the hardware.

It will take a little effort to learn CAN and the CAN peripheral, but this will be less than doing your own protocol on RS-485, at least if you do it right. Besides, CAN is a good thing to learn whereas RS-485 is a legacy from a bygone era.

If you can't use a PIC with CAN built in (although there are some with the same footprint as the archaic 16F877A), you can use the external CAN chip that talks to the PIC over SPI. Our free PIC Development Tools release at http://www.embedinc.com/pic/dload.htm includes source code both for driving the external CAN chip and the internal CAN peripheral of a 18F4580.

You will need something that allows the PC to communicate with the CAN bus, but such things are available off the shelf. We have our own USB to CAN adapter which hasn't made it to a product yet, but I'd be willing to publish the design and the source code for it. If I remember right, National Instruments is one of the companies that makes off the shelf CAN adapters for a PC.

\$\endgroup\$
  • \$\begingroup\$ Gets my vote - I agree this would seem like an easy job for a half decent PIC and CAN. \$\endgroup\$ – Oli Glaser Sep 7 '11 at 15:03
  • \$\begingroup\$ +1 for CAN, which leaves more than enough room for future extensions. \$\endgroup\$ – 0x6d64 Sep 7 '11 at 15:09
  • \$\begingroup\$ First time I've heard about CAN. Is it possible for me to do the CAN wirelessly, or is it has to be strictly physical? As for the 16F877A, that's the PIC I'm most familiar with, and the ones I have right now. I'd prefer using them of course, but if the situation calls for better hardware, then I'll have to use the right PIC. How long is it gonna take to implement the CAN system at average? \$\endgroup\$ – Sodrohu Sep 8 '11 at 7:11
  • 1
    \$\begingroup\$ A USB to CAN adapter looks expensive..at least the ones that I found from a quick googling, like this one CANUSB...is there any way I can implement a hub method, with the slaves to master thru CAN, and the master to PC using RS-232? \$\endgroup\$ – Sodrohu Sep 8 '11 at 8:44
  • 1
    \$\begingroup\$ @Sodrohu: CAN is actually a protocol spec that assumes a electrical bus that passively goes to one state and goes to the other state when actively driven by one or more nodes. This is almost always implemented as a differential pair terminated with 120 Ohms accross it at each end. In any case, this doesn't lend itself well to radio. Using radio is a separate issue, and will add considerable complexity to your system. \$\endgroup\$ – Olin Lathrop Sep 8 '11 at 13:24
7
\$\begingroup\$

RS485 is, in fact, the usual solution for this environment. CAN is also a good solution, but might be a bit much for your application. It's really intended for multiple-master setups. You don't need it since you have a PC mastering the bus, though.

There's a simplified version of CAN called the LIN Bus that assumes a single master connected to multiple slaves. It is usually bridged to a CAN bus for more complex networks. Transceiver chips are available that connect LIN to a standard TTL UART and a few PIO pins. Microchip sells three and provides support code.

\$\endgroup\$
  • \$\begingroup\$ Is there any way to make the RS-485 wireless, or is it strictly physical? \$\endgroup\$ – Sodrohu Sep 8 '11 at 8:50
  • 1
    \$\begingroup\$ RS-485 is a physical layer standard for wired connection. Wireless will be more complex to implement than 485 or CAN. \$\endgroup\$ – Martin Sep 8 '11 at 12:40
  • \$\begingroup\$ From your description of your environment, wireless will be far more complex, because your EMI situation will require sophisticated receivers to drag your signal out of the muck, and still require power to every point you need a sensor. It's making a mountain out of a molehill. \$\endgroup\$ – Mike DeSimone Sep 8 '11 at 21:05
1
\$\begingroup\$

Assuming you don't like the proposed RS485 solution, how about using RS232 in a daisy chain? Each screw counting slave echos every non-configuration method.

Another option is RFID, have each screw counting send out an RFID id/message with the screw count as part of its identifier.

\$\endgroup\$
  • \$\begingroup\$ RS232 daisy chain: When one goes out, they all go out. Well, not all, but you get the idea. Also, all microcontrollers have to pass through the full bandwidth in addition to whatever work they're supposed to be doing. RFID would require a scanner near each unit to make sure it stays powered. \$\endgroup\$ – Mike DeSimone Sep 7 '11 at 13:20
1
\$\begingroup\$

Put an RS-485 transceiver on each board and implement a simple master-slave network. I'd use a more modern chip than the 16F877A, such as the PIC16F887, or a PIC18.

\$\endgroup\$
  • \$\begingroup\$ Is there any obvious advantages in using anything more modern that a 16F877A in this? \$\endgroup\$ – Sodrohu Sep 8 '11 at 8:48
-2
\$\begingroup\$

Here the power is not an issue, you can simply go for a wireless solution.

Because you need a low cost solution, i prefer the following....

First you can make a wired USART network where your all RX pins are connected to the TTL side of a singe MAX, and TX pins connected to the same MAX. Assign address to each of the slave. The slaves remains Idle in communication line while continues its all other activities. Send the inputs(number of screws used) to a queue, in this case, simply an array.

Now the master side,

Which is the PC and is connected to the RS232 side of the MAX. You can simply make your own protocol to communicate with each of the slaves. The better way is to use 9 bit communication with address detect. You can make a simple command set as follows,

COMMAND: ECHO_ADDRESS

HEX VALUE: 0XAA

MEANING: If the ECHO_ADDRESS is received, the addressed slave will send his address back.


COMMAND: SEND_COUNT

HEX VALUE: 0XA1

MEANING: If the SEND_COUNT is received, the addressed slave sends the number of data present in its buffer.


I think this solution is cheap and you no need to go for and advanced processor. The processor you selected has enough RAM and ROM.

Now if you upgrade the system to wireless connectivity, the cheapest method is to get ordinary RF transceivers. remove the cable connected to your RX and TX pins, and insert the transceiver there. Connect the same RF transceiver to your MAX. Here the transmitter frequency at the MAX side and the receiver frequency at the slaves must be same and vice-versa.

When selecting the RF frequency, it is better to consider the environment distortions.

Hai,
The wireless i mentioned is not a modern wireless transceiver like Zigbee, Wi-Fi... I suggested a simple RF transciver of low cost. In this case he don't need a high data rate. I use the wireless module of arround $2 for lower datarate communication and it gives a satisfactory performance. Now, about why i suggested wireless, the answer that I think the customer will be more happy if there is no cables or need for additional wiring, and the product looks good.

We can connect many TX pins together. Because our master controlls the bus, the chanses of collission is too low. But you are right there may have collissions due to communication error. We have to protect the device from this collission, it can be done by some electrical isulator.

This may not be a perfect solution but it works for the current situation.

\$\endgroup\$
  • \$\begingroup\$ Wireless is neither simple nor cheap, and it's a poor solution for devices that don't move and exist in an electrically noisy environment. \$\endgroup\$ – Kevin Vermeer Sep 27 '11 at 20:18
  • 1
    \$\begingroup\$ There's also no need to write "Thanks in advance" and "Thank you for listening" beneath all your posts. Your readers will thank you with upvotes, answers, and comments if your post is worth reading. Please stop this practice. \$\endgroup\$ – Kevin Vermeer Sep 27 '11 at 20:19
  • 1
    \$\begingroup\$ Wireless is neither low cost nor simple compared to wired busses like RS-485 or CAN. You also can't wire TX pins of multiple UARTs together, and you have completely ignored collisions. \$\endgroup\$ – Olin Lathrop Sep 27 '11 at 21:45

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.