Thoughts on the RP2040?

[ataradov]

can you explain further? i mean if i have a usb connection in my product where the user connects it to pc then use a software i give him, how it is done?

It depends on the product. But generally yes, you either need a PC utility to perform the update. If you product has SD Card, you can ask users to place a specially names file on the card and insert it into the product. There are many ways.

i never seen a tutorial for writing a bootloader or how to encrypt firmware though, just know that arduino stuff has one.

Usually you just have another tool that lets you take the raw binary and encrypt it. Tools like this are custom for the project. And that's another reason you want to get away from Arduino anyway. In a real works you will have to use other tools. I guess if all you know is Arduino, you can make an encrypting tool using it, but this is not very efficient.

since people talked about stm32, is it the most used option for products?

It depends on how you count. If you count by units shipped, then some unknown Chinese 4-bit MCU that you never heard of will take the lead because it is used in a ton of toys and other stuff like this. Even 3 cent Padauk MCUs may be "too fancy" for such uses.

But as far as more advanced designs, it sure feels like STM32 are most popular. There is a reason why everyone is cloning their peripherals.

[ataradov]

What about the cheap STM32F103 boards?

With those boards you need to be very careful with fakes. There are a lot of them. Some don't even bother relabeling the device, just ship the cloned one. And single ICs are not readily available and where available they cost a lot more than this board shipped.

LOL. Look at the very first review for the link you provided - "not original stm". And seller's response "Dear, I am very happy that you have received the order. Thanks for your support. I hope that you are satisfied with the items and look forward to doing more business with you in future.Thanks!" Double LOL.

Direct performance comparison is hard. 2xCortex-M0+ at 120 MHz may beat Cortex-M3 at 72 MHz. But I doubt anyone buys those devices for their computational power, so it all boils down to peripherals.

And if you are doing it just for fun, then RP2040 wins, it is much more fun to work with. STM32F103 is pretty mundane MCU, there is nothing bad or good about.

[tomgat]

There is no ST device comparable in performance/price. And especially now when availability is spotty and demand is high. If you are just starting I'd be looking at STM32G0 or G4 series. But again, there is no real way to get those devices now.

Most STM32 chips for the most part are not available, and many have lead times in late 2023 to mid-2024.  The only vendor with worse lead times in this regard is Microchip which has the most bizarre lead times I have ever seen on almost everything.   If you listen to ST sales people, they will tell you to keep designing and that they will "get you whatever chips you need when you are ready for production", but this has not been the case for me unfortunately.  I dont plan to make that mistake again, and instead will have guaranteed supply before I design.

Also, on a side note, aside from the fact that they have immediate supply (ie.  Their direct website shows they have 500 and 3400 reels in stock), I do think the Raspberry Pi Foundation's mission is admirable, and would like to support them if it makes business sense.  I haven't seen anyone bring up any compelling reasons not to use the chip, and actually the more people that post the more it makes me start thinking this chip might have a very bright commercial future ahead of it.

Finally, the most appealing thing about the RP2040 is their documentation.  I dont even need a cup of coffee to read their hardware guide.  Its written for idiots like me.   

[SiliconWizard]

Just don't put too much hope on the ADC. If you don't have to use it, the better. For the rest, have fun. It's a fun chip. It's also very overclockable and has been proven to work at up to 400 MHz (with the right settings for Flash), but with the default settings, 250 MHz is no problem. For the lack of timers, PIO can be used of course, but also PWM.

Would be great if they announced the successor of the RP2040 - with more options, for more packages, more GPIOs, more PIO state machines, a bit more RAM, and with true low power modes down to the µA range. Maybe Cortex-M4 based too, or something like that. And a much better ADC. If they manage to release that for twice the price of the RP2040, they will have me sold!

[chickenHeadKnob]

Surprised no one has mentioned  this in this thread yet:
   It doesn't appear to have a timer/capture function for its timer. In fact the timer resource is very weak. This would be a show stopper for me.
   Credit to Atadorov for pointing it out in an earlier thread on the pico.
   Also there is some bug in the ADC, missing codes or some such. There is a work-around I think.
See mark omo DNL excursions:https://pico-adc.markomo.me/INL-DNL/#why-does-the-dnl-spike

I would like to know more about the work-around for the ADC issue. I don't see how a work-around is possible, other than discarding the lower bits and oversampling to make up for it.

