which protocoal would you prefer ? - Page 1
Forum section: electronics / general

author: BlogRahul
author_rank: Regular Contributor
timestamp: March 11, 2022, 06:01:28 pm
content: I have question suppose device like ADS1115 supports two protocoal I2C and SPI, which protocoal would you prefer to use in project ?I would use SPI when I need fast speed. I would use I2C if I want to save boards pins because SPI use four pins while I2C use two pinswhich protocoal would you prefer ? Do you have any other reason ?

author: Siwastaja
author_rank: Super Contributor
timestamp: March 11, 2022, 06:44:48 pm
content: I2C only if I have multiple devices on board and need to save on pin count.SPI, if at all possible.Main reason: SPI has hardware-level packet delimitation ("nCS") which also resets the communication state for each packet. Less state - good thing. I2C implementations, on the other hand, are notoriously buggy and non-robust. (Leading into extended revisions with timeouts / extra complications like SMbus/PMbus.)SPI - never a problem, ever. More robust, simpler protocol, better performance.Code is usually simpler, too. Very good I2C MCU peripherals seem to be rare; most require software juggling. SPI implementations can usually run on DMA.But yeah, of course, sometimes it's just very handy you can connect many ICs with just two physical signals.

author: rstofer
author_rank: Super Contributor
timestamp: March 11, 2022, 06:47:38 pm
content: I would always choose SPI because it is a simple interface. SS' frames the transaction, none of the Start Condition, Restart Condition, Stop Condition and ACK/NACK stuff to deal with.OTOH, I2C is probably a more secure protocol in the sense that the sender gets acknowledgement that the receiver actually received the message.https://aticleworld.com/difference-between-i2c-and-spi/

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 11, 2022, 06:48:12 pm
content: My favorite protocoal is this one:Oh, you meant protocol... In that case, I prefer SPI as it's very simple to implement, very robust, and much faster than I2c.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 11, 2022, 07:08:02 pm
content: Quote from: rstofer on March 11, 2022, 06:47:38 pmSPI devices almost always implement some kind of status feedback. If nothing else, you can read the same registers back and compare.I have also noticed that the I2C/SPI selection is only a feature of very low-cost devices. Once you go to higher end MEMS IMUs for example, it's either SPI, UART or both, never I2C. And with those devices, things like CRCs become a norm.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 11, 2022, 07:21:20 pm
content: Benefits of I2C is that you can address a number of peripherals with just 2 wires. And it can even be easily extended if needed, something requiring (a lot) more hardware with SPI.Speed is limited, but these days, as long as you comply with the bus requirements, you can communicate as fast as 1 Mbps with I2C, or even up to 3 Mbps when supported. For a lot of the peripherals available as I2C (sensors, low-speed ADCs) that's usually more than good enough.As to the ADS1115, it's I2C-only AFAIK. The "equivalent" part with SPI is the ADS1118.In general, apart from the above point I made (you need to address a number of devices with limited routing resources, and all the more if you want that expandable), I2C will have to be used if you have no choice: many sensor ICs are only available as I2C. Otherwise, it's up to you, your design, your knowledge, your CPU/MCU, and possibly the direction of the wind.

author: rstofer
author_rank: Super Contributor
timestamp: March 11, 2022, 09:28:47 pm
content: Quote from: Siwastaja on March 11, 2022, 07:08:02 pmThat's true but it isn't a built-in feature of the interface, it is some kind of code tied to the end of the transaction. I2C slaves can also extend the clock while they gather up the data to transmit. SPI doesn't have this feature.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 12, 2022, 06:14:16 am
content: Clock stretching is exactly one of those totally unwanted features. Thankfully, 99% of I2C slaves don't do it. But I would like to see aguaranteeof that not happening, and a configuration bit in I2C master peripheral to prevent the feature.I2C ACK/NACK mechanisms is not robust enough to add any real value.SPI does not need such mechanisms because it does not have those failure modes (like addressing failure) by design. Unlike I2C which is well known to get stuck in some wrong state or just stop working, literally the only thing that can go wrong in SPI is Signal Integrity. Which can go wrong in any physical protocol, I2C included. I2C has nothing built-in against that.SPI's strength is in the fact that the master device just runs through the clocks, 100% success guaranteed, and slave just clocks bits out, 100% success guaranteed. Nothing else can go wrong except physical signal corruption, and it only affects that particular transaction. (Although, itispossible to write poor SPI code and make it stuck because of missed SCLK cycle. Always use the nCS signal as the packet delimiter!)If physical corruption is to be taken seriously, both SPI and I2C require status bits and checksumming in data (on top of the I2C/SPI specification). It's just that I2C devices very rarely implement this. Some SPI devices do, some don't. SPI is used in high-end devices (automotive safety critical parts etc.) - I2C, never.

