SPI, I2C, Etc...

[AtomSoft]

Ok i have 2 simple questions which may spark up something bigger i hope.

Is it a good idea to create a custom protocol?

I know that seems like a crazy question but think about it....

SPI is awesome but has the issue of having a Slave Select pin for every device on the line which means more IO is needed.

I2C is great also but it has the issue of bus collisions and maybe not knowing when the bus if free without wasting a few clocks.

I was thinking of making my own Protocol.

I would call it ASTIP. Which as you may have guessed would stand for AtomSoftTech Intergrated Protocol.

It would be more similar to the I2C protocol but with 1 extra pin. This extra pin would be the busy line.

One would first sample the Busy Line and ensure its not in use. If its not in use then one would start a transfer of data somewhat like I2C.

Each device on the line would have there own address and would be able to control the Busy Line at any time but only one at a time.

The busy line since controlled by the slaves would also allow the MASTER to know if a SLAVE is there or not. For example :

1. Master is a PIC18F4620
2. Slave is a BT Module (BTM) with a IC/MCU with my protocol...

Case A:
The master #1 would sends out the address and begin to poll the busy line. If there is something wrong or if the BTM isnt on board the busy line would not be changed and the master would know and cease activity or retry.

Case B:
The master #1 sends out the address and begins to poll the busy line. The BTM is there and gets the address and first responds by setting the Busy line low. This will tell the master that the device is present and ready for commands and data. Also it will tell the other slaves that the line is busy.

Also each slave can then also have a internal interrupt for what ever its doing and when data is ready for the MASTER it can poll the Busy Line and if its free pull it low and the master can then clock in any data waiting on the line with a included address as the first byte.

Well as you can see this is still pretty rough as its all in my head really. But i like it and just wanted to share it.

Do you think making something like this is worth some time. (i have tons of time) Or do you think my time is better spent doing or learning something else

Additionally:
Each device would have a built in buffer which may vary in size to store data from a interrupt or something so data isnt lost when the line is busy.

Also current I2C, SPI etc.. devices can be fitted with a XXX to ASTIP converter. (where xxx = spi,i2c, etc)

 

[misterT]

I don't see how you can have bus collision if there is only one master. If you want the slaves to be able to initiate a data transmission, you could read about CAN bus to give you more ideas. And also, multimaster i2c is not particularly new idea: https://www.i2c-bus.org/MultiMaster/

 

[dknguyen]

Your description is strange though because it sounds like you only have one master with many slaves but the slaves can initiate transmissions without a request from the master (which would in fact make it a multi-master system). If you only have one master and the slaves cannot initiate a transmission and can only respond, then you won't ever have collisions anyways. Why would you ever need a busy line if there is only one master?

Read up about how CAN works. They both have non-destructive collision detection and arbitration by driven dominant bit states that override recessive bit states. CAN is especially elegant. Your own similar protocal might use CAN transceivers or RS-485 transceivers with pull-ups (driving the enable line instead of the input line to simulate dominant and recessive states just like a CAN transceiver). Multi-master I2C uses recessive/dominant states as well for this purpose in for the form if pull-up resistors with the fact the pins can only ever drive the line LOW or high impedance.

You listen to the line before initiating a transmission and read back what you sent to make sure it is in fact what you sent to detect collisions. If you are using dominant/recessive states and a well thought-out message format you can have some transmitters back off and allow the dominant message (the message with the first bit that is dominant relative to the other colliding messages' recessive bits) to continue interrupted. This is how CAN works. You don't ever need a busy line to arbitrate the bus.

But you don't want multi-master unless you need it since single master that polls the slaves will be able to use nearly all the bandwidth while multi-masters can only make use of 37% of this (information theory I think) due to collisions, etc.

So I'd say you have better things to spend your time on...like reading up how the CAN bus dominant and recessive bits work with the structure of the message frame to achieve non-destructive collision detection.
https://www.softing.com/home/en/ind...-bus/more-can-bus/index.php?navanchor=3010320

Menu on left side about the CAN bus. Of interest are things about bus arbitration, message addressing/priority, and bus arbitration, and error handling.

 

[AtomSoft]

How about data corruption and 2 slaves sees 2 different address and activates each other.

 

[dknguyen]

If the bits are messed en route to two different destination devices, when they communicate the same arbitration happens again since the dominant bits in the one message from device A will override the recessive bits in the other message from Device B. When device B detects what is on the bus is not what it sent, it backs off and the other transmission continues uninterrupted and device B can retry again at a later time. This holds true whether the destinations respond at exactly the same time or at separate times (in theory if the response times were different then the lagging device would not transmit since it would listen to the line and realize it is busy and retry later when the line is clear.

There also exists an error frame message as well that can be sent and heard by all devices to indicate more severe errors. Read the link in my previous post to learn more.

 

[AtomSoft]

Ok one question... i will read the link asap as it seems more of what i want...

How does the other devices know when a byte belongs to them? What are the odds that a I2C device doesnt send a packet which looks like a address packet? Anyway.. Im off to learn me some CAN ! I always thought this was only for long distance communication. I guess not

 

[AtomSoft]

BTW i found this:

**broken link removed**

 

[dknguyen]

It knows what is address and what is not by knowing the format that all messages are sent in (ie. first 8 bits are address, next 8 bits are message length, next X bits are the ddata, last X bits are the CRC checksum).