What's the state of micrcontrollers these days?
cgracey
Posts: 14,155
Can any of you guys relate your recent experiences programming various microcontrollers, aside from Propellers?
- What's good/effective about them?
- What's bad/frustrating about them?
- What directions have they trended in?
- Are things generally opening up or closing tighter?
- Is there an increasing sense of liberation using modern microcontrollers, or do you sense a long arm of increasing control?
- Are they fun?
I've been out of the loop for so long I really don't know much, anymore.
I feel a little unsure about things, now that the Prop2 is nearly done.
I'm not asking for encouragement, here. I'm just trying to assess where we are at in the big picture.
- What's good/effective about them?
- What's bad/frustrating about them?
- What directions have they trended in?
- Are things generally opening up or closing tighter?
- Is there an increasing sense of liberation using modern microcontrollers, or do you sense a long arm of increasing control?
- Are they fun?
I've been out of the loop for so long I really don't know much, anymore.
I feel a little unsure about things, now that the Prop2 is nearly done.
I'm not asking for encouragement, here. I'm just trying to assess where we are at in the big picture.
Comments
We get quite a few dev kits in here and spend 1 hour evaluating / trying to get them up and running and strutting their stuff. What we glean in that first hour is often reflected in how the longer term project goes.
Universal pin functionality is something valuable and distinct. Even more so, with analog functions.
If you look at the forums, pretty much every vendor struggles with Software quirks, and users bleat about the bloat of the Eclipse or whatever IDE was chosen.
Fuses cause a lot of headaches over in AVR land, and Microchip buying Atmel has spooked the cattle a little...
Smaller and cheaper, and also larger and more $$ - you can get good MCUs from `31c for a SiLabs EFM8BB1, up to $20+, for ARM monsters with 1M+ Flash and > 100 Pins.
intel have even (re)joined the Microcontroller fray again, after a rather long holiday, with a $2.53 32K Flash device
Digikey shows 61109 (!) MCUs,
Cheapest is EFM8BB10F2G-A-QFN20 at ~32c/1k, for ADC,UART,i2c,SPI,25MHz,256R,2kF
with SiLabs, Microchip, TI, Cypress, Atmel,ST all offering sub 40c parts, & Freescale and Renesas close behind.
Sorting from the BIG end,
Infineon parts can have 8MB of Flash 516LFBGA ~ $40,
Renesas show parts with 10MB RAM, 324FBGA, ~ $38
If we filter to a P2 matching 100 pins, 6102 show up
Sub ~$2 ones come from Toshiba, Atmel, Spansion, Silabs, NXP, with Toshiba winning Code/$ with 512kF,32kR @ $1.75
Fastest in 100 pins are Atmel 300MHz SAM07's 2MBF,385kBR at $9.75
ST, TI, Microchip have 200MHz level parts, in 100pins, all about $10
Software, as always, gets ever larger, fixes seem to take longer, but the SDKs have come down significantly.
Besides RaspPi Zero at the crazy $5, there are a lot of HW Debug included Eval Boards in the $10/$20/Sub$30 areas.
Not quite sure what control you mean ?
With cheap SDKs and free software, there is not much sense of any leash ?
Hehe, if it were too easy, it would be no fun
I think P2 is quite well placed, as it does not try to compete head-on with Vanilla MCUs, and certainly will appeal to those using larger ARM or ATOMs, who need something better at the Real-Time-Coal-Face.
eg a P2 will never displace a small EFM8BB1 / STM8 etc, but it could certainly talk to many of those.
Likewise, a P2 will never displace a RaspPi level ARM/Atom/Quark, running an OS, but it could certainly talk to those.
Some vendors do not even call their parts Microcontrollers - AnalogDevices have some ARM M4's, that appear in Digikey's
Embedded - DSP (Digital Signal Processors) section, with $10~$17 price points, up to 240MHz, 2MB flash, 176 pins.
The MZ series is a 32bit MIPs CPU with lots of RAM and FLASH.
http://blog.imgtec.com/mips-processors/microchip-upgrades-pic32mz-ef-family-to-mips-m-class-m5150-mcu
200MHz 512KB SRAM 2MB FLASH plus cache RAM too.
http://www.microchip.com/wwwproducts/en/PIC32MZ1024ECG100
$7.80/1K
I haven't seen any micros recently (other than ARM) that require external FLASH/EEPROM. It is a problem we have lived with because of the nice prop architecture. One of the original big attractors for the prop was lots of RAM (hub). But 32KB is miniscule these days.
Flash for code still compromises the overall MHz, and the new FTDI parts (8b & 32b) load Code-RAM from a Boot-flash area.
Anyway my biggest bugbear with most of the more complex ones is to do not only with the tools but also with the limitations of the I/O pin assignments, you can have this but you can't have that. You want this but you need to read 20 pages of the user manual just for that little peripheral, and get it right (don't forget the errata too). There are all kinds of unknowns and we don't have the luxury of spending weeks evaluating a product (and tools) to find out how great it is except for one little thing that breaks it.
So this gets me to the Prop, the tools are simple in that they are not unnecessarily complex but I suppose the one big salient feature of the Prop architecture that really stands out from the market is the flexibility of the I/O. I know I can assign any I/O pin and make it do what I want, even if I have to dedicate a cog or two to the job as that's what they are there for. P2/P3 of course has what I see as a peripheral per pin and still has 16 cogs sitting around twiddling their thumbs. But the other chips have one thing the P2/P3 hasn't achieved yet, because as you know we can click online and have them sitting on our bench the next day.
I've worked with a few more microcontrollers like those from STM and PIC32:
- What's good/effective about them?
They are feature-rich, some of them even contains FPU (Floating point unit) and a DAC for a very low price. On top of that, some higher end STM32s have SDRAM memory interfaces which you can turn it to a frame buffer if you have a TFT connected. The PIC32s on the other hand, has a DIP form factor for the lower end ones, but for the PIC32MZs they have a very huge pool of SRAM.
- What's bad/frustrating about them?
The IDE and the support packages. The STM32Cube works pretty well but there are a lot of bloat in between. Too many lines of code for simple things like GPIO. Oh well, they have a lot of flash for these processors... They have a seperate app for me to enable/disable peripherals and generate the code too, and that is what made it convenient.
For the PIC32, they decided to follow the path of STM32Cube by putting the Harmony inside. It's slightly better than the latter, but they have libraries which doesn't work at all, like the File System. What I liked about it is the GUI which I can select or disable the pins for a specific function.
Both of the IDE and support packages are extremely sluggish and difficult for beginners.
For the STM32, the documentation is pretty disorganized, and some "attention/important note" was written too small in the corner, causing readers to miss that bit of information. The examples are pretty lacking too, and flowcharts are mostly absent.
For the PIC (8/16/32) the app notes are abundant, and they are very clear in explaining peripherals and other things. I keep these app notes and read them regularly.
- What directions have they trended in?
I suspect it is more towards integration and simplification.
- Are things generally opening up or closing tighter?
I believe it's opening up. Some of the compilers are free for certain models of processors, example: Keil MDK5 - STM32 Cortex-M0. Future models of PIC32 probably include a graphics controller too.
- Is there an increasing sense of liberation using modern microcontrollers, or do you sense a long arm of increasing control?
It's more towards liberation. Again, they have included a lot of features inside (which was a luxury back then) nowadays that facilitates programming. However, this must be accompanied by more user documentations and app notes too. Newer microcontrollers with better features give less burden to the programmers, and allows focus on how to get the overall job done.
- Are they fun?
Yes - the high integration of microcontrollers has allowed programmers to put more focus on the programming aspects, and allow new ideas to be conceived without worrying so much of what is happening inside the microcontroller.
It seems the main area of improvement could be in the simplification of the development environments.
It also seems that silicon complexity is being hidden somewhat by GUI setup menus, which suggests that peripherals are not easily (re) configurable at runtime.
TI did not see these $1 ARM hitting them like this, as their MSP432 progress is slow and they should just bought Atmel
instead of letting Microchip do that (Microchip is not innovative they just buy companies lately)
I use IAR workbench as IDE and it's pretty good and the code it generates is tight,
I pretty much always look at resulting assembler code and I could not do it better by hand.
I don't use GUI like Grace to set things up, a simple macro I created converts "pin names" to real pins so they can be moved in later design.
https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/468000
Bluetooth SOC is the latest thing, BLE 4.2 with ARM. (bluetooth4.1+ can now do internet with IPV6)
NXP bought Freescale and continuing their BLE line, you get 512KB of flash and 128Kb of ram, DC-DC converter, Balun for around $3
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/w-series/kinetis-bluetooth-low-energy-wireless-mcu:KW31Z
Parallax seem to be on board with this, given the great number of command-line tools available on the Parallax Inc. GitHub account, but I want to voice the opinion anyway to be sure.
Whatever simplification is done to the tooling, please ensure all of the core functionality is still available at the command line. And where an existing interface already exists, please try to follow it. Then wrap those tools with however simple/easy of a tool you want. This is likely a little more work than tightly integrating the core tool (i.e.: compiler) with the development environment (i.e.: editor) but it makes a much wider audience happy.
I wholeheartedly understand wanting tools that are easier to use than Eclipse and other IDEs, but many of the resulting products (SimpleIDE, Arduino's IDE, etc) are downright painful for anyone familiar enough with a full IDE to utilize the features. And then of course there's the weirdos that enjoy a terminal text editor more than whatever "simple" tool comes out next.
That's part of the general dumbing-down of the Audience too.
Yes, if you want a quick guide (27 pages) on what is good/bad, take a look at a well-resourced companies new offering here:
http://www.intel.com/content/www/us/en/embedded/products/quark/mcu/system-studio-getting-started-guide.html
Pluses:
Use Eclipse, and FT232H (HS USB) for the Debug link, which helps with better step/refresh response.
Minuses:
Pages 17,19,23,24 say
Note: Average flashing times are approx. 40secs.
- wow, that 40s seems rather s-l-o-w for 32k max, one wonders what that FT232H is doing ??
and the Debug screen shots show a Terminal, but on page 8 is
1. Make sure all JTAG-Jumpers are set correctly.
2. Connect the USB cable to a host machine and also to USB power supply and JTAG over USB interface to power up the Intel® Quark™ Microcontroller Board.
3. Attach the UART-A pins to a FTDI cable, for serial output of the board.
So, yes, they have a high spec USB, but no COM port on board ?
It is common for Better Debug systems to include a VCP(UART) link, on the same Debug connector.
FPGA vendors do this using FT2232H, one side for JTAG, other side for UART.
I would rather intel spent the extra $1, increased the kit price, and got it into a single-unit.
Screen shots on
Page 17, Figure 8. Running a Project and
Page 20 Figure 9. Opening a Serial View and
Page 22 Figure 10. Accessing SOC Registers
all show typical Debug Views.
Note the Register View, DisAsm View, and Source code highlight/ breakpoints, and Variable Watch windows.
That's what users expect on their better MCU tools.
Unusual steps:
Page 23 15.0 Updating ROM Image
Note: This procedure is only required if it is the first time the board is being used.
That suggests they have Debug Helpers in the OTP ROM ? - because that is OTP, no mention of what happens when firmware gets out of phase with PC side ?
Given that just about every uC coming onto the market now has internal debugging circuitry, either JTAG or proprietary, and associated debugging 'pods' for around the $30-$50 mark, how will the P2 stack up against them?
Which means I now use such devices as 'intelligent logic' to abstract the hardware into functional blocks. I no longer have a pile of switches connected as IO to my main processor; instead I have those same switches connected to a small sub $1 chip which deals with all the nitty-gritty and sends the main uC pre-formatted data.
In a way, I'm using multi-core designs but spreading those cores all over the PCB.
Some of them, yes. It's certainly been fun returning to my first uC core and seeing how far it has come.
We have been clamouring for ifdef compilation and macros for at least 8 years. Two guys did the ifdef compilation as some of us still use this (bst and homespun). We now have OpenSpin that does ifdef compilation but not @@@, and no macros. But who uses it? We don't have a simple PropTool equivalent with a better terminal mode and Roy's OpenSpin.
It is the Propeller Architecture that sucked me in. The pasm code is simple and regular for when it is needed. Spin is fine for slow top level work. PropTool is simple to use (with just those few extras required). Multiple cores (cogs) make my code easy to write as I can debug objects easily without interference from other code running in other cogs. I/O pins are extremely flexible. Cores (cogs) can do all sorts of smart peripherals. This means I only need to have a single chip on my shelf, although I wish it were more
Another of the big features was this great forum. Unfortunately, for whatever reason, this is no longer really true anymore. Many of the regulars have left. I have no idea where they went, otherwise I might join them
One point that is missing in the prop is the ability to run a big program in a single core. I guess this may resolve itself with P2 and hubexec but I still don't share the contention that every core (cog) must be equal.
Indeed, this is my main use for this itty-bitty micros, as I/O and as A/D. They certainly are a lot cheaper and more versatile than the dedicated chips for those functions over SPI and I2C. In fact sometimes those dedicated chips won't cut it, I had to do A/D over an isolation barrier and there is no easy way to do this with I2C or SPI but easy enough when you set it up to transmit asynch and all processed and filtered already.
I wonder about them, too. I suppose the ongoing development got frustrating and wasn't so interesting, after a while. I, too, wonder what they are doing and if a real Prop2 would bring them back.
I'm glad you guys are still around, though!
A lot has been going on in recent years.
I'm pretty much out of the micro-controller scene now a days. I just can't stomach the thought of dealing with yet another 1000 page manual describing all the registers and pins of whatever device. Professionally I don't have a need to do that any more. But otherwise...
The Raspberry Pi arrived and in four years has shipped nearly ten million units. It's not a micro-controller but it can do a lot of what people traditionally used MCU's for. Designed as an educational device it has found use in many commercial uses. It comes with Linux and just about any programming language you want.
At the small end of the scale there is the Espruino. A tiny STM32F4 micro-controller board with built in Javascript. Sounds crazy but it is amazingly easy to use, no IDE required. It is capable of very low power consumption. http://www.espruino.com/
Or if you hate JS and Python is your thing there is the Micro Python https://micropython.org/
Today of course the Internet Of things is all the rage. So the tiny ESP8266 WIFI adapter, programmable in Lua a language like JS, is everywhere.
None of these are actual chips of course, rather chip + board + software, all packaged and easy to use, like a Prop with Spin.
Things have been opening up. One almost never needs some proprietary, single, platform, clunky, IDE anymore.
What I worry about closing up is this IoT business. Big players are vying to grab that potentially huge market. They want to get us hooked on their "cloud" services, with their protocols and deployment methods.
The epitome of this is Microsoft's "Azure Certified for IoT scheme". https://azure.microsoft.com/en-us/marketplace/certified-iot-program/ From that page:
"we are focusing on hardware partners (OEM) that have an IoT device. If an OEM wants to ensure their device integrates with Azure IoT Suite and Azure IoT Hub, the Azure Certified for IoT program is the right course for them
The idea being that a consumer will look for the MS IoT Certified Logo on any products they buy. Getting that certification for your hardware will no doubt involve locking yourself into MS protocols and software stack.
This all meant I ended up on Linux (using Wine for the game) and I stopped experimenting with QNX. It was never any specific "I don't want to do that any more", I would probably pick it up again if something enticed me back.
Good to see you, Heater!
Maybe things are trending such that single chips aren't looked at as solutions as much as board-level products are, nowadays. Maybe the new people using electronics are more about hooking up wires than making PCB's from scratch. One thing that kind of bugs me about board-level stuff is that it seems so transitory. As I get older, life seems more transitory, anyway.
I was thinking today that a Prop2 chip-resident editor, compiler, and debugger tool may take 32KB, which is about 1/30,000th of the size of the standard IDEs nowadays. I like the idea of getting right to work and not being bogged down by PC-level development software+OS issues. I wonder if that kind of thing would matter to many people. I suppose they just go with the current development paradigm and don't really question it because it's pretty much how everything else works. That Espruino sounds pretty clean.
In the other hand, I never had any bad experiences with the Prop Tool or SimpleIDE. Both of these are simple to use, configurable and to the point. Plus, SimpleIDE is Open Source, which I favor, because it will be a plus when someone tries to build my projects. I normally tend to abandon closed software solutions if I can, as these are never of much use for my projects.
To professional developers? No.
They will want their source code residing on a sever with version control taking care of backups and rollbacks.
Good point.
Our prime board (revision A) uses a infineon XMC ARM cortex 0 as a companion chip emulation eeprom. It turned out, you can only do, what the designers imagined. And that was hidden in a verbose not carefully edited 800 page document. While the prop will have a short description and the user has all the freedom to figure out what can be done, what the designer never imagined. (And that is a lot, if you imagine what Chip imagined).
So we placed another ARM on the board, only connected to power, to create firmware to support P1. But still there is no idea, how generic firmware has to be made and so we are waiting to have time and ideas.
We know: the prop is unique and if the prop succeeds, no doubt there will be a next, shrinked generation which outperforms many other processors. We often discussed a killer application and the answer is pending.
As far as getting the chip into more commercial use, this probably wouldn't have much effect. (Although very useful in an offsite situation, With no or limited internet access (Think midnight in Chennai in a tire plant, for instance) it could be a project-saver!)
As hobby use goes, it could make for a standalone controller board in a PI-Lite kind of application, or even better as a PI add on.
Just plug it in and start developing. I would find it irresistible.
I'm just thinking about what kinds of things could help differentiate the Prop2, aside from the chip, itself.
Then ten years ago magical things started to happen. The Arduino arrived making the use of an MCU very easy.
Then came the idea of putting those tiny SMD micro-controllers and sensors and other chips onto break out boards and selling them to hobbyists. Enter people like Adafruit and Sparkfun and now millions of offerings from China on ebay.
People got the idea they could make their own weird and wonderful electronic thing, something that was not commercial produced, an artistic thing, a robotic thing, whatever. Electronics was a hobby again thanks to break out boards.
On the other hand, it has never been easier or cheaper to get a custom PCB made using the services of OSHPark and such, and free design tools. Nobody cares about IDE size on their PC now a days. RAM is dirt cheap and we have piles of it. It makes no sense to spend much effort on optimizing for size.
People do like getting right to work though. Having to install a different big clunky IDE for every job is a pain.
Enter WEB based IDEs. Like the Espruino, Micro-Python, mbed etc. All runs in the browser. Quick and simple. We can do that with a Spin "IDE" in the browser today.
So, sure perhaps have a compiler in the chip, but have the user interface in the browser. Everyone has one.
I actually backed the Espruino project on Kickstarter. We had already compiled a smaller, simpler version of it's JS engine and I think someone got it to run on a Prop with external RAM. Then came the offer that if the Espruino met it's target the new improved JS engine would be open sourced. So I backed it just to get the JS engine with a view to it one day running on the Prop 2.
Ensure that whatever dev tools there are run on the Pi without hassle.
There are 10 million Pi out there. It will be 12 or 14 million by the time the P2 arrives. I can't help thinking that attracting that huge user base of the young and curious is not a good idea. A Pi is great and all but not so much for fast real-time stuff. It needs the Prop to help.
Provide software for the Prop and the Pi that does useful stuff out of the box and can be used from Python, JS, C/C++ whatever language from the Pi users software, no special Prop development needed by them. A hook to get them
started.
As an example, the Pi cannot use a VGA display. A ready made VGA driving HAT would be welcomed by many. Being able to combine that with other functionality would be great.
The Pi side software should be able to mix and match ready made Propeller objects for various functionalities, compile them and load them to the Prop then make use of them via UART or SPI communication. All wrapped up in a C library, usable from Python or JS or whatever.