Raspberry Pi is now a microcontroller

Go To Last Post
95 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

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

Apparently the RP2040 ADC has a design or manufacturing flaw, sample capacitors inside the ADC have sizes incorrect by about 0.8% and this results in non-linearity errors for some ADC codes.

Here is a good article on the issue:

https://pico-adc.markomo.me/INL-DNL/

 

 

In other words, I was thinking about getting one but I guess I'll wait for a silicon revision.

Last Edited: Mon. Apr 12, 2021 - 08:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But still better than a org. AVR with a 10 bit ADC ;)

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

"Dare to be naïve." - Buckminster Fuller

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

sparrow2 wrote:

But still better than a org. AVR with a 10 bit ADC ;)

 

Take a 12-Bit ADC AVR-DA/DB!

These 8-Bit controllers are still a replacement in 99% of cases of use. Smaller, more flexible, more energy efficient, but above all, much easier to program. To call RPi chips "microcontroller" is an insult to any real microcontroller chip like AVR/PIC.

Last Edited: Wed. Jul 14, 2021 - 04:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
To call RPi chips "microcontroller" is an insult to any real microcontroller chip like AVR/PIC.
I've used Teensy 4.0 and 4.1 quite a lot. I program them using Arduino. Under the hood the chip is a 600MHz  IMXRT1062DVJ6A  which is a 32/64 bit Cortex M7 (it can actually overclock to 900MHz or more). Sure it's a bit faster than a 16/20/32MHz AVR but it has UART, SPI, I2C, timers, ADC, etc and (in Arduino at least) the programming interface to such devices is pretty much identical to what you might use for a 16MHz 328P on an Uno. So does such a chip not count as a "microcontroller" then ?

 

Sure there are ARM Cortex (the Cortex-A rather than Cortex-M) that are "application processors" that are intended to run OS like Linux and that may not have much in the way of CPU peripherals (just sysclocks, DRAM controllers, etc) and I'd agree that you might be hard pushed to call these "microcontrollers" but as soon as you put even something like this into a chip as an SoC (System on Chip) where it is the core but then surrounded by typical peripherals at what point does it stop being an application processor and start becoming a controller. (in reality actually, SoCs with Cortex-A CPUs will often have a couple of M3's or M4's dotted around that mop up the interfaces to the system peripherals but overall the thing can be used as an embedded controller). In fact if you study a modern car you might find 20-50 (or more) such CPUs (A's, M's, 8051's, AVR's etc etc) dotted around performing some kind of embedded role in the car.

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

GermanFranz wrote:
To call RPi chips "microcontroller" is an insult to any real microcontroller chip like AVR/PIC.

