A BluePill For Arduino Dependence

Arduinos are helpful but some applications require more than what Arduinos can provide. However, it’s not always easy to make the switch from a developed ecosystem into the abyss that is hardware engineering. [Vadim] noticed this, which prompted him to write a guide to shepherd people on their quest for an Arduino-free environment, one BluePill at a time.

With an extended metaphor comparing Arduino use and physical addiction, [Vadim’s] writing is a joy to read. He chose to focus on the BluePill (aka the next Arduino Killer™) which is a $1.75 ARM board with the form factor of an Arduino Nano. After describing where to get the board and it’s an accompanying programmer, [Vadim] introduces PlatformIO, an alternative to the Arduino IDE. But wait! Before the Arduino die-hards leave, take note that PlatformIO can use all of the “Arduino Language,” so your digitalWrites and analogReads are safe (for now). Like any getting started guide, [Vadim] includes the obligatory blinking an LED program. And, in the end, [Vadim] sets his readers up to be comfortable in the middle ground between Arduino Land and the Wild West.

The debate for/against Arduino has been simmering for quite some time, but most agree that Arduino is a good place to start: it’s simpler and easier than jumping head first. However, at some point, many want to remove their “crippling Arduino dependency” (in the words of [Vadim]) and move on to bigger and better things. If you’re at this point, or still cling to your Uno, swing on over and give Vadim’s post a read. If you’re already in the trenches, head on over and read our posts about the BluePill and PlatformIO which are great complements for [Vadim’s].

