I'm designing a bus system that can be used to connect a single controller device with multiple sensors and actors in a building area. When writing a specification for such a system, the terms "master" and "slave" traditionally come to mind. Aside from the recent discussion about these terms, I don't consider them appropriate for this bus system because a master usually instructs a slave to unconditionally do something, and nothing else, at no other time. In my understanding, a slave is a device that does not act on its own. I2C is a good example for this, an I2C slave cannot inform the master about an event (without using a separate interrupt line, i.e.), it must be asked to tell.
My bus devices can all send messages at their own discretion. Whenever something relevant happens, any device can send a message on the bus to the controller, subject to collision avoidance. So I don't consider my devices "slaves".
I've read up a few topics here and found proposals for the I2C protocol to use "controller" and "target" or SPI to use "controller" and "peripheral".
I've almost decided on the term "controller" for my system. And I kinda like the term "peripheral", but it's a relatively complex word (at least from my native German POV) and German translations would sound really strange ("Peripheriegerät" with 6 syllables), while the English word would be even more impossible to speak in a localised document.
Are there any alternatives? What terms could be used for "slave" bus devices that have their own will and right of speech (to use that terminology)?
I'd prefer to avoid the terms "device" or "node" for their generic meaning which could be both a controller or the other part of the bus.
There has been many other names for Master and Slave before NXP released their new official standard for the I2C bus UM10204.pdf
In that document they are serious about Controller and Target. I assume that we all will be talking about Controller and Target in a few years.
A network consists of nodes. I think that this is the most general kind of connected devices. On a bus (without loops) only one device can speak at a time or there exists a conflict that has to be solved somehow (bus arbitration). Until now that special device is a master that dictates the communication and all other slaves have to obey. For machines the master/slave relationship and terminology is not offending in any way, it only makes absolutely clear how communication is going on.
But bus mastership is not necessarily a static property of a bus node. On an I2C bus each node normally behaves as a slave, listening to the traffic on the bus and eventually communicating with another bus master when addressed. In the Arduino framework the slave implements its communication features in OnRequest and OnReceive callback functions. In turn each node can become the bus master (Arduino: Wire.beginTransmission/requestFrom), provided that no other master with a higher priority request is elected as the actually one and only master of the bus. Yes, priorities on this multi-master bus are not assigned to masters but to slaves, precisely to their slave ID which has to be unique on each bus. Masters instead deserve no specific ID if they don't want or need to be addressable by other nodes.
As mentioned above already I don't favor any tinkering with clear and well established terminology in the technical area. How would you like to rename e.g. a master-slave flip-flop? Or male and female connectors? How to distinguish between a hardware controller and a software bus master?
OT: Und bitte auch keine ':' oder '*' mit völlig verhunzter Aussprache unserer (schönen? klaren?) deutschen Sprache.
During my time spent on military avionics, we used a MIL-STD-1553 data bus. The terminology there was "Bus Controller" (BC) and "Remote Terminal" (RT). In that scenario, there was one device in charge of the bus, the BC.
You seem to be looking for names for devices on an ad-hoc network. I guess "node" is a good general description.
It looks like "target" might become a widespread word here. Although I'd understand it as the destination of something, which might be more confusing than "slave".
The word "remote (device)" might also be interesting. And of course the very generic "node".
To be clear, the biggest problem I personally have with "slave" is not offending somebody (or some-machine; although it would be nice if nobody could blame me for using the word if I don't need it) but that these devices may send on the bus without being asked which a slave traditionally can't do. But this is no real peer-to-peer network as a "peripheral" device (one that isn't the controller) can only talk to the controller, not to any other device. And even though one might look at it as dynamic roles (like a device is a "master" while it sends a request message), I need fixed names for the boxes that will be installed somewhere. They cannot change names all the time.
Considering this is in a building and several remote units I assume they are connected with wires hence I2C. It is my opinion I2C is a bad choice as it will not do what you want. Take a look at CAN, you can label the nodes any way you want. It is CSMANDS ie Carrier Sense, Multiple Access, Non Destructive Arbitration. wires over 1000' are OK and it is faster than I2C. I use the MPC2515 with Cory Fowlers library, it works very well. Any node can initiate a transmission at any time. If you like you could call a node a peer if you like. With this method there is no Bus Controller, every node can do its thing without permission from any other node. Your software can change this but it is not a hardware limitation. Hint if you use CAN you must have at least two nodes as one has to acknowledge the other.
My PHY is RS-485, not I2C. (I've seen others using I2C for home automation.) Collision avoidance is implemented through monitoring the RXD pin first, and message CRC in the end, with message confirmation and resending. It works reasonably well for the design goal to be DIY-feasible. It's not something professional. I'm going to publish all of it but it's not there yet.
I have carefully looked at CAN and consider it the technically superior solution but it's much more complex to build. My devices need a small MCU like an ATtiny1614 and an RS-485 transceiver chip, that's all. A separate CAN controller would be required (3 chips) or a different MCU with CAN builtin (usually bigger or hard to hand-solder at home). Stuff needs to fit behind a wall switch (no mains voltage here).
Even better would be something that only requires 2 wires instead of 4 by modulating the data over the power, like KNX does it (or maybe also SPE/PoE). But I haven't fully understood the details of it and it would probably require custom chips or large circuits.
That's for the technical details. In this thread I'm mainly looking for words.
Letting us know you were running RS-485 at the beginning would have saved us a lot of time. FYI
I got CAN running in a few hours, the library and examples had everything I needed. Also I am curious, what three chips does the can interface need, the MPC2515 needs only the Phy interface plus itself and a crystal. The interface from the CAN to the Tiney is SPI. Here is a simple schematic showing how it is done. The ATiney1614 has more flash, ram, and is faster then the UNO. There are several examples of of the Tiney running CAN.
Why's that? Does the choice of a PHY (while using the same device semantics) change anything at the recommended terminology?
And the required 3 chips are: MCU (ATtiny1614), CAN controller (MCP2515), CAN transceiver. Oh, and AFAIK CAN messages have a very limited maximum length. I totally forgot that. 8 bytes are not enough for my application, I need a few more with the option of dozens. (I also can't read your attached image, it's too small.)
