1. Home
  2. Embedded Programming
  3. MCU with CANbus + 10-bit ADC
  4. Page 2

MCU with CANbus + 10-bit ADC

I've been thinking more about this. It is a pitty that using one UART per node makes more complex the flow control. By flow control I mean how a transmitter knows that the receiver to which it has sent some data has already processed it and is ready to accept more. I don't want to use extra wires in the cables to implement hardware flow control, because that means more connectors and less reliability. With two UARTs per node, I was thinking of using some kind of acknowledgement data to immediately signal the transmitter that the receiver is ready to accept more data. However, with one UART per node, the acknowledgement should travel around the entire ring, to reach the original transmitter, and that can be a hell of a protocol :-)

Some options that I see:

1) Not to implement flow control, and assume, from the point of view of each transmitter, that the corresponding receiver is infinitely fast. I'm a little bit worried, because the MCU needs to be cheap, and the amount of RAM will be very limited. 2) If 1) gives problems at peak times, I could insert forced wait times until problems disappear. 3) The system could start with zero wait times, and slowly and dynamically adjust them, in case problems are detected. For this, the UARTs need to signal that a new word has been received before having read the previous one, which I think is a standard feature. Sounds vague and complex, but might work, though maybe not efficiently enough.

Any ideas?

Best,

Reply to
Mochuelo
Loading thread data ...

Read my eariler post - with the ripple loop scheme, you have very simple slaves. Signal with the 9th bit in uart. When a slave sees a rising edge on the 9th bit chain, it removes the following N bytes (info TO slave), and replaces them with it's messages (info FROM slave), and on these reply bytes it sets the 9th bit LOW. the next bytes simply pass thru, and now the next slave sees these clean bytes, as the first rising edge, so it removes/replaces them. and so on, right around the loop. eg, Slaves have 4 byte packets, master sends 40 bytes. Master sends > 40 bytes with 9th bit low. Starts message, 40 bytes with 9th bit high

1st slave 9th Bit IN = 40_Hi, OUT = 4_Low + 36_Hi 2st slave 9th Bit IN = 4_Low + 36_Hi, OUT = 4_Low + 4_Low + 32_Hi etc Master counts slaves, but inspection of the 9th bit stretch, so the frame size is usually > slaves.

The slave needs to be ready with a small buffer, so what it sends could be from the previous frame (not this one ) if you need a lot of time.

Because every node runs its own baud, we found that having some small gaps between bytes ( extra stop bits ), gives the system more tolerance to baud rate creepages. ( ie your average baud must be less than the slowest actual baud of any node ) IIRC, this was good to appx 1 MBaud

There is no message-address info, or overhead, as the slaves position in the loop sets the 'address', adding /removing slaves can be automatic. Info is fully deteministic, and set by the frame rate.

I think Interbus has a similar scheme.

Suitable uC: The Atmel new AT89LPC213/4/6 series, Philips LPC9xx, or if you need serious analog operation as well, Silabs C8051F41x series....

-jg

Reply to
Jim Granville

Ok, now I understand. Thanks for the clear explanation. The idea is quite nice.

Several comments:

- I would prefer not to use polled communications, and that's why I didn't mention masters and slaves. The reason is that I know that more than one company has had problems with similar systems (actually using power line communications (PLC) instead of a ring of point-to-point segments), using polling. I would like each sensor not to generate new data until something has changed in its state. With your scheme, N bytes are devoted to (sent to and received from) each sensor, each "round," regardless of whether they have changed the state or not, and whether there's something in its configuration that needs to be changed or not. Some numbers: with {115200 bauds, 9 data_bits/word, 1 stop_bit/word, 4 bytes/frame, 200 nodes/ring (100 on each side of the aisle), and the nodes always have ready the data to be sent} the total time across the ring would be around 77 ms. That would not be bad at all. I'll think about this (and especially about the frame size that I would actually need).

- The fact that there is no address information does not worry me.

If I end up going for the 1-UART/sensor solution, I might even go down to an ATmega48, which I've used a lot. The sensors need to be very cheap.

Thanks again,

Reply to
Mochuelo

I forgot to ask.

If the baud rates were intentionally different, why did you do that?

If the baud rates were UNintentionally different, you noticed problems using one stop bit and crystals or ceramic resonators at the nodes?

Thanks,

Reply to
Mochuelo

Neither, we avoided a potential problem :)

If you stream continually, then you put a lot of pressure on the single stop bit ( actually half a stop bit, as it is mid-tested for STOP, before the uart flips to start edge sampling.. ) as that is the total time-elasticity. Also, RX must complete, before the RI sets, and it needs to test 9th bit, to decide what to TX, so you can see a SW aperture also creeps into the budget. Often TX waits for the next whole BIT time, before send - so whilst RX should be fractional bit tolerant, TX is not.

You can easily test this, in a full system :)

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.