µC prototyping platform -- with single-chip availability? - Page 1
Forum section: electronics / general

author: ebastler
author_rank: Super Contributor
timestamp: April 07, 2022, 06:25:40 am
content: Over the past years I have used several small DIP-sized microcontroller boards for prototyping: Based on the ATmega32U4 (DIP-24 "Pro Micro" from Sparkfun or no-name clones), and various STM32 family members ('F030, 'F103, 'F3xx, 'F4xx, in various DIP-40 "Blue Pill" or "Black Pill" flavors). I have used the Arduino IDE for quick-and-dirty projects, and the Atmel or STM IDEs when I needed more control or lower overhead.With the current chip supply bottlenecks, most of these boards are still available, although often a bit more expensive. But it seems that none of the chips are available individually, for projects where I want to move from cobbled-together prototype to an integrated PCB. So I am looking for alternatives which still support this path.Any recommendations for a small microcontroller prototyping platform, with the µC itself being available off the shelf too? I take general GPIO, SPI, and analog inputs for granted; USB support would be very nice indeed. DIP format PCB is preferred, with pins or castellations. Support for the Arduino IDE would be a plus; I do like those quick & dirty tests...One option that looks interesting is the RP2040. Both, the Raspberry Pi Pico board and the chip itself, seem to be widely available and very low cost. Raspberry's own software environment (focused on microPython) seems a bit different from the rest, but 3rd party support for the Arduino IDE is available ("Arduino-Pico" project on github). If you have used the RP2040 I would appreciate your take on it.Thanks for your suggestions!

author: newbrain
author_rank: Super Contributor
timestamp: April 07, 2022, 11:07:21 am
content: I have used the RP2040 (in its Pico incarnation) for some of my personal projects. I have also bought some bare chips and intend to try my hand at having a PCB done.The considerations below are based on the C 'experience' - I never used µPython for the RP2040 or, god forbid, Arduino stuff.I tend not to scout libraries or drivers around the net and mostly write my own - I might use the SDK provided with an MCU, if I find it useful.The good:The chip is fast, and faster than declared (no issues in clocking the cores well over 200 MHz)The dual core handling is the simplest of all multi cores I have tried (e.g. NXP LPC43xx), thanks to the HW (FIFO and semaphores) and SDK support.The SDK is very simple to use, not horribly written, quite good at basic functionality, but see also below.Setting up a working library plus toolchain environment with VS Code is really simple.The peripheral set is enough for most tasks, with PIO adding a degree of flexibility.SPI up to 60 MHz.Some interesting peripherals: PIO, interpolator, HW divideLearning to program the PIO is fun.I love the pinout of the Pico, with a GND every 4th GPIO and the straight sequential numbering (if you ever used a Nucleo or Disco board, you might know the pain)The bad:The SDK is a bit limited: to implement a DMA or IRQ version of peripheral driver you are mostly on your own: they provide some building blocks, but not all that is needed. For me, that's more fun, but others might prefer a more complete library. See, e.g., my repoherefor reading/writing I2C memories and register based peripherals (no guarantees, written to help a friend with their Pico project).Timers. Who needs timers. Timers are overrated. Though admittedly this is mitigated by the PWMs and the independent DMA timers.A lot of things are done in a different way with respect to many of the MCU I know (NXP, ST, ex Atmel), e.g. the way GPIO registers are organized. Not a big deal, but it takes some getting used to.Building the utilities in toolchain requires Microsoft's compilers on Windows. This has licensing implication*, out of a hobbyist use. They could have gone with cygwin or msys2 (which is required to compile the specially modified OpenOCD)Not putting a reset button on the Pico was just silly.Learning to program the PIO is 'fun'. (but you are not forced to use it, after all)The ugly:The moronic DP/AP arrangement for the two cores that makes debugging less efficient (e.g. to monitor breakpoints in both cores) and needs special versions of OpenOCD (or a specific built-in support for pyocd) and only works with some probes.The datasheet is crap - very little in terms of electrical characteristics, many confusing or incomplete descriptions, parts taken straight from the IP vendor docs with no real connection to the naming used elsewhere - it's a decent draft for a DS, to be very kind.*Licensing of the Microsoft command line compilers is bound to having a valid Visual Studio license. For hobbyists, the Community edition is OK to use, but in a commercial environment VS Community is subject to many limitations.So to use your Pico, you might need a commercial Visual Studio license - open source be damned.

