Multiplexing serial line

Question

I have built this ID sensor for a Scalextric slot car track, based on a PIC12F629. The ID sensor sends the ID of a detected car as a RS232 signal on one pin (TTL level).

My question is, how can I receive data from like four of these micro controllers into another micro controller's (PIC18F2550) USART?

I came up with these possibilities:

1. Just connect all of the serial lines "directly" to the RX pin of the PIC18 and hope that two cars doesn't pass any sensor that close in time so the signals are overlapping each other. This could actually be a good start and will probably work 99.9% of the time. I mean, the mathematical probability that two cars are detected that close in time cannot be worth the effort of the other suggestions...after all, it's a hobby project.
2. Implement a busy signal that is raised when the ID sensors sends data and checked before sending.
3. Add some fancy multiplexer chip that eats the serial signals and outs them on a single line.

Each ID sensor chip will be coded with an identifier that is sent as part of the data, so they can be separated at the receiving end.

Update: Added some more info about the sensor hardware.

Answer 1

If you set your protocol up so the cars only respond when queries by the controller, then you can just tie (at the logical level, at least) everyone together.

The trick is whether you have real RS-232 (with 1 = -6 to -12 V, and 0 = 6 to 12 V) or just a standard logic line (1 = VCC, 0 = GND). Either the data sheet or a scope should answer this.

If it's standard logic, it could be really easy. If your sensors can control their output drivers, then program them to not drive the output unless a message is going out. If you have to leave the output driver on all the time, have it drive a transistor or two to make an "open-collector" configuration, connect all the sensors' collectors together, and pull up the connected line to VCC and hook it to your main controller's RX pin. This works because the RS-232 protocol idles at a logic 1 state. If RS-232 signal levels are used, then you have to change the transistor configuration a bit, but it'll still be open-collector at heart.

The main controller simply asks each sensor for its data in sequence. Each sensor responds when queried. That way you don't have more than one driving the RX line at a time, which is the main goal.

Now if you can't get your sensors to speak only when spoken to... then your problem got a lot hard. So much that the simple answer is to give each sensor its own serial port, maybe using 8-pin controllers as sensor managers, which can then be hooked up on a cooperative serial bus. Other techniques, such as collision detection with message retransmission (like 10base-T Ethernet did), are much more complex.

Answer 2

If your sensor can accommodate a "ready" line, and defer any events which arrive when it's not asserted, transmitting them when it is, your best bet may be to send a separate busy wire to each sensor and use an "AND" gate to combine the signals from all the sensors. I would suggest that if you have four sensors, you should cycle the "ready" wires in round-robin fashion, with some "dead" time between them (when nobody is "ready"); if a byte comes in during the "dead" time, assume it was sent by the last active sensor. Set the "ready" time long enough that a sensor will be able to react, and the dead time long enough that a sensor will have time to finish transmitting an event that occurs just before its "ready" line was deasserted.

Edit

Based upon further descriptions, given that apparently each sensor has a distinct known ID number, I'm thinking the best approach may be to have a single serial line which is connected to a PWM output via parallel resistor and diode, so that it is pulled up for 1,900us every 2ms but pulled down for 200us (if one could have a PWM switch between active-low and floating, that would be even better). As soon as a car is seen, a sensor should start the following state machine, keeping track of how many tens of microseconds have elapsed since it began executing.

1. Wait for data line to be high.
2. Wait for data line to be low.
3. Clear line-low timer
4. Wait for data line to go high, incrementing line-low timer (and main timer) while waiting.
5. If timer indicates line was low less than 200us, go back to step 2
6. Keep incrementing line-low timer while watching for line to go low, until that timer reaches some duration which is unique for the node's ID. If line goes low within that time, go back to step 3.
7. Set data line to output, transmit the data at a rate of 16us/bit or so (driving the line actively for both high and low), and start looking for the next car. Note that the data should include the number of 10us intervals that have elapsed between seeing the car and commencing transmission.

Using a UART, this approach should allow one to process cars that arrive on any sensor, in any order, and resolve their timings within 10us, with the proviso that cars will be processed sequentially at a rate of one every 2ms, and sensors will be "blind" between the time they see a car and the main CPU gets around to processing it. Unless there are a really huge number of sensors, that shouldn't pose a problem. Note that the main CPU doesn't have to have any precise timing on anything but its PWM output. Everything else can be inferred from the serial data stream (including the "long breaks" resulting from the PWM "low" pulses).

Answer 3

You can implement a MODBUS protocol in RTU mode with RS485 interface which works fine on PIC(Not that sure about your PIC).

You can have a multidrop line to rest your different microcontroller devices and have a nice communication between them on the serial UART.

You can make your PIC18F2550 as a master which will initiate the transaction from any other 4 controllers.

Answer 4

Use time-division multiplexing. The master sends a sync pulse on a separate line that the slaves use to reset a timer. When a slave has data to send it waits until the timer equals (slave number * timeslot width) ticks before sending. The timeslot should be long enough to send the packet and account for clock inaccuracy between sensors.

Electrically, you may want to pull-up the shared TX line and toggle between 0 and tri-state to transmit instead of sourcing current to assert a 1.

Answer 5

I found this site with a solution called BlackNet. It's based on a pretty simple protocol where the idea is that every node on the network has an own timeslot. I.e. it's some sort of round-robin logic. The last image on the page shows a schema with the least amount of components needed for it to work.

I used this idea and just connected the two sensors that I've built directly to the RX pin on the PIC18F2550. However, I didn't implement the round-robin protocol, but just bit-banging the data onto the line (and hope that only one transmits at a time). So far it have actually worked pretty well...

For future readers: If it's critical that your data always gets through, the solution I've used is probably not a good idea. However, if you rarely sends data and can live with the possibility that it collides and you want the easiest solution possible, I think this one is good enough.