author: TomS_
author_rank: Frequent Contributor
timestamp: March 12, 2022, 07:14:20 am
content: I prefer SPI where ever possible for much the same reasons other people have mentioned.I2C seems to be everywhere I look though. Most telecom and high end server gear I look at will have I2C muxes and what not sprinkled all over the boards to cram as much of it in as possible.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 12, 2022, 08:31:30 am
content: You can see the trend of I2C being used for configuration, but less for data paths.If you have many ICs and just need to configure a few bits, I2C is obviously much simpler to route and also offers significant pin savings on the master device.My earlier comments assume that1) you have really the choice,2) you don't assign high cost to the increased signal count, i.e., have the pins and routing space available

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 12, 2022, 09:22:32 am
content: It all depends on your design requirements and constraints.i2c is nice for connecting multiple devices without increasing the pin usage (And might ease the pcb routing), but if ain't a problem, SPI can be a lot faster, doesn't have address/protocol overhead, and it's simpler overall.If sharing the SPI bus with other devices, and any of them needs to be fast while others doesn't, I'd split them in 2 buses. Don't you have more spi buses? Choose i2c for the slower ones!Not needing high thoroughput and the i2c version is noticeably cheaper? Go straight to i2c.

author: Microdoser
author_rank: Frequent Contributor
timestamp: March 12, 2022, 10:14:11 am
content: Quote from: Sal Ammoniac on March 11, 2022, 06:48:12 pmThat's ProtoOil. ProtoCoal is trees.

author: nctnico
author_rank: Super Contributor
timestamp: March 12, 2022, 12:03:56 pm
content: Quote from: rstofer on March 11, 2022, 09:28:47 pmAnd lets not forget that I2C has been designed to be able to deal with narrow pulses on the lines by incorporating filtering on the signals. Just from an EMC perspective I prefer I2C; it is more robust by design compared to SPI. If you use SPI on a board that runs in a noisy environment, then you'll need to add countermeasures to make sure narrow pulses don't cause problems.BTW: I have come across quite a few SPI devices that don't offer reading back what you send to it.

author: langwadt
author_rank: Super Contributor
timestamp: March 12, 2022, 12:16:09 pm
content: Quote from: Microdoser on March 12, 2022, 10:14:11 amand "ProtoOil" is really plankton and algae

author: Siwastaja
author_rank: Super Contributor
timestamp: March 12, 2022, 01:14:10 pm
content: Yes, I2C standard has some consideration to signal integrity. Similarly, UART (multisampling). SPI does not, it needs to be added on top, if it is important.I always add series termination on all SPI lines (47R at the source), like I do with push-pull GPIO pins regardless of protocol. Except if the signal is physically very short (a few cm), I might not bother.I2C drivers have slew rate control built in, I guess; I just use the pullups and no series resistor.In any case, clock edge sampled single-ended logic level fast interfaces are extremely commonplace, in memory buses for example. All computers, old or modern, completely depend on these interfaces never to miss or double the clock. SPI ain't different. But you need to understand SI. I2C might be more forgiving, especially with slow clock speeds (which are usually enough).I would not recommend using I2C off-board, though. This isn't the supposed use case. It's not magically much better than SPI. Consider CAN or RS422/485 or similar if youactuallyneed robustness instead of guesstimated empty talk.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 12, 2022, 06:23:25 pm
content: Quote from: Microdoser on March 12, 2022, 10:14:11 amTrees are boring. T-Rexes are cool. Besides, any organic matter, plant or animal, contributes to both coal and oil.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 12, 2022, 06:47:35 pm
content: I prefer SPI over I2C whenever possible, but I’m often frustrated by the quirks many microcontroller SPI peripherals have.For example, many MCU SPI implementations limit the number of bits transferred per frame to common values like 8, 16, or 24 bits. That’s usually okay until you run into an SPI slave that uses some oddball frame size, and then you have to kludge it. I’d prefer a more flexible arrangement where the SPI peripheral supports a range of frame sizes rather than a limited number of fixed sizes. For example, the Infineon XMC4000 series SPI supports frame sizes ranging from 1 to 63 bits.Slave Select handling is also something some MCU vendors don’t get right. A good example is the STM32F7 series. None of them (as far as I know) control the SS line directly—you have to do it yourself using a GPIO output port. They finally got it right in the STM32H7 series.For anything requiring going off-board more than a few cm, I drop SPI like a hot potato and switch to CAN.

