10 ms·

How to pick a microcontroller

227 points by adastra 10y ago

std_throwaway 10y ago
A quicker guide for real beginners: Do you want to understand in detail what's happening? => Arduino UNO Is the UNO too small/slow? => Arduino Due Still too small or you really just want a small computer running Linux but with GPIO-Pins? => Raspberry PI
- Palomides 10y ago
  I think this is more of a guide for somewhat experienced hardware people picking a microcontroller to go into production than a complete beginner to electronics. Agreed that anyone else should just grab an arduino.
- guitarbill 10y ago
  Paul Stoffregen's Teensy boards are the way to go. The hardware and the software are excellent. Heaps of power thanks to the ARM Cortex M4 and you still get the Arduino IDE. Can't recommend them enough, wish I had of moved to them far sooner. Everybody I've given one to has loved them, and the USB support is also very welcome. (As far as price goes, they're development boards and worth every cent for beginners.)
  - Marazan 10y ago
    Extreme agreement from me.
  - analog31 10y ago
    The Teensy boards are fabulous. I'm so impressed by what Paul Stoffgren has done. He must be some kind of 100x developer. And there are some power users of his boards, who have contributed libraries as well. It's worth noting that while you can ease your way into programming with the functions available within the Arduino IDE, there are libraries for many of the special functions of the chips, and all of the special function registers are exposed, so you can make full use of your hardware capabilities if desired. As for choosing a microcontroller, I'm generally tempted to start by choosing a development tool, because I'll be spending more of my time in code development and testing than in any other activity.
    - abdupattoh 10y ago
      Having worked on college labs with Paul 100x is about right. We just kinda looked in wonder at his projects... and he sold us the parts for ours... A real serving individual actually.
    - Berobero 10y ago
      We've had the pleasure of having Paul as a sponsor for our senior project, a sample-based midi synthesizer, running on, at least, the Teensy 3.2 and 3.6; we got free hardware for development, and he's been quite supportive, despite being obviously perpetually busy. And I can't say I ever felt at all hindered by the hardware or its libraries, and although we started the project with almost no embedded experience. Quite a fun way to end college.
      - brokenmachine 10y ago
        Do you have a site about your project? I'm interested in synths (and teensies) and would be interested to see it.
  - moosingin3space 10y ago
    Additionally, there is a (small) community around programming Teensy in Rust, which is awesome.
  - std_throwaway 10y ago
    I'll have to look into those. Being able to start with the Arduino IDE is a big plus for beginners.
  - gwu78 10y ago
    One of the things I like about this choice is one does not need an IDE, at least not with the 2.0. One can do non-graphical (systems) programming on an underpowered computer with no graphics. I statically compile the loader. On BSD at least, no 3rd party libs are needed. Then all I need is avr-gcc. I can do everything from the command line. No closed source tools. No requisite graphics layer (e.g., Windows OS). No large interpreters (Python, etc.). https://raw.githubusercontent.com/PaulStoffregen/teensy_loader_cli/master/teensy_loader_cli.c https://raw.githubusercontent.com/PaulStoffregen/teensy_load... Can anyone recommend other boards where everything can be done like this, i.e., without needing closed sorce tools, graphics layer, or installation of interpreters and scripting libraries? e.g.: http://home.hccnet.nl/anij/nof/noforth.html http://home.hccnet.nl/anij/nof/noforth.html
    - detaro 10y ago
      The AVR-based Arduinos (Really, I think most AVR-based boards, unless it has some really strange proprietary way of flashing). The MSP430-based TI Launchpads. The various ESP-something WLAN boards have open toolchains and programming over serial as well as far as I know.
      - david-given 10y ago
        I have about 2/3 of an 8080 emulator running CP/M for a MSP430 LaunchPad somewhere; because that MSP430 only has 2kB of RAM it has to swap to an external SRAM device. There's AT keyboard support (via an external level shifter). I got it to the point of booting (very slowly) up to the command line prompt and processing basic commands, but unfortunately I never figured out how to make the screen work, so that's where the project stalled. The hardware's since been broken up and repurposed. All in C and hand-written assembly tied together with a makefile, using tools that are in Debian. The standard flash tool (also in Debian) is really easy to use and even supports JTAG debugging over USB. (Also the MSP430 has a lovely assembly instruction set if you want to work with that sort of thing.) Can't comment about AVR or ESP; never used them.
    - TD-Linux 10y ago
      Any of the Cortex-M* series are also generally a good choice, for example the STM32* series. All of these are supported in mainline gcc, and have open source support libraries provided by the vendor or via libopencm3. Be a bit careful, as some vendors like to use proprietary licenses for their headers, but in most cases there is at least one open source alternative. And of course the RISC-V HiFive1, though it's still very new and in sampling quantities.
- juliendorra 10y ago
  Do you want easy wifi and Bluetooth ? ESP. (Arduino Yun are a nightmare in workshops / sprint context)
  - std_throwaway 10y ago
    Of course, do they come with a nice IDE and a big library/ecosystem of soft/hardware examples?
    - StavrosK 10y ago
      Yep.
  - bigiain 10y ago
    I'll recommend NextThing CHIPs here too (I started buying them because PiZeros are/were too difficult to get in quantities greater then one. Same with the PiZeroW right now, I've got a project where I'd like 12 of them, but it's not work jumping through the hoops (and paying 12 times the shipping costs to Australia) to bother right now.
  - deleted 10y ago
    [deleted]
- simonbarker87 10y ago
  I would say that if you are looking at getting started with embedded electronics from an electrical engineering/professional stand pint and looking to put things into production then don't start with Arduino and certainly don't view an RPi as a viable embedded solution. A PicKit 2 and a 16F series Microchip microcontroller would be a much better starting point just to get up and running without feeling overwhelmed.
  - jfroma 10y ago
    I loved that one. We spend an entire year on high school programming the 16F84 on assembler. We re-implemented all projects we did the previous year with nand gates like semaphore, infrared barriers for counting stuff etc with pics, and it was mindblowing for me. I also remember we did a board for writing the program in the pic because it was too expensive in my country.
  - std_throwaway 10y ago
    I come from the angle of "absolute beginner" who is trying to get started quickly. If you are really "looking to put things into production" you might be right. Using those boards I proposed will always have big disadvantages. The original article is not written for absolute beginners, but for people who would go through the pain of soldering 100 pins to a self-designed PCB and failing 5 times before getting a working version.
  - TD-Linux 10y ago
    I agree with not starting with the RPi (to avoid the complexities of the Linux kernel), but I started with the PIC and SX series (before Arduino was a thing) and wouldn't recommend it anymore. If you want to learn an assembly language and twiddle registers then maybe you'd like the PIC, but I don't think it's more "professional" - virtually everyone uses C if at all possible at this point, and the AVR (or bigger PICs) are just as "production-ready" as the old PIC16F series. And you can still twiddle AVR registers with C if you so desire.
    - simonbarker87 10y ago
      Assembly on PIC is horrible, I agree. I've only done one project in assembly on PIC and since then only used C with PIC which works fine across the whole range.