author: ebastler
author_rank: Super Contributor
timestamp: April 07, 2022, 11:55:57 am
content: Wow, thank you very much for the detailed reply!Sounds like the RP2040 is definitely worth exploring, but will also imply a bit of a learning curve. (Not unexpected, of course.) It also would be a bit of an upgrade from the microcontrollers I have used so far. But given the low price, one can probably tolerate the overkill even in applications where I previously got by with the old Atmel 32U4.Time to get a Pico to play with, I guess... But further recommendations, maybe for simpler chips, are still welcome!

author: newbrain
author_rank: Super Contributor
timestamp: April 07, 2022, 12:59:18 pm
content: Quote from: ebastler on April 07, 2022, 11:55:57 amWith respect to Atmel 8 bitters yes, it's absolutely an upgrade and a little learning curve.OTOH, you already used some other Arm based MCUs: setting up the environment and experimenting is absolutely easier, IME, than fighting Eclipse 🤮.Using the project generator athttps://github.com/raspberrypi/pico-project-generatorwill get you started quickly.Adding your code and libraries to the project is also easy, the Cmake based build system is a bit complex, but works quite right and allows you to move your project from Windows to Lunux to Mac with minimal fuss (I often develop from a variety of machines).While I find the DS abysmal, theSDK guideandgetting started guideare quite decently written.Are RP2040 and Pico the best thing since sliced bread? Probably not, but they are cheap, available, powerful enough, and reasonably easy to use.E.g. my first project, that took me very little time to develop, is a LW modulator that behaves like an USB audio card and I use to to test SDR software.It takes 48 kS/s audio (L+R = I+Q) and upsample them to 1.536 MS/s using the internal interpolator, then quadrature modulate a 96 kHz carrier.The PIO is used as a fast GPIO to transfer the data to a R2R DAC. One core is used for USB and a small I2C OLED display handling (DMA), the other for upsampling, modulation and feeding data to the PIO.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 07, 2022, 06:17:33 pm
content: I agree with most of newbrain's post, except the following (some of which is more opinion than a real issue):Quote from: newbrain on April 07, 2022, 11:07:21 amYeah, I absolutely don't mind. Actually, I much prefer it. The all-in-one approach such as with STM32's HAL looks cute until you find out that it's very inefficient, reconfiguring the DMA for every fricking transfer, etc.Quote from: newbrain on April 07, 2022, 11:07:21 amThis absolutely looked like a major downside at first sight, but you can get timer functionality with PWM indeed, and not just that. With the PIO as well, which is very flexible.The thing I think could have been improved is allowing the single general timer to have more than one clock source... But I guess it's mainly there to be used as a general timing reference, so running off the system clock only is ok-ish.Quote from: newbrain on April 07, 2022, 11:07:21 amYeah, I personally don't much care, but YMMV. The learning curve when going with a different vendor is always there anyway.Quote from: newbrain on April 07, 2022, 11:07:21 amI never used OpenOCD with it so far, so I didn't bother building it, but all the rest can be built without MS compilers. That's what I did. It requires writing your own makefiles though, but the tools are simple enough that it's not a big deal. You're on your own though, so that's certainly not beginner-friendly in that respect (or even anyone moderately skilled) if you want to do anything differently than what is provided with the SDK. Likewise, I used the SDK without CMake (which I personally don't use, so it's not part of my usual tools), but it takes some work to iron this out.Quote from: newbrain on April 07, 2022, 11:07:21 amThat I agree with, especially if you program it using the USB bootloader (didn't try using SWD for this so far.)Fortunately, the pins "RUN" (which is equivalent to a reset) and GND are 5.08mm apart, so even if you don't put the Pico board on a breadboard, you can just insert a through-hole pushbutton in those two holes and that does the trick.Quote from: newbrain on April 07, 2022, 11:07:21 amThat part looks pretty suboptimal indeed. I personally very rarely use a debugger on small MCUs, so I don't care, but for people who do, that would be a significant downside.Quote from: newbrain on April 07, 2022, 11:07:21 amWhile the functional description is rather good (and was praised by many), everything low-level hardware related is not great indeed.Speaking of hardware, while this chip is pretty amazing for its price and functionalities, it has no reasonable "low-power" mode to speak of, compared to almost every MCU on the market with a M0+ core. Although the documentation about it it's again scarce, don't expect to be able to get below the mA mark in low-power mode, while many "similar" MCUs on the market can achieve the uA mark or below. Not a big deal for many applications, but certainly is for anything battery-operated.

