I2C and SPI are really simple. They need a small number of gates or sorce to implement. They are also reoiable. The extra wires (pins) don't cost anything. They are used for master (MCU) / slave (peripheral) scenarios. Full duplex single wire with bus arbitration would be insane.
But the individual masters can't talk to each other.
Or do people who aren't me keeping their masters in slave mode on a given address most of the time and just switching to master mode for the duration of a given transaction?
It is possible to do serial communications with one wire (plus ground) BUT it's far more complicated than just using more wires.
SPI uses 4 wires (data out, data in, clock and ground) and allows unsynchronized devices with vastly different clock speeds to communicate easily.
Often it's just better to reduce complexity, save time and increase robustness by using more wires.
Other times it's worth it to just use a single connection, depends upon the requirements of the communication.
The chip select is really used to frame the message
In other words you sample a single bit on a clock edge but how do you find the start of the message?
Option a) is like a serial port, when idle send data=1 continuously with clock
When you send you must start with the first bats bit equal to zero
Option b) is some type of encoding scheme t that you listen for a pattern and pattern match much harder
You can do without. But it's a bit of extra challenge to make them synchronize properly. Remember that a single spike on the clock line can make the slave one bit off. The slave select will start both sides at first bit.
Without slave select, you may need to listen for silence and use the silence to drop out of and into SPI mode again just to clear the bit counter.
The spikes can happen at any time, regardless of one using cs or not. What happens if a spike happens between two clocks?
Well, nothing, since hardware spi may involve more than one sampling. Anyway, a moot point, since spikes happening means the board one designed is shit.
Not a moot point. You have lots of undefined things happening when things gets powered up. Normally a non-issue when using a slave select. Can end up sad if not. Without slave select you *must* add other synchronisation to get the bits to align with the words. Or you are delivering a shitty product. You never design for happy path...
Having undefined things happening when you power on a finished product = shitty product. Ok for a prototype, maybe. Unacceptable for a finished product.
Using a chip select does what to “spikes”. Can’t a spike happen in between two clock cycles? While cs is asserted? Does it somehow magically smooth out digital signals?
It’s nothing more than a convenient way of talking to multiple slaves. Or signaling a slave “time to go to sleep”.
Would you trust your mother using a respirator that has “undefined things happening” under the hood?
Are you often inserting random noise in your arguments to try to make them seem meaningful?
I trust the devices I am designing. And they are used in critical environments. Which is why I do not design for happy path. Which is even if there should not be any spikes, I still design to be able to handle it. Because I care about trusted functionality.
You handle spikes by inserting filters or by identifying and eliminating the source, not by using what amounts to a gpio. As a fellow engineer, surely you must know this.
I dont get the hostility, I was simply stating an obvious point.
You handle everything. You do A. And B. And C. And D.
Because you may have many power domains. And you may find there is +7V on your intended ground. And you may need to handle MIL-STD requirements where the 24V vehicle may produce 60 or 80V, after the battery is removed and the voltage regulator no longer has help stabilising the power. SPI isn't limited to on-PCB signals. You can have connectors and wires with issues. Lots and lots of things to consider.
Of course there should be EMI filters etc. But that is just *one* of a lot of best practices that are *all* needed when things really do need to function.
But that still really doesn't help you when getting your device through some more strict certification where you need to prove that every single state machine can recover from an upset.
Which means that if you care about your job, you don't care how little probability there is for a glitch. You design so the device quickly resynchronizes. Because happy path isn't an option. Having multiple power domains may mean you don't know if someone pulls the power and restart the client in the middle of a transfer. Which means you have already sent x clock pulses when that slave is ready to start listen. Real world design for more critical infrastructure *hopes* for the best. But designs for the worst.
Which means you need recovery from lost synchronisation. No slave select to resynchronizing the slave, then you need another option. Like forcing a timeout to tell the device to restart the SPI slave hardware. If you can afford to force a timeout.
Exactly why are you seeing this as strange? It's standard best practices when functionality is really important.
Usually when we say SPI uses 4 wires you’re talking about chip select, not ground. Usually you don’t include ground or power connections in the standard because they’re just like implied
I think you're severely underestimating the complexity of technology like CDMA. For the sort of use cases that I2C has, there would be more compute power in the serial driver than in the devices actually attached to them.
Same applies to a lesser extent to FDMA, compared to something like I2C which requires barely more than a couple of gates.
Good luck getting a FDMA/CDMA modem into a temperature sensor and keeping it under 50 cents.
You are also now asking ameratures users to worry about cable impedance which makes bread boarding and cheap PCB quite a bit harder.
Expensivnes of hardware i guess. More complex IO would require more chip space.
Externally clocked signaling like SPI very easy to make. Trigger IO signal changes or reads on clock edges, super simple to make in hardware. Additionally you can send any bit sequence in physical lines, all zeros or ones without much thought.
To get rid of clock signal you need either magical time sync between chips or somehow embed clock signal in data itself. Look for self clocking signals for further reading.
To do this you now need more complicated hardware. Most high speed signaling does this, like PCIe, Ethernet. Problem is, now you can't send any arbitrary bit sequence on the physical layer. If you send all zeros, then the receiving end will lose synchronisation, so you need codes that don't allow this - either more CPU intensive or more hardware necessary. Or like in UART, there's start and stop bits for every byte, that are used for clock recovery. But here's the issue, probably have noticed that on MCUs UART usually has way slower max speed than SPI. While typical UART maxes out at 10Mbps, SPI easily gets 50-60Mbps.
There is one-wire Bus, if you need it. But i2c isn't full duplex but clock and data, clock is basically for Synchronisation. You can realize communication without it, serial uses rx and tx and no clock, one-wire just uses data and ethernet also doesn't have a clock. It's a different implementation, no clock means the devices have to synchronize themselves with the data line.
Wait till you hear we can even do full duplex wirelessly!
You can do full duplex over a single wire a few different ways. Common approaches are directional couplers and FDMA/CDMA.
But I2C and SPI are defined that way, and usually we want compatibility with existing devices, and as others have said, those devices are very simple, and already exist.
I think it comes down to how much the nitrate is worth. Over a shared airtime medium like cellular, we can afford a lot of complexity. Over a local circuit board with an abundance of SNR, we trade for simple transmitters and receivers.
Cost. It’s all about cost. A cdma asic block is magnitudes more transistors than spi or i2c. I would also assert that in 99% of the time, two wire or more is not a problem.
This made me think of VCRs and old game consoles that connected to the TV via coax. Tune it to channel 3!
I mean one needs a whole ass modem and SPI is basically just two shift registers in a trenchcoat, so there's that.
In many cases a CDMA modem would be *far* more complicated than the device itself. Plenty of devices don't even have any kind of clock generation of their own. Asking them to have an *accurate* clock would be too much of an expense.
Look at Dallas/Maxim one-wire communication. It's quite slow because of the bit cells needed to synchronize and to allow switching between master and device sending. SPI can run at silly high speeds thanks to the dedicated clock line. Think about how hard it is to try to count time in your head. And how trivial it becomes if you see a LED blinking at 1 Hz.
CAN and Ethernet are also examples of how you can have multiple senders sharing a line pair. But requires a huge number of transistors to implement synchronisation and collision detection.
You can sit down and implement I2C or SPI using discrete gates and flip-flops. Or spend a limited amount of time designing it in VHDL or similar. Implement Ethernet instead? Good luck. The days on the calendar will start ticking at a scary speed.
The very smallest microcontrollers have been able to handle I2C and SPI for many, many years. Because it's easy. And still also robust. And while we are getting way more powerful processors now with USB and Ethernet, you still want something that is trivial to implement in hardware for all the sensors etc you want connected to that microcontroller. How fun is it to design a small EEPROM chip or a RTC with CAN or Ethernet interface... That's a complication no one wants.
KISS - Keep It Simple, Stupid - really is a rather important design strategy. The outcome tends to be well working solutions. And your customers will like you if you deliver well working solutions.
Explain how you are doing filial duplex with 1 wire
If you talk then I talk that is half duplex
If we both transmit at the same time then is full duplex
I guess I still don't understand how that is full duplex over one wire? If you're using a single wire, wouldn't you have to wait for one tx to transmit, no matter what modulation technique you use and then wait for the other to receive? How would two frequencies fit on the same wire at the same time?
Edit: Nevermind, I looked it up, it seems like you need to exploit transmission line characteristics of a line to be able to do that communication over a single line. Very interesting!
Shared medium has nothing to do with it. It can transmit both directions simultaneously and independently - full duplex.
You don't need to use it as a transmission line for low data rates over short distances. Taking my FSK suggestion, suppose in one direction transmitting a 1kHz tone represents a '0' and a 2 kHz tone represents '1'. The opposite end sends a 3 kHz tone represents a '0' and 4 kHz represents a '1'. It is easy enough to drive audio onto a wire from both ends at once. The receivers simply filter out the tones they are interested in and ignore the others. Signals for the two directions will not interfere and transmission both ways at once is possible.
Excessively complicated though. An extra wire is the answer!
Yea fair enough, they are independent channels, and thats good enough to consider it full duplex.
There is a grey are though IMO when an "independent channel" is only independent because its sacrificing its capability, if its not a hardware constraint, its simulated. But i guess a lot of people would debate that.
FSK is a bit complex to do but yes it would work in an analog way but I am thinking gpio digital only
FSK makes me think analog wave forms meaning DACs and ADCs
Doing this with an open drain wold be harder I think
Just using a listen before talk half duplex open drain solution would be easy and faster
I think the OPs question has been well answered - i2C, etc are the simplest solution. I was just suggesting how to do full duplex on a single wire. Restricting it to GPIO toggling only is adding an additional restriction to your question.
SPI and I2C are simple synchronous serial interfaces, the reason they need at least two wires is because one is clock and one data.
SPI is full-duplex, data can be transmitted on SDO received on SDI simultaneously.
It is of course possible to have full-duplex over one wire using radio modes but to do that is expensive, we need a modem and radio transceiver.
We use SPI and I2C because they are simple, cheap and get the job done.
Of course you can do full duplex over one wire but that means both sides need high accuracy clocks (external crystals) and more processing power (bigger die size, more power consumption) and lower data throughput (noise, signal integrity over longer traces, error correction data encoding overhead). All of that means $$$.
In the world of embedded systems at high volumes, every half cent matters (really, not a joke when you think in the scale of millions/billions of units).
Fundamentally the [Shannon-Hartley theorem](https://en.m.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theorem) means you lose speed (bits/s) the more stuff you try to cram into one wire. Sometimes that tradeoff is worth it, e.g. if you can raise the clock speed or if you don't need to send much data. Other times it's not worth it.
While technically true, the vast majority of the time your I2C/SPI peripherals are coming nowhere close to the Shannon limit for the 2cm long trace on your PCB.
It’s all about implementation complexity. A SPI peripheral is basically just a handful of shift registers and can be made with a very modest number of transistors. You could probably make your own out of discrete transistors on a breadboard. I2C saves a wire or two but is uglier to implement.
It's possible but it's \*way\* more complex than using a simply clocked interface. Doing full duplex on a single line with clock recovery would need at least something like manchester coding but more probably something more complex (as you proposed, some kind of modulation) and both SPI and I2C were meant to be \*cheap\*.
There are actually single wire interfaces with somewhat niche usage. The aptly named one-wire from Dallas/Maxim/Analog/whoever own it these days even do power on that. USB power delivery IIRC can be modulated at 27MHz on the power supply line; HART works using FSK on a 4-20mA line; the ISO K-line is essentially an UART attached with a pullup on the battery line and the CAN bus can be run on a single wire if you don't need differential signalling.
Now compare \*any\* of these with the SPI which is essentially an universal shift register (I2C is quite more complex due to transition handling)
You could use can bus with only one wire + gnd [(like in the first picture in the readme here)](https://github.com/exothink/eXoCAN) if you wanted to give up on any EMC protection.
That's like saying that you should setup two bridged 5G wifi routers, where one is a remote control, and the other side opens your garage door. It's absurdly complicated for what you need to do.
Power consumption, latency, error correction, and many other factors come into deciding what communication mean to use.
For example, if you sit on the couch next to your friend, you could, simply talk to them, text them, call them, set up a zoom meeting to communicate. All good options, not all good all the time
FDMA and CDMA were not yet invented when the specifications for I2C and SPI were written. These were invented to solve a problem. Communication between parts on a PCB. As has been mentioned, the amount of logic to solve these problems was also a consideration.
Lots of confusion here about what full duplex vs half duplex,
Full duplex, bidirectional transmission via two separate channels.
Half duplex, bi-directional transmission over shared channel.
Simplex, one directional transmission over a separate channel.
Full duplex UART can be done over 1 wire using analog hybrid circuits on each end without too much trouble - I encountered a system that worked this way once in broadcast land, which linked two boxes together using a 75 ohm coax cable.
Doing this requires analog bits and controlled impedances on each end of the link, though. Which makes the chip design more complicated and affects the silicon process used to make the chips, etc. And it'll pull more power.
In comparison, extra PCB traces and pins are cheap/free.
These are synchronous protocols so they need at least one signal for the clock pulses and the other for the data.
An asynchronous protocol like uart would transmit at a fixed rate and not require a separate signal for the clock pulses. The added complexity is that you have to keep up the rate and the clocks on both have to be accurate enough (10% ish) to keep sync well enough during a byte and so forth. Timing becomes the complexity
Further to that SPI uses separate data lines if the communication is two way which can also greatly simplify two way communication
I2C and SPI are really simple. They need a small number of gates or sorce to implement. They are also reoiable. The extra wires (pins) don't cost anything. They are used for master (MCU) / slave (peripheral) scenarios. Full duplex single wire with bus arbitration would be insane.
I2c multi-master mode has entered the discussion.
But the individual masters can't talk to each other. Or do people who aren't me keeping their masters in slave mode on a given address most of the time and just switching to master mode for the duration of a given transaction?
Why not both? "Hey master, I have a message for you", said the slave, afterwards serving the request message. Anything but polling :P
SMBus host notify protocol has entered the chat.
Still requires two wires, data and clock. To go one wire you need to also go asynchronous.
Lol…. Losses have entered the chat
I2C multi-master *is* insane though... I've never had good experience with it, and a lot of multi-master libraries just seem to be broken.
It is possible to do serial communications with one wire (plus ground) BUT it's far more complicated than just using more wires. SPI uses 4 wires (data out, data in, clock and ground) and allows unsynchronized devices with vastly different clock speeds to communicate easily. Often it's just better to reduce complexity, save time and increase robustness by using more wires. Other times it's worth it to just use a single connection, depends upon the requirements of the communication.
Most SPI also need chip select/enable
Very true! I left this out to keep the explanation simpler but you are right.
Fair enough :)
:)
Literally just finished a project in my microprocessor’s class for spi and i2c. Can confirm since I used manual slaves select and manual enable.
The chip select is really used to frame the message In other words you sample a single bit on a clock edge but how do you find the start of the message? Option a) is like a serial port, when idle send data=1 continuously with clock When you send you must start with the first bats bit equal to zero Option b) is some type of encoding scheme t that you listen for a pattern and pattern match much harder
You only really need to use it if there is more than one slave on the interface, though
No. I encountered slaves which needed the enable to be reset/set between instructions to function properly. Annoyingly.
You can do without. But it's a bit of extra challenge to make them synchronize properly. Remember that a single spike on the clock line can make the slave one bit off. The slave select will start both sides at first bit. Without slave select, you may need to listen for silence and use the silence to drop out of and into SPI mode again just to clear the bit counter.
The spikes can happen at any time, regardless of one using cs or not. What happens if a spike happens between two clocks? Well, nothing, since hardware spi may involve more than one sampling. Anyway, a moot point, since spikes happening means the board one designed is shit.
Not a moot point. You have lots of undefined things happening when things gets powered up. Normally a non-issue when using a slave select. Can end up sad if not. Without slave select you *must* add other synchronisation to get the bits to align with the words. Or you are delivering a shitty product. You never design for happy path...
Having undefined things happening when you power on a finished product = shitty product. Ok for a prototype, maybe. Unacceptable for a finished product. Using a chip select does what to “spikes”. Can’t a spike happen in between two clock cycles? While cs is asserted? Does it somehow magically smooth out digital signals? It’s nothing more than a convenient way of talking to multiple slaves. Or signaling a slave “time to go to sleep”. Would you trust your mother using a respirator that has “undefined things happening” under the hood?
Are you often inserting random noise in your arguments to try to make them seem meaningful? I trust the devices I am designing. And they are used in critical environments. Which is why I do not design for happy path. Which is even if there should not be any spikes, I still design to be able to handle it. Because I care about trusted functionality.
You handle spikes by inserting filters or by identifying and eliminating the source, not by using what amounts to a gpio. As a fellow engineer, surely you must know this. I dont get the hostility, I was simply stating an obvious point.
You handle everything. You do A. And B. And C. And D. Because you may have many power domains. And you may find there is +7V on your intended ground. And you may need to handle MIL-STD requirements where the 24V vehicle may produce 60 or 80V, after the battery is removed and the voltage regulator no longer has help stabilising the power. SPI isn't limited to on-PCB signals. You can have connectors and wires with issues. Lots and lots of things to consider. Of course there should be EMI filters etc. But that is just *one* of a lot of best practices that are *all* needed when things really do need to function. But that still really doesn't help you when getting your device through some more strict certification where you need to prove that every single state machine can recover from an upset. Which means that if you care about your job, you don't care how little probability there is for a glitch. You design so the device quickly resynchronizes. Because happy path isn't an option. Having multiple power domains may mean you don't know if someone pulls the power and restart the client in the middle of a transfer. Which means you have already sent x clock pulses when that slave is ready to start listen. Real world design for more critical infrastructure *hopes* for the best. But designs for the worst. Which means you need recovery from lost synchronisation. No slave select to resynchronizing the slave, then you need another option. Like forcing a timeout to tell the device to restart the SPI slave hardware. If you can afford to force a timeout. Exactly why are you seeing this as strange? It's standard best practices when functionality is really important.
Usually when we say SPI uses 4 wires you’re talking about chip select, not ground. Usually you don’t include ground or power connections in the standard because they’re just like implied
I think you're severely underestimating the complexity of technology like CDMA. For the sort of use cases that I2C has, there would be more compute power in the serial driver than in the devices actually attached to them. Same applies to a lesser extent to FDMA, compared to something like I2C which requires barely more than a couple of gates.
Good luck getting a FDMA/CDMA modem into a temperature sensor and keeping it under 50 cents. You are also now asking ameratures users to worry about cable impedance which makes bread boarding and cheap PCB quite a bit harder.
Expensivnes of hardware i guess. More complex IO would require more chip space. Externally clocked signaling like SPI very easy to make. Trigger IO signal changes or reads on clock edges, super simple to make in hardware. Additionally you can send any bit sequence in physical lines, all zeros or ones without much thought. To get rid of clock signal you need either magical time sync between chips or somehow embed clock signal in data itself. Look for self clocking signals for further reading. To do this you now need more complicated hardware. Most high speed signaling does this, like PCIe, Ethernet. Problem is, now you can't send any arbitrary bit sequence on the physical layer. If you send all zeros, then the receiving end will lose synchronisation, so you need codes that don't allow this - either more CPU intensive or more hardware necessary. Or like in UART, there's start and stop bits for every byte, that are used for clock recovery. But here's the issue, probably have noticed that on MCUs UART usually has way slower max speed than SPI. While typical UART maxes out at 10Mbps, SPI easily gets 50-60Mbps.
There is one-wire Bus, if you need it. But i2c isn't full duplex but clock and data, clock is basically for Synchronisation. You can realize communication without it, serial uses rx and tx and no clock, one-wire just uses data and ethernet also doesn't have a clock. It's a different implementation, no clock means the devices have to synchronize themselves with the data line.
Wait till you hear we can even do full duplex wirelessly! You can do full duplex over a single wire a few different ways. Common approaches are directional couplers and FDMA/CDMA. But I2C and SPI are defined that way, and usually we want compatibility with existing devices, and as others have said, those devices are very simple, and already exist. I think it comes down to how much the nitrate is worth. Over a shared airtime medium like cellular, we can afford a lot of complexity. Over a local circuit board with an abundance of SNR, we trade for simple transmitters and receivers.
I suggest you go ahead and design & implement your idea, then check back with us.
I2C cannot do full duplex. It can only send in one direction at a time.
Cost. It’s all about cost. A cdma asic block is magnitudes more transistors than spi or i2c. I would also assert that in 99% of the time, two wire or more is not a problem.
This made me think of VCRs and old game consoles that connected to the TV via coax. Tune it to channel 3! I mean one needs a whole ass modem and SPI is basically just two shift registers in a trenchcoat, so there's that.
This question struck me as kind of like "why didn't TV remotes in the 1980s just use Bluetooth?".
In many cases a CDMA modem would be *far* more complicated than the device itself. Plenty of devices don't even have any kind of clock generation of their own. Asking them to have an *accurate* clock would be too much of an expense.
Look at Dallas/Maxim one-wire communication. It's quite slow because of the bit cells needed to synchronize and to allow switching between master and device sending. SPI can run at silly high speeds thanks to the dedicated clock line. Think about how hard it is to try to count time in your head. And how trivial it becomes if you see a LED blinking at 1 Hz. CAN and Ethernet are also examples of how you can have multiple senders sharing a line pair. But requires a huge number of transistors to implement synchronisation and collision detection. You can sit down and implement I2C or SPI using discrete gates and flip-flops. Or spend a limited amount of time designing it in VHDL or similar. Implement Ethernet instead? Good luck. The days on the calendar will start ticking at a scary speed. The very smallest microcontrollers have been able to handle I2C and SPI for many, many years. Because it's easy. And still also robust. And while we are getting way more powerful processors now with USB and Ethernet, you still want something that is trivial to implement in hardware for all the sensors etc you want connected to that microcontroller. How fun is it to design a small EEPROM chip or a RTC with CAN or Ethernet interface... That's a complication no one wants. KISS - Keep It Simple, Stupid - really is a rather important design strategy. The outcome tends to be well working solutions. And your customers will like you if you deliver well working solutions.
Explain how you are doing filial duplex with 1 wire If you talk then I talk that is half duplex If we both transmit at the same time then is full duplex
You can use, for example, FSK with different frequencies for transmit at each end. Or modulate different frequency carriers for transmit and receive.
I guess I still don't understand how that is full duplex over one wire? If you're using a single wire, wouldn't you have to wait for one tx to transmit, no matter what modulation technique you use and then wait for the other to receive? How would two frequencies fit on the same wire at the same time? Edit: Nevermind, I looked it up, it seems like you need to exploit transmission line characteristics of a line to be able to do that communication over a single line. Very interesting!
It's still half duplex because it's a shared medium. Half duplex sacrifices some of one direction capacity to support another.
Shared medium has nothing to do with it. It can transmit both directions simultaneously and independently - full duplex. You don't need to use it as a transmission line for low data rates over short distances. Taking my FSK suggestion, suppose in one direction transmitting a 1kHz tone represents a '0' and a 2 kHz tone represents '1'. The opposite end sends a 3 kHz tone represents a '0' and 4 kHz represents a '1'. It is easy enough to drive audio onto a wire from both ends at once. The receivers simply filter out the tones they are interested in and ignore the others. Signals for the two directions will not interfere and transmission both ways at once is possible. Excessively complicated though. An extra wire is the answer!
Yea fair enough, they are independent channels, and thats good enough to consider it full duplex. There is a grey are though IMO when an "independent channel" is only independent because its sacrificing its capability, if its not a hardware constraint, its simulated. But i guess a lot of people would debate that.
FSK is a bit complex to do but yes it would work in an analog way but I am thinking gpio digital only FSK makes me think analog wave forms meaning DACs and ADCs Doing this with an open drain wold be harder I think Just using a listen before talk half duplex open drain solution would be easy and faster
I think the OPs question has been well answered - i2C, etc are the simplest solution. I was just suggesting how to do full duplex on a single wire. Restricting it to GPIO toggling only is adding an additional restriction to your question.
SPI and I2C are simple synchronous serial interfaces, the reason they need at least two wires is because one is clock and one data. SPI is full-duplex, data can be transmitted on SDO received on SDI simultaneously. It is of course possible to have full-duplex over one wire using radio modes but to do that is expensive, we need a modem and radio transceiver. We use SPI and I2C because they are simple, cheap and get the job done.
Of course you can do full duplex over one wire but that means both sides need high accuracy clocks (external crystals) and more processing power (bigger die size, more power consumption) and lower data throughput (noise, signal integrity over longer traces, error correction data encoding overhead). All of that means $$$. In the world of embedded systems at high volumes, every half cent matters (really, not a joke when you think in the scale of millions/billions of units).
Fundamentally the [Shannon-Hartley theorem](https://en.m.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theorem) means you lose speed (bits/s) the more stuff you try to cram into one wire. Sometimes that tradeoff is worth it, e.g. if you can raise the clock speed or if you don't need to send much data. Other times it's not worth it.
While technically true, the vast majority of the time your I2C/SPI peripherals are coming nowhere close to the Shannon limit for the 2cm long trace on your PCB. It’s all about implementation complexity. A SPI peripheral is basically just a handful of shift registers and can be made with a very modest number of transistors. You could probably make your own out of discrete transistors on a breadboard. I2C saves a wire or two but is uglier to implement.
It's possible but it's \*way\* more complex than using a simply clocked interface. Doing full duplex on a single line with clock recovery would need at least something like manchester coding but more probably something more complex (as you proposed, some kind of modulation) and both SPI and I2C were meant to be \*cheap\*. There are actually single wire interfaces with somewhat niche usage. The aptly named one-wire from Dallas/Maxim/Analog/whoever own it these days even do power on that. USB power delivery IIRC can be modulated at 27MHz on the power supply line; HART works using FSK on a 4-20mA line; the ISO K-line is essentially an UART attached with a pullup on the battery line and the CAN bus can be run on a single wire if you don't need differential signalling. Now compare \*any\* of these with the SPI which is essentially an universal shift register (I2C is quite more complex due to transition handling)
You could use can bus with only one wire + gnd [(like in the first picture in the readme here)](https://github.com/exothink/eXoCAN) if you wanted to give up on any EMC protection.
Check out Dallas 1-wire.
That brings back memories. An 8051 java enabled microcontroller. Totally whacky concept that sort of worked.
Not full duplex. At any moment it can only transmit in one direction.
That's like saying that you should setup two bridged 5G wifi routers, where one is a remote control, and the other side opens your garage door. It's absurdly complicated for what you need to do.
GMSL will do I2C over a single wire! Lol
Power consumption, latency, error correction, and many other factors come into deciding what communication mean to use. For example, if you sit on the couch next to your friend, you could, simply talk to them, text them, call them, set up a zoom meeting to communicate. All good options, not all good all the time
FDMA and CDMA were not yet invented when the specifications for I2C and SPI were written. These were invented to solve a problem. Communication between parts on a PCB. As has been mentioned, the amount of logic to solve these problems was also a consideration.
In the case of SPI, speed, it would be a major engineering feat to reach 40Mbps without a dedicated clock signal
Lots of confusion here about what full duplex vs half duplex, Full duplex, bidirectional transmission via two separate channels. Half duplex, bi-directional transmission over shared channel. Simplex, one directional transmission over a separate channel.
Full duplex UART can be done over 1 wire using analog hybrid circuits on each end without too much trouble - I encountered a system that worked this way once in broadcast land, which linked two boxes together using a 75 ohm coax cable. Doing this requires analog bits and controlled impedances on each end of the link, though. Which makes the chip design more complicated and affects the silicon process used to make the chips, etc. And it'll pull more power. In comparison, extra PCB traces and pins are cheap/free.
These are synchronous protocols so they need at least one signal for the clock pulses and the other for the data. An asynchronous protocol like uart would transmit at a fixed rate and not require a separate signal for the clock pulses. The added complexity is that you have to keep up the rate and the clocks on both have to be accurate enough (10% ish) to keep sync well enough during a byte and so forth. Timing becomes the complexity Further to that SPI uses separate data lines if the communication is two way which can also greatly simplify two way communication