Tiny 2040 - a tiny RP2040 stamp

[ag123]

i see it partly a matter of preference and that after all they are 2 different products (pico vs stm32) with different features.
stm32 has more advanced (at least different) IOs, the hardware timers is already one difference.
pico puts its flash in a separate spi chip, it means someone who bother to hack that can extract the firmware from the flash chip, this would be of concern for those who seek to 'protect' their firmware. this is a same problem for esp32 and esp8266.
the right stm32 socs has sdio, pico's sdio is done using PIO !
https://github.com/raspberrypi/pico-ext ... /sd_card.c
oh but then pico has PIO, 'they' 'hyped' so much about it
https://www.raspberrypi.org/blog/what-is-pio/
but PIO is useful i think it may be possible to bit bang 10 mbps ethernet using manchester encoding, if that's possible it is fun
at least you could talk ethernet and slow down the whole 10 gbps ethernet and hog that to talk to your host pc
https://github.com/raspberrypi/pico-examples#pio
oh and for 1 thing pico is dual core, i'm not too sure if one of the core can bit bang bluetooth le or wifi at 2.4ghz
oh TI has got this funky chip
https://www.ti.com/product/CC2500
https://www.aliexpress.com/wholesale?ca ... ext=cc2500
maybe it is after all possible

[AndrewBCN]

i see it partly a matter of preference...
...

Yes, for a simple hobby project it is very much a matter of preference or in other words a totally subjective choice, since any MCU will do, and there are always people willing to try the latest chip on the market, specially if it is actively promoted on social media (YouTube, etc).
There is an ironical expression in France, which goes like: "Why make it simple when you can always make it more complicated?"

It's quite the opposite if you are an engineer and have to choose an MCU for a project under development, with constraints such as:
- Production costs.
- Development resources (engineer man.hours, lab costs, maintainability of source code, etc).
- Technical constraints.
- Time-to-proof-of-concept, time-to-market.
- Etc.
Then the choice becomes an objective examination of the vast choice of available MCUs and it is in that situation that the RP2040 shows its total lack of competitiveness.

[ag123]

one thing though don't write off that PIO stuff
https://en.wikipedia.org/wiki/Cypress_PSoC
https://www.intel.com/content/www/us/en ... one-v.html

I think ST would need to get into this as well, PIO can 'simplify' some stuff where firmware can't catch up with hardware speeds.
e.g. manchester encoding (ethernet 10 mbps), BTLE whitening (LSFR and xor), USB high speeds, WIFI encoding / decoding etc ( this can simplify the transceiver phy design).
it can even 'bit bang' usb if you'd like. the point where FPGA and SOC are getting pulled together first started with things like PSOC from cypress, then the dedicated ones xilinx and altera etc. But sooner than later (which is now) they'd find themselves into soc silicon as well.
quite soon they may even be LUT (look up table) style PIO stuff which is pretty much a macrocell inside a soc.

'multi-core' is the other thing that's getting into pico. my guess is soon more socs will start to have the same features.

[mrburnette]

...
Then the choice becomes an objective examination of the vast choice of available MCUs and it is in that situation that the RP2040 shows its total lack of competitiveness.

Rather early in the life-cycle to assess "competitiveness" I think.

It may well be that RPi Foundation is not interested in profit; which is to say that for a non-profit, maybe break-even is good enough and that future rPis may incorporate the RP2040 directly on the board. Were the RP2040 provided on the board integrated in a standard way, I would think that RPiF already has a winner since Adafruit, SparkFun, and Arduino Corporate are already implementing hardware with a vast quantity of libraries provided to the end-user at no-cost and open source. Major coup IMO.

[AndrewBCN]

...maybe break-even is good enough and that future rPis may incorporate the RP2040 directly on the board.
...

I am sorry to say but I believe that would be just absurd.
Why make the RPi more complicated and more expensive, just to add a redundant "feature" that nobody asked for and that 99.99% of the RPi community is never going to use?
Btw, the expansion connector is there for this exact reason: so that makers and companies can create a "hat" with whatever MCU they want. And the fact that separate "hats" with an onboard MCU are rather rare (a quick search found exactly 2, and they are not exactly selling in the thousands) shows there is negligible demand for that, for the simple reason that the GPIOs onboard the RPi make an extra MCU redundant for most applications.

Of course nobody can predict the future, but beyond the hype, there are real reasons why the RP2040 is going to have a negligible impact in the maker/hobby market, and zero impact in the much, much larger industrial embedded MCU market.

[mlundin]

I think it is a bit presumptions to talk about what others think about the board. You dont like it, dont use it.

I did some testing setting it up as a simple synth with I2S output, worked great and less hassle than using I2S on most STM32 boards I have tried. Setting up the tools for C++ development was easy, there is some learning curve for VS Code, but the documentation was very clear.

As for usefulness, its a quite potent M0 plus board , of course not great for floating point, there is support for communication and locking between the cores, even if the current dev core doesnt include any RTOS, but neither does Arudion, Teensy or STDuino. The PIO can be used for very precisely clocked pin IO in situations that would be real tricky on other boards.