author: hans
author_rank: Super Contributor
timestamp: March 12, 2022, 06:55:31 pm
content: Quote from: Siwastaja on March 12, 2022, 06:14:16 amI was thinking clock stretching can be one of the major advantages of I2C. Clock stretching allows slower devices to halt the master to read a response. SPI does not really have a standardized way of doing this. Some ADCs may hold their output bit high or low waiting until a conversion is done, which means that the software must poll the data line before it can clock out valid data. A I2C slave instead may instead NACK or keep pulling the clock till it's done to reply. Clock stretching also allows MCUs to handle I2C slave protocol even if it's in a critical code section somewhere else (with perhaps IRQs turned off for a few dozen microseconds).If you're pushing bytes using DMA over SPI, then there is not really a way to prevent buffer overruns/underruns for the slave device. If the slave is hard silicon, this is usually not a problem. But for software implementations, I do like I2C. On SPI you have to make sure that the clock speed or burst length is not too high and that the firmware always serves the SPI slave IRQ in time.Essentially I2c is less real-time. If that suits your needs its neat. But it can also be more tedious with a naive implementation. A bit-banged I2C implementation that's fully compliant, is non-trivial and also needs some-what accurate delay loops. OTOH SPI is basically connecting 2 shift registers together with a clock and enable pin. It's dead simple, but everything else must be taken care of at higher protocol levels.The issue about I2C locking up is an annoying one. Sometimes a bus reset helps. But certainly the start-write-restart-read-stop transaction is a tedious one, and if unlucky, one to fail often on bad implementations.If I need the performance, or have the pins to spare on PCB, I will use SPI.If I need to also code the slave device, I'd rather use I2C.If I need ICs off-board, I prefer I2C (I know this is not best-practice or robust).If I want to connect low-data rate stuff together (tens/hundreds Hz kind of stuff), I prefer I2C.If I need something low power, I use SPI.

author: eugene
author_rank: Frequent Contributor
timestamp: March 12, 2022, 08:24:55 pm
content: The passive pull-ups on I2C mean that it tends to be more sensitive to noisy environments. This is not typically a problem if the master and slave are close together, but I was once asked to build a system with an I2C sensor at the end of a 1m unshielded cable. It was necessary to add low pass filtering and run the bus at a relatively slow speed to avoid communication errors. Switching to a similar sensor with SPI was much more robust.Admittedly, this is an abuse of both protocols as they're meant for communication between devices on the same PCB. But, I see a lot of sensor break-out boards from the usual vendors that might be carelessly used. It's my experience that SPI is likely to be more reliable in those cases.

author: westfw
author_rank: Super Contributor
timestamp: March 13, 2022, 10:23:45 pm
content: Theoretically I think I prefer I2C, because it's more flexible and tends to have more intelligence built into the peripheral on the microcontroller. SPI reception of data seems so kludgy, for instance, especially when you have bulk data in one direction at a time.But I2C is so horribly slow (and high overhead) compared to SPI.

author: rstofer
author_rank: Super Contributor
timestamp: March 14, 2022, 12:54:12 am
content: But I2C can reach out to a mile:https://www.abcelectronique.com/forum/attachment.php?attachmentid=29845The data rate is pretty low but it apparently works.

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 14, 2022, 06:09:48 am
content: Also would spi if you add termination resistors to avoid reflections and greatly reduce the clock speed...

