You've still got the cost of entry - you need to send the cmd, address and dummy bytes before you get your read data - that's going to cost a few clocks.
What if the host could load some firmware for a callback to run on the MCU? Maybe a callback on the MCU could run the new software. For example, to twiddle a ws2812 line based on feedback from an analog line without help from the host. I guess the MCU would be running an elementary OS of its own at that point. I am far out of my depth, so that may be entirely crazy talk.
Ron, you could do what you propose if the mcu is running micropython and communicates to the big Pi via uart serial. You could have a python script that loads a python script onto the micro.
Having the big Pi run the spi is not unreasonable, but probably more trouble than what it's worth. The big Pi's peripherals are crappy - I haven't looked at the Pi4 closely to see if it is much better.
Something like NXP's imx8 series have an A series and a M series on the same chip and can share memory. That would be workable methinks.
To demonstrate the ultimate interconnectedness of everything, there's a M0 implementation of BASIC on the same site: https://www.quinapalus.com/psb.html ;)
(For non-Brits, a 'pound shop' is a shop where everything costs one pound, except, increasingly, the things that don't).
You've still got the cost of entry - you need to send the cmd, address and dummy bytes before you get your read data - that's going to cost a few clocks. As Seymour Cray opined 'cache is no substitute for memory bandwidth'.
Most flash has some flavour of page read - set up an address and keep reading and it auto-incs to the next address. Good for cache loads; not so handy if you're naively trying to execute from the flash where your read address is likely to be leaping around in loops and comparisons. But if you can get it into the cache and execute from there, or into the ram (as we do) then you're golden and it all runs at top speed.
Kartman wrote:
As for barnacle's suggestion of using serial flash for a 6502 - I would've thought the extra hardware alone would've made it impractical. One could use a little fpga and you'd get the 6502 for free.
What would be the fun if it were easy? This is to fill a minor need I've probably rabbited on about before: I would love a parallel flash/eeprom with an SPI write option - and there doesn't seem to be such an animal. That way, you can make a vintage 8-bit system without having also to make/buy an eeprom programmer or having a load-from-serial functionality (which of course has to work before you solder the part to the board...)
Until you get a cache miss from jumping around! Or like the game programmers back in the early days of PCs - write your code so you optimise cache hits. I haven't done a comparison with what you could expect if the flash was internal - using external qspi flash might actually be competitive.
As an aside, I had been pondering a simple little processor where I would do alu operations on the data as it is shifted in/out of what was going to be a serial dram - so I could use a 1 bit alu if using spi or a 4bit alu if using qspi. If doing a fetch, the PC would increment by doing alu add ops whilst shifting out the address and so on. I don't think it would've been too fast - not by today's standards.
The first Intel with cache was 80486's (some of the clones had it from 386).
Define "old". The Pentium Pro was launched in 1995, over 25 years ago. We can still easily recognize the P6 core inside whatever Intel sells these days.
Add: my first PC was a 8088 a 100% clone, 4.77MHz with 640 KRAM 256K on the mother board and a full (really full) size 8 bit ISA card with 384k. (now it's close to what you get for $4!)
my first PC was a 8088 a 100% clone, 4.77MHz with 640 KRAM 256K
Ha, I had a 8088 256k PC clone near the end of college (~ 91); I was too busy at school and a TV repair shop to learn anything about it, but it played a few games (those memories are fuzzy). Latter (~95), I got a 386sx 16MHz 512kDRAM; it is crazy how these chips are stepping over the footprint of those old machines.
Yes, the 3V3, anemic current sinking, and sourcing are pathetic, but you mean its IO toggle rate (right?). I am reasonably sure that is due to the multitasking OS (I suspect all of them are like that), the R-Pi hardware (aside from its bugs) is much faster when done as bare-metal software (right?).
I like the idea of micro-python; maybe it could be loaded at power-up and provide default services to mimic the expected GPIO setup (speed is not a concern since what we have now is not acceptable). The user could swap functions or craft their craziness (including logic) to run in place of whatever defaults they want to replace; a terminal interface to the MCU would be helpful; maybe something like RPC calls could be done over the QSPI hard link to expose default hardware and a terminal for interacting with Python. That would be a lot of work, but absurd stuff happens.
Yes, the 3V3, anemic current sinking, and sourcing are pathetic, but you mean its IO toggle rate (right?). I am reasonably sure that is due to the multitasking OS (I suspect all of them are like that), the R-Pi hardware (aside from its bugs) is much faster when done as bare-metal software (right?).
The RasPi chip started life as a set top box - it didn't need a decent uart etc. Even if you do bare metal or linux kernel drivers, the peripherals are lacking. Things might be different for the Pi4 - I've not looked at it closely. The RasPi started out as a method of writing off excess stock of the Broadcom set top box chips - brilliant idea.
Compare this with the Sitara cpu on the Beaglebone - it was meant as an embedded chip and thus has far superior peripherals. There's also the likes of the NXP imx8 which can have an extra Cortex M4 core or two.
I somehow suspect the RP2040 started life as a Broadcom chip - I get the feeling that an ex - XMOS person did the PIO.
I almost got to work with a Sitara (Beagle), during which I read several less than shinny stories before my involvement ended. I was very fearful of its memory interface and successfully getting the bypass caps to fit under the thing. That was before the module that includes everything was available. I am sure it has superior peripherals, but the Linux support seems to have crashed and burned.
So what's so bad about the RPi UART(s)? Looks like it's got one industry standardish 1655x UART with pretty deep FIFOs, and one "mini uart" with less capabilities, but still better than most microcontrollers...
I thought the main complaint against RPi IO was that the ethernet and WiFi were on the "other side" of a USB switch.
What if the host could load some firmware for a callback to run on the MCU? Maybe a callback on the MCU could run the new software. For example, to twiddle a ws2812 line based on feedback from an analog line without help from the host. I guess the MCU would be running an elementary OS of its own at that point. I am far out of my depth, so that may be entirely crazy talk.
my projects: https://github.com/epccs
- Log in or register to post comments
TopThe floating point library: https://www.quinapalus.com/qfpli...
- Log in or register to post comments
TopRon, you could do what you propose if the mcu is running micropython and communicates to the big Pi via uart serial. You could have a python script that loads a python script onto the micro.
Having the big Pi run the spi is not unreasonable, but probably more trouble than what it's worth. The big Pi's peripherals are crappy - I haven't looked at the Pi4 closely to see if it is much better.
Something like NXP's imx8 series have an A series and a M series on the same chip and can share memory. That would be workable methinks.
- Log in or register to post comments
TopTo demonstrate the ultimate interconnectedness of everything, there's a M0 implementation of BASIC on the same site: https://www.quinapalus.com/psb.html ;)
(For non-Brits, a 'pound shop' is a shop where everything costs one pound, except, increasingly, the things that don't).
- Log in or register to post comments
TopMost flash has some flavour of page read - set up an address and keep reading and it auto-incs to the next address. Good for cache loads; not so handy if you're naively trying to execute from the flash where your read address is likely to be leaping around in loops and comparisons. But if you can get it into the cache and execute from there, or into the ram (as we do) then you're golden and it all runs at top speed.
What would be the fun if it were easy? This is to fill a minor need I've probably rabbited on about before: I would love a parallel flash/eeprom with an SPI write option - and there doesn't seem to be such an animal. That way, you can make a vintage 8-bit system without having also to make/buy an eeprom programmer or having a load-from-serial functionality (which of course has to work before you solder the part to the board...)
Neil
Neil Barnes
www.nailed-barnacle.co.uk
- Log in or register to post comments
TopUntil you get a cache miss from jumping around! Or like the game programmers back in the early days of PCs - write your code so you optimise cache hits. I haven't done a comparison with what you could expect if the flash was internal - using external qspi flash might actually be competitive.
As an aside, I had been pondering a simple little processor where I would do alu operations on the data as it is shifted in/out of what was going to be a serial dram - so I could use a 1 bit alu if using spi or a 4bit alu if using qspi. If doing a fetch, the PC would increment by doing alu add ops whilst shifting out the address and so on. I don't think it would've been too fast - not by today's standards.
- Log in or register to post comments
TopI have some souvenirs from back then
- Log in or register to post comments
TopThere was no cache on old PC's !
The first Intel with cache was 80486's (some of the clones had it from 386).
- Log in or register to post comments
TopDefine "old". The Pentium Pro was launched in 1995, over 25 years ago. We can still easily recognize the P6 core inside whatever Intel sells these days.
- Log in or register to post comments
Top? I just did those before 80486 ;)
Add: my first PC was a 8088 a 100% clone, 4.77MHz with 640 KRAM 256K on the mother board and a full (really full) size 8 bit ISA card with 384k. (now it's close to what you get for $4!)
I got it in 86, but used it from 1985.
- Log in or register to post comments
TopLol my first x86 was a 486.
- Log in or register to post comments
TopHa, I had a 8088 256k PC clone near the end of college (~ 91); I was too busy at school and a TV repair shop to learn anything about it, but it played a few games (those memories are fuzzy). Latter (~95), I got a 386sx 16MHz 512kDRAM; it is crazy how these chips are stepping over the footprint of those old machines.
my projects: https://github.com/epccs
- Log in or register to post comments
TopThe thing you have to appreciate about Python is that the number of available (free) add-on libraries is near infinite.
- Log in or register to post comments
TopYes, the 3V3, anemic current sinking, and sourcing are pathetic, but you mean its IO toggle rate (right?). I am reasonably sure that is due to the multitasking OS (I suspect all of them are like that), the R-Pi hardware (aside from its bugs) is much faster when done as bare-metal software (right?).
I like the idea of micro-python; maybe it could be loaded at power-up and provide default services to mimic the expected GPIO setup (speed is not a concern since what we have now is not acceptable). The user could swap functions or craft their craziness (including logic) to run in place of whatever defaults they want to replace; a terminal interface to the MCU would be helpful; maybe something like RPC calls could be done over the QSPI hard link to expose default hardware and a terminal for interacting with Python. That would be a lot of work, but absurd stuff happens.
update: stuff
my projects: https://github.com/epccs
- Log in or register to post comments
TopThe RasPi chip started life as a set top box - it didn't need a decent uart etc. Even if you do bare metal or linux kernel drivers, the peripherals are lacking. Things might be different for the Pi4 - I've not looked at it closely. The RasPi started out as a method of writing off excess stock of the Broadcom set top box chips - brilliant idea.
Compare this with the Sitara cpu on the Beaglebone - it was meant as an embedded chip and thus has far superior peripherals. There's also the likes of the NXP imx8 which can have an extra Cortex M4 core or two.
I somehow suspect the RP2040 started life as a Broadcom chip - I get the feeling that an ex - XMOS person did the PIO.
- Log in or register to post comments
TopI almost got to work with a Sitara (Beagle), during which I read several less than shinny stories before my involvement ended. I was very fearful of its memory interface and successfully getting the bypass caps to fit under the thing. That was before the module that includes everything was available. I am sure it has superior peripherals, but the Linux support seems to have crashed and burned.
https://elinux.org/BeagleBone_Operating_Systems
On the other hand, the R-Pi is thriving.
https://www.raspberrypi.org/software/operating-systems/
my projects: https://github.com/epccs
- Log in or register to post comments
TopSo what's so bad about the RPi UART(s)? Looks like it's got one industry standardish 1655x UART with pretty deep FIFOs, and one "mini uart" with less capabilities, but still better than most microcontrollers...
I thought the main complaint against RPi IO was that the ethernet and WiFi were on the "other side" of a USB switch.
- Log in or register to post comments
TopPiPico decapped
https://twitter.com/johndmcmaster/status/1355092011829719046
I do not follow twitter, this was from hackernews.
my projects: https://github.com/epccs
- Log in or register to post comments
TopDocumentation for windows is terrible.
Happy Trails,
Mike
JaxCoder.com
- Log in or register to post comments
TopPages