Raspberry Pi is now a microcontroller

Go To Last Post
70 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The floating point library:  https://www.quinapalus.com/qfpli...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

The floating point library:  https://www.quinapalus.com/qfpli...

 

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).

Last Edited: Sat. Jan 23, 2021 - 01:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

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...)

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
runs at top speed.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Kartman wrote:
back in the early days of PCs - write your code so you optimise cache hits

 

I have some souvenirs from back then smiley

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There was no cache on old PC's !

The first Intel with cache was 80486's  (some of the clones had it from 386). 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

There was no cache on old PC's !

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

? 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.

Last Edited: Sat. Jan 23, 2021 - 05:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lol my first x86 was a 486.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The thing you have to appreciate about Python is that the number of available (free) add-on libraries is near infinite.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
The big Pi's peripherals are crappy

 

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.

 

update: stuff

Last Edited: Sun. Jan 24, 2021 - 05:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ron_sutherland wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

https://elinux.org/BeagleBone_Operating_Systems

 

On the other hand, the R-Pi is thriving.

 

https://www.raspberrypi.org/software/operating-systems/

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it didn't need a decent uart

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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PiPico decapped

 

https://twitter.com/johndmcmaster/status/1355092011829719046

 

I do not follow twitter, this was from hackernews.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Documentation for windows is terrible.

Happy Trails,

Mike

JaxCoder.com

Pages