You do realise that the chip under discussion here is a Cortex-M0 (OK, so it's dual-core) - not the Cortex-A or ARM9 of the Raspberry Pi single-board computers ?

 

What makes AVR/PIC any more "real" than Cortex-M0? or any other Cortex-M ?

 

Could you not equally say that things like AVR/PIC are an insult to any "real" microcontroller chip like the original 4-bit Intel 4004 ?

 

Or even the original 8051?

 

Surely, "microcontroller" has always covered a broad spectrum from 4-bit updwards ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
To call RPi chips "microcontroller" is an insult to any real microcontroller chip like AVR/PIC.

 

It may be a translation problem; I think the AVR/PIC are more likely to be envious of a dual-core ARM M0 /w 264kB SRAM (core separated banks?) on die (that is some crazy stuff). I wonder how deep the instruction pipe is; maybe 133MHz is as fast as they can go from SRAM without adding to the instruction pipeline. Does anyone know if the M0 has much of an instruction pipe? Maybe that is what the number after tells (M#) (that was a joke btw).

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

ron_sutherland wrote:
I think the AVR/PIC are more likely to be envious of a dual-core ...
rather than the anthropomorphic, a dual-core AVR (XMEGA) :

megaAVR 0-series | Page 4 | AVR Freaks

"Dare to be naïve." - Buckminster Fuller

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

ron_sutherland wrote:
It may be a translation problem; I think the AVR/PIC are more likely to be envious of a dual-core ARM M0

 

No, it's not a translation problem.

Now one can argue endlessly about definitions of terms.

The classic 8-Bit microcontroller (I mentioned one attractive type above) is sufficient for 99% of all classic controller applications - that is my experience. And in many cases (in my case in smart home applications) with 2 MHz clock and less! If stronger 32-bit types with much more MHz are used today, they are often only used to hide their inefficient programming. I am certainly not jealous of the many great ARM features - cause they are ultimately unnecessary and only complicate programming. In understanding the chip and in the requirements of the development environment. Such insights are of course unsympathetic to those whose eyes light up only at maximum MHz and complex cores+peripherals, but in short, I really don't know what raison d'être a RP2040 would have as a classic "microcontroller".

Last Edited: Thu. Jul 15, 2021 - 07:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

GermanFranz wrote:
I really don't know what raison d'être a RP2040 would have as a classic "microcontroller".
I've used similar to make a synthesizer for example. It still has "controller" features like reading encoders, joystick and so on and driving a GLCD to give the user feedback but then it uses CPU power to do audio processing to synthesize or play samples of sound - something it's quite tricky to get a 16/20/32MHz "controller" to do.

 

I imagine if you were to do anything with video rather than audio you would welcome the heft CPU power behind the controller peripherals too!

 

In fact as a general rule in audio and video applications you simply can never have enough CPU power!

 

But two lots of 133MHz in RP2040 or even 600MHz in Teensy 4.x goes some of the way!

 

Microcontrollers are far more ubiquitous than just opening valves or stepping motors you know!

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

clawson wrote:
and driving a GLCD
Epson has LCD controllers and, IIRC, others also.

clawson wrote:
In fact as a general rule in audio and video applications you simply can never have enough CPU power!
GPU for awhile.

 


Memory Display Controllers (Epson VDC, Memory-in-Pixel LCD)

S1D13517 (Epson VDC, LCD)

...

Additionally, the S1D13517 incorporates a 2D graphics engine with alpha blending capability.

...

Such is in some MCU as a peripheral though coming up short on which MCU (APU?)

 

NTSC or PAL, 18 mA typical :

VLSI Solution-VS23S010 - 1 Mbit Versatile SPI / 8-Bit Parallel Bus SRAM

https://octopart.com/search?q=VS23S010D-L&currency=USD&specs=0

VS23S0X0 - VLSI Solution Webstore

 

EGA to VGA: The initiation of bit-mapped graphics and the chip clone wars | Electronic Design

 

edit : adds VGA to composite video; up to 75 mA typical

VLSI Solution-VS23S040 - 4 Mbit Versatile SPI / 8-Bit Parallel Bus SRAM

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Jul 15, 2021 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
In fact as a general rule in audio and video applications you simply can never have enough CPU power!

 

Of course.

But I would no longer call audio / video applications a classic task for a microcontroller. For these, 32/64-bit machines are ideal.

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

GermanFranz wrote:
But I would no longer call audio / video applications a classic task for a microcontroller. 
Guess we can argue this til the cows come home but I guess it's what one perceives a controller? 

 

Personally I think I work on "controllers" because I am working on an embedded application. It has a fixed job. The ultimate output is the control of a cars brakes and steering wheel. The idea being to prevent the car from killing people. However the "controller" at the heart of this is (these days) and insanely powerful piece of silicon that often, in a single SoC has two or three Cortex-M cores that are doing low level jobs like interfacing to CAN, LIN, UART, Ethernet, ADC, SPI, I2C, etc above this are often quad or octa cores which might be M-7s or perhaps Cortex-A doing "application processing". Alongside this there are often multi-core graphics processors - both input processors and output processors that take the workload off the A/M7's because 4 or 8 of those is still not enough power.

 

But at the end of the day it's a box that sits under the hood of your car and controls the vehicle so in my eyes that is a "controller".

 

Your mileage may vary.

 

(actually such boxes are known in the trade as "ECU" - that is "Electronic Control Unit" - cars these days have many of these - another may be doing ABS and another doing cruise control etc etc).

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

By the very definition of microcontroller, it must have some form of inbuilt flash memory. But RP2040 doesn't have one.

 

Can we really call it a true microcontroller?  🤔

Last Edited: Thu. Jul 15, 2021 - 02:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would like to remind of the "micro" in micro-controller.

This is nothing I would associate with

 

  • Dual-core Arm Cortex-M0+ @ 133MHz
  • 264KB  on-chip RAM
  • Support for up to 16MB of off-chip Flash memory via dedicated QSPI bus

 

When it comes to UARTs, SPI, I2C, ADC and DAC, PWM and some useful GPIOs in general a simpler AVR/PIC "Micro" is definitely enough in most cases-  even more advantageous.

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

Heisen wrote:
By the very definition of microcontroller, it must have some form of inbuilt flash memory.
Sorry but where is it defined that a "microcontroller" must have internal flash? There's a lot of devices these days that can actually do the initial program load from SPIflash for example. 

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

GermanFranz wrote:
For these, 32/64-bit machines are ideal.
re Opus audio codec, concur though 16b MCU are capable with AVR XMEGA as a possibility at a low bit-rate.

 

MCU vs CoreMark
SAMV71 1503
PIC32MZ EF   710
dsPIC33CH   395
   
   
   
   

 

PIC32 Digital Audio | Microchip Technology

PolarFire® SoC FPGA: Opus Codec Benchmarking (RISC-V)

New Digital Signal Controller (DSC) Accelerates DSP Performance for Time-Critical Control Applications | Microchip Technology | Microchip Technology

On what platforms does Opus run? | OpusFAQ - XiphWiki

CPU Performance Benchmark – MCU Performance Benchmark – CoreMark – EEMBC Embedded Microprocessor Benchmark Consortium

 

Conversely, recall 8-bit video games :

Roman Black's BTc 1bit Sound Encoding Algorithms (PIC)

 

"Dare to be naïve." - Buckminster Fuller

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

Heisen wrote:
... it must have some form of inbuilt flash memory.
Flash becomes non-functional at a very elevated temperature (geophysical, thermal noise) and looses data with enough radiation energy and flux; a partial work-around is non-volatile memory with ECC (MRAM, some F-RAM, some EEPROM)

 

Reference Design HT-DAB-1 | VORAGO Technologies — VORAGO Technologies

Extreme Temperature ARM® Cortex®-M0 MCU VA10800 | VORAGO Technologies — VORAGO Technologies

RIP Opportunity | The Embedded Muse 368

Apollo4 - Ambiq

 

"Dare to be naïve." - Buckminster Fuller

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

GermanFranz wrote:

  • 264KB  on-chip RAM

I raise 'ya and toss in an MMUwink

GermanFranz wrote:
... in general a simpler AVR/PIC "Micro" is definitely enough in most cases-  even more advantageous.
Disadvantageous is negotiating the license for third parties; so, 8051 are common with RISC-V as a recent arrival.

 


HUGE Memory MCU | AVR Freaks (PIC32MZ DA)

 

ESP32-S2 Wi-Fi MCU I Espressif (ULP core is RISC-V)

 

"Dare to be naïve." - Buckminster Fuller

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


clawson wrote:
Sorry but where is it defined that a "microcontroller" must have internal flash?

I heard on amp hour podcast where Dave from eevblog was mentioning this, he was criticizing  RP2040 on being called a microcontroller knowing that it does not have flash memory.

 

But yeah the Wikipedia definition says any form of program memory is okay for microcontroller.

 

But I see some sites stating the opposite. Which I guess is causing this confusion.

 

https://www.pcmag.com/encyclopedia/term/microcontroller

 

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

GermanFranz wrote:
The classic 8-Bit microcontroller (I mentioned one attractive type above) is sufficient for 99% of all classic controller applications - that is my experience. And in many cases (in my case in smart home applications) with 2 MHz clock and less! If stronger 32-bit types with much more MHz are used today, they are often only used to hide their inefficient programming. I am certainly not jealous of the many great ARM features - cause they are ultimately unnecessary and only complicate programming. In understanding the chip and in the requirements of the development environment. Such insights are of course unsympathetic to those whose eyes light up only at maximum MHz and complex cores+peripherals, but in short, I really don't know what raison d'être a RP2040 would have as a classic "microcontroller".

 

It is so much easier to get things done with an AVR-type device, probably due to its lower complexity, but that R-Pi chip is fascinating. I would likely dislike learning the software side of that complexity, but I like pondering the hardware.

 

 

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

gchapman wrote:

Flash becomes non-functional at a very elevated temperature (geophysical, thermal noise) and looses data with enough radiation energy and flux; a partial work-around is non-volatile memory with ECC (MRAM, some F-RAM, some EEPROM)

 

When I was working with high-temperature stuff, five years or so ago, I was investigating FRAM; no maker would certify its livespan at the high temperatures to be found down a deep drill shaft. I was able to show it working for short periods - tens of hours - at temperatures in excess of 150C but never got the chance to work on longer testing.

 

Controllers vs processors: I take the rule of thumb that it's the addition of peripherals that makes a processor into a controller: serial or parallel ports, timers, and other things which might with a traditional processor require external components. I don't believe that it's necessary to have the program memory inside the chip - external flash with four or eight bits that can load into and execute from onboard RAM works fine.

 

Neil

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

it must have some form of inbuilt flash memory.

Nonsense.  Pretty much any internal memory will do, "definition-wise", and the rp2040 internal ROM certainly qualifies even if the RAM doesn't.

Don't forget that the earliest "microcontrollers" predate flash, and had either internal ROM (8048. TMS1000) or EPROM (8751, PIC)

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

In 1995-1996 I was working with Z80 systems. For industrial applications. I was using Z80 CPU with SRAM and EPROM, SIO, CTC, and the gpio pins with HC374/574/244/245. The Z80 CPU+SIO+CTC+RAM+EPROM was the "microcontroller". Real embedded applications, C cross compiler, flash programming was EPROM burning :-)

In parallel I was working with 8051 systems, with external memories. The "microcontroller" was 80C31+RAM+EPROM. A step forward.

2000-2005 working with Rabbit2000 systems. Microcontroller was Rabbit+SRAM+Parallel NOR Flash. In system programming this time.

Since 1998 I was working with AVR real microcontrollers. I remember that at first they were 8K flash at max., 512 ram. Still very useful for a LOT of applications.

Guess what, the older systems were slowly shadowed by the AVR micros, which were more and more powerful and easier to use.

Since 2009-2010 I started to use Cortex-M micros for my bigger apps.

RPi micro + SPI flash is a no brainer compared to my Z80/Rabbit/8051 systems. But now, for me, it is too late for it. I can't see a reason to use it instead of any other Cortex-M I already use.

"Microcontroller" or not, is just wording. I don't care what you call a thing. I care what can you do with it.

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


ron_sutherland wrote:
but that R-Pi chip is fascinating. I would likely dislike learning the software side of that complexity,
One thing the Raspberry people do well is to deliver a "system" rather than simply a component. 

 

If you follow the series of links (starting with one in post #1):

 

https://www.raspberrypi.org/blog...

https://www.raspberrypi.org/docu...

https://www.raspberrypi.org/docu...

https://github.com/raspberrypi/p...

 

then you arrive at:

/**
 * Copyright (c) 2020 Raspberry Pi (Trading) Ltd.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 */

#include "pico/stdlib.h"

int main() {
#ifndef PICO_DEFAULT_LED_PIN
#warning blink example requires a board with a regular LED
#else
    const uint LED_PIN = PICO_DEFAULT_LED_PIN;
    gpio_init(LED_PIN);
    gpio_set_dir(LED_PIN, GPIO_OUT);
    while (true) {
        gpio_put(LED_PIN, 1);
        sleep_ms(250);
        gpio_put(LED_PIN, 0);
        sleep_ms(250);
    }
#endif
}

as your first "LED blinker". It doesn't actually look any more complex than what you might do in Arduino (say). Sure the APIs are different and something to be learned but that may be as far as the complexity goes. One assumes that in their CRT they are doing all the "magic" to get the complex chip into a runnable state - so you don't have to worry about that.

 

On that link journey you may have seen that you basically have a choice between C/C++ and MicroPython. It's quite possible the latter may actually be a simpler route still (for those who already know a bit of Python). Python is very easy to use - a bit like modern day BASIC. From their Python PDF:

 

https://datasheets.raspberrypi.o...

 

One sees usage such as:

(in a typically Python style this is actually doing it "live"/interactively rather than with a "compiled" program - though that is possible too - you can put these lines into a .py file then have it all interpreted at once).

 

Pages