- blhack 10y ago
  I'll append with: Do you need wifi: Wemos D1 mini Do you need bluetooth low energy: light blue bean
  - antoniuschan99 10y ago
    Light blue bean is $30. ESP is production ready. But doesn't have bluetooth (esp32 is not ready for prime time yet). What are other considerations? Wemos D1 mini or NodeMCU :).
    - MrBuddyCasino 10y ago
      "esp32 is not ready for prime time yet" There are some rough edges, but its already very useable, especially since the new silicon came out. Got anything specific in mind?
      - kirrent 10y ago
        I just came back to my esp32 after a 6 week hiatus and the framework has evolved impressively in that amount of time. It's an awesome product for a steal of a price. Definitely at the usable stage.
        antoniuschan99 10y ago
        That's great to hear! If that's the case, then it's basically just supply chain issues that's left. It's still hard to get batches and it's probably still pretty expensive compared to the 8266?
        MrBuddyCasino 10y ago
        That is true, but the SDK is so much better that frankly I don't care, but then I'm not doing high volume products either so thats easy to say.
    - Eridrus 10y ago
      For BLE, but no Wifi, nRF51/52 chips seem like a good fit; bonus is that they're low power,
- bsamuels 10y ago
  your advice is excellent for makers and hackers, but if you're building a product, arduino/raspberry pi is far too expensive
  - std_throwaway 10y ago
    That depends on what the product may cost and how many you intend to sell. In general you might be right. But if you look in getting started and having a solution (suboptimal but working) quickly, then they are a good choice. Maybe not the best choice, but good.
  - jononor 10y ago
    Many/most Arduino boards are open source. So if you small and are trying to get a simple product line established you can start with designing a daughter/motherboard that the Arduino board plugs into for first series. Then, once you scale up, embed the Arduino parts into the same board. You can use a clone also, which can be much cheaper. But I wouldn't go recommend Atmega328 for new designs unless its extremely simple, so when I say "Arduino" I mean something similar, like a Teensy 3+ or Olimex STM32 or Adafruit Feather M0
  - justin66 10y ago
    The RPi (its SoC, really) is probably a fine choice financially for the applications where it doesn't represent ridiculous overengineering.
- jwr 10y ago
  I disagree. Everything you listed a) can't be used for products, b) doesn't let you make progress beyond "oh look, I lit up an LED!". Sure, if you never programmed a small device, by all means, start with an Arduino. But after you do light up that LED, please learn more. Go bare metal, learn about interrupts, state machines, entering sleep states -- without those things you'll stay forever in the toy world. In the real world, if you work with battery-powered devices, you never have the comfort of busy waiting for your UART/I2C transmission to finish, or calling analogRead() and getting immediate results (because ADC takes time and you want to do it asynchronously). It's my pet peeve: I'm very happy that Arduino has been such a success, but I think too few people progress beyond that, and many believe this is how one programs embedded devices. As for RPI, it's neither a production device, nor a learning tool for embedded programming. The complexity involved means there is no way a beginner can understand everything that's going on.
  - learc83 10y ago
    >I disagree. You don't seem to actually disagree. You said: >Sure, if you never programmed a small device, by all means, start with an Arduino. And the OP said advice "for real beginners", i.e., people who have never programmed a small device. I didn't read anything that hinted that the OP was suggesting people never advance beyond Arduino. Again your disagreeing with things the OP never said. You: >As for RPI, it's neither a production device, nor a learning tool for embedded programming. OP: >you really just want a small computer running Linux but with GPIO-Pins?=> Raspberry PI
  - std_throwaway 10y ago
    As the other poster stated, you don't really disagree, just misunderstand. You can actually do everything you need in the Arduino IDE and then leave the IDE, compile and upload your own program written from scratch to the UNO. All that while staying compatible to the dozens of hardware extensions out there. The "Arduino" part is not the destination, it's three quarters of the path to the destination and that path is already paved.
    - jwr 10y ago
      No, I do not misunderstand -- I design products, as in things which are produced. Arduino is not for making products.