author: newbrain
author_rank: Super Contributor
timestamp: April 07, 2022, 09:18:47 pm
content: QuoteAh, CMakeisthe best thing after sliced bread, especially when coupled with ninja. It's a tool worth learning, IMO of course!A weekend I was especially fed up with MCUxpresso, I moved my SDR project (about 200 kLOC acros ~100 source files) to CMake + ninja + clang and removed any possible dependency from that opprobrium.Now it compiles in less than 2 seconds, vs more than 10 with makefiles and gcc. Most of the improvement is due to CMake + ninja (clang is often slightly slower than gcc).CMake is extremely versatile and quite easy to use especially if compared with autotools.If the build system is done correctly, it's also very portable across platforms - the RP2040 SDK one is, as is mine, there are exactly zero OS dependent parts in my CMakeLists.txt files, the only thing needed is that the compiler be in the PATH.I've also heard good things about meson, which I use 'passively' as it's the native build system forpicolibc(nothing to do with the Pico board!).For the rest, I think we are mostly agreeing, many of the 'bad' things should really be filed in the "mildly annoying" category - but I don't think Sergio Leone ever went round to direct "The good, the mildly annoying and the ugly".I still feel that introducing a dependency on an MS compiler is just a pointlessly out of tune note, note that I'm anything but an MS hater.

author: thm_w
author_rank: Super Contributor
timestamp: April 07, 2022, 10:09:10 pm
content: Quote from: ebastler on April 07, 2022, 06:25:40 amPut female headers and use the full board in your project.Can do the same with the RP 2040 pico.

author: PlainName
author_rank: Super Contributor
timestamp: April 07, 2022, 11:12:02 pm
content: QuoteExcept when it isn't. The thing that stumps me (and, it seems, much of the web) is getting it to compile something when something else has changed. A typical one might be to run some util to work out the version of a project, and have that update (or not) the temporary version.inc which is used to derive the permanent version.h. Given up on that.Current one that often fails is where I have a bunch of HTML files which need to go in a blob. Obviously, I don't want to recreate that blob every compile, so I just want it happening whenever there is a change in the folder (unknown number and names of files since they may be generated by some website generator). What I wound up with is:Code:# Make HTML files into embedded binary source to place in RO memory.file (GLOB_RECURSE bin_files RELATIVE ${CMAKE_SOURCE_DIR}/main/wifi/html ${CMAKE_SOURCE_DIR}/main/wifi/html/*)add_custom_command(OUTPUT ../main/wifi/html_files.hWORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/main/wifi/htmlCOMMAND bin2c.exe -t -d html_files.h -o html_files.c ${bin_files}COMMAND move html_files.* ..DEPENDS ${CMAKE_SOURCE_DIR}/main/wifi/configurator.c)add_custom_target(embed_html DEPENDS ${CMAKE_SOURCE_DIR}/main/wifi/html_files.h)add_dependencies(${PROJECT_NAME}.elf embed_html)But to get it to work I have to delete html_files.h. And if html_files.c doesn't exist (first run of a reset project) it stops the compile and won't work until I create a dummy version.With makefiles it would be (and was) trivial.

author: westfw
author_rank: Super Contributor
timestamp: April 08, 2022, 02:44:17 am
content: QuoteI lot of people seem to be pretty annoyed with the mixture of SDK and Basic hardware definitions, and their directory organization. It's "fine" if you like CMake and/or VSCode and use it "as the developers intended", but it seems to be significantly more painful to use if you want to change the environment at all.For example, people who tried to build the microPython distribution on windows discovered that the command lines produced by the build exceeded Windows Maximum Command Line Length (8k), thanks to 3k+ worth of "-I path" options. (https://github.com/micropython/micropython/issues/7012)Likewise, ignoring CMSIS (even CMSIS-Core) (although I believe that's been sort-of fixed)I really like this Pico Development board:https://www.cytron.io/p-maker-pi-picoIt has some of the things that RPi left out (the RESET button!) and a bunch of other stuff useful in the development stages.(Alas, it seems to use enough additional components that it's also out of stock, most places. :-( )

author: ebastler
author_rank: Super Contributor
timestamp: April 08, 2022, 05:29:07 am
content: Quote from: thm_w on April 07, 2022, 10:09:10 pmSure, I have done that -- as a shortcut in earlier years, and out of necessity now that the ICs are unavailable. But it can be limiting: Adds height and takes more real estate on the board, USB jack ends up in an inconvenient place, often not all pins are brought out. So it would be good to have a prototyping platform which gives me the option to place the microcontroller directly on-board.

author: fchk
author_rank: Frequent Contributor
timestamp: April 12, 2022, 01:20:48 pm
content: For some small one-off projects I often use PIC24/dsPIC33 and the smaller PIC32. They are available, there are also DIP versions, and everything is quite simple.Devboards are unnecessary, the minimum external connections are low (some capacitors, pullup on MCLR).fchk