author: Berni
author_rank: Super Contributor
timestamp: March 14, 2022, 07:16:57 am
content: Quote from: rstofer on March 14, 2022, 12:54:12 amThat is a pretty impressive distance for I2C. Even if it is only 1.5KHz clock speedBut yes SPI would go an even longer distance if it is properly terminated. Only real limitation there is the round trip delay. Doing the math this works out to about 70Khz max clock speed. Tho it needs more wires so not as practical. The actual correct protocol for these distances is RS485 anyway, as it is designed to actually work over a mile long cable and designed to handle noise that is inevitably picked up in a real use case. Given a good enough cable it can likely do 1Mbit over that mile.Back to the topic. I do also prefer SPI whenever possible. The few extra wires are not going to be that hard to route on a PCB while you get superior reliability and performance. The only benefit of I2C is the ability to have lots of devices on only 2 wires, in all other aspects other protocols beat it.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 14, 2022, 03:00:10 pm
content: Quote from: rstofer on March 14, 2022, 12:54:12 amNo it can't, and no it won't work.This is "for fun" type of article.There's a big difference between "working", and actually working. Latter means passing EMI (susceptibility part is relevant here) and working reliably in real world, not just for 5 minutes in a ideal test condition.It's of course possible that adding enough filtering, it could even work reliably. But no one would replicate what is shown in the article in a serious project/product. This is all meaningless.Both SPI and I2C are for on-board communication. Use them wisely. For longer links, go for something else unless you really know what you are doing, and ready to do some serious work.