- userbinator 10y ago
  Do you want to understand in detail what's happening? => Arduino UNO I wonder what your definition of "understand in detail what's happening" is if you recommend an Arduino for that. It doesn't have to get as far as https://www.youtube.com/watch?v=UJHeDvr_doM https://www.youtube.com/watch?v=UJHeDvr_doM (something that I recommend every should try at least once if they claim to know how things really work) but I think reading the datasheet and using the bare MCU with Asm is a good start, things which those staying within the limits of the Arduino ecosystem wouldn't be doing. Along the same lines as that, there's also https://www.youtube.com/watch?v=8ZYMrcHm91s https://www.youtube.com/watch?v=8ZYMrcHm91s for those who claim to understand I2C.
  - std_throwaway 10y ago
    You can actually do a soft transition from the (opaque) Arduino programming style to a programming style closer to hardware. After all, Arduino programs are just C++ and you can plug in your own functions and assembler and you can even compile and upload your own ASM/C/C++ program written from scratch and compiled with the gnu-avr-toolchain to the UNO. After you have done all of that it might be a good idea to start soldering the AVR on your own boards.
    - petra 10y ago
      Isn't it better to start with the mbed though(if you intend for a commercial product, at least at kickstarter/~20K-units level) ? The quality of the libraries is higher(written by professionals), you have a wider selection of supported mcu's if you'd need to port, some mcu's support the mbed, easy to-use low-power api(an event driven framework that automatically puts the mcu to sleep when it isn't needed), ARM has put a lot of work in the security of the device and that's something that's very hard to replicate. And like the arduino, if something isn't optimal - you can always write your own. The only major drawback is the mbed is a bit more complex. For example, you need to use pointers, unlike the Arduino, where it's not a necessity.
      - TD-Linux 10y ago
        Not really, I generally find vendor libraries to be middling in quality, I think the core Arduino libraries are actually far more battle tested (if much less featureful). If you don't need more than the Arduino provides, it's probably not worth the extra complexity. The Atmega8 (and entire series of attiny/atmegas) is totally suitable for commercial applications - just stick the chip directly on your PCB. AVRs are pretty ubiquitous in consumer products.
- joshvm 10y ago
  There is also the Particle Photon which is a really nice little ARM board with built in WiFi. The library is more or less the same as Arduino, but not quite identical. It's still ARM C underneath so you can interleave your own code if you want to. It costs around $20. The system is designed to work with their cloud interface, but everything is open source and you can run offline if you need to. What's particularly neat about Particle is that if you decide that you want to make a product, they've got extensive guides on how to do it.
cmrdporcupine 10y ago
Parallax Propeller
- shmolyneaux 10y ago
  As someone who has used the parallax propeller, I feel like you a doing a bit of a disservice to not include some reasons for or against it. Cons: - Comparatively high price point at $8 - The custom 8-core architecture is more difficult to make full use of - No other chips in the family (can't flexibly move up or down in flash size / IO / core count) - No interrupts - Uncertain availability, and may be nearing end-of-life (this is speculative) - Programming in C is secondary to the proprietary scripting language SPIN (which has an interpreter in the chip) Pro: - The processor is open source under GPL v3 - Multicore architecture makes it easy to create systems that work concurrently - VGA output - No interrupts - SPIN isn't that bad... and assembly code integrates nicely with it
  - smaddox 10y ago
    Thanks for this, I was unfamiliar with this option. It sounds quite enticing. I also found this article by the founder informative: http://www.parallax.com/propeller/qna/Default.htm#HomeTopics/WhyWorks.htm http://www.parallax.com/propeller/qna/Default.htm#HomeTopics...
  - cmrdporcupine 10y ago
    Wow, some lovely downvotes for making a suggestion. Not sure how two words can be so offensive to people... Other advantages to Propeller in addition to what you say: - DIP form factor, easy to breadboard - Very little supporting circuity needed. Very easy to set up. - Enthusiastic intimate helpful community on the forum - GCC available (not an advantage over Arduino but it exists you don't have to use SPIN) - Pretty high performance compared to Arduino -- 80mhz on 8 cores [tho that doesn't tell the whole story since memory accesses to the shared memory take a lot of cycles) Other disadvantages: - Small memory space. 32k of slow shared memory space, only 2k per cog (core) - New Propeller 2 is taking years to come out and the old Prop 1 is really starting to show its age
contingencies 10y ago
1: PLAY "Shenzhen I/O"[0] 2: JMP :1 [0] http://www.zachtronics.com/shenzhen-io/ http://www.zachtronics.com/shenzhen-io/
- falcolas 10y ago
  Be sure to jump to Factorio when you want a bit more experience in designing circuit traces. It's amazing how quickly main bus designs naturally evolve.
  - contingencies 10y ago
    Hehe, literally in Shenzhen right now. There are loads of people with better skills. I am happy to outsource.
- TheMagicHorsey 10y ago
  Is this a recruiting tool?
  - tedunangst 10y ago
    Not anymore than FarmVille is a recruiting tool for farms I think. Just a game that happens to look like work (which is true for many games).
falcolas 10y ago
Now that you've picked a microcontroller, here's some tips on the next steps: "How to be: A smart hardware programmer" https://youtu.be/g8QDCMuy6oM https://youtu.be/g8QDCMuy6oM I link to this only partially in jest - you really will need way more components than the plan says you'll need. Even microcontrollers; misaligning a header by one pin can result in things like putting the output of a 3C Li-Poly over a signal header...
- taneq 10y ago
  Yeah, one of the biggest shocks to the system when going from desktop software development to embedded development is how easy it is to fry your hardware (and since this is pre-alpha grade hardware, often even with a software mistake). Never buy just one of anything because you'll let the magic smoke out, a /lot/. And that goes double if you're doing anything higher voltage than CPU supply voltage, or higher current than a few hundred milliamps.
- bigiain 10y ago
  This is why I like prototyping with Arduinos - you'll 99% likeley get away with plugging an 11.1V (or 12-13V fresh off the charge) battery into any of the pins on an Arduino. You'll be looking for another RasPi if you made _that_ mistake...
  - falcolas 10y ago
    In this case, it wasn't the voltage, which had been brought down to 5v by the motor controller, it was the 160+amps. Not milliamps, amps (3300 mah, 50c battery). Drone batteries are nasty pieces of work...
    - bigiain 10y ago
      Indeed. I wasn't paying enough attention when soldering a plug onto a 7 cell 5800mAhr 40c battery once. I melted the tip of my iron, and pretty much vapourised the plug's contacts... (The battery seemed fine about it - I got 6 or 8 months out of it powering a bicycle before it started to show signs of imminently-firey puffiness...)
jwr 10y ago
One more thing to consider: if your time is limited and you have to design/build lots of different devices, stick to more extensive product lines. As an example the NXP Kinetis, while having its share of warts and issues, is a huge product line with hundreds of chips, sharing a similar architecture. This means that you can use a chip that fits requirements well, ranging from tiny simple M0+ devices all the way to monster M4 chips with 1M flash and every peripheral one can imagine. They not only share some peripherals, but you use the same SDK, documentation formats are the same, etc. This is a huge time saver and lets you use the right chip for each project, instead of sticking the same expensive microcontroller everywhere, or using ones from different manufacturers.
- jpm_sd 10y ago
  I switched from STM32 to the Kinetis family two years ago and I've been super happy with the change. The free IDE is actually pretty solid and support has been adequate. Now that Freescale has been doubly gobbled up (first by NXP and then NXP by Qualcomm) this may go downhill a bit, but the user forums are decent. Edit: I'm also using an M4 with dual bank flash almost everywhere. The projects I'm doing these days aren't particularly BOM cost sensitive and the headroom + foolproof firmware updating are fantastic (as the article says).
  - jwr 10y ago
    Interesting -- could you write about your impressions? How do peripherals compare? I think you get 32-bit timers on the STM32? And I heard that most other peripherals are newer/better than the 8-bit peripherals that NXP/Freescale adapts to the Kinetis chips -- what do you think?
    - jpm_sd 10y ago
      I guess I just haven't needed those bells and whistles. 32 bit timers are kinda huge. And some of the peripherals on the STM are suffering from "newer ain't always better" - the CAN and I2C controllers are more complicated than they need to be, IMHO. Edit: I can't make any useful comparison on analog peripherals since I use external ADCs, DACs, etc. more or less 100% of the time
ChuckMcM 10y ago
Generally solid advice (although its more like "how to pick a micro-controller for your design you're trying to keep as cheap as possible.") and one of the areas where I quibble is the use of "generator" tools to generate I/O code. The STCube application is easy to use for beginners but easily uses twice as much flash as actual user written code. That isn't a problem if your app is small and the flash is large but puts you at a disadvantage if you are competing with people who know how to write that code. My philosophy has been to develop an understanding of the peripheral fairly deeply, write a 'driver' for it and a bunch of documentation that will remind me of the quirks when I come back to it, and then put that in a library. The benefit is 'easy code' (just use the library) that is more efficient and smaller than generated code, and a quick spin up document if I need to dive in and do more complex work with the peripheral.
- sureshjoshi 10y ago
  That is a great point about the downsides of generated code that I didn't mention (but should have). I don't think it uses twice as much flash per se, but it definitely does use 'more' than hand-rolling your own code. But ST-Cube has also gotten MUCH better over the last few years and no longer generates a lot of unnecessary, yet compiled, code. The version I first used in 2012ish was pretty weak. I try to approach this from the direction of what gets me up and running fastest (and what has the lowest barrier to entry for my team - including communication), and then I re-factor out the guts afterwards if needed. Practically speaking, my workflow is that I have a set of heavily unit tested and mocked out middleware and device drivers, that are portable to any ARM... So, all I need are the low-level drivers which interact with the peripherals. I can generate them with ST-Cube, hook them into my middleware/drivers through interfaces (C++) or linking (C). From here, I run my automated integration tests to make sure everything works on my hardware - and once that's done, I evaluate my flash usage. If needed, I gut the generated code in favour of something hand-rolled, while being able to make sure everything is still 'correct'. Also, contextually, I almost never use anything less than 32kB flash - so I don't often need to hyper-optimize.
maxander 10y ago
Its slightly ironic that this article "for beginners" is filled with obscure acronyms he doesn't define (UART, BOM, BLE...).
- tptacek 10y ago
  A more productive way to make this point is to simply ask what the terms mean. UART is a programmable serial interface; it usually refers to the kind of serial you speak to peripherals in the outside world, as opposed to something like SPI, which is serial spoken to components on the same board. BOM is "bill of materials". It's the catalog and price of all the components needed to ship an actual product. If your chip doesn't have an RTC (clock), and you need to buy another part to provide it, that adds to your BOM. BLE is Bluetooth Low Energy.
  - maxander 10y ago
    Its all readily googlable, certainly. My point was that its poor practice when writing a piece aimed at introducing people to a subject; if they have to go to google every few lines to see what something means, that distracts attention from what the article is actually trying to convey. For that matter, they could just as easily google for a different article.
    - StavrosK 10y ago
      The author should have used this shameless plug of mine: https://skorokithakis.github.io/expounder/ https://skorokithakis.github.io/expounder/
    - skrebbel 10y ago
      Your confusion stems from what kind of beginner the author means. You read it as "total beginner to anything vaguely related to microcontroller programmer". I assume the authors means it as "has programmed stuff with microcontrollers before but never made a hardware design from scratch yet". After all, picking a microcontroller is a design/architecture choice more than a programming choice.
pjc50 10y ago
Related on EE.stackexchange: https://electronics.stackexchange.com/questions/264794/how-do-i-come-up-with-a-list-of-requirements-for-a-microcontroller-for-my-projec/264813#264813 https://electronics.stackexchange.com/questions/264794/how-d... I agree with OP's "grief factor" - difficult to estimate but really critical to your project timeline. I'm also going to advocate my "pick something" suggestion; the first one of anything you buy in an unfamiliar product area will always be wrong. This applies to computers, cars, cameras, houses, everything; when you're entering the market you won't understand your own requirements and anti-requirements. So buy something cheap and standard then use it to understand how it's inadequate for you specifically. You'll also appreciate the expensive options. If you've never bought a microcontroller, buy an Arduino. It may not be right but you'll have a lot of company.
- sureshjoshi 10y ago
  The "grief factor" is how I run my life :) I agree with "pick something" with the addendum of "pick something that someone experienced you know/trust recommended after hearing how little you know about it".
  - bigiain 10y ago
    Heh. My "pick something" strategy almost always turns on the "What have I got sitting around that's close enough for what I need?" Sure, and STM32 or an Atmel AT8 _might_ be a better choice, but if I've got a drawer full of Arduinos and a bunch of projects with RaspberryPis in them that haven't been powered up for months - I'll go rat those bits and use them... (Last weekend, I wanted a 6dof IMU sensor - which I could have ordered - but I just used a spare quadcopter control board with a dud baro sensor, because it was there when I wanted it... I ended up using the mags in the 9dof sensors on the flight controller as well, so win all round...)
- fragmede 10y ago
  If we're recommending pet favorites, the Raspberry Pi Zero Wireless, despite being the newest, is now my recommended "microcontroller". There are a few tweaks needed on top of the base Rasbian distro to make it appropriate for use as a microcontroller, but with a base price of $10, it's cheaper, more powerful, and has accessories (ie - anything USB with open source Linux drivers), than some Arduinos. Built in wifi, Linux, plus USB and GPIO, means it's perfect for the device end of an hobbiest-level IoT project.
jordz 10y ago
We use NXP/Kinetis chips (Cortex M0+) and have been relatively happy with them from a cost and hassle point of view. When developing we use SWD with a kinetis dev board as the programmer hooked up to the target MCU. We have had strange issues with the MSB bricking things when updating the bootloaders but thankfully they're cheap enough to replace.
plandis 10y ago
Starting with a beefy ARM chip! Try Arduino. If you are not familiar with micro controllers you might as well stick to something that is made for beginners. Plus as you get more advanced you can always use the raw AVR chip without the added Arduino bootloader.
zw123456 10y ago
This was a pretty good overview. I get asked this same question a lot because I have been working with microprocessors for decades and I have used many different ones from the old 8051 to Microchip, Arm and even FPGA embedded. The way I usually start is I ask this "will you need an OS like Linux ?" (there are a bunch of follow on questions on that issue to decide that. If the answer is yes then that steers you to a much bigger and more expensive chip, usually and increases the complexity significantly. For beginners who need an OS for their project, I steer them to the RPI simply because there is just a ton of resources on the web to help them along. There are other really good boards but I steer them to an off the shelf solution like that and the RPI seems to be really well supported. If you don't need Linux or RTOS or similar then that narrows it to a lower end simpler solution. For beginners I almost always steer them to the Arduino even though I rarely use it myself but for the same reason, tons of support on the web and you can, over time move to C or C++ on it as you advance your skills. I am not a big super fan of those platforms I personally have my own dev system using my own boards and system that I have evolved over the years to be able to get designs done very fast. But I just think those are good starting points for a beginner.
69mlgsniperdad 10y ago
Couple of thoughts after skimming the article. Consider weighing the importance of being able to upgrade or change uC. Don't choose a controller made by only one manufacturer (unless there is a level of certainty or confidence in their continued production/support and profitability). It would be unfortunate for example, if you used an atmega microcontroller and they went out of business, or changed their strategy and abandoned a platform, requiring you to switch to an alternative and rewrite some or all of your code. Having a codebase that can be made to run on different platforms easily would be ideal. If there is a good chance, after a small order, you realize from feedback you are missing some crucial features and need to make changes, changes which require more it's higher or more precise clock, or whatever, make sure that the jump to the next size chip doesn't abandon or make a drastic jump in price or available volume. If you plan to manufacturer your product for a long time, ensure that you are confident in the availability of quantities at similar price for however long you expect to require it. Always be wary of jumping on board anything brand new. The Intel Edison/Curie for example based on the Quark ended up having an unfixable segfault, and was virtually abandoned shortly after it's release.
bschwindHN 10y ago
How is almost no one talking about the esp32? WiFi, Bluetooth, two cores, and an ultra low power processor that can wake the main cores for when you need low power consumption are just the main features of this thing, there are plenty more. Not to mention they have a great tool chain with lots of example code.

227 points by adastra 10y ago

A quicker guide for real beginners: Do you want to understand in detail what's happening? => Arduino UNO Is the UNO too small/slow? => Arduino Due Still too small or you really just want a small computer running Linux but with GPIO-Pins? => Raspberry PI

Palomides 10y ago
I think this is more of a guide for somewhat experienced hardware people picking a microcontroller to go into production than a complete beginner to electronics. Agreed that anyone else should just grab an arduino.
guitarbill 10y ago
Paul Stoffregen's Teensy boards are the way to go. The hardware and the software are excellent. Heaps of power thanks to the ARM Cortex M4 and you still get the Arduino IDE. Can't recommend them enough, wish I had of moved to them far sooner. Everybody I've given one to has loved them, and the USB support is also very welcome. (As far as price goes, they're development boards and worth every cent for beginners.)
- Marazan 10y ago
  Extreme agreement from me.
- analog31 10y ago
  The Teensy boards are fabulous. I'm so impressed by what Paul Stoffgren has done. He must be some kind of 100x developer. And there are some power users of his boards, who have contributed libraries as well. It's worth noting that while you can ease your way into programming with the functions available within the Arduino IDE, there are libraries for many of the special functions of the chips, and all of the special function registers are exposed, so you can make full use of your hardware capabilities if desired. As for choosing a microcontroller, I'm generally tempted to start by choosing a development tool, because I'll be spending more of my time in code development and testing than in any other activity.
  - abdupattoh 10y ago
    Having worked on college labs with Paul 100x is about right. We just kinda looked in wonder at his projects... and he sold us the parts for ours... A real serving individual actually.
  - Berobero 10y ago
    We've had the pleasure of having Paul as a sponsor for our senior project, a sample-based midi synthesizer, running on, at least, the Teensy 3.2 and 3.6; we got free hardware for development, and he's been quite supportive, despite being obviously perpetually busy. And I can't say I ever felt at all hindered by the hardware or its libraries, and although we started the project with almost no embedded experience. Quite a fun way to end college.
    - brokenmachine 10y ago
      Do you have a site about your project? I'm interested in synths (and teensies) and would be interested to see it.
- moosingin3space 10y ago
  Additionally, there is a (small) community around programming Teensy in Rust, which is awesome.
- std_throwaway 10y ago
  I'll have to look into those. Being able to start with the Arduino IDE is a big plus for beginners.
- gwu78 10y ago
  One of the things I like about this choice is one does not need an IDE, at least not with the 2.0. One can do non-graphical (systems) programming on an underpowered computer with no graphics. I statically compile the loader. On BSD at least, no 3rd party libs are needed. Then all I need is avr-gcc. I can do everything from the command line. No closed source tools. No requisite graphics layer (e.g., Windows OS). No large interpreters (Python, etc.). https://raw.githubusercontent.com/PaulStoffregen/teensy_loader_cli/master/teensy_loader_cli.c https://raw.githubusercontent.com/PaulStoffregen/teensy_load... Can anyone recommend other boards where everything can be done like this, i.e., without needing closed sorce tools, graphics layer, or installation of interpreters and scripting libraries? e.g.: http://home.hccnet.nl/anij/nof/noforth.html http://home.hccnet.nl/anij/nof/noforth.html
  - detaro 10y ago
    The AVR-based Arduinos (Really, I think most AVR-based boards, unless it has some really strange proprietary way of flashing). The MSP430-based TI Launchpads. The various ESP-something WLAN boards have open toolchains and programming over serial as well as far as I know.
    - david-given 10y ago
      I have about 2/3 of an 8080 emulator running CP/M for a MSP430 LaunchPad somewhere; because that MSP430 only has 2kB of RAM it has to swap to an external SRAM device. There's AT keyboard support (via an external level shifter). I got it to the point of booting (very slowly) up to the command line prompt and processing basic commands, but unfortunately I never figured out how to make the screen work, so that's where the project stalled. The hardware's since been broken up and repurposed. All in C and hand-written assembly tied together with a makefile, using tools that are in Debian. The standard flash tool (also in Debian) is really easy to use and even supports JTAG debugging over USB. (Also the MSP430 has a lovely assembly instruction set if you want to work with that sort of thing.) Can't comment about AVR or ESP; never used them.
  - TD-Linux 10y ago
    Any of the Cortex-M* series are also generally a good choice, for example the STM32* series. All of these are supported in mainline gcc, and have open source support libraries provided by the vendor or via libopencm3. Be a bit careful, as some vendors like to use proprietary licenses for their headers, but in most cases there is at least one open source alternative. And of course the RISC-V HiFive1, though it's still very new and in sampling quantities.
juliendorra 10y ago
Do you want easy wifi and Bluetooth ? ESP. (Arduino Yun are a nightmare in workshops / sprint context)
- std_throwaway 10y ago
  Of course, do they come with a nice IDE and a big library/ecosystem of soft/hardware examples?
  - StavrosK 10y ago
    Yep.
- bigiain 10y ago
  I'll recommend NextThing CHIPs here too (I started buying them because PiZeros are/were too difficult to get in quantities greater then one. Same with the PiZeroW right now, I've got a project where I'd like 12 of them, but it's not work jumping through the hoops (and paying 12 times the shipping costs to Australia) to bother right now.
- deleted 10y ago
  [deleted]
simonbarker87 10y ago
I would say that if you are looking at getting started with embedded electronics from an electrical engineering/professional stand pint and looking to put things into production then don't start with Arduino and certainly don't view an RPi as a viable embedded solution. A PicKit 2 and a 16F series Microchip microcontroller would be a much better starting point just to get up and running without feeling overwhelmed.
- jfroma 10y ago
  I loved that one. We spend an entire year on high school programming the 16F84 on assembler. We re-implemented all projects we did the previous year with nand gates like semaphore, infrared barriers for counting stuff etc with pics, and it was mindblowing for me. I also remember we did a board for writing the program in the pic because it was too expensive in my country.
- std_throwaway 10y ago
  I come from the angle of "absolute beginner" who is trying to get started quickly. If you are really "looking to put things into production" you might be right. Using those boards I proposed will always have big disadvantages. The original article is not written for absolute beginners, but for people who would go through the pain of soldering 100 pins to a self-designed PCB and failing 5 times before getting a working version.
- TD-Linux 10y ago
  I agree with not starting with the RPi (to avoid the complexities of the Linux kernel), but I started with the PIC and SX series (before Arduino was a thing) and wouldn't recommend it anymore. If you want to learn an assembly language and twiddle registers then maybe you'd like the PIC, but I don't think it's more "professional" - virtually everyone uses C if at all possible at this point, and the AVR (or bigger PICs) are just as "production-ready" as the old PIC16F series. And you can still twiddle AVR registers with C if you so desire.
  - simonbarker87 10y ago
    Assembly on PIC is horrible, I agree. I've only done one project in assembly on PIC and since then only used C with PIC which works fine across the whole range.
blhack 10y ago
I'll append with: Do you need wifi: Wemos D1 mini Do you need bluetooth low energy: light blue bean
- antoniuschan99 10y ago
  Light blue bean is $30. ESP is production ready. But doesn't have bluetooth (esp32 is not ready for prime time yet). What are other considerations? Wemos D1 mini or NodeMCU :).
  - MrBuddyCasino 10y ago
    "esp32 is not ready for prime time yet" There are some rough edges, but its already very useable, especially since the new silicon came out. Got anything specific in mind?
    - kirrent 10y ago
      I just came back to my esp32 after a 6 week hiatus and the framework has evolved impressively in that amount of time. It's an awesome product for a steal of a price. Definitely at the usable stage.
      - antoniuschan99 10y ago
        That's great to hear! If that's the case, then it's basically just supply chain issues that's left. It's still hard to get batches and it's probably still pretty expensive compared to the 8266?
        MrBuddyCasino 10y ago
        That is true, but the SDK is so much better that frankly I don't care, but then I'm not doing high volume products either so thats easy to say.
  - Eridrus 10y ago
    For BLE, but no Wifi, nRF51/52 chips seem like a good fit; bonus is that they're low power,
bsamuels 10y ago
your advice is excellent for makers and hackers, but if you're building a product, arduino/raspberry pi is far too expensive
- std_throwaway 10y ago
  That depends on what the product may cost and how many you intend to sell. In general you might be right. But if you look in getting started and having a solution (suboptimal but working) quickly, then they are a good choice. Maybe not the best choice, but good.
- jononor 10y ago
  Many/most Arduino boards are open source. So if you small and are trying to get a simple product line established you can start with designing a daughter/motherboard that the Arduino board plugs into for first series. Then, once you scale up, embed the Arduino parts into the same board. You can use a clone also, which can be much cheaper. But I wouldn't go recommend Atmega328 for new designs unless its extremely simple, so when I say "Arduino" I mean something similar, like a Teensy 3+ or Olimex STM32 or Adafruit Feather M0
- justin66 10y ago
  The RPi (its SoC, really) is probably a fine choice financially for the applications where it doesn't represent ridiculous overengineering.
jwr 10y ago
I disagree. Everything you listed a) can't be used for products, b) doesn't let you make progress beyond "oh look, I lit up an LED!". Sure, if you never programmed a small device, by all means, start with an Arduino. But after you do light up that LED, please learn more. Go bare metal, learn about interrupts, state machines, entering sleep states -- without those things you'll stay forever in the toy world. In the real world, if you work with battery-powered devices, you never have the comfort of busy waiting for your UART/I2C transmission to finish, or calling analogRead() and getting immediate results (because ADC takes time and you want to do it asynchronously). It's my pet peeve: I'm very happy that Arduino has been such a success, but I think too few people progress beyond that, and many believe this is how one programs embedded devices. As for RPI, it's neither a production device, nor a learning tool for embedded programming. The complexity involved means there is no way a beginner can understand everything that's going on.
- learc83 10y ago
  >I disagree. You don't seem to actually disagree. You said: >Sure, if you never programmed a small device, by all means, start with an Arduino. And the OP said advice "for real beginners", i.e., people who have never programmed a small device. I didn't read anything that hinted that the OP was suggesting people never advance beyond Arduino. Again your disagreeing with things the OP never said. You: >As for RPI, it's neither a production device, nor a learning tool for embedded programming. OP: >you really just want a small computer running Linux but with GPIO-Pins?=> Raspberry PI