48 thoughts on “A BluePill For Arduino Dependence

  1. “crippling Arduino dependency” what rot, I use FPGA’s and all sorts of varied devices, I always have some avr’s with a bootloader blown on them, just purely for ease and convenience, just the other day I needed a programmer of an obsolete eeprom, no problem just wired a spare arduino and programmed the eeprom with a quick sketch.
    alternatively I could have hand coded a load of low level hardware dependent routines before coding the programmer, what you already have those? guess what – you have your own version of arduino, but without the community….

    1. Agree! Even for “hard coders” or development using other platforms an arduino board is quite handy!
      It’s the hardware version of a scripting language which helps you to automate stuff while developing your main project.

    2. i agree with the sentiment of not reinventing the wheel.

      however, a lot of the basic i/o libraries for arduino are considered harmful.

      also, the arduino community is considered harmful.

      don’t mind me, i just hate everything that’s bad. :P

    1. Arduino is a well-structured ecosystem. A very friendly and well-supported IDE and programming infrastructure, a great set of libraries, a strong community, a family of easy to use boards and many available plug-in boards (despite the unfortunate pin positions).

    1. The AVR 8-bit chips are very simple and pleasant to program, but they’re limited to 20 MHz and the lack of DMA makes you have to use the CPU for some tasks that you could otherwise offload to hardware. Reasons you might want a faster chip (or a 32-bit one) include things like real-time audio processing, very fast ADC applications, serious number crunching, or just more memory. That said, they’re plenty for the vast majority of projects you see on Hackaday.

      The boards in question, though, are ridiculously cheap, partly b/c the processor onboard is a bit old in the tooth, but it’s still a lot faster than the (yet older) AVR designs. So for the same price as an Arduino clone, you can get something with more memory, more processing power, more bit-depth, more this and more that. The only catch is learning to use some (slightly) different hardware.

      1. It seems to me the ARM arena needs a book, written in a clear and easily understood style with illustrative examples and a dash of humour. It could show what is exactly going on at the hardware level and give new folks a real sense of achievement and satisfaction that comes with understanding and using that. You’re working on that right, Elliot?

      1. You do know that ST Link clones from China are no more than a STM32F103, the very same one as on this blue pill ?
        Funny thing is, I own several legit ST boards. Guess what ? They all have a F103 onboard to serve as an embedded ST Link probe !

        1. yeah i got turned onto the stm32 from one of the “value line discovery” boards, and when i bought a heap of the “bluepills” after using up my discovery boards, i bought another discovery to serve as programmer so i’d start with a known quantity. love stm32! so cheap, so not-8-bit.

  2. PlatformIO is cool, but requires Eclipse (gross) or Atom (buggy in my personal experience.) There is a command-line option, but it’s really no better than using a standard peripheral library, CMSIS, and GCC. ‘Arduino’ is basically just C anyways.

    The ARM Cortex-M lines are super cool – it’s a shame there isn’t more documentation, but I’m sure that’ll change soon. Platforms like mbed are trying to make development easier, but they are also trying to do that without giving up control of the toolchain in an online IDE – personally, I feel like that is right fucked.

    1. While PlatformIO itself is a console application, it can be used in combination with one’s favorite Cloud & Standalone IDE or text editor such as PlatformIO IDE for Atom, CLion, Eclipse, Emacs, NetBeans, Qt Creator, Sublime Text, VIM, Visual Studio, PlatformIO IDE for VScode, etc.

      The Cool thing about PlatformIO is that in it’s core it is just a few Python cripts.
      I first installed pip, an then installed platfromio with pip.

      A very cool thing of platformio is that you jest tell it the name of a chip or board and then when it needs to compile some C source and it can’t find a compiler, it just pulls it from the web and instantly (almost, takes about 20s) installs it.

      The interopability of building code for different platforms also is very much more than
      “not better than using a standard peripheral lib, CMSIS / GCC”.

  3. Arduino is for mechanical tasks and yet those who are software forward seem constantly to soap box alternative platforms as if they are advancing their culture. Let us make this perfectly clear to those who needlessly despise Arduino, we do not care about high processing video POV displays or transmitting wireless data from your worn out desk chair to your phone so you can operate a video game from your butt cheeks. We want merely to reliably pick up, push, turn on and off so as to seek real world solutions. Burn. #Arduino4Life

    1. “Arduinos are helpful but some applications require more than what Arduinos can provide”

      You didn’t read this at all, did you? You just saw something against your board of choice, and decided to blithely comment without really considering what you were saying.


      1. You did not read my commentary at all, did you? You’d just rather emote to some one who is expressing their opinion that you have no obligation to reply to – unless of course offering evidence to counter the commentary. Which you did not, bcz, I read it quite clearly and your quote from the article is elaborated on by my commentary — and I have read the numerous other articles for years that reference desires beyond what inherently Arduino is capable of. I am tired of the redundancy of misaligned angst toward Arduino by people who venture out side of the boundaries of the core engineering and then dismiss Arduino as being primitive. Would you this time prefer clif notes so as to more easily delineate my observation you obviously needlessly must reply to? Burn.

      1. Having experimented with other MCUs for primary tasks, Arduino has most certainly been the most reliable in my book and it is hard to argue that this is not best demonstrated by it’s global success. Is it perfect? Nothing is. The user is most accountable to that regard. For the most part, per my opinion and experience, I would reckon it as far more reliable than most. They do after all manufacture industrial versions of their product which is a very bold statement on reliability. Now for the humor part — I can row a boat, canoe?

    2. Funny thing you mention those legitimately highly demanding applications. However, you don’t need to go that far to feel limited by arduino. It is hard to do timing critical stuff with arduino (at least, with the libraries).

      Some friends of mine had a school project where they had to trigger from 4 piezo sensors, measure the time difference between them, and hand it to a PC for further processing. This was to locate an impact on a wooden board no larger than a shoe box, with the piezo at the four sides. When basic IO functions like digital{Read,Write} take more than 50 cycles to run on a 16 MHz CPU, running like crazy reading inputs, you can’t do very much. Oh and interrupts did not cut it, as their Uno only has 2. I ended up giving them an ARM board (MSP432) with 4 pin interrupts and a time-counting timer. I wrote them bare metal stuff (interrupts, timer, UART mainly) to give them a framework as easy as arduino, but that did fit their needs. After that, the math was a breeze and the project worked :]

      1. I want to add that Arduino was still beneficial for them. They had never programmed anything in their life, let alone a microcontroller. The arduino did an excellent job at teaching them the basics of microcontrollers, bits of logic, …
        However, where the arduino totally fails is at showing its limits to non-experienced people.

        1. Yeah. Non-experienced people. The target audience for the Arduino ecosystem and not the target for ARM. Just exactly how does one ‘show its limits’ to non-experienced people when they have no basis for comparison? It seems odd to say the ARM is an alternative for them when you did all the work.

          I see the Leonardo has 5 and the Mega2560 has 6 hardware interrupt pins. Those would be alternates within the Arduino ecosystem.

          In any case you can have a race condition on your example – two ultrasonic pulses come back in the same interval that it takes to process the data, making one sensor disappear. Even if the interrupts get queued, the delay means that it will appear there is a difference in distance when the actual timing is identical. Maybe they didn’t notice; probably it didn’t matter. But how did that become shown as a limit to the non-experienced people?

          1. > Yeah. Non-experienced people. The target audience for the Arduino ecosystem and not the target for ARM.

            Not exactly, since ARM can be as user friendly to newbies as Arduino is. Arduino is just a shitload of code to make an easy to use HAL. Take a Blue Pill (STM32F103, 72MHz ARM CPU). Burn the stm32duino bootloader (the only hard point though), and you got a powerful board for a small price. And it’s ARM !

            > Just exactly how does one ‘show its limits’ to non-experienced people when they have no basis for comparison?

            I don’t see anywhere an arduino page explaining some more in-depth stuff. People hardly talk about interrupts, and even less about the limitations of the venerable digitalRead.
            It hides everything from the end user, making him having no clue what was happening.
            Of course, this is a huge criticism, but I have no better solutions to show the limits other than to put huge warnings, with pages slowly getting down into stuff.

            > It seems odd to say the ARM is an alternative for them when you did all the work.
            > I see the Leonardo has 5 and the Mega2560 has 6 hardware interrupt pins. Those would be alternates within the Arduino ecosystem.

            School only had Unos, and I had an ARM board at home (while I was working on smaller stuff with MSP430s).
            As for the work, I only wrote a very crude HAL by copy/pasting Ti’s examples. Only wrote the skeletons for the five interrupts functions (timer + pins), aka no actual code in it telling them “that one gets called every x ns” and “those are called when a rising edge reaches pins x, y, z, w”. They did the rest. They even wrote (a crude) UART driver, while I only copy pasted peripheral config from ti’s code.

            They noticed themselves something was wrong, but they blamed their code and not the platform. As they were beginners, they did not dare blame the Arduino library, as it should just work. Even some basic info about the rough execution speed of common functions would have helped them a lot. But no, they were using tools assuming they were good.
            They did see the pulses on a good ol’ scope coming in, with the timings. I don’t have the numbers, but in pretty much every usable case (piezo things less than 1m away from each other), the delay between pulses was lower than the execution time of digitalRead(). When your approach is to loop 4 serial reads, it can’t work.
            An interrupt taking a few cycles instead of 50 made the project possible.

  4. arduino is a huge time saver. but it helps to know the underlying avr libraries as well. like i dont use arduino types i use avr types, and i usually access the hardware through the register defines when speed is required. you can do things like scan an entire port in one call rather than doing one for each pin im using. there are also features on the chip that are not implemented in the arduino api, like the analog comparator and the watchdog timer. i dont think i need to be independant from the arduino api, its there when i dont have a lot of time and i can just not use it when i need performance.

  5. Yeah, the problem is INSTALLING and/or REMOVING multiple toolchains in the same environment. Still to this day, installing a new toolchain is almost guaranteed to clobber all of your environment settings and default extension assignments. Experienced developers know how to tame this. The inexperienced get stuck with many problems that take a LOT of time and work to fix or undo (if they can really be completely undone at all). Well designed Windows installations (rare when it comes to embedded toolchains) have a simple uninstall option. In Linux, the contamination is FAR worse. Repositories, even with the latest Linux releases are always hopelessly out of date. This requires installing new source repositories, which often do NOT work, especially if you try an automated uninstall. And no, running multiple toolchains/IDEs in virtual machines is often NOT a viable option, especially for youngsters and almost everyone else on the planet in the developing world who do not have money to throw at meeting the minimum the system requirements to effectively run responsive VMs. And then there’s Ecliipse – talk about user hostile!

  6. Good grief moat because I have yet to have projects that required the most minimal of microprocessor power I only simply toyed with the arduino, just to be doing so. As I look in from the outside I think that the elitist like attitudes I see have me hesitant to enter the fray if I were to have gnarly problem I couldn’t sort out on my own. Even though I understand it’s probably like amateur radio. Where at the bottom there are ignorant asses who can’t even communicate their ignorance well, while at the top there are intelligent engineers with excellent communication skills who know the subject willing to take the time to give the lesser of us excellent instruction without judgment. While Vadim should be commended for creating an alternative, but the judgmental portions of the write up would be best left out, as they could turn away those targeted for conversion. There are no arduino addicts, and is there where, their dependency affects no one else.

    1. +1

      It’s very convenient to have a stockpile of well supported widely used simple low cost arduinos to throw at any task. I think of the arduino as I do a screwdriver… there are ALWAYS going to be a few in my toolbox. They save cutting myself on the bleeding edge of every new fancy-dangled new board and toolchain that wastes my time. KISS

  7. hardly getting rid of arduino is it?! its using the stm32duino core – which in my experience is a terrible port (nowhere near as good as the esp8266 port for example) all this is is getting rid of the ide, well that’s nothing new either.

  8. While I absolutely like the Cortex-M MCUs, especially the ones from STM, for real projects there’s absolutely nothing that tops putting an lowly DIP version of an AT(whatever) on a breadboard, connect a few wires, load an example in the Arduino IDE, modify a couple of lines and have a proof-of-concept implemented before your coffee is brewed. Heck, if you forget about the shitty Arduino IDE you can even do more professional-style stuff; though an 8bit MCU gets a bit long in the tooth fairly quickly… It’s like using a script-language like Python on your computer to do some quick stuff rather than launching a full-blown project…

  9. I am copying zoobab’s comment from Vadim’s blog:

    zoobab2 September 2017 at 21:31
    It is really bad those bluepills come with the wrong resistor on R10 which fucks up the USB, and with a bootloader that does not support USB. It seems the BlackPill version has the USB fixed, and can be reflashed with a boot loader that supports USB, meaning those external flashers are not needed anymore.


    So where can you get this blackpill which can alleviate much headache?

    1. Although R10 being 10k is incorrect, as it should be 1.5k, the board still works with most PC’s etc.

      Fixing the problem isn’t that hard either just solder a normal 1.8k resistor in parallel
      Solder the resistor between the though hole connections for PA12 and 3.3V

  10. That’s not the direction I’d tell anyone to go – the thing to get you off an ardunio (with it’s crippling memory constraints) is a 8266 – cheap, basic wifi, much faster, more memory, and just as easy to use as an ardunio as the library port is quite good..

  11. >hardly getting rid of arduino is it?! its using the stm32duino core
    Meanwhile there are 3 cores which means 3 different implementations:
    – stm32duino
    – stm32generic
    – stm itself
    They are not all the same.
    Find them on github.

    1. No necessarily. You can program the STM32F103C8T6 also via (built-in) serial bootloader, same as the usual AVR MCUs. However if you do opt for the cheap ST-Link debugger, you not only have a much more capable (and dedicated) programmer at hand you can also do proper debugging which also requires extra hardware with AVR MCUs but that costs a whole lot more and is a lot more trickier to use.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.