Here is the biggest SPI flash part I could find, in stock, at Digi-Key. It's a 1Gb (256Mx4) device that starts up, like all SPI flashes, in DI/DO SPI mode (though they term these pins DQ0/DQ1). Note the driving of DQ1 and ignoring of DQ0 during an output command at a very certain clock edge:
"Revision History: As of 3/20/2014 we are shipping v1.1 which adds a tri-state buffer to the MISO pin so that you can use the CC3000 with other SPI devices on the same bus."
Sounds like some chip wasn't even respecting the SPI chip select. So they put an external buffer. I guess that this is an approach that could be used with P2 boards if needed, and the 3-wire solution isn't quite working due to a chip not working as expected.
We are talking here about a very controlled situation, with an established genre of flash chips that all work the same way. There will be no need to add buffers or resistors to anything. I doubt any company is going to make a new SPI flash that breaks the established rules for DI/DO behavior. I could be wrong, but I really doubt it. I'm sure if we could get word from some engineers who wrote the design specs for these chips, they would all tell us that the tristate behavior on DO was to allow DI and DO to be connected, saving a signal path. There is no other reason why they would have designed them the way they did. This is hardly debatable.
Here is something I just found. This is some obscure cap-touch-sensing chip with a SPI interface from Analog Devices. Note that it, too, waits for an output command before driving SDO and ignoring SDI, just like the SPI flash chips do. I have been looking at different SPI devices at Digi-Key and I have not been able to find any device that breaks these SPI rules:
>We are talking here about a very controlled situation, with an established genre of flash chips that all work the same way
OK - I thought that people might be sharing these pins with arbitrary SPI chips. But you seem to be saying that they are reserved for SPI flash chips only, and you'll have a list of approved devices.
I don't like that timing diagram, because it only defines that time from /CS rising to tristate. Maybe there's another diagram in the spec?
>We are talking here about a very controlled situation, with an established genre of flash chips that all work the same way
OK - I thought that people might be sharing these pins with arbitrary SPI chips. But you seem to be saying that they are reserved for SPI flash chips only, and you'll have a list of approved devices.
I don't like that timing diagram, because it only defines that time from /CS rising to tristate. Maybe there's another diagram in the spec?
That diagram is lacking a lot - that's all there is! I think because it's only meant to run at 5MHz, they figured it doesn't matter. SPI flash chips are characterized quite thoroughly, though, because they run much faster.
That pin-sharing matter is moot, because we are not building a SPI bus, we are just using a SPI flash in a very controlled way. We (maybe just I) need it to do ONE thing, only - serve boot code. It can do this very quickly and reliably over that one-pin data path.
I have been looking at different SPI devices at Digi-Key and I have not been able to find any device that breaks these SPI rules
If you are looking outside of Memory, then plenty of devices do not follow your 'assumed SPI rule'.
* Try On Semi NCV7754
* Any Microcontroller SPI port, has Separate MISO, MOSI and it drives the OUT as soon as CS=L
* Classic ?C595 series, also do Serial IN, and Serial out immediate drive.
Some SPI parts are designed explicitly to allow serial chaining (similar to ?C595)
I have been looking at different SPI devices at Digi-Key and I have not been able to find any device that breaks these SPI rules
If you are looking outside of Memory, then plenty of devices do not follow your 'assumed SPI rule'.
* Try On Semi NCV7754
* Any Microcontroller SPI port, has Separate MISO, MOSI and it drives the OUT as soon as CS=L
* Classic ?C595 series, also do Serial IN, and Serial out immediate drive.
Some SPI parts are designed explicitly to allow serial chaining (similar to ?C595)
I looked at that NCV7754. It's use of SPI is so simplistic that it's only acting as a shift register. Yes, it would take a controller with separate DI and DO to talk to. Or, you could just write several assembly instructions. Nonetheless, it's a good example of how simple SPI can actually be. I like it!
Would you say there are many devices these days that have SPI interfaces? I really don't know. I'm wondering if many SPI peripherals would likely get attached to the Prop2.
3 wire connection of SPI-Memory is no problem, I have done this many times.
And a minimal pincount for connection of the boot memory is desirable.
But the argument that it puts someboy off to use Quad modes makes the whole idea noncredible, especially if this is the main purpose for this kind of connection.
I anyway don't understand all these concerns about the reboot. Millions of FPGAs, XMOS chips, ESP-chips and others boot from SPI-Flashs and they don't care about a possible QPI mode or a Write/Erase in progress. Some send a WakeUp command, so that you can put the Flash in Deep-sleep mode if desired.
3 wire connection of SPI-Memory is no problem, I have done this many times.
And a minimal pincount for connection of the boot memory is desirable.
But the argument that it puts someboy off to use Quad modes makes the whole idea noncredible, especially if this is the main purpose for this kind of connection.
I anyway don't understand all these concerns about the reboot. Millions of FPGAs, XMOS chips, ESP-chips and others boot from SPI-Flashs and they don't care about a possible QPI mode or a Write/Erase in progress. Some send a WakeUp command, so that you can put the Flash in Deep-sleep mode if desired.
>Would you say there are many devices these days that have SPI interfaces? I really don't know.
I think that it depends on the context. When we were working on GPS chips for smartphones we had I2C/SPI/UART interfaces, and eventually dropped SPI due to lack of interest. I think that customers liked the UART because it was trivially full-duplex and low pin-count. Versus I2C/SPI where they either had to poll them or react to an interrupt. But in this case it was us with flexibility and the customers choosing what worked best given that flexibility. Doesn't mean that they weren't willing to use SPI for other chips.
Now for sensor chips there's an I3C interface which appears to be a combo of I2C and SPI. Not sure how that's catching on, but it might be worth a look since if it's a hit in smartphones then you could potentially see low priced sensors with I3C interfaces. Chips in that market ship in the billion quantities.
That pin-sharing matter is moot, because we are not building a SPI bus, we are just using a SPI flash in a very controlled way. We (maybe just I) need it to do ONE thing, only - serve boot code. It can do this very quickly and reliably over that one-pin data path.
Maybe could also merge the Prop's CS and CLK outputs too? Bring the boot pin count down to just tuned two pins - clock and data. This would need some external passives to filter the clock to make the automatic CS. It would limit maximum duration of clock gap with CS held.
Is there sequences where CS is held low while not clocking? Or where CS must go low distinctly before CLK?
That pin-sharing matter is moot, because we are not building a SPI bus, we are just using a SPI flash in a very controlled way. We (maybe just I) need it to do ONE thing, only - serve boot code. It can do this very quickly and reliably over that one-pin data path.
Maybe could also merge the Prop's CS and CLK outputs too? Bring the boot pin count down to just tuned two pins - clock and data. This would need some external passives to filter the clock to make the automatic CS. It would limit maximum duration of clock gap with CS held.
Is there sequences where CS is held low while not clocking? Or where CS must go low distinctly before CLK?
It's true that CSn cycles very seldom. A resistor and cap could do the trick, while maintaining very low duty cycle to keep CSn low. I don't know if we need to get that crazy, though. Is a pin worth a resistor and a cap? That is the question. Heck, you could even use a 250k resistor to CSn and exploit parasitic capacitance. Might leave CSn vulnerable to other aggressors, though. And any implementation would probably increase read times by 4x. Hey, if we put it in quad mode...
I hope it was no too harsh, with my limited english it's not easy to find the right words.
For this relatively new Lattice FPGA the SPI commands are described quite well. On page 12 you see the wake up as diagram. The whole chapter about SPI Master configuration is worth to read.
The 0xAB code in the #1, is the Release from Deep Power Down and lookup ID command.
Given the P2 is not a super low Icc part, this is more optional ie do you want to include it ?
Macronix says:
"The Deep Power-down (DP) instruction places the device into a minimum power consumption state, Deep Power
down mode, in which the quiescent current is reduced from ISB1 to ISB2."
ISB1 VCC Standby Current ~9 < 50 uA at VIN = VCC or GND, CS# = VCC
ISB2 Deep Power-down Current ~0.1 < 0.5 uA at VIN = VCC or GND, CS# = VCC
ie if 9uA to 0.1uA bothers the system, you might use Deep Power Down. Is that likely ?
I looked at that NCV7754. It's use of SPI is so simplistic that it's only acting as a shift register. Yes, it would take a controller with separate DI and DO to talk to. Or, you could just write several assembly instructions. Nonetheless, it's a good example of how simple SPI can actually be. I like it!
Would you say there are many devices these days that have SPI interfaces? I really don't know. I'm wondering if many SPI peripherals would likely get attached to the Prop2.
Sure. Look at the choices for serial :
i2c has limited speed, 1MHz or 3.4MHz so if you want anything faster SPI is the Sync Bus choice.
UART is common, but getting > 1MHz is not easy, many UARTS have a SysCLK/16 inbuilt.
The ?C595 shift registers series include Relay drivers, and yes, those could often P2 Attach.
Likewise, small MCUs from 28c up, come with SPI ports in HW. If their UART is already used, or not fast enough, there is SPI.
It's true that CSn cycles very seldom. A resistor and cap could do the trick, while maintaining very low duty cycle to keep CSn low. I don't know if we need to get that crazy, though. Is a pin worth a resistor and a cap? That is the question. Heck, you could even use a 250k resistor to CSn and exploit parasitic capacitance. Might leave CSn vulnerable to other aggressors, though. And any implementation would probably increase read times by 4x. Hey, if we put it in quad mode...
Ugh - surely i2c is a better way to save pins, than adding RC lottery to SPI ?
ie if you want minimal-pin choice, just include i2c in the ROM.
There are too many posts to keep up, while still doing work, or visiting family. So I will be quick and short.
If SPI was meant to share DI/DO, then they would only have used 1 common pin. I2C was already common, although licensed at the time.
If the objective is to save pins, then use the option to read I2C by checking for a pullup on CLK as I explained pages ago. For a small EEPROM and tiny package, then they are cheap and basically cannot be beaten.
If not present, then use 4pin SPI Flash. Forget 3 psin SPI Flash.
With a 4pin SPI interface, at least I can share the pins with other devices. Quite possibly I will not be able to do this with 3pin SPI.
Let my try some math again... I have it as around 2 second to load 256kB at 1 MHz. Is that right?
close enough.. 256*1024*(9/1M) = 2.359296s
There is a 3.4 MHz i2c spec, but not many parts seem to include that.
Yes, the 3MHz buss speed is available from many years, it's nothing new or really recent.
But the problem of I2C and bus sharing between many devices is that the bus should operate at the speed of the lower capable device.
Chip, in my life I've never seen direct (short) connection between DI and DO on SPI. I've seen it in block diagrams, conceptual, to explain the working, but then in the real world implementation always a resistor was placed between DO and DI.
DI is always an input to a spi device while DO is output when selected (CS) and required by the received command on DI (ie when data needs to be transmitted from the device). The resistor was always used (and explained) because of the timings and possible signal short circuits between the device DO and the host DI that is still outputting and not switched to HiZ in order to receive DO.
Between the device (flash) DI+DO is never a problem because DI is always an input and is never driven. Of course this is not true while in SDI/SQI/QPI modes where under certain conditions with CS asserted both DI(IO0) and DO(IO1) could be driven at opposite levels.
Thus a resistor should be always required and suggested by the documentation so you should at least enter in DO+R+DI mode of thinking, even if this poses a Fmax limit on the bus.
Here is something I just found. This is some obscure cap-touch-sensing chip with a SPI interface from Analog Devices. Note that it, too, waits for an output command before driving SDO and ignoring SDI, just like the SPI flash chips do. I have been looking at different SPI devices at Digi-Key and I have not been able to find any device that breaks these SPI rules:
I think this is common practice in every SPI device.
We are talking here about a very controlled situation, with an established genre of flash chips that all work the same way. There will be no need to add buffers or resistors to anything. I doubt any company is going to make a new SPI flash that breaks the established rules for DI/DO behavior. I could be wrong, but I really doubt it. I'm sure if we could get word from some engineers who wrote the design specs for these chips, they would all tell us that the tristate behavior on DO was to allow DI and DO to be connected, saving a signal path. There is no other reason why they would have designed them the way they did. This is hardly debatable.
I not agree with you. The 3state (HiZ) behavior is not there to allow you use 3pin bus. It is there to share bus between many parallel devices on 4pin bus. Not all the devices support daisy (serial) connections of MISO MOSI signals, specially if these must be shared between SPI and SDI/SQI/QPI devices.
The 3pin (DI+DO) bus has born after the 4pin bus, mainly as a trick to save a pin on lower MCU and specially where there is no hw peripheral and the user needs to bitbang the communication
Here is something I just found. This is some obscure cap-touch-sensing chip with a SPI interface from Analog Devices. Note that it, too, waits for an output command before driving SDO and ignoring SDI, just like the SPI flash chips do. I have been looking at different SPI devices at Digi-Key and I have not been able to find any device that breaks these SPI rules:
I think this is common practice in every SPI device.
We are talking here about a very controlled situation, with an established genre of flash chips that all work the same way. There will be no need to add buffers or resistors to anything. I doubt any company is going to make a new SPI flash that breaks the established rules for DI/DO behavior. I could be wrong, but I really doubt it. I'm sure if we could get word from some engineers who wrote the design specs for these chips, they would all tell us that the tristate behavior on DO was to allow DI and DO to be connected, saving a signal path. There is no other reason why they would have designed them the way they did. This is hardly debatable.
I not agree with you. The 3state (HiZ) behavior is not there to allow you use 3pin bus. It is there to share bus between many parallel devices on 4pin bus. Not all the devices support daisy (serial) connections of MISO MOSI signals, specially if these must be shared between SPI and SDI/SQI/QPI devices.
The 3pin (DI+DO) bus has born after the 4pin bus, mainly as a trick to save a pin on lower MCU and specially where there is no hw peripheral and the user needs to bitbang the communication
But by SPI standard, whenever a slave has its CSn driven low, it drives its DO pin, while the other slaves float their DO pins. These memory chips, however, are nuanced, beyond that, by waiting until they receive a command on their DI before actually driving their DO, at which point they start ignoring their DI. This matter of needing a resistor, I don't understand. It's absolutely NOT necessary with memory chips IF the master can stop driving DI+DO just before dropping the clock after the last command bit. These resistors people show between DI and DO are not needed to talk to memories over 3 pins, IF the master can do the dance properly. Keep in mind, this is NOT a SPI bus. This is just using a memory that implements a superset of the basic SPI protocol, which allows common DI and DO signalling.
All that needs to be said is that the SPI memory will never be in a state, by its own design, where it will be driving its DO and needing a different state on its DI. This is not to SPI standard, but this is how all SPI memory devices are designed. If the master can play its part correctly, by ceasing to drive DI+D0 before dropping the clock after the last command bit was driven, there will never be contention. You can deduce this from every SPI memory datasheet. These memories were designed to operate this way. Otherwise, they would be driving their DO pins whenever their CSn was driven low.
Does an SD card work if you tie DI and DO on the SPI boot flash? In other words, can I share those three pins between a SPI boot flash and an SD card?
NO. You will have contention on at least some cards, including SanDisk, because they do not drop driving the DO line when /CS goes high. It requires additional clocks with DI=1.
In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.
Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!
But according to Cluso you won't be able to share those 3 pins with an SD card.
That's right. SD cards are different animals. They need discrete DI and DO signals. They will take 4 pins to talk to.
Actually, maybe sharing isn't such a big deal. After all, we have lots of COGs so we might want a separate COG handling SD from the one accessing the SPI flash so the operations can be overlapped. That will require separate pins anyway.
But by SPI standard, whenever a slave has its CSn driven low, it drives its DO pin, while the other slaves float their DO pins. These memory chips, however, are nuanced, beyond that, by waiting until they receive a command on their DI before actually driving their DO, at which point they start ignoring their DI. This matter of needing a resistor, I don't understand. It's absolutely NOT necessary with memory chips IF the master can stop driving DI+DO just before dropping the clock after the last command bit. These resistors people show between DI and DO are not needed to talk to memories over 3 pins, IF the master can do the dance properly. Keep in mind, this is NOT a SPI bus. This is just using a memory that implements a superset of the basic SPI protocol, which allows common DI and DO signalling.
All that needs to be said is that the SPI memory will never be in a state, by its own design, where it will be driving its DO and needing a different state on its DI. This is not to SPI standard, but this is how all SPI memory devices are designed. If the master can play its part correctly, by ceasing to drive DI+D0 before dropping the clock after the last command bit was driven, there will never be contention. You can deduce this from every SPI memory datasheet. These memories were designed to operate this way. Otherwise, they would be driving their DO pins whenever their CSn was driven low.
Yes, but contention can arise from flash itself. Physically shorting together DI and DO will of course dissuade the user to go beyond 1bit mode because the two IOs can't be accessed separately. But switching to 4bit in this condition do not result only in unworking behaviour. It can potentially destroy the flash because its IO0 and IO1 can be driven the opposite way by itself. Think of SDI/SQI that receives commands in standard 1bit mode while outputing data on 2/4 lines (IO0..IO3). What happens if IO0 and IO1 are shorted and their outputted bits differ?
Neither a power-cycle will make such boad operational again. Of course you have to blame the programmer but I would like to avoid a product that can be damaged by software.
But according to Cluso you won't be able to share those 3 pins with an SD card.
That's right. SD cards are different animals. They need discrete DI and DO signals. They will take 4 pins to talk to.
Actually, maybe sharing isn't such a big deal. After all, we have lots of COGs so we might want a separate COG handling SD from the one accessing the SPI flash so the operations can be overlapped. That will require separate pins anyway.
We need to figure out how to differentiate SPI from SD SPI. I think I read that DI should be
But by SPI standard, whenever a slave has its CSn driven low, it drives its DO pin, while the other slaves float their DO pins. These memory chips, however, are nuanced, beyond that, by waiting until they receive a command on their DI before actually driving their DO, at which point they start ignoring their DI. This matter of needing a resistor, I don't understand. It's absolutely NOT necessary with memory chips IF the master can stop driving DI+DO just before dropping the clock after the last command bit. These resistors people show between DI and DO are not needed to talk to memories over 3 pins, IF the master can do the dance properly. Keep in mind, this is NOT a SPI bus. This is just using a memory that implements a superset of the basic SPI protocol, which allows common DI and DO signalling.
All that needs to be said is that the SPI memory will never be in a state, by its own design, where it will be driving its DO and needing a different state on its DI. This is not to SPI standard, but this is how all SPI memory devices are designed. If the master can play its part correctly, by ceasing to drive DI+D0 before dropping the clock after the last command bit was driven, there will never be contention. You can deduce this from every SPI memory datasheet. These memories were designed to operate this way. Otherwise, they would be driving their DO pins whenever their CSn was driven low.
Yes, but contention can arise from flash itself. Physically shorting together DI and DO will of course dissuade the user to go beyond 1bit mode because the two IOs can't be accessed separately. But switching to 4bit in this condition do not result only in unworking behaviour. It can potentially destroy the flash because its IO0 and IO1 can be driven the opposite way by itself. Think of SDI/SQI that receives commands in standard 1bit mode while outputing data on 2/4 lines (IO0..IO3). What happens if IO0 and IO1 are shorted and their outputted bits differ?
Neither a power-cycle will make such boad operational again. Of course you have to blame the programmer but I would like to avoid a product that can be damaged by software.
You have the same potential problems just by tying WPn or HOLDn high (even worse, as VCC is about zero ohms). Think about that. And chips are designed not to burn up under such shorted circumstances. By outputing to DI/DO/WPn/HOLDn (DQ0..DQ3) when any of them are outputting would also cause contention. It would only waste power, though.
Comments
Yes, nominally SPI parts sample the Command.Address data on the Rising CLK edge, and update-out on the Falling CLK edge.
We are talking here about a very controlled situation, with an established genre of flash chips that all work the same way. There will be no need to add buffers or resistors to anything. I doubt any company is going to make a new SPI flash that breaks the established rules for DI/DO behavior. I could be wrong, but I really doubt it. I'm sure if we could get word from some engineers who wrote the design specs for these chips, they would all tell us that the tristate behavior on DO was to allow DI and DO to be connected, saving a signal path. There is no other reason why they would have designed them the way they did. This is hardly debatable.
Here is something I just found. This is some obscure cap-touch-sensing chip with a SPI interface from Analog Devices. Note that it, too, waits for an output command before driving SDO and ignoring SDI, just like the SPI flash chips do. I have been looking at different SPI devices at Digi-Key and I have not been able to find any device that breaks these SPI rules:
OK - I thought that people might be sharing these pins with arbitrary SPI chips. But you seem to be saying that they are reserved for SPI flash chips only, and you'll have a list of approved devices.
I don't like that timing diagram, because it only defines that time from /CS rising to tristate. Maybe there's another diagram in the spec?
That diagram is lacking a lot - that's all there is! I think because it's only meant to run at 5MHz, they figured it doesn't matter. SPI flash chips are characterized quite thoroughly, though, because they run much faster.
That pin-sharing matter is moot, because we are not building a SPI bus, we are just using a SPI flash in a very controlled way. We (maybe just I) need it to do ONE thing, only - serve boot code. It can do this very quickly and reliably over that one-pin data path.
* Try On Semi NCV7754
* Any Microcontroller SPI port, has Separate MISO, MOSI and it drives the OUT as soon as CS=L
* Classic ?C595 series, also do Serial IN, and Serial out immediate drive.
Some SPI parts are designed explicitly to allow serial chaining (similar to ?C595)
I looked at that NCV7754. It's use of SPI is so simplistic that it's only acting as a shift register. Yes, it would take a controller with separate DI and DO to talk to. Or, you could just write several assembly instructions. Nonetheless, it's a good example of how simple SPI can actually be. I like it!
Would you say there are many devices these days that have SPI interfaces? I really don't know. I'm wondering if many SPI peripherals would likely get attached to the Prop2.
And a minimal pincount for connection of the boot memory is desirable.
But the argument that it puts someboy off to use Quad modes makes the whole idea noncredible, especially if this is the main purpose for this kind of connection.
I anyway don't understand all these concerns about the reboot. Millions of FPGAs, XMOS chips, ESP-chips and others boot from SPI-Flashs and they don't care about a possible QPI mode or a Write/Erase in progress. Some send a WakeUp command, so that you can put the Flash in Deep-sleep mode if desired.
Andy
I see what you are saying, Andy. Point taken.
Jmg, what do you know about wake-up commands?
I think that it depends on the context. When we were working on GPS chips for smartphones we had I2C/SPI/UART interfaces, and eventually dropped SPI due to lack of interest. I think that customers liked the UART because it was trivially full-duplex and low pin-count. Versus I2C/SPI where they either had to poll them or react to an interrupt. But in this case it was us with flexibility and the customers choosing what worked best given that flexibility. Doesn't mean that they weren't willing to use SPI for other chips.
Now for sensor chips there's an I3C interface which appears to be a combo of I2C and SPI. Not sure how that's catching on, but it might be worth a look since if it's a hit in smartphones then you could potentially see low priced sensors with I3C interfaces. Chips in that market ship in the billion quantities.
Maybe could also merge the Prop's CS and CLK outputs too? Bring the boot pin count down to just tuned two pins - clock and data. This would need some external passives to filter the clock to make the automatic CS. It would limit maximum duration of clock gap with CS held.
Is there sequences where CS is held low while not clocking? Or where CS must go low distinctly before CLK?
It's true that CSn cycles very seldom. A resistor and cap could do the trick, while maintaining very low duty cycle to keep CSn low. I don't know if we need to get that crazy, though. Is a pin worth a resistor and a cap? That is the question. Heck, you could even use a 250k resistor to CSn and exploit parasitic capacitance. Might leave CSn vulnerable to other aggressors, though. And any implementation would probably increase read times by 4x. Hey, if we put it in quad mode...
I hope it was no too harsh, with my limited english it's not easy to find the right words.
For this relatively new Lattice FPGA the SPI commands are described quite well. On page 12 you see the wake up as diagram. The whole chapter about SPI Master configuration is worth to read.
Andy
The 0xAB code in the #1, is the Release from Deep Power Down and lookup ID command.
Given the P2 is not a super low Icc part, this is more optional ie do you want to include it ?
Macronix says:
"The Deep Power-down (DP) instruction places the device into a minimum power consumption state, Deep Power
down mode, in which the quiescent current is reduced from ISB1 to ISB2."
ISB1 VCC Standby Current ~9 < 50 uA at VIN = VCC or GND, CS# = VCC
ISB2 Deep Power-down Current ~0.1 < 0.5 uA at VIN = VCC or GND, CS# = VCC
ie if 9uA to 0.1uA bothers the system, you might use Deep Power Down. Is that likely ?
Sure. Look at the choices for serial :
i2c has limited speed, 1MHz or 3.4MHz so if you want anything faster SPI is the Sync Bus choice.
UART is common, but getting > 1MHz is not easy, many UARTS have a SysCLK/16 inbuilt.
The ?C595 shift registers series include Relay drivers, and yes, those could often P2 Attach.
Likewise, small MCUs from 28c up, come with SPI ports in HW. If their UART is already used, or not fast enough, there is SPI.
ie if you want minimal-pin choice, just include i2c in the ROM.
If SPI was meant to share DI/DO, then they would only have used 1 common pin. I2C was already common, although licensed at the time.
If the objective is to save pins, then use the option to read I2C by checking for a pullup on CLK as I explained pages ago. For a small EEPROM and tiny package, then they are cheap and basically cannot be beaten.
If not present, then use 4pin SPI Flash. Forget 3 psin SPI Flash.
With a 4pin SPI interface, at least I can share the pins with other devices. Quite possibly I will not be able to do this with 3pin SPI.
Now, here is a diagram of SPI for SD Card. It may not be totally reliable, but the basics are correct
http://elm-chan.org/docs/mmc/mmc_e.html
Yes, the 3MHz buss speed is available from many years, it's nothing new or really recent.
But the problem of I2C and bus sharing between many devices is that the bus should operate at the speed of the lower capable device.
Chip, in my life I've never seen direct (short) connection between DI and DO on SPI. I've seen it in block diagrams, conceptual, to explain the working, but then in the real world implementation always a resistor was placed between DO and DI.
DI is always an input to a spi device while DO is output when selected (CS) and required by the received command on DI (ie when data needs to be transmitted from the device). The resistor was always used (and explained) because of the timings and possible signal short circuits between the device DO and the host DI that is still outputting and not switched to HiZ in order to receive DO.
Between the device (flash) DI+DO is never a problem because DI is always an input and is never driven. Of course this is not true while in SDI/SQI/QPI modes where under certain conditions with CS asserted both DI(IO0) and DO(IO1) could be driven at opposite levels.
Thus a resistor should be always required and suggested by the documentation so you should at least enter in DO+R+DI mode of thinking, even if this poses a Fmax limit on the bus.
I not agree with you. The 3state (HiZ) behavior is not there to allow you use 3pin bus. It is there to share bus between many parallel devices on 4pin bus. Not all the devices support daisy (serial) connections of MISO MOSI signals, specially if these must be shared between SPI and SDI/SQI/QPI devices.
The 3pin (DI+DO) bus has born after the 4pin bus, mainly as a trick to save a pin on lower MCU and specially where there is no hw peripheral and the user needs to bitbang the communication
But by SPI standard, whenever a slave has its CSn driven low, it drives its DO pin, while the other slaves float their DO pins. These memory chips, however, are nuanced, beyond that, by waiting until they receive a command on their DI before actually driving their DO, at which point they start ignoring their DI. This matter of needing a resistor, I don't understand. It's absolutely NOT necessary with memory chips IF the master can stop driving DI+DO just before dropping the clock after the last command bit. These resistors people show between DI and DO are not needed to talk to memories over 3 pins, IF the master can do the dance properly. Keep in mind, this is NOT a SPI bus. This is just using a memory that implements a superset of the basic SPI protocol, which allows common DI and DO signalling.
All that needs to be said is that the SPI memory will never be in a state, by its own design, where it will be driving its DO and needing a different state on its DI. This is not to SPI standard, but this is how all SPI memory devices are designed. If the master can play its part correctly, by ceasing to drive DI+D0 before dropping the clock after the last command bit was driven, there will never be contention. You can deduce this from every SPI memory datasheet. These memories were designed to operate this way. Otherwise, they would be driving their DO pins whenever their CSn was driven low.
In addition to this, the norm is for the micro to output DI=1 while receiving data in on the DO pin.
Thus, SD SPI WILL NOT WORK WITH SHARED DI & DO !!!
I think that is what you were after David.
That's right. SD cards are different animals. They need discrete DI and DO signals. They will take 4 pins to talk to.
Yes, but contention can arise from flash itself. Physically shorting together DI and DO will of course dissuade the user to go beyond 1bit mode because the two IOs can't be accessed separately. But switching to 4bit in this condition do not result only in unworking behaviour. It can potentially destroy the flash because its IO0 and IO1 can be driven the opposite way by itself. Think of SDI/SQI that receives commands in standard 1bit mode while outputing data on 2/4 lines (IO0..IO3). What happens if IO0 and IO1 are shorted and their outputted bits differ?
Neither a power-cycle will make such boad operational again. Of course you have to blame the programmer but I would like to avoid a product that can be damaged by software.
We need to figure out how to differentiate SPI from SD SPI. I think I read that DI should be
You have the same potential problems just by tying WPn or HOLDn high (even worse, as VCC is about zero ohms). Think about that. And chips are designed not to burn up under such shorted circumstances. By outputing to DI/DO/WPn/HOLDn (DQ0..DQ3) when any of them are outputting would also cause contention. It would only waste power, though.