- std_throwaway 10y ago
  As the other poster stated, you don't really disagree, just misunderstand. You can actually do everything you need in the Arduino IDE and then leave the IDE, compile and upload your own program written from scratch to the UNO. All that while staying compatible to the dozens of hardware extensions out there. The "Arduino" part is not the destination, it's three quarters of the path to the destination and that path is already paved.
  - jwr 10y ago
    No, I do not misunderstand -- I design products, as in things which are produced. Arduino is not for making products.
userbinator 10y ago
Do you want to understand in detail what's happening? => Arduino UNO I wonder what your definition of "understand in detail what's happening" is if you recommend an Arduino for that. It doesn't have to get as far as https://www.youtube.com/watch?v=UJHeDvr_doM https://www.youtube.com/watch?v=UJHeDvr_doM (something that I recommend every should try at least once if they claim to know how things really work) but I think reading the datasheet and using the bare MCU with Asm is a good start, things which those staying within the limits of the Arduino ecosystem wouldn't be doing. Along the same lines as that, there's also https://www.youtube.com/watch?v=8ZYMrcHm91s https://www.youtube.com/watch?v=8ZYMrcHm91s for those who claim to understand I2C.
- std_throwaway 10y ago
  You can actually do a soft transition from the (opaque) Arduino programming style to a programming style closer to hardware. After all, Arduino programs are just C++ and you can plug in your own functions and assembler and you can even compile and upload your own ASM/C/C++ program written from scratch and compiled with the gnu-avr-toolchain to the UNO. After you have done all of that it might be a good idea to start soldering the AVR on your own boards.
  - petra 10y ago
    Isn't it better to start with the mbed though(if you intend for a commercial product, at least at kickstarter/~20K-units level) ? The quality of the libraries is higher(written by professionals), you have a wider selection of supported mcu's if you'd need to port, some mcu's support the mbed, easy to-use low-power api(an event driven framework that automatically puts the mcu to sleep when it isn't needed), ARM has put a lot of work in the security of the device and that's something that's very hard to replicate. And like the arduino, if something isn't optimal - you can always write your own. The only major drawback is the mbed is a bit more complex. For example, you need to use pointers, unlike the Arduino, where it's not a necessity.
    - TD-Linux 10y ago
      Not really, I generally find vendor libraries to be middling in quality, I think the core Arduino libraries are actually far more battle tested (if much less featureful). If you don't need more than the Arduino provides, it's probably not worth the extra complexity. The Atmega8 (and entire series of attiny/atmegas) is totally suitable for commercial applications - just stick the chip directly on your PCB. AVRs are pretty ubiquitous in consumer products.
joshvm 10y ago
There is also the Particle Photon which is a really nice little ARM board with built in WiFi. The library is more or less the same as Arduino, but not quite identical. It's still ARM C underneath so you can interleave your own code if you want to. It costs around $20. The system is designed to work with their cloud interface, but everything is open source and you can run offline if you need to. What's particularly neat about Particle is that if you decide that you want to make a product, they've got extensive guides on how to do it.

cmrdporcupine 10y ago

Parallax Propeller

shmolyneaux 10y ago
As someone who has used the parallax propeller, I feel like you a doing a bit of a disservice to not include some reasons for or against it. Cons: - Comparatively high price point at $8 - The custom 8-core architecture is more difficult to make full use of - No other chips in the family (can't flexibly move up or down in flash size / IO / core count) - No interrupts - Uncertain availability, and may be nearing end-of-life (this is speculative) - Programming in C is secondary to the proprietary scripting language SPIN (which has an interpreter in the chip) Pro: - The processor is open source under GPL v3 - Multicore architecture makes it easy to create systems that work concurrently - VGA output - No interrupts - SPIN isn't that bad... and assembly code integrates nicely with it
- smaddox 10y ago
  Thanks for this, I was unfamiliar with this option. It sounds quite enticing. I also found this article by the founder informative: http://www.parallax.com/propeller/qna/Default.htm#HomeTopics/WhyWorks.htm http://www.parallax.com/propeller/qna/Default.htm#HomeTopics...
- cmrdporcupine 10y ago
  Wow, some lovely downvotes for making a suggestion. Not sure how two words can be so offensive to people... Other advantages to Propeller in addition to what you say: - DIP form factor, easy to breadboard - Very little supporting circuity needed. Very easy to set up. - Enthusiastic intimate helpful community on the forum - GCC available (not an advantage over Arduino but it exists you don't have to use SPIN) - Pretty high performance compared to Arduino -- 80mhz on 8 cores [tho that doesn't tell the whole story since memory accesses to the shared memory take a lot of cycles) Other disadvantages: - Small memory space. 32k of slow shared memory space, only 2k per cog (core) - New Propeller 2 is taking years to come out and the old Prop 1 is really starting to show its age

contingencies 10y ago

1: PLAY "Shenzhen I/O"[0] 2: JMP :1 [0] http://www.zachtronics.com/shenzhen-io/ http://www.zachtronics.com/shenzhen-io/

falcolas 10y ago
Be sure to jump to Factorio when you want a bit more experience in designing circuit traces. It's amazing how quickly main bus designs naturally evolve.
- contingencies 10y ago
  Hehe, literally in Shenzhen right now. There are loads of people with better skills. I am happy to outsource.
TheMagicHorsey 10y ago
Is this a recruiting tool?
- tedunangst 10y ago
  Not anymore than FarmVille is a recruiting tool for farms I think. Just a game that happens to look like work (which is true for many games).

falcolas 10y ago

Now that you've picked a microcontroller, here's some tips on the next steps: "How to be: A smart hardware programmer" https://youtu.be/g8QDCMuy6oM https://youtu.be/g8QDCMuy6oM I link to this only partially in jest - you really will need way more components than the plan says you'll need. Even microcontrollers; misaligning a header by one pin can result in things like putting the output of a 3C Li-Poly over a signal header...

taneq 10y ago
Yeah, one of the biggest shocks to the system when going from desktop software development to embedded development is how easy it is to fry your hardware (and since this is pre-alpha grade hardware, often even with a software mistake). Never buy just one of anything because you'll let the magic smoke out, a /lot/. And that goes double if you're doing anything higher voltage than CPU supply voltage, or higher current than a few hundred milliamps.
bigiain 10y ago
This is why I like prototyping with Arduinos - you'll 99% likeley get away with plugging an 11.1V (or 12-13V fresh off the charge) battery into any of the pins on an Arduino. You'll be looking for another RasPi if you made _that_ mistake...
- falcolas 10y ago
  In this case, it wasn't the voltage, which had been brought down to 5v by the motor controller, it was the 160+amps. Not milliamps, amps (3300 mah, 50c battery). Drone batteries are nasty pieces of work...
  - bigiain 10y ago
    Indeed. I wasn't paying enough attention when soldering a plug onto a 7 cell 5800mAhr 40c battery once. I melted the tip of my iron, and pretty much vapourised the plug's contacts... (The battery seemed fine about it - I got 6 or 8 months out of it powering a bicycle before it started to show signs of imminently-firey puffiness...)

jwr 10y ago

One more thing to consider: if your time is limited and you have to design/build lots of different devices, stick to more extensive product lines. As an example the NXP Kinetis, while having its share of warts and issues, is a huge product line with hundreds of chips, sharing a similar architecture. This means that you can use a chip that fits requirements well, ranging from tiny simple M0+ devices all the way to monster M4 chips with 1M flash and every peripheral one can imagine. They not only share some peripherals, but you use the same SDK, documentation formats are the same, etc. This is a huge time saver and lets you use the right chip for each project, instead of sticking the same expensive microcontroller everywhere, or using ones from different manufacturers.

jpm_sd 10y ago
I switched from STM32 to the Kinetis family two years ago and I've been super happy with the change. The free IDE is actually pretty solid and support has been adequate. Now that Freescale has been doubly gobbled up (first by NXP and then NXP by Qualcomm) this may go downhill a bit, but the user forums are decent. Edit: I'm also using an M4 with dual bank flash almost everywhere. The projects I'm doing these days aren't particularly BOM cost sensitive and the headroom + foolproof firmware updating are fantastic (as the article says).
- jwr 10y ago
  Interesting -- could you write about your impressions? How do peripherals compare? I think you get 32-bit timers on the STM32? And I heard that most other peripherals are newer/better than the 8-bit peripherals that NXP/Freescale adapts to the Kinetis chips -- what do you think?
  - jpm_sd 10y ago
    I guess I just haven't needed those bells and whistles. 32 bit timers are kinda huge. And some of the peripherals on the STM are suffering from "newer ain't always better" - the CAN and I2C controllers are more complicated than they need to be, IMHO. Edit: I can't make any useful comparison on analog peripherals since I use external ADCs, DACs, etc. more or less 100% of the time

ChuckMcM 10y ago

Generally solid advice (although its more like "how to pick a micro-controller for your design you're trying to keep as cheap as possible.") and one of the areas where I quibble is the use of "generator" tools to generate I/O code. The STCube application is easy to use for beginners but easily uses twice as much flash as actual user written code. That isn't a problem if your app is small and the flash is large but puts you at a disadvantage if you are competing with people who know how to write that code. My philosophy has been to develop an understanding of the peripheral fairly deeply, write a 'driver' for it and a bunch of documentation that will remind me of the quirks when I come back to it, and then put that in a library. The benefit is 'easy code' (just use the library) that is more efficient and smaller than generated code, and a quick spin up document if I need to dive in and do more complex work with the peripheral.

sureshjoshi 10y ago
That is a great point about the downsides of generated code that I didn't mention (but should have). I don't think it uses twice as much flash per se, but it definitely does use 'more' than hand-rolling your own code. But ST-Cube has also gotten MUCH better over the last few years and no longer generates a lot of unnecessary, yet compiled, code. The version I first used in 2012ish was pretty weak. I try to approach this from the direction of what gets me up and running fastest (and what has the lowest barrier to entry for my team - including communication), and then I re-factor out the guts afterwards if needed. Practically speaking, my workflow is that I have a set of heavily unit tested and mocked out middleware and device drivers, that are portable to any ARM... So, all I need are the low-level drivers which interact with the peripherals. I can generate them with ST-Cube, hook them into my middleware/drivers through interfaces (C++) or linking (C). From here, I run my automated integration tests to make sure everything works on my hardware - and once that's done, I evaluate my flash usage. If needed, I gut the generated code in favour of something hand-rolled, while being able to make sure everything is still 'correct'. Also, contextually, I almost never use anything less than 32kB flash - so I don't often need to hyper-optimize.

maxander 10y ago

Its slightly ironic that this article "for beginners" is filled with obscure acronyms he doesn't define (UART, BOM, BLE...).

tptacek 10y ago
A more productive way to make this point is to simply ask what the terms mean. UART is a programmable serial interface; it usually refers to the kind of serial you speak to peripherals in the outside world, as opposed to something like SPI, which is serial spoken to components on the same board. BOM is "bill of materials". It's the catalog and price of all the components needed to ship an actual product. If your chip doesn't have an RTC (clock), and you need to buy another part to provide it, that adds to your BOM. BLE is Bluetooth Low Energy.
- maxander 10y ago
  Its all readily googlable, certainly. My point was that its poor practice when writing a piece aimed at introducing people to a subject; if they have to go to google every few lines to see what something means, that distracts attention from what the article is actually trying to convey. For that matter, they could just as easily google for a different article.
  - StavrosK 10y ago
    The author should have used this shameless plug of mine: https://skorokithakis.github.io/expounder/ https://skorokithakis.github.io/expounder/
  - skrebbel 10y ago
    Your confusion stems from what kind of beginner the author means. You read it as "total beginner to anything vaguely related to microcontroller programmer". I assume the authors means it as "has programmed stuff with microcontrollers before but never made a hardware design from scratch yet". After all, picking a microcontroller is a design/architecture choice more than a programming choice.

pjc50 10y ago

Related on EE.stackexchange: https://electronics.stackexchange.com/questions/264794/how-do-i-come-up-with-a-list-of-requirements-for-a-microcontroller-for-my-projec/264813#264813 https://electronics.stackexchange.com/questions/264794/how-d... I agree with OP's "grief factor" - difficult to estimate but really critical to your project timeline. I'm also going to advocate my "pick something" suggestion; the first one of anything you buy in an unfamiliar product area will always be wrong. This applies to computers, cars, cameras, houses, everything; when you're entering the market you won't understand your own requirements and anti-requirements. So buy something cheap and standard then use it to understand how it's inadequate for you specifically. You'll also appreciate the expensive options. If you've never bought a microcontroller, buy an Arduino. It may not be right but you'll have a lot of company.

sureshjoshi 10y ago
The "grief factor" is how I run my life :) I agree with "pick something" with the addendum of "pick something that someone experienced you know/trust recommended after hearing how little you know about it".
- bigiain 10y ago
  Heh. My "pick something" strategy almost always turns on the "What have I got sitting around that's close enough for what I need?" Sure, and STM32 or an Atmel AT8 _might_ be a better choice, but if I've got a drawer full of Arduinos and a bunch of projects with RaspberryPis in them that haven't been powered up for months - I'll go rat those bits and use them... (Last weekend, I wanted a 6dof IMU sensor - which I could have ordered - but I just used a spare quadcopter control board with a dud baro sensor, because it was there when I wanted it... I ended up using the mags in the 9dof sensors on the flight controller as well, so win all round...)
fragmede 10y ago
If we're recommending pet favorites, the Raspberry Pi Zero Wireless, despite being the newest, is now my recommended "microcontroller". There are a few tweaks needed on top of the base Rasbian distro to make it appropriate for use as a microcontroller, but with a base price of $10, it's cheaper, more powerful, and has accessories (ie - anything USB with open source Linux drivers), than some Arduinos. Built in wifi, Linux, plus USB and GPIO, means it's perfect for the device end of an hobbiest-level IoT project.

jordz 10y ago

We use NXP/Kinetis chips (Cortex M0+) and have been relatively happy with them from a cost and hassle point of view. When developing we use SWD with a kinetis dev board as the programmer hooked up to the target MCU. We have had strange issues with the MSB bricking things when updating the bootloaders but thankfully they're cheap enough to replace.

plandis 10y ago

Starting with a beefy ARM chip! Try Arduino. If you are not familiar with micro controllers you might as well stick to something that is made for beginners. Plus as you get more advanced you can always use the raw AVR chip without the added Arduino bootloader.

zw123456 10y ago

This was a pretty good overview. I get asked this same question a lot because I have been working with microprocessors for decades and I have used many different ones from the old 8051 to Microchip, Arm and even FPGA embedded. The way I usually start is I ask this "will you need an OS like Linux ?" (there are a bunch of follow on questions on that issue to decide that. If the answer is yes then that steers you to a much bigger and more expensive chip, usually and increases the complexity significantly. For beginners who need an OS for their project, I steer them to the RPI simply because there is just a ton of resources on the web to help them along. There are other really good boards but I steer them to an off the shelf solution like that and the RPI seems to be really well supported. If you don't need Linux or RTOS or similar then that narrows it to a lower end simpler solution. For beginners I almost always steer them to the Arduino even though I rarely use it myself but for the same reason, tons of support on the web and you can, over time move to C or C++ on it as you advance your skills. I am not a big super fan of those platforms I personally have my own dev system using my own boards and system that I have evolved over the years to be able to get designs done very fast. But I just think those are good starting points for a beginner.

69mlgsniperdad 10y ago

Couple of thoughts after skimming the article. Consider weighing the importance of being able to upgrade or change uC. Don't choose a controller made by only one manufacturer (unless there is a level of certainty or confidence in their continued production/support and profitability). It would be unfortunate for example, if you used an atmega microcontroller and they went out of business, or changed their strategy and abandoned a platform, requiring you to switch to an alternative and rewrite some or all of your code. Having a codebase that can be made to run on different platforms easily would be ideal. If there is a good chance, after a small order, you realize from feedback you are missing some crucial features and need to make changes, changes which require more it's higher or more precise clock, or whatever, make sure that the jump to the next size chip doesn't abandon or make a drastic jump in price or available volume. If you plan to manufacturer your product for a long time, ensure that you are confident in the availability of quantities at similar price for however long you expect to require it. Always be wary of jumping on board anything brand new. The Intel Edison/Curie for example based on the Quark ended up having an unfixable segfault, and was virtually abandoned shortly after it's release.

bschwindHN 10y ago

How is almost no one talking about the esp32? WiFi, Bluetooth, two cores, and an ultra low power processor that can wake the main cores for when you need low power consumption are just the main features of this thing, there are plenty more. Not to mention they have a great tool chain with lots of example code.