How to pick a microcontroller(sureshjoshi.com) |
How to pick a microcontroller(sureshjoshi.com) |
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.
Built in wifi, Linux, plus USB and GPIO, means it's perfect for the device end of an hobbiest-level IoT project.
You will inevitably need adc functionality, possibly real time clock and battery usage.
Most servos don't need wifi or Ethernet. Instead, you will usually want to be able to read a voltage and then time how long it takes for that to change.
15 cent quartz crystal and built in adcs. Bitbanging pwm from raspberry pi is also horribly inaccurate... You need a ton of shields to just run a motor with an encoder on it... While arduino can do all that around 10mA
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".
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.
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.
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).
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.
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.
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...
Drone batteries are nasty pieces of work...
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
2: JMP :1
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.
It depends. If you know what they mean but want to point TFA's deficiency, OP's post is the way to go :)
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.
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
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)
- 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 ageI also found this article by the founder informative: http://www.parallax.com/propeller/qna/Default.htm#HomeTopics...
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.
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_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?
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 (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 for those who claim to understand I2C.
After you have done all of that it might be a good idea to start soldering the AVR on your own boards.
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.
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.
I also remember we did a board for writing the program in the pic because it was too expensive in my country.
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.
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.
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
Nonsense. This device: http://nanthealth.com/vitality/, which was a "big deal" to telemedicine folks (and is still a good product, please somebody reproduce it for cheap), and resulted in a MASSIVE exit for the people who founded it, was built around an atmega328p.
I would be good money that it was prototyped on an arduino.
This: https://www.industrialshields.com/ is based on an arduino. Like an actual, blue, retail arduino.
I've personally built one-offs for advertising installations (products for sure, but probably not exactly what you meant), that are full of arduinos.
>doesn't let you make progress beyond "oh look, I lit up an LED!".
This is wrong enough to make me think that you either don't actually know what a microcontroller is, or are being deliberately misleading.
The RPI is a useful production device in some niche applications, thanks to the Compute Module. There are a lot of circumstances where you need a powerful SoC, but you don't have the time or the budget to deal with a dense BGA; the RPI Compute Module replaces a lot of difficult design work with a standard SODIMM slot. Obviously it's no use in a mass-market consumer product, but it makes a ton of sense for a small-volume industrial device.
I absolutely agree that an Arduino shouldn't be the core of a consumer electronics device, but for anyone not familiar enough with the field to know that already, it's probably at about the right level.
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.
Do you need wifi: Wemos D1 mini
Do you need bluetooth low energy: light blue bean
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 :).
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
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...)
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
I'm interested in synths (and teensies) and would be interested to see it.
If they don't have RAM and ROM on the actual chip, and need an operating system for you to do anything with them, then they're microprocessors.
The SoC cost is not a way to differentiate them either, one of our current designs uses an 8-bit microcontroller than costs more than the Pi Zero!
You can easily spend around $10 on a single filter (ex: 8-pole Filter... such as https://www.digikey.com/product-detail/en/linear-technology/...). If you need an 8-pole elliptical filter, you just go out and buy one, amirite?
The "production" competitor to the Raspberry Pi Zero is honestly something like... the Octavo Systems OSD3358. At $50, you may wonder why this device is superior... but it has integrated RAM, Open Documentation, the features that are necessary for microcontroller work (ADC, DAC, PRU/Programmable Realtime Units, RTC, on-board LDO Regulator, on-board Lithium-Ion cell balancer and Lithium-Ion manager, support for TWO Crystal Oscillators, 114 GPIO, 6 UARTs).
http://www.digikey.com/product-detail/en/octavo-systems-llc/...
Its all about your REQUIREMENTs. The Raspberry Pi Zero barely does anything aside from computer things (Ex: WiFi, USB).
Don't get me wrong, the Raspberry Pi Zero is a wonderful computer. But microcontrollers are things that can work with Thermocouples, control Active Filters, and control motors. In contrast, the Raspberry Pi burns itself out if you put an LED on its weak GPIO pins... and even "Realtime" Linux can't save you from the micro-second delay associated with the GPIO pin hardware.
The OSD3358 is definitely the right approach, since putting high-speed impedance/timing matched DDR lines on a board to make it work right with a modern 1GHz+ CPU is a much higher level of difficulty. Plus you will also need to make your PCB 8 or 10 layers to shield the interference which increases the cost.
I thought package-on-package (like the AM335x's predecessor, the OMAP) was the way to go, but I'm starting to like the monolithic package better.
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.
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.
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.
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.
And of course the RISC-V HiFive1, though it's still very new and in sampling quantities.
There are some rough edges, but its already very useable, especially since the new silicon came out. Got anything specific in mind?
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?