And here's another problem: if we support I2C EEPROM by having a pull-up on SDA (otherwise SPI DI/DO), but no pull-up on SCL (otherwise SPI flash CSn), we don't have a true I2C bus. That is not going to be acceptable, either, right? I mean you can't just use a SPI flash or I2C EEPROM without fully supporting a bus implementation on those same pins, right? That would be like breaking the rules.
The P2 boot conversation seems to be going in circles. I have to say that I liked it so much more when the approach was just the semi-standard 4-pin SPI. What if the P2 stays that way, and effectively forbids using any other form of SPI as boot? It's simple and unambiguous. For a lot of applications, this will be fine. If people want to use some advanced SPI (e.g. SQI, QPI, SD, HyperFlash, or whatever new device might come along in the next 10 to 20 years), use a very small multi-stage boot SPI flash that switches to the "other" device. Yes, this will require one more component. Yes, this will effectively reduce the usable pins by 1 (the boot /CS will generally not be used beyond boot). But so what? Why lock in the possible boot devices (and the complication that goes with it) in the ROM? Is this really any more of a showstopper than the P2 not having internal flash to start with?
Also, there's 4x potential electrical contention using quad modes.
I don't think so, but maybe we're thinking about it differently...
For a 4-pin I/O flash, I would have pullups on IO2 and IO3.
Then, we need to exit 4-pin mode at boot, which just means applying internal weak pullup on SI and SO and toggling the clock twice.
There's no chance of contention there and it only uses the 4 regular SPI pins.
At that point, you either have a regular SPI flash on DI/DO or you have a quad flash in SPI mode that will talk the same way on DI/DO.
Later on, after ROM boot, you could read JEDEC ID and decide if flash chip is quad interface or not, if you wanted to.
And here's another problem: if we support I2C EEPROM by having a pull-up on SDA (otherwise SPI DI/DO), but no pull-up on SCL (otherwise SPI flash CSn), we don't have a true I2C bus. That is not going to be acceptable, either, right? I mean you can't just use a SPI flash or I2C EEPROM without fully supporting a bus implementation on those same pins, right? That would be like breaking the rules.
Who wants a true I2C bus anyway? There are so many standard but not-true I2C buses around that still uses the I2C signals. We are mainly concerned with booting are we not? However I perceive a tongue-in-cheek comment here anyway as some think that the boot device must fully support an implementation even if it complicates the whole boot process and in the process they end up losing the plot.
I've been looking at i2c EEPROMs. They advertise a 100-year data retention, while SPI flash chips only claim 20 years. Well, 20 years has already gone by for BASIC Stamps. I wouldn't want Prop2's failing after 20 years. Maybe we should just use i2c. I'm being serious. This way, the serial booter could actually program firmware. No special stub programmers or device awareness is necessary. Solves a lot of problems.
I've been looking at i2c EEPROMs. They advertise a 100-year data retention, while SPI flash chips only claim 20 years. Well, 20 years has already gone by for BASIC Stamps. I wouldn't want Prop2's failing after 20 years. Maybe we should just use i2c. I'm being serious. This way, the serial booter could actually program firmware. No special stub programmers or device awareness is necessary. Solves a lot of problems.
Can you get EEPROMs that will hold 512K bytes? How much do they cost?
If you made a SPI bus from the existing CLK pin and flash DI/DO pin, using the flash DI/DO pin as the DI and the next pin down as the DO, how is this going to be problematic? Only if the SPI flash's CSn pin is low, could the DI pin possibly be driven. I guess that would just mean that you wouldn't use some standard SPI library to deal with the flash, right?
Also, there's 4x potential electrical contention using quad modes.
Jeez, that's like going back to vacuum tubes... They last a long time too, but wouldn't want to use them in a new design...
Does re-writing the flash reset the clock on retention?
If so, you wouldn't need new hardware, just a serial intervention...
I met a guy who made 800W tube hi-fi amplifiers. He was using delay relays to sequence the start-up. I told him he could use a microcontroller and he laughed. He said, at that time (20 years ago), that EPROMS only had a 40-year data retention. He wanted to make a product to last over a hundred years. He sold those amps for over $100,000 a pair.
I've been looking at i2c EEPROMs. They advertise a 100-year data retention, while SPI flash chips only claim 20 years. Well, 20 years has already gone by for BASIC Stamps. I wouldn't want Prop2's failing after 20 years. Maybe we should just use i2c. I'm being serious. This way, the serial booter could actually program firmware. No special stub programmers or device awareness is necessary. Solves a lot of problems.
I agree. Booting from eeprom is simple and reliable. The software in the eeprom can then boot from whatever device the user wants. Also lives up to erco's byline regarding simplicity.
How about those quad-exit commands? You mean the $FF patterns of variable CLK counts?
Yes! - the ones given in #1, you asked about before.
Any SD card code will include similar exit-preambles, Cluso has mentioned a couple already.
Such preambles are essentially invisible to the user, unless they scope the pins -- but they do notice if they are not there
Okay, so these should do it, in this order?
Send_1b_CS(8,$ff) ' classic M4 exit Quad command, as in NXP etc
Send_1b_CS(16,$ffff) ' classic M4 exit Dual command
Send_1b_CS(2,$ff) ' nibble coverage, in case any parts lack the above, assumes Pullups on DIO3..DIO0. Parts listed below do not need this.
' << by here, BUS should be back in Single-bit mode.
PollBusy ' confirm device connected, and confirm is not Busy
' Optional firm reset - for some newer, larger parts.
Send_1b_CS(8,$66) ' newer 66H,99H command pair
Send_1b_CS(8,$99) ' newer 66H,99H command pair
Wait(>40us) ' does more than a pin-mode change
PollBusy ' unclear if poll busy can be used for 40us timing
' check device ID for <> 00,ff as connected device.
I thought of a way I could impede dual/quad function.... Hold pin 58 low during SPI boot read. That would be like standing on someone's foot while their shoelaces are tied together. No booting for wise guys!
Chip, I've been very busy the last 2 days, I've not reead all the posts.
When trasmitting " FF" in 4bit through 1b the IO2/3 pullups will do the work and DO will be driven high by DI through a series resistor
But I suggest you to reverse the FF
Send_1b_CS(2,$ff) ' nibble coverage, assumes Pullups on DIO3..DIO0. Parts listed below do not need this.
Send_1b_CS(8,$ff) ' classic M4 exit Quad command, as in NXP etc
Send_1b_CS(16,$ffff) ' classic M4 exit Dual command
The docs would explain why this decision was made, too, not hiding anything, but giving the rationale for why it is only 3 pins, and always the same three pins.
Big Problem: Only in an ideal world, does everyone read all the DOCs.. => more support bandwidth & more surprised/annoyed customers. Best avoided, surely ?
As the one who makes the chip and tools, and must deal with customer tech issues, I'd like to have the basic framework be simple and consistent, before users introduce complexities of their own.
That said, I might change my mind.
I'm all for simplicity, but the support cost of 3-pin will easily be MORE than 4 pin.
3 Pin is non-standard, and can be kludged into 4 pin.
If you say SPI-BOOT anywhere in the specs, that is what users will expect.
4-pin can have the simple and invisible exit-preambles included, and that is less complex than you imagine.
To prove this, simply include the preambles in a 4-bit boot, and release the code. Quick and easy, and testing can proceed.
You will easily gauge from the actual use, in the wild, what parts this works with.
And here's another problem: if we support I2C EEPROM by having a pull-up on SDA (otherwise SPI DI/DO), but no pull-up on SCL (otherwise SPI flash CSn), we don't have a true I2C bus. That is not going to be acceptable, either, right? I mean you can't just use a SPI flash or I2C EEPROM without fully supporting a bus implementation on those same pins, right? That would be like breaking the rules.
You can choose a pull-up map for i2c that is legal, I think there is already one above somewhere.
I've been looking at i2c EEPROMs. They advertise a 100-year data retention, while SPI flash chips only claim 20 years. Well, 20 years has already gone by for BASIC Stamps. I wouldn't want Prop2's failing after 20 years. Maybe we should just use i2c. I'm being serious. This way, the serial booter could actually program firmware. No special stub programmers or device awareness is necessary. Solves a lot of problems.
i2c alone would be good, if SPI-FLASH vendors made same-price i2c-pinout variants.
The 100 years is also only an estimate, plus you will have to include SPI flash with any i2c (i2c parts are too small), so the assumed gain in time, is not real - if the flash fails, the system fails, ergo no gained time.
i2c is also MUCH more expensive in large memory choices, (> 10x price of SPI flash) so it is not a viable choice for full-image boot, assuming you could find a 512K byte i2c part. Digikey tops out at 256kB, half a P2.
How about those quad-exit commands? You mean the $FF patterns of variable CLK counts?
Yes! - the ones given in #1, you asked about before.
Any SD card code will include similar exit-preambles, Cluso has mentioned a couple already.
Such preambles are essentially invisible to the user, unless they scope the pins -- but they do notice if they are not there
Okay, so these should do it, in this order?
Send_1b_CS(8,$ff) ' classic M4 exit Quad command, as in NXP etc
Send_1b_CS(16,$ffff) ' classic M4 exit Dual command
Send_1b_CS(2,$ff) ' nibble coverage, in case any parts lack the above, assumes Pullups on DIO3..DIO0. Parts listed below do not need this.
' << by here, BUS should be back in Single-bit mode.
PollBusy ' confirm device connected, and confirm is not Busy
' Optional firm reset - for some newer, larger parts.
Send_1b_CS(8,$66) ' newer 66H,99H command pair
Send_1b_CS(8,$99) ' newer 66H,99H command pair
Wait(>40us) ' does more than a pin-mode change
PollBusy ' unclear if poll busy can be used for 40us timing
' check device ID for <> 00,ff as connected device.
I thought of a way I could impede dual/quad function.... Hold pin 58 low during SPI boot read. That would be like standing on someone's foot while their shoelaces are tied together. No booting for wise guys!
Chip, I've been very busy the last 2 days, I've not reead all the posts.
When trasmitting " FF" in 4bit through 1b the IO2/3 pullups will do the work and DO will be driven high by DI through a series resistor
But I suggest you to reverse the FF
Send_1b_CS(2,$ff) ' nibble coverage, assumes Pullups on DIO3..DIO0. Parts listed below do not need this.
Send_1b_CS(8,$ff) ' classic M4 exit Quad command, as in NXP etc
Send_1b_CS(16,$ffff) ' classic M4 exit Dual command
256kB is only 64 longs, right? You could only fill 1/4 of a cog with that...
Not on my calculator
Largest Digikey i2c part is 256kBytes, or 2Mb - which is only half of a P2 memory.
M24M02-DRMN6TP STMicroelectronics IC EEPROM 2MBIT 1MHZ 8SO $1.76040 2,500 2M (256K x 8 )
Quite a contrast with 8x the memory (4 x P2 images possible), for appx 1/10 the price...
FT25H16S-RT Fremont Micro SERIAL FLASH 16M-BIT 120MHz $0.18600 2,500 16M (2M x 8 ) 120MHz
At some point, we will want to load something like 256kB into P2 RAM.
Just ridiculous with i2c eeprom.
About 80x faster with SPI flash.
640x faster with DDR SQI flash, right?
Let my try some math again... I have it as around 2 second to load 256kB at 1 MHz. Is that right?
Yes. It would take a little over 2 seconds. The cheapest such parts at Digi-Key are $1.76, qty 2k. That's quite a contrast to the 17-cent 512KB SPI part. It's 20x more expensive per bit.
I feel like this 3-pin vs 4-pin SPI issue has drifted into the perception-is-reality zone, so it may be futile to argue, but I made a picture to show why 3-pin is okay, even if it is unusual. I tried to use restive colors here:
Calling it a SPI design intention is maybe optimistic - Wiki says this "Three-wire serial buses
As mentioned, one variant of SPI uses single bidirectional data line (slave out/slave in, called SISO) instead of two unidirectional ones (MOSI and MISO). This variant is restricted to a half duplex mode. It tends to be used for lower performance parts, such as small EEPROMs used only during system startup and certain sensors, and Microwire. Few SPI master controllers support this mode; although it can often be easily bit-banged in software."
So one risk of 3-wire alone, is you move into untested territory.
If the vendors do not test it, or document it, it is risky - eg one vendor may decide driving DO earlier is a good idea, to save power (This avoids floating pins) - or they may hide some test-modes in that DO slot.
Strictly, to short DI-DO, you need to be sure the CMOS drive in P2 removes, before the FLASH drive the pin, but does drive long enough to latch a Valid Address LSB.
That means the delays and phase with the clock now matters.
"The 3-wire nomenclature is the general category of emcompassing the SPI and Microwire busses. The Microwire is a subset of SPI with slightly different timing and data latching. This last part tripped us up at work when we tried to access an SPI EEPROM with a PIC configured for the Microwire data latching."
A Microwire part, like CAT93C46, does specify a timing from last write edge, to DO driven. (Tpd0)
The OnSemi data suggests this drives 0, for a partial bit time.
"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.
Calling it a SPI design intention is maybe optimistic - Wiki says this "Three-wire serial buses
As mentioned, one variant of SPI uses single bidirectional data line (slave out/slave in, called SISO) instead of two unidirectional ones (MOSI and MISO). This variant is restricted to a half duplex mode. It tends to be used for lower performance parts, such as small EEPROMs used only during system startup and certain sensors, and Microwire. Few SPI master controllers support this mode; although it can often be easily bit-banged in software."
So one risk of 3-wire alone, is you move into untested territory.
If the vendors do not test it, or document it, it is risky - eg one vendor may decide driving DO earlier is a good idea, to save power (This avoids floating pins) - or they may hide some test-modes in that DO slot.
It seems to me that the tri-stating of DO and ignoring of DI is a foundational principal of SPI. All SPI parts do this, and I can't imagine they don't design and test for this. You know all those switchovers must occur at certain edges for SPI, just as for QPI.
Comments
I don't think so, but maybe we're thinking about it differently...
For a 4-pin I/O flash, I would have pullups on IO2 and IO3.
Then, we need to exit 4-pin mode at boot, which just means applying internal weak pullup on SI and SO and toggling the clock twice.
There's no chance of contention there and it only uses the 4 regular SPI pins.
At that point, you either have a regular SPI flash on DI/DO or you have a quad flash in SPI mode that will talk the same way on DI/DO.
Later on, after ROM boot, you could read JEDEC ID and decide if flash chip is quad interface or not, if you wanted to.
Who wants a true I2C bus anyway? There are so many standard but not-true I2C buses around that still uses the I2C signals. We are mainly concerned with booting are we not? However I perceive a tongue-in-cheek comment here anyway as some think that the boot device must fully support an implementation even if it complicates the whole boot process and in the process they end up losing the plot.
Does re-writing the flash reset the clock on retention?
If so, you wouldn't need new hardware, just a serial intervention...
I met a guy who made 800W tube hi-fi amplifiers. He was using delay relays to sequence the start-up. I told him he could use a microcontroller and he laughed. He said, at that time (20 years ago), that EPROMS only had a 40-year data retention. He wanted to make a product to last over a hundred years. He sold those amps for over $100,000 a pair.
I agree. Booting from eeprom is simple and reliable. The software in the eeprom can then boot from whatever device the user wants. Also lives up to erco's byline regarding simplicity.
Chip, I've been very busy the last 2 days, I've not reead all the posts.
If you want to use 3 pin then it comes to this: When trasmitting " FF" in 4bit through 1b the IO2/3 pullups will do the work and DO will be driven high by DI through a series resistor
But I suggest you to reverse the FF Edit: edited to fix layout of pin connections
Big Problem: Only in an ideal world, does everyone read all the DOCs.. => more support bandwidth & more surprised/annoyed customers. Best avoided, surely ?
I'm all for simplicity, but the support cost of 3-pin will easily be MORE than 4 pin.
3 Pin is non-standard, and can be kludged into 4 pin.
If you say SPI-BOOT anywhere in the specs, that is what users will expect.
4-pin can have the simple and invisible exit-preambles included, and that is less complex than you imagine.
To prove this, simply include the preambles in a 4-bit boot, and release the code. Quick and easy, and testing can proceed.
You will easily gauge from the actual use, in the wild, what parts this works with.
You can choose a pull-up map for i2c that is legal, I think there is already one above somewhere.
i2c alone would be good, if SPI-FLASH vendors made same-price i2c-pinout variants.
The 100 years is also only an estimate, plus you will have to include SPI flash with any i2c (i2c parts are too small), so the assumed gain in time, is not real - if the flash fails, the system fails, ergo no gained time.
i2c is also MUCH more expensive in large memory choices, (> 10x price of SPI flash) so it is not a viable choice for full-image boot, assuming you could find a 512K byte i2c part. Digikey tops out at 256kB, half a P2.
Will do. Thanks.
Largest Digikey i2c part is 256kBytes, or 2Mb - which is only half of a P2 memory.
M24M02-DRMN6TP STMicroelectronics IC EEPROM 2MBIT 1MHZ 8SO $1.76040 2,500 2M (256K x 8 )
Quite a contrast with 8x the memory (4 x P2 images possible), for appx 1/10 the price...
FT25H16S-RT Fremont Micro SERIAL FLASH 16M-BIT 120MHz $0.18600 2,500 16M (2M x 8 ) 120MHz
I'm home sick with the flu today, I'll blame it on that...
Microwire was an older Natsemi variant, that did allow 3-pin choice.
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Microwire
close enough.. 256*1024*(9/1M) = 2.359296s
There is a 3.4 MHz i2c spec, but not many parts seem to include that.
Just ridiculous with i2c eeprom.
About 80x faster with SPI flash.
640x faster with DDR SQI flash, right?
Yes. It would take a little over 2 seconds. The cheapest such parts at Digi-Key are $1.76, qty 2k. That's quite a contrast to the 17-cent 512KB SPI part. It's 20x more expensive per bit.
Calling it a SPI design intention is maybe optimistic - Wiki says this
"Three-wire serial buses
As mentioned, one variant of SPI uses single bidirectional data line (slave out/slave in, called SISO) instead of two unidirectional ones (MOSI and MISO). This variant is restricted to a half duplex mode. It tends to be used for lower performance parts, such as small EEPROMs used only during system startup and certain sensors, and Microwire. Few SPI master controllers support this mode; although it can often be easily bit-banged in software."
So one risk of 3-wire alone, is you move into untested territory.
If the vendors do not test it, or document it, it is risky - eg one vendor may decide driving DO earlier is a good idea, to save power (This avoids floating pins) - or they may hide some test-modes in that DO slot.
Strictly, to short DI-DO, you need to be sure the CMOS drive in P2 removes, before the FLASH drive the pin, but does drive long enough to latch a Valid Address LSB.
That means the delays and phase with the clock now matters.
Google also finds this
http://www.microchip.com/forums/m202051.aspx
"The 3-wire nomenclature is the general category of emcompassing the SPI and Microwire busses. The Microwire is a subset of SPI with slightly different timing and data latching. This last part tripped us up at work when we tried to access an SPI EEPROM with a PIC configured for the Microwire data latching."
A Microwire part, like CAT93C46, does specify a timing from last write edge, to DO driven. (Tpd0)
The OnSemi data suggests this drives 0, for a partial bit time.
Here's something to ponder - why did Adafruit make this change?
https://www.adafruit.com/product/1469
"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.
It seems to me that the tri-stating of DO and ignoring of DI is a foundational principal of SPI. All SPI parts do this, and I can't imagine they don't design and test for this. You know all those switchovers must occur at certain edges for SPI, just as for QPI.