So speaking only for myself I find the board quite nice and will use it more, would even like to see a future variant based on the M4F or M7 cores

[ag123]

for what's worth Rpi can easily release a core A board with rp2040 as a 'satelite' chip on board.
STM32 literally have that on chip instead
https://www.st.com/en/microcontrollers- ... eries.html
beaglebone black have that design well early from the beginning and they called their lesser mcus a 'PRU' on chip.
https://beagleboard.org/black

but for now i'd think they'd remain separate products till the demand is there.
mcus meet the needs of a different 'segment', which is the io intensive set of 'things'.

taking some comparisons from the desktop pc boards and cpu designs. board buses are commonly divided between the 'north bridge' high speed GB/s buses that feeds memory, the drives / ssds and video.

then there is 'south bridge' these possibly needs say up to MB/s of throughput (say USB) and other peripherals maybe keyboard, system / cpu fan control and various. a theme of which is that it may involve handling large amount of connecting 'wires' with very little data (e.g. a keyboard).
i'd guess mcus fit here for now and that more commonly, mcus are also used independently for small electronics gadgets
these also may have more fussy hard timeslot intensive requirements, e.g. if one is scanning a led matrix display, pauses in that scanning would be irritating and may break the illusion of a picture. (after all only one single led is on at a time) or perhaps pauses may lead to skipped steps on steppers etc.

[AndrewBCN]

I think it is a bit presumptions to talk about what others think about the board.
...

My comment was not about the Pico board, but about the RP2040 chip.
"Raspberry Pi Pico is a tiny, fast, and versatile board built using RP2040, a brand new microcontroller chip designed by Raspberry Pi in the UK."

Obviously people are free to think whatever they want about the Pico board, but as I wrote in a previous comment, when you are an engineer deciding on the MCU chip to use in a project, you have to deal with various constraints and have to justify your choices with rational arguments.

And I didn't conjecture about what people think or have in their head, I was just stating a fact: you can browse through various years of Raspberry Pi forum posts and you won't find a single thread with: "We need a Raspberry Pi Single Board Computer with an extra MCU chip onboard, besides the main SOC chip."

So here is a fact, not a conjecture or an opinion: there was exactly zero demand for a Raspberry Pi SBC with an extra MCU onboard, until now.

[AndrewBCN]

'multi-core' is the other thing that's getting into pico. my guess is soon more socs will start to have the same features.

I think you meant "MCUs" and not "SOCs" in that statement, since multi-core SOCs are rather commonplace nowadays.

Multi-core MCUs have been available for many years, and the ESP family is a good example of multi-core put to good use. However, the multi-core "feature" is rather useless if you don't have a RTOS managing the multiple cores - and again the ESP family is a good example of that.

The RP2040 MCU unfortunately arrived without an RTOS, so if your project requires you to use the two cores, you are basically going to have to reinvent the wheel or use a third-party RTOS with SMP support. As a maker, personally, my life is too short for that kind of thing, but that's just me. As an engineer I would find it hard to justify the increased development costs vs another MCU with a pre-installed RTOS (e.g. an ESP32).

[ag123]

@AndrewBCN
agreed that multi-core creates 'unnecessary complexities' and it is more than just an 'RTOS' problem.
there would be questions like if an interrupt fires, which core would it run on?
'conventionally' for a single core the cpu is either in thread mode (normal run) or in an interrupt (isr) mode.
but in this case when one of the core is in interrupt mode, the other core could still be running a thread.
this creates a lot of 'unexpected' situations, e.g. if a circular buffer is used, both the interrupt thread and main thread could update the index registers.
this would at least cause data loss or in a worse case place things in an inconsistent state. there would be more of such cases.
unfortunately, the way that things are evolving means that there'd be more of such 'dual core' mcus hitting the markets.

the notion is that each core can possibly handle mutually exclusive - different IO, and hence allow more overlapping IO or processing to occur.
e.g. one core could handle the radio say bluetooth or wifi this is already happening - STM32WB !
https://www.st.com/en/microcontrollers- ... eries.html
while the other can process sensor inputs (e.g. count steps on accelerometer, monitor heart beats on the IR spo2 sensor), handle lcds, maintain time and general os functions etc this use case is most common for a *smart watch* or *fitness tracker*

what is often neglected is the extra complexity that these simultaneous io creates, one of those scenarios is as like mentioned in the 1st paragraph.
so things like pico probably neglect some of that and developers end up having to handle the various 'hard to do' synchronizations / mutex locking etc
deadlocks are very likely on mcus as io is involved. a simple locking situation where thread 1 locks port A followed by port B while thread 2 locks port B followed by port A results in a deadlock. and these can be very difficult to debug

but nevertheless as pico and stm32wb and more has shown, this trend of multi-core is going to happen despite all the complexities and non-best practices. that's simply because multi-core gives the sales and product team more things to hype about. a trouble is multi-core is not the same as having 2 separate mcus with each having its own independent memory and io. IO and memory is shared and that is where is the problem.