Depending on what you need the timer/capture for, it might be possible to implement it with PIO.

There are two classes of problem with the ADC. The first class results in random errors, there oversampling and averaging helps. Since the RP2040 doesn't have an internal VREF for the ADC, you either need to supply an external one or at least make sure the power is well regulated. The  low noise mode actually generates more noise in the ADC  than the power save mode (see Mark Omo)

The second class of problem is the non-linear systemic errors due to bad implementation. The good news is that consistent non-linearity can be corrected with table look-up post processing.  DNL spikes at four values (512,1536,2560,3584). INL follows a predictable sawtooth. See RP2040 datasheet section 4.9.4 pages 563-564.
To address this you could brute force the correct code with a 4k by 16bit direct replacement table, improving both DNL and INL. But we can do better at little cost. You could pack the table and only store 12 bits per entry. But we can do even better. For the DNL you can simply exclude the problematic code points from your averaging.

For INL you can get by with only storing signed bytes (seven bits offset plus sign) so a 4K by 8  table. You can compress this more by incorporating the regularities of the sawtooth  but I wouldn't bother. The RP2040 has a decent amount of memory and you will be loading from an external ROM so...

You can also dick around by adding an external R2R DAC and adding selective DC offsets to each measurement and then subtracting the offsets after performing the table look-up post processing. That spreads the measurements around and helps to average out the DNL effects. I would consider that a heroic effort though, just to rehabilitate a shitty ADC on a one dollar part. The ADC is not hopeless, just shitty.

[hubi]

Surprised no one has mentioned  this in this thread yet:
   It doesn't appear to have a timer/capture function for its timer. In fact the timer resource is very weak. This would be a show stopper for me.
   Credit to Atadorov for pointing it out in an earlier thread on the pico.
   Also there is some bug in the ADC, missing codes or some such. There is a work-around I think.
See mark omo DNL excursions:https://pico-adc.markomo.me/INL-DNL/#why-does-the-dnl-spike

I would like to know more about the work-around for the ADC issue. I don't see how a work-around is possible, other than discarding the lower bits and oversampling to make up for it.

Depending on what you need the timer/capture for, it might be possible to implement it with PIO.

There are two classes of problem with the ADC. The first class results in random errors, there oversampling and averaging helps. Since the RP2040 doesn't have an internal VREF for the ADC, you either need to supply an external one or at least make sure the power is well regulated. The  low noise mode actually generates more noise in the ADC  than the power save mode (see Mark Omo)

The second class of problem is the non-linear systemic errors due to bad implementation. The good news is that consistent non-linearity can be corrected with table look-up post processing.  DNL spikes at four values (512,1536,2560,3584). INL follows a predictable sawtooth. See RP2040 datasheet section 4.9.4 pages 563-564.
To address this you could brute force the correct code with a 4k by 16bit direct replacement table, improving both DNL and INL. But we can do better at little cost. You could pack the table and only store 12 bits per entry. But we can do even better. For the DNL you can simply exclude the problematic code points from your averaging.

For INL you can get by with only storing signed bytes (seven bits offset plus sign) so a 4K by 8  table. You can compress this more by incorporating the regularities of the sawtooth  but I wouldn't bother. The RP2040 has a decent amount of memory and you will be loading from an external ROM so...

You can also dick around by adding an external R2R DAC and adding selective DC offsets to each measurement and then subtracting the offsets after performing the table look-up post processing. That spreads the measurements around and helps to average out the DNL effects. I would consider that a heroic effort though, just to rehabilitate a shitty ADC on a one dollar part. The ADC is not hopeless, just shitty.

Thank you for the explanation. I have to think about the lookup table for a while, I'm struggling to understand how the discontinuities in the saw tooth would transform a noisy input signal.

[tomgat]

You can also dick around by adding an external R2R DAC and adding selective DC offsets to each measurement and then subtracting the offsets after performing the table look-up post processing. That spreads the measurements around and helps to average out the DNL effects. I would consider that a heroic effort though, just to rehabilitate a shitty ADC on a one dollar part. The ADC is not hopeless, just shitty.

To your point, no $0.70 part is perfect.  Also, if a person needs precision there are plenty of cost effective 16bit to 24bit sigma delta ADCs out there.