Erlend,
Do you desire to interactively program the Propeller?
...
No,no, I simply use the onboard EEPROM to store some text strings, and to embed them in the program is not very practical since they are many, and get generated from a pc spreadsheet. I saw someone else wanting to do batch transfer, so I wanted to share my code.
I am fine with the 'conventional' way of programming P.
Peter Jakacki,
I am indeed aware of the difference, and aware of the problem I have created. But the Tachyon thread is still absurdly long.
(Not contending here, just chatting so....)
and the numerous P2 threads discussing wishes, dreams, and visions is okay while Tachyon which is mostly about new features for P1 (without RPis or more Props etc) or information about how to use it is somehow getting under your skin???? In the words of one our politicians "Please Explain".
Okay, Erland seems good. So I wander a bit off-topic and explain.
I simply feel that most threads of a technical nature are best when short and to the point. I am a bit wary of anything that is over 2 or 3 pages unless there is a concerted effort to keep it on track.
Peter Jakacki, you indeed do an exemplary job of maintaining the Tachyon thread.
This thread on the size of EEproms seems a bit exceptional in that it has 4.3K or so viewings to date. Many people appear to have come and gone without commenting.
I really don't know how to develop a criteria for what makes any thread more worthy than others. So of the 'old threads' that no longer have active participation are actually gold mines of good information.
++++++++++
In my own case, I am still trying to decide what is the absolute largest I2C EEprom available today that will working nicely with a Propeller 1 and the origninal PNut boot v0.10 that it contains.
I feel comfortable with 128Kx8 devices being available. But the more I search Digikey, it seems I might be able to go twice or four times that in a single EEprom.
Why bother? Well, now that we have the P1V code for FPGA, I might be able to get the Dram on the device to actually load 512Kx8 binary images if and when a Spin compiler comes along that will create them.
I guess this is one more dream in the Brotherhood of Puzzlement that we share.
Seriously though, there isn't any good reason to go to a really large eeprom, they are too slow and too limited. If you really want extra storage just use a cheap 16MByte SPI Flash like I use on the P8 or microSD.
Yes, I suspect you are correct. I have long admired your wealth of technical pragmatism. It takes me weeks to investigate and resolve what you already know to be the best current solution available.
Do these SPI Flash come in the same SOIC footprint as an EEprom? This whole idea simply started as an up-grade of the on-board EEprom.
I suspect not. You mention SPI, which is faster that I2C and not the same, sometimes required 3 wires rather than the 2 required by i2C. So I am left with the EEprom in the middle that loads an SPI driver and then boots from it.
The BeMicroCV provides an mini SDcard slot, so all the EEprom really needs to do is to pass off communications to download a binary on the SDcard. And so, the EEprom need not be larger than the code required to hand-off the task. I believe the Propeller 1 standard of 32KB does that nicely.
Just for everyone.....
The issue of I2C EEproms versus SPI EEproms and other SPI devices for booting does indeed matter.
And I2C EEprom may only operation at 400KHz top speed, while an SPI device might easily exceed 10 times that. Some of the variables involved are the operating voltage, additional devices on the I2C bus, and so on.
So the 400KHz is just a rough figure, but I will use it for this example.
The standard 32KBytes in a Propeller binary at 400,000hz would take 0.665 seconds to load. A 64KByte EEprom would take twice the time, a 128K EEprom would take four times the time, and so on.
Parallax historically chose the I2C EEprom for its own reasons, which I suspect are the following:
1. Pins 28 and Pins 29 could be used for other IC2 devices after booting if the devices properly following IC2 addressing in the same way as on-board EEprom.
2. I2C uses a two-pin setup -- one pin for Clock and one pin for bi-directional Data, while SPI tends to use three pins for EEproms at high speed (some SPI has adapted to only two pins).
3. Since the Propeller 1 needed only 32KB to be loaded and download, the half-second regions seemed acceptable.
Yes, I could dig into the inner workings and come up with a better figure than 0.665 seconds to boot, but that really isn't the point.
The point is that I2C will always be slower and a new means of loading and booting larger binaries seems slicker. But it still may be well worthwhile maintaining an I2C bus for sensors, displays, and input devices that demand it.
Parallax has provided a lot of boards with an extra 32KB for a total EEprom storage capacity of 64KB. Catalina C has used that feature in a handy way. But most of use just exploit the extra 32KB minimally for 'scratch pad' durable memory.
A 128KB binary would take 4 times longer to boot roughly @ 2.66 seconds. Doubling or quadrupling that borders on waiting too long.
Do you have an application that you wish to boot quickly? Stay with the 32KB binary and add an SDcard (which is also an SPI device) or SPI Flash.
Even if you wish to just have a lot of separate random access storage on an I2C EEprom, you are ahead in the waiting game to use an SPI device. Just trying to swap for a larger EEprom will always be restricting performance.
First, the 1Mbit EEProms are, I believe, all capable of 1MHz operation. Certainly that's true of the Atmel and ST parts. I use them on all my designs and use the extra memory for both double-buffering in-the-field firmware upgrades to minimize the window for "bricking" due to communications/power failures and also for persistent storage.
Second, boot time of the existing device is limited by the fact that it boots using the internal oscillator and runs at some obscenely slow speed until after the image is loaded. This takes 1.6 seconds, even though the EEPROM image can be read in 1/2 that time even at 400KHz. Take a close look at figures 12 and 13 on page 30 of the Datasheet - NOT the manual - and weep.
Third, the existing device will never load images greater than 32KB, because that's what its boot loader does and that's all the ram it has.
If you build your own boot strap (a la Catalina) then your 2nd level boot can run at 128K bytes per second, but you will always pay the 1.3 second penalty because the internal boot loader can't be defeated.
If you build your own FPGA implementation, it, too, can run at 128K bytes per second with no penalty because you can rewrite the boot loader.
On the topic of an SD-type approach, it costs several pins and some board space. It's not likely to be a reasonable bootstrapping solution for most applications.
Finally, I find that in nearly all applications, writing a standalone program that loads things like string literals into the EEPROM in the desired format is the best approach. The complexity of building a PC environment to do a download has just never proven worthwhile.
It might be possible to get around the 1.6 second boot time. The boot loader first checks for a download over the serial port. An inexpensive PIC chip could be programmed to talk over the serial port and load a small boot program. That should take a fraction of a second. The small boot program could then download from the EEPROM at 1 MHz, which should take about a quarter of a second.
There's no documentation for the "serial" boot option other than the source code that is not well documented either. I believe the baud rate is not very high, do you know? Also, I believe it always downloads the full 32KB - no?
Comments
No,no, I simply use the onboard EEPROM to store some text strings, and to embed them in the program is not very practical since they are many, and get generated from a pc spreadsheet. I saw someone else wanting to do batch transfer, so I wanted to share my code.
I am fine with the 'conventional' way of programming P.
Erlend
and the numerous P2 threads discussing wishes, dreams, and visions is okay while Tachyon which is mostly about new features for P1 (without RPis or more Props etc) or information about how to use it is somehow getting under your skin???? In the words of one our politicians "Please Explain".
I simply feel that most threads of a technical nature are best when short and to the point. I am a bit wary of anything that is over 2 or 3 pages unless there is a concerted effort to keep it on track.
Peter Jakacki, you indeed do an exemplary job of maintaining the Tachyon thread.
This thread on the size of EEproms seems a bit exceptional in that it has 4.3K or so viewings to date. Many people appear to have come and gone without commenting.
I really don't know how to develop a criteria for what makes any thread more worthy than others. So of the 'old threads' that no longer have active participation are actually gold mines of good information.
++++++++++
In my own case, I am still trying to decide what is the absolute largest I2C EEprom available today that will working nicely with a Propeller 1 and the origninal PNut boot v0.10 that it contains.
I feel comfortable with 128Kx8 devices being available. But the more I search Digikey, it seems I might be able to go twice or four times that in a single EEprom.
Why bother? Well, now that we have the P1V code for FPGA, I might be able to get the Dram on the device to actually load 512Kx8 binary images if and when a Spin compiler comes along that will create them.
I guess this is one more dream in the Brotherhood of Puzzlement that we share.
Do these SPI Flash come in the same SOIC footprint as an EEprom? This whole idea simply started as an up-grade of the on-board EEprom.
I suspect not. You mention SPI, which is faster that I2C and not the same, sometimes required 3 wires rather than the 2 required by i2C. So I am left with the EEprom in the middle that loads an SPI driver and then boots from it.
The BeMicroCV provides an mini SDcard slot, so all the EEprom really needs to do is to pass off communications to download a binary on the SDcard. And so, the EEprom need not be larger than the code required to hand-off the task. I believe the Propeller 1 standard of 32KB does that nicely.
The issue of I2C EEproms versus SPI EEproms and other SPI devices for booting does indeed matter.
And I2C EEprom may only operation at 400KHz top speed, while an SPI device might easily exceed 10 times that. Some of the variables involved are the operating voltage, additional devices on the I2C bus, and so on.
So the 400KHz is just a rough figure, but I will use it for this example.
The standard 32KBytes in a Propeller binary at 400,000hz would take 0.665 seconds to load. A 64KByte EEprom would take twice the time, a 128K EEprom would take four times the time, and so on.
Parallax historically chose the I2C EEprom for its own reasons, which I suspect are the following:
1. Pins 28 and Pins 29 could be used for other IC2 devices after booting if the devices properly following IC2 addressing in the same way as on-board EEprom.
2. I2C uses a two-pin setup -- one pin for Clock and one pin for bi-directional Data, while SPI tends to use three pins for EEproms at high speed (some SPI has adapted to only two pins).
3. Since the Propeller 1 needed only 32KB to be loaded and download, the half-second regions seemed acceptable.
Yes, I could dig into the inner workings and come up with a better figure than 0.665 seconds to boot, but that really isn't the point.
The point is that I2C will always be slower and a new means of loading and booting larger binaries seems slicker. But it still may be well worthwhile maintaining an I2C bus for sensors, displays, and input devices that demand it.
Parallax has provided a lot of boards with an extra 32KB for a total EEprom storage capacity of 64KB. Catalina C has used that feature in a handy way. But most of use just exploit the extra 32KB minimally for 'scratch pad' durable memory.
A 128KB binary would take 4 times longer to boot roughly @ 2.66 seconds. Doubling or quadrupling that borders on waiting too long.
Do you have an application that you wish to boot quickly? Stay with the 32KB binary and add an SDcard (which is also an SPI device) or SPI Flash.
Even if you wish to just have a lot of separate random access storage on an I2C EEprom, you are ahead in the waiting game to use an SPI device. Just trying to swap for a larger EEprom will always be restricting performance.
First, the 1Mbit EEProms are, I believe, all capable of 1MHz operation. Certainly that's true of the Atmel and ST parts. I use them on all my designs and use the extra memory for both double-buffering in-the-field firmware upgrades to minimize the window for "bricking" due to communications/power failures and also for persistent storage.
Second, boot time of the existing device is limited by the fact that it boots using the internal oscillator and runs at some obscenely slow speed until after the image is loaded. This takes 1.6 seconds, even though the EEPROM image can be read in 1/2 that time even at 400KHz. Take a close look at figures 12 and 13 on page 30 of the Datasheet - NOT the manual - and weep.
Third, the existing device will never load images greater than 32KB, because that's what its boot loader does and that's all the ram it has.
If you build your own boot strap (a la Catalina) then your 2nd level boot can run at 128K bytes per second, but you will always pay the 1.3 second penalty because the internal boot loader can't be defeated.
If you build your own FPGA implementation, it, too, can run at 128K bytes per second with no penalty because you can rewrite the boot loader.
On the topic of an SD-type approach, it costs several pins and some board space. It's not likely to be a reasonable bootstrapping solution for most applications.
Finally, I find that in nearly all applications, writing a standalone program that loads things like string literals into the EEPROM in the desired format is the best approach. The complexity of building a PC environment to do a download has just never proven worthwhile.
There's no documentation for the "serial" boot option other than the source code that is not well documented either. I believe the baud rate is not very high, do you know? Also, I believe it always downloads the full 32KB - no?
I just checked the boot source code, it does use a dynamic count of long words to be sent.
Not an inexpensive approach, but interesting an interesting observation and possibly worth pursuing.