author: peter-h
author_rank: Super Contributor
timestamp: March 14, 2022, 04:55:09 pm
content: I've had some "fun" with the ADS1118, but it does work. SPI only.SPI is far simpler than I2C. I once bit-banged I2C on a H8/300 uC and it took 600us to read a 12 bit ADCAnd there were so many ambiguities in the data sheet (ADS7828); basically TI implemented both fast and slow I2C in such a way that the silicon was the same and they just generated two sets of timing specs in the data sheets. Nothing actually changed in the way you drove it. Bizzare.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: March 16, 2022, 07:01:07 pm
content: I do not have a real preference.SPI is a lot simpler then I2C, but I2C can do extremely much with just two wires.SPI can also reach much higher clock speeds and data transfer (expecially quad SPI).An SPI bus is also easy to isolate with opto couplers.However, if you want to control some 10+ (low speed) IC's in a project, then SPI becomes difficult.Most microcontrollers have peripherals for both.Because of it's simplicity, SPI is easy to learn and I would certainly start there.You just need to read the datasheet, and set a few bits in some registers.I2C is al lot more difficult to master. There are quite a few exception states (clock stretching, repeated starts, multi bus master (seldom used).For I2c I hope you can get a decently written library for your microcontroller to start with.For I2C, also have a look at SMBus. (System Management Bus). It is a slightly modified I2C. One of the significant changes is that it has better defined timing and also implements timeouts and recovery from bus faults.

author: Berni
author_rank: Super Contributor
timestamp: March 17, 2022, 07:01:09 am
content: Getting a lot of devices on a I2C bus can be difficult in practice however.For throwing a bunch of different sensors onto a bus it works nicely since they are all different chips with different addresses. Sometimes you do get addresses colliding, but in most cases you can convince one of those conflicting devices to move to a different address. However when you want to have something like 10 identical ADC chips on a bus you run into problems. Most chips are able to be set for 1 alternative address, a lot can do 3 alternative addresses, rare ones can even do 7, but i don't think i seen more than that. So in a lot of cases getting more than 2 of the same chip on the bus is not so easy. As a result you need to have multiple I2C buses or a mux chip.SPI does not have this problem, but admittedly does get a bit annoying by the time you have 10 chip select lines. You can use a BCD to decimal chip from the standard 74xx logic series to get that down to 4 lines, or a shift register to get it down to 3. However quite a few simpler SPI chips support daisy chaining by feeding the MISO of one chip into the MOSI of the next. Then the SPI master simply makes one really long SPI transaction and data gets distributed to all the chips by shifting it trough. This works really well for DMA too.All depends on how well designed the chip is. I seen them range from beautifully simple "just clock it and get data out" to horrendously complicated messes of registers that work in the most annoying way possible.

author: mikerj
author_rank: Super Contributor
timestamp: March 17, 2022, 08:52:24 am
content: If I have a choice I avoid I2C, there are several potential traps to fall down. One really annoying thing is that unlike SPI with it's symmetrical drive it's difficult to control the slew rate on the falling edge of the I2C data/clock signals. When you have sensitive analog signals nearby (or even on the same IC) controlling slew rate is important to reduce crosstalk.Another common issue is that's it's possible to get into a situation where a slave is holding data low preventing a stop or start being asserted (e.g. micro gets reset part way through a transaction), and you have to resort to bit bashing clock cycles out to get it to release the pin. SPI uses more pins (which can make it a non-starter in some applications), but it's simpler to implement, much faster and more reliable IME.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 17, 2022, 06:15:06 pm
content: Quote from: Berni on March 17, 2022, 07:01:09 amThis applies in spades to MCU I2C implementations. Some offer minimalistic support for drivers with the drivers having to control sequencing though every single state during a bus transaction. Others handle most of the state transitions automatically and driver code only needs to handle exceptions. Some require complex calculations to set the bit timing while others make it simple.My current favorite implementation is on the STM32F7 and H7 parts. Most of the work is done by the peripheral and it’s very robust with few quirks common to other implementations.

author: Renate
author_rank: Super Contributor
timestamp: March 17, 2022, 07:27:56 pm
content: Clock stretching in I²C is a demonstrated phenomenom when the devices are travelling at relativistic speeds.Sensors? Give me I²C so they can be attached or detached and I know what's going on.Color LCD display? Give me SPI because I need the speed.I also use 40 bit SPI on Analog Devices AD9850 DDS synthesizer (but I have to bop the chip select myself).Oh, yeah, if you do AVR with AtmelICE, you can use the DGI Gateway for a debug "serial" interface over SPI (the same one you used to program).It's more convenient than using the UART pins, especially if you need them for something else.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 17, 2022, 07:49:54 pm
content: Quote from: Sal Ammoniac on March 17, 2022, 06:15:06 pmYes, they FINALLY spent the (rather manageable) effort to actuallydesignthe I2C peripheral they are advertising. With the F7/H7 families, it also becameactuallypossible to use DMA for I2C.Earlier STM32 MCUs claim to have "I2C" but what it really is, is just a stupid generator of a few simple IO patterns needed to implement I2C, but you still need to do half of the hard work in software. Now create start condition! Is start condition produced? Now clock bits! Are the bits out? Now create stop condition! A single transaction required many interrupts close to each other, and oh boy the possible number of different fault conditions, I remember spending a whole week if not more to write reliable I2C communication in STM32F2 series.Many MCUs are/were similar. Lazy MCU peripheral designers, nothing else.Also the recovery sequence sucks, and the fact that even that isn't necessarily enough. I have heard about designers who simply routinely add a high-side power switch on every I2C IC so they can reset them and retry communication.Now, of course it is also possible to colossally fail an SPI slave device so that it does not reset the communication state on high level of nCS. It's just that I have never seen or heard about one. It's quite easy to get right.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: March 25, 2022, 05:00:58 am
content: If you want t have a lot of identical IC's on an I2C bus, then you have a bunch of options.If your Chip has an adress line that can be toggled to change the I2C address, then you can use an I2C I/O expander to toggle the address lines. So set them all low, except for the chip you want to talk to at some time. With a Demux such as an 74HC138 you can also build further upon this idea.There are also I2C switches, which can branch off an I2C bus, and thus create extra address space.And of course, a lot of uC's have multiple I2C buses. It's also quite common that I2C I/O lines can have "alternate positions" on your uC, and you can also use this to add more "virtual" I2C buses to your uC.With all those switches you may run out of bandwidth (Especially if you have to switch the switches via I2C too) So plan ahead.

author: Berni
author_rank: Super Contributor
timestamp: March 25, 2022, 06:29:56 am
content: Not all I2C chip address select pins can be toggled on the fly. Some only check them on power up, especially the ones that have some special extra combinations to squeeze more address options in (like high/float/low or connecting some other pins together, or pullup resistor value etc.). Certainly a neat trick for the ones that do work with it.Tho my usual fix for address collisions is adding an extra I2C bus since modern MCUs often have 3 separate I2C controllers. This also helps increase the bandwidth of this molasses slow bus.But I2C is still an excellent bus for simple things that don't need performance like temperature sensors or slow ADC/DACs that only get updated a few times per second. As long as you have a smart I2C driver that can do things in the background (waiting for a I2C transfer to finish can eat a lot of CPU time due to how slow the bus is)

author: mariush
author_rank: Super Contributor
timestamp: March 25, 2022, 07:21:10 am
content: Besides the added complexity is there a reason why USB isn't used more often instead of i2c or spi?For example, a 1 wire temperature sensor could easily work as a usb 1.1 device, 1.5 mbps or 10mbs is plenty fastSame for an adc or a led driver or display controller ...Well i guess the polling rate of 125/1000 Hz could be an issue for devices that have to interrupt faster than 1ms but other than that...

author: hans
author_rank: Super Contributor
timestamp: March 25, 2022, 09:12:27 am
content: Because I2C and SPI are mostly just a standardized way of shifting bytes in/out of serial devices. Sure I2C has some addressing and multi-master bus arbitration , but other than there is nothing to it.USB has a whole protocol: multiple tokens, endpoints, device descriptors, setup state machines, and multiple protocol classes and host/client drivers.In addition, each USB device needs an unique VID/PID pair to identify itself. These need to be unique to avoid driver conflicts. The USB association manages, *cough* sells VID/PID ranges for customers to use. For companies making many USB products this is a small fee to pay, but anyone else starting it's very expensive.The "standardized" USB protocol for attached equipment is probably something like CDC-ACM, e.g. a serial port, just like the old days where everyone used RS232 to hook things up together/to PCs.

author: Berni
author_rank: Super Contributor
timestamp: March 25, 2022, 09:37:50 am
content: USB has too much complexity indeed.But the other reason is that USB requires an accurate clock signal to send data at the correct bitrate. This means that a lot of USB chips also have a crystal next to them, or they use extra trickery in that they calibrate there own internal oscillator against the data being received, so it might garble some of the first transmissions.This is some of the same reason why UART is pretty rarely used for communication between chips. You do see it used when talking to modules (like GPS, bluetooth etc..) but there the module contains a full on MCU (with usually again a crystal). You never see UART in things like temperature sensors, ADCs, DACs, IO Expanders...etc Since using I2C or SPI the clock is provided by a dedicated clock wire, removing any timing issues since slave and master both run from the same clock signal.In fact SPI is so simple that you can directly connect a jelly bean 74HC595 shift register directly to a SPI bus and it will work like a IO expander. Any data bits you clock in will appear on the shift register outputs at the end of the SPI transfer. So this shows that it takes only 1 shift register chip to create a valid SPI Slave device.

author: Renate
author_rank: Super Contributor
timestamp: March 25, 2022, 10:20:13 am
content: Quote from: hans on March 25, 2022, 09:12:27 amAlso, they need a unique serial string. Even in a one-off device, give it one, even if it's "1".Especially in Windows it makes a big difference swapping ports.Yeah, the USB-IF controls the numbers. Maybe they should have made them like A, B, C, D IP numbers.And yes, USB (especially host) is a lot more complicated than I²C.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 25, 2022, 10:38:56 am
content: As this thread shows, even just I2C is on the bad end of the complexity spectrum embedded developers want to deal with (with clock stretching, multimaster and poorly specified error recovery that led to modifications like PMbus/SMbus). We deal with I2C fine, but USB is orders of magnitude more complex, so obviously no-go.People like me see deterministic timing as a real value; not only for hard realtime, but as a simplification, too.

author: brucehoult
author_rank: Super Contributor
timestamp: March 25, 2022, 11:26:29 pm
content: Quote from: Berni on March 14, 2022, 07:16:57 amBack 35 years ago Apple computers had networking that used their serial ports (RS-422 from a Zilog Z8530 SCC chip) with external passive components (mostly a transformer) to do CDMA at 230.4 kbps up to 100m on shielded twisted pair. A 3rd party, Farallon provided an alternative passive external box (again, mostly a transformer) driving unshielded twisted pair that extended the range to 1 km / 3000 ft.Farallon also supported a 1 Mbps mode, but I don't recall now what the range of that was.

author: westfw
author_rank: Super Contributor
timestamp: March 30, 2022, 03:10:22 am
content: QuoteIn addition to the complexities already mentioned, USB is also highly asymmetric, with the "host" side being much more complicated than the (already complex) "device" side. Many microcontrollers ONLY implement the "device" side.QuoteUnfortunately (?) that design pretty much ONLY worked with that particular Zilog chip, meaning anyone that wanted to implement localTalk had to use that exact chip. Which ended up not being very popular, and it slowed the adoption of Ethernet on Macs :-(

author: brucehoult
author_rank: Super Contributor
timestamp: March 30, 2022, 03:53:09 am
content: Quote from: westfw on March 30, 2022, 03:10:22 amQuite justifiably so, I'd say, as a PhoneNet adaptor was I think something like $25 while ThinNet and early 10baseT cards were hundreds of dollars. 230.4 kbps was faster than most people's internet connections until into the 2000's (I had 128k/128k DSL until 2004), so was just fine for distributing internet around the home for a long time. 10baseT was decently cheap by ... 1998 ? .. or so, but not really a huge advantage at that point unless you were using a centralised file server.