@ Mr. John Smith - You mean… I would have to put a resistor value depending on the length of the total bus and what’s connected to it?
That would be a real drawback on my plans, as I don’t know how much nodes will be plugged to it in advance 
@ DanielM - Yes, however the tolerance isn’t as exact as 120ohms. You may just end up having practical limits on how many devices can connect and how long the wires can be. Since Can bus has 11 bit ids… that is a lot of potential devices.
Or 29 bits if you need more than the 2047 that 11 bits offer. 
On the termination issue, CAN bus is not really design as a hot pluggable bus and more of a thought out from the start type bus. You can do the hot plugging if you design ahead the first and last devices on the bus and include the termination on them. You can then plug in mid position devices and it should work. Try to avoid creating a star topology. Short runs should be fine with lower speeds but long runs will be an issue with the higher rates due to reflections. Adding on the end requires you to move the termination from the current last device.
The reference from Mr John Smith about having to use a bus transceiver and it’s added cost is no different to using RS232 or RS485. They all require extra devices to connect your microcontroller to the bus. There is no suitable way to connect TTL (3.3V or 5.0V) together unless the distance is very short.
@ Dave McLaughlin - Thanks Dave and Mr Smith for the clarification.
I understand better now what’s needed. On a logical/protocol point of view CAN seems suitable for me. But the hardware is a bugger. The intended topology was a chain, but without really a beginning and a end. I guess I can try to have a first and last node, and insert others in between. I have to think if I can live with that mechanical constraint.
Bit banging :wall: my own protocol and use a simple flat ribbon cable, at least for close exchange between nodes, seems to have its appeal again…
LON requires special hardware but it has a "free topology " using a twisted pair cable. You can daisy chain, use a “star”, or combination of both.
On the “roll your own front” even RS485 required termination but is pretty forgiving at slower baud rates. I would suggest a polling protocol that the master polls all known slaves then polls for unknown slaves to catch new additions to the network. If 2 slaves collide they back off their reaponse time by a random value. If you can’t do that you will need some type of time slice protocol where each slaves transmits at a set time. (TDMA)
I
@ skeller - It’s the special hardware that concerns me 
Need to go back to simpler things. At least simpler hardware things for me :whistle: ) I’ll give a go simulating on a little windows program this parallel protocol I have in mind. I’m just thinking a 12 or so flat ribbon cable could provide the data & control bus, and handchecking without any kind of clock would make the data go forward. 3 control lines should be okay, something like BUSY (bus in use) READY (data can be read) and NEXT (provide next data) and a parallel 8 bits data bus. Would be a sort of parallel protocol I guess, but including a master and a list of slaves with a bidirectional exchange, all plugged on the same ribbon.
I guess in term of cost having a dedicated very small uC that handle the protocol on each node will cost less than a couple of specialized hardware or termination plugs. I could talk to this specialized uC with SPI for example, so it output the raw data to the ribbon cable and handle all the handchecking.
If some are interested I’ll post the progress here. And if I fail, I’ll swallow the pill and punish myself with additional hardware 
And you’re sure you cant use Radios? It’s pretty easy to create a mesh network wirelessly. I’ve even see a video of a connected home light switch that stores energy from the ambient EMR so that it doesn’t need a battery to operate.
@ Mr. John Smith - Radio is definitely something I’ll use for remote nodes, but I really need a cheap solution with a master and several slaves connected together on very close proximity (30cm or so). A bit like a Gadgeteer uC with lots of connected sensors to it. But with sensors that have their own processing power, and a protocol that will recognize new modules automatically with their own unique ID (64 bits)
A radio transmitter/ceceiver mandatory on each node would be too expensive IMO.
If I manage to do it as it is in my mind right now, a parallel flat ribbon between two small uC as a fast protocol link, then nothing forbid that one of those uC node is a repeater for a wireless connection, to have part of the network adressed wirelessly and completely transparently to the protocol.
I’ll just say “signal integrity”. Running a flat parallel cable like you propose will be fine in non-hostile environments and in short runs, but push either of those areas and I don’t know that you can trust either of those factors to not cause you issues.
Agree. Also depending on the speed you will have to include guard lines (GND) between the signals to reduce any possibility of cross talk. This is what the 80 conductor IDE cables did when you used them with the 40 way IDE drives before SATA cable along.
Even your short run connections would benefit from something like RS485 or even CAN. With CAN you don’t need any protocol development. It’s already done and it just works. Once you have used CAN you won’t believe how easy it is to work with and to add new nodes without any code changes except to the devices that wish to work with that data.
I once developed a weather station with CAN bus and then I wanted to control my boiler and have the weather information as part of the protocol. I simply used the same bus and sent and received the boiler control and status on it at the same time as the weather station. No need to run a different cable or choose a different protocol. It just works.
@ Dave McLaughlin - Of course you’re right. But I’m not really aiming at several MB speed. Just curious Dave, how did you handle the terminaison node problem with CAN? Is if a sensitive setting? Even if I choose to plug with flat cable the close proximity nodes, I’ll still need a viable solution for nodes that are far away, either wireless of something wired