10 ms·

The Best and Worst Microcontroller SDKs

101 points by ducktective 6y ago

rahimiali 6y ago
I recently started using the ESP32 and its IDF sdk, and find it hits all the authors’s desiderata.
- sitzkrieg 6y ago
  I agree, this is a nice writeup but I was surprised there were not some other big players covered. ESP32, Microchip XC32, Ti CCS etc ..
- ampdepolymerase 6y ago
  I do wish Arduino would increase the scope of their supported features. As a platform abstraction layer, using the arduino.h C++ header provides an excellent embedded development experience and there is a large number of compatible libraries online. But the scope is very, very small and limited. For features like parallel IO however you often have to drop down to inline assembly/invoke platform sdk.
  - II2II 6y ago
    I have been using PlatformIO as of late, which has the option of selecting frameworks when the project is created. While that doesn't really solve the problem of having a universal abstraction layer, it does ease the burden of installing frameworks since it handles that automatically and it provides a more consistent development environment. As for that universal abstraction layer, I doubt that it is practical. There is too much variation across features offered by MCUs. Ultimately some features would end up unsupported on some products unless every vendor decided to put their weight behind it (and agree upon how everything should be implemented).
  - amelius 6y ago
    One problem I have with Arduino and such is that they sell their products as educational toys, and thus unsuitable to incorporate into any serious product.
    - imtringued 6y ago
      Arduinos are just a dev board. You can always take the underlying micrcontroller and design your own PCB.
      - 00deadbeef 6y ago
        You don’t even need to use it with Arduino hardware. At this point I think there are more people using the Arduino SDK with ESP devices.
- flqn 6y ago
  Agreed, the ESP32 ecosystem is a stellar example of what MCU vendors could offer.
  - sgtnoodle 6y ago
    When I used it for a hobby project, it was pretty gnarly. All I wanted to do was sample an ADC channel at 8Khz. The software triggered ADC proved to be fundamentally broken (it felt like a race condition in their lower level coprocessor), and I had to switch to I2S so that the ADC would be accessed by DMA. The documentation was basically non-existent and the most relevant code examples were an incoherent mess. I eventually got it to work barely well enough, after probably spending 16 hours on it. I'm still impressed with the wifi functionality. It's a cool chip, and I appreciate the company's willingness to support hobbiests. I wouldn't use their SDK as the reference for a particularly good vendor support package, though. On the other hand, maybe there are no good vendor support packages and ESP32 is one of the least worst?
    - elcritch 6y ago
      I've had similar experience with the ESP-IDF, with racey bugs in certain parts and broken i2c, etc. Though turns out most of those were due to their v4.1 branch being listed as stable (AFAICT) but it's actually pretty broken. Switched to v4.0 and everything works. Still it's open source and the dev's will respond to GitHub issues. Overall I'd say it's not too bad, or not so much worse than other chips. It seems every piece of embedded hardware will have quirks and the SDK's will have pain points. From what I gather and my limited experience, it's more a matter of how many and how severe. I prefer at least an open source SDK where it's possible to share patches with the broader community. From what I gather here and elsewhere the only other open source SDK's are for the Nordic chips. P.S. the esp32's ADC supposedly has terrible calibration issues.
      - sgtnoodle 6y ago
        I used the ESP32 to build a two lead ECG SD logger with real time viewing over wifi. I randomly had to get a pacemaker this year, and it's been very useful to self-diagnose device issues (such as why my heart rate was jumping back and forth between 50bpm and 100bpm!) The pacemaker generates 350uS 2V "capture pulses", and they're very easy to detect coming out of an analog ECG amplifier front end. The ESP32 would completely miss maybe 1 out of every 5 capture pulses until I switched to I2S. Now it reliably samples every single pulse. The data coming out is good enough to see what I need to see; qualitatively how my heart is beating. When using software triggered ADC conversions via an 8Khz timer interrupt, the racey issue would occur periodically for several milliseconds at a time. The ADC would act as if its input was disconnected and floating. With a changing input signal, the samples would read as a nearly constant voltage and completely miss blips that were well within the Nyquist frequency. Switching to I2S/DMA seemed to work around that issue. Even with the ADC working reliably, the samples suffer from what I can only guess is horrendous differential non-linearity. The waveform really looks quite ugly, despite the ADC being driven by a very low impedance amplifier output. At least I can clean up the ECG plots with a low pass filter to make them pretty. The pacemaker pulse is a 350uS square wave, but the heart's natural impulses are significantly lower frequency.
- kps 6y ago
  The author's article only covers ARM Cortex-M4 SDKs; its title is a little over-broad.
- Rebelgecko 6y ago
  Are you using the IDF directly or via something like PlatformIO? I've been using PIO a lot, but I wonder if there's advantages to just using the IDF on its own
  - rahimiali 6y ago
    I’m invoking idf.py directly. I edit my code in vim.
rektide 6y ago
brilliant write up. I really hope this gives way ylpre developers writing about their development experience, their quality of life with their tools, discussing what factors effect them. especially embedded but cross-environment compares elsewhere could be neat too.
ohazi 6y ago
> Cypress PSoC Creator, Maxim DARWIN 0/10 Ha. I inherited a project that used a PSoC module and had to set up and keep a Windows box around for a year until I could get that damned thing designed out of the next revision (replaced with a Nordic). Everything has to be done in a buggy, bloated, custom GUI tool, even configuring peripherals, even flashing. Nothing is scriptable. Their chip might have been perfectly fine, but working with their software was torture. They treat their customers like idiots -- you have to pull teeth to get something as basic as a memory map so that you can fix things when they inevitably don't work. Completely agree with the 0/10 assessment. I'd sooner quit my job than use one of these chips again. Edit: Another comment suggests that Cypress has a new, less insane software tool now, that's cross platform and can work with Makefiles. shrug
- duskwuff 6y ago
  The PSoC hardware isn't fully documented, either. Some critical parts of the UDB architecture (which is arguably the most interesting part of the product!) aren't explained in the register documentation -- for example, the registers which control routing are described as "RAM configuration bytes for channel", with no further explanation. If you're using Cypress's IDE, it can generate the required configuration data for you. But if you want to take off on your own, you're out of luck.
- lmilcin 6y ago
  I keep my toolchains for embedded development on Linux VMs. Basically: one project === one VM. I know I cane bring it up after couple of years and be able to fix a bug or add a feature.
jmgao 6y ago
I've been using Zephyr with Nordic chips for all of my personal projects lately, and it's been fantastic. (Zephyr's the upstream for the mentioned "equally excellent nRF-Connect-SDK") Unlike most of the other options, Zephyr's run as an actual open source project and not just as a closed box you can peer into every once in a while, and Nordic seem to have gone all in on it.
- sunsetSamurai 6y ago
  Hi, what type of personal projects are you working on? I started learning c recently and I want to learn embedded development, but I don't know where to start or how.
  - jmgao 6y ago
    My main one right now is a low latency game controller firmware: https://github.com/passinglink/passinglink https://github.com/passinglink/passinglink I think the most important thing to do figure out what you actually want to make. Any microcontroller SDKs are going to be at least usable for most things.
  - ls65536 6y ago
    Not OP, but one thing I found useful when starting out with embedded development was to just get a simple "hello world" sort of program running on bare metal and printing over serial, and to try to understand what was happening in various places that made my program work (code execution on the microcontroller, sending of data over the serial lines, and so on). Even a straightforward Arduino-based environment [0] is usually enough to get started and begin poking around to see what else is possible! For myself, after getting something simple like the above working, it was a gateway to much more experimentation of further possibilities, and ultimately I ended up making an interactive shell [1][2] with some built-in utilities and text games I also wrote that runs on a variety of AVR microcontrollers (those very same Arduino boards I had when starting out). [0] https://www.arduino.cc/ https://www.arduino.cc/ [1] https://community.atmel.com/projects/avrsysh-systemshell-some-built-utilities-and-some-games https://community.atmel.com/projects/avrsysh-systemshell-som... [2] https://github.com/ls4096/avrsysh https://github.com/ls4096/avrsysh
AlphaSite 6y ago
What about the mbed sdk? I’m curious how it compares to these.
- rohfle 6y ago
  I found it easier to work with mbed than STM32Cube for USB and ethernet. I found it really hard to understand the autogenerated STM32Cube with USER CODE BEGIN lines and couldn't make sense of non-working examples for Ethernet and USB for my target board. Mbed was more of an abstraction layer - I saw a lot of similarities to what STM32Cube does underneath. The process of adding target platforms has a bit of a steep learning curve. I copied a target with the same MCU and worked from there. But once the target platform is implemented writing code is pretty enjoyable. See https://github.com/ARMmbed/mbed-os/pull/11648/files https://github.com/ARMmbed/mbed-os/pull/11648/files for the example of adding a target See https://rohfle.gitlab.io/posts/2019-10-19-olimex-stm32e407-tutorial-mbed-os/ https://rohfle.gitlab.io/posts/2019-10-19-olimex-stm32e407-t... for example ethernet code
bfrog 6y ago
I really like the nxp sdks, what wasn't rated here is how well written the sdks and peripheral drivers are. My experience with nxp was really good. ST SDK is good as well but has these two different levels to it that add confusion to creating software.
amelius 6y ago
Perhaps we could make a similar list for FPGAs. Or for more complicated systems like Nvidia Jetson.
- deleted 6y ago
  [deleted]
- user5994461 6y ago
  If I did that for Xilinx (Vivado) this wouldn't be a comparison but a long rant ^^ There's only two manufacturers of FPGA, Xilinx and Altera, I don't imagine the other one is any better. More than the tooling, there's a very steep learning curve, it's a professional tool for professional EE/SW, I don't think it's something you can jump into easily like you could jump into an arduino example or a python shell. Literally none of the things mentioned in this article would be applicable because HDL (hardware design) is not software development.
  - vvanders 6y ago
    It's a litte out of date('13) but fpga4fun has a comparison[1]. [1] https://www.fpga4fun.com/FPGAsoftware1.html https://www.fpga4fun.com/FPGAsoftware1.html
    - user5994461 6y ago
      Sadly the article is obsolete. It's talking about Xilinx ISE, the previous IDE from Xilinx that was retired in 2013. It was already end of life when the article was written.
  - nereye 6y ago
    Arguably, Xilinx and Altera are no longer independent manufacturers, having been bought by AMD and Intel. Whilst those are the major players, there are independent FPGA manufacturers other than those two, Lattice (notable for having an open source toolset) and the PolarFire family from Microsemi, plus Gowin from China.
    - 6y ago
user5994461 6y ago
I'm surprised from this checklist because this checked almost none of what I would be looking for in a as a professional embedded developer. What I would like to see: How easy to push the software from the computer to the microcontroller? Preferably you should be able to push the firmware over USB or something like that in a few seconds. Don't mind whether that's a command line tool or a button in the IDE but there has to be something and it MUST work. Is the tool friendly to source control? I had very bad experiences with embedded tools automatically creating hundreds of files all over the project and editing them on every build, causing a massive headache to store the project in source control. Note that software developers expect their development tools to support source control natively but I have no illusion of that happening in embedded IDE. How easy to make a simple software and how is the documentation? For reference the basic in EE is to blink a LED, the microcontroller should provide API with documentation and examples to do that (and much more). It's shocking how many MCU have zero doc and the little there is doesn't work. Personal note: It's funny the author wants to compile a hello world because that's not a thing in embedded, there's no screen on a microcontroller so printf("hello world") does nothing. Last. I'd like to know about debug capabilities? Can you connect the computer to the MCU and debug directly on the device? Ideally there should be a full debugger including breakpoint support and step by step execution and displaying all local variables. The debugger should also be able to show debug output from the microcontroller (output from printf or equivalent).
- ls65536 6y ago
  > there's no screen on a microcontroller so printf("hello world") does nothing Unless printf() is ultimately hooked up to some text-capable interface, like a UART with a terminal on the other end. :) Although I will agree that in general this isn't a typical use case for embedded microcontrollers in the real world.
  - monocasa 6y ago
    I'd say a lot of UARTs are running debug consoles, but you don't want that for a hello world typically because it can be pretty complex to initialize when the whole point of a hello world is to get something happening with the minimum of setup. The UART will have pin config, the clock tree, and the UART itself that all need to be initialized, and can be finicky when setup incorrectly (particularly the clock tree). Blinking an LED with a busy wait loop square wave is way simpler and gives you externally visible code execution with less that can go wrong than printing to the UART.
d-sc 6y ago
Can personally voice for the Nordic series chips. Their Sdk has allowed for some of the most pleasant coding I have ever done.
snvzz 6y ago
Article has good points, but for some reason does choose to ignore the alternative, open SDKs many µC families have available. The likes of avr-libc, energia, stm32-base, stm32duino or libopencm3.
las_balas_tres 6y ago
Microchips MplabX is maybe not the worst I have used but what irritates me about it is you have to purchase a license for the c compiler to get it to produce optimized code. Even though it is a gcc based compiler. You would think a hardware company like them would give away the development tools to encourage people to use their hardware. The funny thing is, is that it's relatively simple to bypass their license check
- slezyr 6y ago
  > The funny thing is, is that it's relatively simple to bypass their license check That's a business decision. You don't need a secure DRM for products that are intended for other companies and it's waste of money to make one. No sane company will pirate it anyway.
jbirer 6y ago
The best SDK for me is no SDK. I have been playing around with these new Sipeed Longan Nano things that have an LCD display attached and you just stick it in the USB port. I have been doing mostly low level work writing my own LCD and interrupt handler routines and it's been good so far. There's of course a small amount of work to be done but I don't have to deal with the things mentioned in the article.
00deadbeef 6y ago
No mention of ESP8266/ESP32?
rapjr9 6y ago
I used Nordic SDK's for years and didn't like them. There were many problems: - They released new versions often, and they were tied to new versions of the hardware. So you HAD to upgrade your SDK to use the new hardware. And they would drop support for the old hardware so if you wanted to be able to buy chips you had to upgrade. - They changed the API's often which broke all my software. Not little changes either but major ones. - They have lots of examples programs but the examples can't be combined. Want to use the interrupt handling example with the timer example? It doesn't work and you have to reverse engineer their code to find out why. - The example programs are not updated until long after the SDK changes. Because the changes in API's are large the examples often don't work. - Some features didn't work. We specifically chose the nRF51822 because it was supposed to be able to do simultaneous send and receive of BLE on multiple channels. Turns out that was marketing hype, the feature was experimental, and they didn't deliver a complete working example for years. - The debugger was useless. It worked for simple programs but this chip is a real time system and turning on the debugger broke the real time operations. Often it didn't even work at all, returning random values for variable contents. It's difficult to find out things like this when all you have is the spec sheets and forums to rely on. It's only when you get deep into the system you find them out. That's why developers often stick with one microcontroller forever; they know it inside out and all the tricks to making it work. I have a suspicion that some of the problems were intentional to get people to buy their development services. Microcontrollers themselves are still stuck in the dark ages. Atmel introduced some positive changes but most MCU's are still really primitive and difficult to use. A 5000 page manual? You've got to be kidding! And critical changes to the info in the manuals is published in errata sheets? Unusable! If I turn on a UART why doesn't it default to a standard configuration instead of making me set bits in registers? Perhaps it would increase cost slightly but there should be much more standardized automation in MCU's and more should be done in hardware rather than requiring software. There should be autonegotiation of communication protocols. MCU design hasn't changed much in decades and is ripe for disruption.

101 points by ducktective 6y ago

rahimiali 6y ago

I recently started using the ESP32 and its IDF sdk, and find it hits all the authors’s desiderata.

sitzkrieg 6y ago
I agree, this is a nice writeup but I was surprised there were not some other big players covered. ESP32, Microchip XC32, Ti CCS etc ..
ampdepolymerase 6y ago
I do wish Arduino would increase the scope of their supported features. As a platform abstraction layer, using the arduino.h C++ header provides an excellent embedded development experience and there is a large number of compatible libraries online. But the scope is very, very small and limited. For features like parallel IO however you often have to drop down to inline assembly/invoke platform sdk.
- II2II 6y ago
  I have been using PlatformIO as of late, which has the option of selecting frameworks when the project is created. While that doesn't really solve the problem of having a universal abstraction layer, it does ease the burden of installing frameworks since it handles that automatically and it provides a more consistent development environment. As for that universal abstraction layer, I doubt that it is practical. There is too much variation across features offered by MCUs. Ultimately some features would end up unsupported on some products unless every vendor decided to put their weight behind it (and agree upon how everything should be implemented).
- amelius 6y ago
  One problem I have with Arduino and such is that they sell their products as educational toys, and thus unsuitable to incorporate into any serious product.
  - imtringued 6y ago
    Arduinos are just a dev board. You can always take the underlying micrcontroller and design your own PCB.
    - 00deadbeef 6y ago
      You don’t even need to use it with Arduino hardware. At this point I think there are more people using the Arduino SDK with ESP devices.
flqn 6y ago
Agreed, the ESP32 ecosystem is a stellar example of what MCU vendors could offer.
- sgtnoodle 6y ago
  When I used it for a hobby project, it was pretty gnarly. All I wanted to do was sample an ADC channel at 8Khz. The software triggered ADC proved to be fundamentally broken (it felt like a race condition in their lower level coprocessor), and I had to switch to I2S so that the ADC would be accessed by DMA. The documentation was basically non-existent and the most relevant code examples were an incoherent mess. I eventually got it to work barely well enough, after probably spending 16 hours on it. I'm still impressed with the wifi functionality. It's a cool chip, and I appreciate the company's willingness to support hobbiests. I wouldn't use their SDK as the reference for a particularly good vendor support package, though. On the other hand, maybe there are no good vendor support packages and ESP32 is one of the least worst?
  - elcritch 6y ago
    I've had similar experience with the ESP-IDF, with racey bugs in certain parts and broken i2c, etc. Though turns out most of those were due to their v4.1 branch being listed as stable (AFAICT) but it's actually pretty broken. Switched to v4.0 and everything works. Still it's open source and the dev's will respond to GitHub issues. Overall I'd say it's not too bad, or not so much worse than other chips. It seems every piece of embedded hardware will have quirks and the SDK's will have pain points. From what I gather and my limited experience, it's more a matter of how many and how severe. I prefer at least an open source SDK where it's possible to share patches with the broader community. From what I gather here and elsewhere the only other open source SDK's are for the Nordic chips. P.S. the esp32's ADC supposedly has terrible calibration issues.
    - sgtnoodle 6y ago
      I used the ESP32 to build a two lead ECG SD logger with real time viewing over wifi. I randomly had to get a pacemaker this year, and it's been very useful to self-diagnose device issues (such as why my heart rate was jumping back and forth between 50bpm and 100bpm!) The pacemaker generates 350uS 2V "capture pulses", and they're very easy to detect coming out of an analog ECG amplifier front end. The ESP32 would completely miss maybe 1 out of every 5 capture pulses until I switched to I2S. Now it reliably samples every single pulse. The data coming out is good enough to see what I need to see; qualitatively how my heart is beating. When using software triggered ADC conversions via an 8Khz timer interrupt, the racey issue would occur periodically for several milliseconds at a time. The ADC would act as if its input was disconnected and floating. With a changing input signal, the samples would read as a nearly constant voltage and completely miss blips that were well within the Nyquist frequency. Switching to I2S/DMA seemed to work around that issue. Even with the ADC working reliably, the samples suffer from what I can only guess is horrendous differential non-linearity. The waveform really looks quite ugly, despite the ADC being driven by a very low impedance amplifier output. At least I can clean up the ECG plots with a low pass filter to make them pretty. The pacemaker pulse is a 350uS square wave, but the heart's natural impulses are significantly lower frequency.
kps 6y ago
The author's article only covers ARM Cortex-M4 SDKs; its title is a little over-broad.
Rebelgecko 6y ago
Are you using the IDF directly or via something like PlatformIO? I've been using PIO a lot, but I wonder if there's advantages to just using the IDF on its own
- rahimiali 6y ago
  I’m invoking idf.py directly. I edit my code in vim.

rektide 6y ago

brilliant write up. I really hope this gives way ylpre developers writing about their development experience, their quality of life with their tools, discussing what factors effect them. especially embedded but cross-environment compares elsewhere could be neat too.

ohazi 6y ago

> Cypress PSoC Creator, Maxim DARWIN 0/10 Ha. I inherited a project that used a PSoC module and had to set up and keep a Windows box around for a year until I could get that damned thing designed out of the next revision (replaced with a Nordic). Everything has to be done in a buggy, bloated, custom GUI tool, even configuring peripherals, even flashing. Nothing is scriptable. Their chip might have been perfectly fine, but working with their software was torture. They treat their customers like idiots -- you have to pull teeth to get something as basic as a memory map so that you can fix things when they inevitably don't work. Completely agree with the 0/10 assessment. I'd sooner quit my job than use one of these chips again. Edit: Another comment suggests that Cypress has a new, less insane software tool now, that's cross platform and can work with Makefiles. shrug

duskwuff 6y ago
The PSoC hardware isn't fully documented, either. Some critical parts of the UDB architecture (which is arguably the most interesting part of the product!) aren't explained in the register documentation -- for example, the registers which control routing are described as "RAM configuration bytes for channel", with no further explanation. If you're using Cypress's IDE, it can generate the required configuration data for you. But if you want to take off on your own, you're out of luck.
lmilcin 6y ago
I keep my toolchains for embedded development on Linux VMs. Basically: one project === one VM. I know I cane bring it up after couple of years and be able to fix a bug or add a feature.

jmgao 6y ago

I've been using Zephyr with Nordic chips for all of my personal projects lately, and it's been fantastic. (Zephyr's the upstream for the mentioned "equally excellent nRF-Connect-SDK") Unlike most of the other options, Zephyr's run as an actual open source project and not just as a closed box you can peer into every once in a while, and Nordic seem to have gone all in on it.

sunsetSamurai 6y ago
Hi, what type of personal projects are you working on? I started learning c recently and I want to learn embedded development, but I don't know where to start or how.
- jmgao 6y ago
  My main one right now is a low latency game controller firmware: https://github.com/passinglink/passinglink https://github.com/passinglink/passinglink I think the most important thing to do figure out what you actually want to make. Any microcontroller SDKs are going to be at least usable for most things.
- ls65536 6y ago
  Not OP, but one thing I found useful when starting out with embedded development was to just get a simple "hello world" sort of program running on bare metal and printing over serial, and to try to understand what was happening in various places that made my program work (code execution on the microcontroller, sending of data over the serial lines, and so on). Even a straightforward Arduino-based environment [0] is usually enough to get started and begin poking around to see what else is possible! For myself, after getting something simple like the above working, it was a gateway to much more experimentation of further possibilities, and ultimately I ended up making an interactive shell [1][2] with some built-in utilities and text games I also wrote that runs on a variety of AVR microcontrollers (those very same Arduino boards I had when starting out). [0] https://www.arduino.cc/ https://www.arduino.cc/ [1] https://community.atmel.com/projects/avrsysh-systemshell-some-built-utilities-and-some-games https://community.atmel.com/projects/avrsysh-systemshell-som... [2] https://github.com/ls4096/avrsysh https://github.com/ls4096/avrsysh

AlphaSite 6y ago

What about the mbed sdk? I’m curious how it compares to these.

rohfle 6y ago
I found it easier to work with mbed than STM32Cube for USB and ethernet. I found it really hard to understand the autogenerated STM32Cube with USER CODE BEGIN lines and couldn't make sense of non-working examples for Ethernet and USB for my target board. Mbed was more of an abstraction layer - I saw a lot of similarities to what STM32Cube does underneath. The process of adding target platforms has a bit of a steep learning curve. I copied a target with the same MCU and worked from there. But once the target platform is implemented writing code is pretty enjoyable. See https://github.com/ARMmbed/mbed-os/pull/11648/files https://github.com/ARMmbed/mbed-os/pull/11648/files for the example of adding a target See https://rohfle.gitlab.io/posts/2019-10-19-olimex-stm32e407-tutorial-mbed-os/ https://rohfle.gitlab.io/posts/2019-10-19-olimex-stm32e407-t... for example ethernet code

bfrog 6y ago

I really like the nxp sdks, what wasn't rated here is how well written the sdks and peripheral drivers are. My experience with nxp was really good. ST SDK is good as well but has these two different levels to it that add confusion to creating software.

amelius 6y ago

Perhaps we could make a similar list for FPGAs. Or for more complicated systems like Nvidia Jetson.

deleted 6y ago
[deleted]
user5994461 6y ago
If I did that for Xilinx (Vivado) this wouldn't be a comparison but a long rant ^^ There's only two manufacturers of FPGA, Xilinx and Altera, I don't imagine the other one is any better. More than the tooling, there's a very steep learning curve, it's a professional tool for professional EE/SW, I don't think it's something you can jump into easily like you could jump into an arduino example or a python shell. Literally none of the things mentioned in this article would be applicable because HDL (hardware design) is not software development.
- vvanders 6y ago
  It's a litte out of date('13) but fpga4fun has a comparison[1]. [1] https://www.fpga4fun.com/FPGAsoftware1.html https://www.fpga4fun.com/FPGAsoftware1.html
  - user5994461 6y ago
    Sadly the article is obsolete. It's talking about Xilinx ISE, the previous IDE from Xilinx that was retired in 2013. It was already end of life when the article was written.
- nereye 6y ago
  Arguably, Xilinx and Altera are no longer independent manufacturers, having been bought by AMD and Intel. Whilst those are the major players, there are independent FPGA manufacturers other than those two, Lattice (notable for having an open source toolset) and the PolarFire family from Microsemi, plus Gowin from China.
  - 6y ago

user5994461 6y ago

I'm surprised from this checklist because this checked almost none of what I would be looking for in a as a professional embedded developer. What I would like to see: How easy to push the software from the computer to the microcontroller? Preferably you should be able to push the firmware over USB or something like that in a few seconds. Don't mind whether that's a command line tool or a button in the IDE but there has to be something and it MUST work. Is the tool friendly to source control? I had very bad experiences with embedded tools automatically creating hundreds of files all over the project and editing them on every build, causing a massive headache to store the project in source control. Note that software developers expect their development tools to support source control natively but I have no illusion of that happening in embedded IDE. How easy to make a simple software and how is the documentation? For reference the basic in EE is to blink a LED, the microcontroller should provide API with documentation and examples to do that (and much more). It's shocking how many MCU have zero doc and the little there is doesn't work. Personal note: It's funny the author wants to compile a hello world because that's not a thing in embedded, there's no screen on a microcontroller so printf("hello world") does nothing. Last. I'd like to know about debug capabilities? Can you connect the computer to the MCU and debug directly on the device? Ideally there should be a full debugger including breakpoint support and step by step execution and displaying all local variables. The debugger should also be able to show debug output from the microcontroller (output from printf or equivalent).

ls65536 6y ago
> there's no screen on a microcontroller so printf("hello world") does nothing Unless printf() is ultimately hooked up to some text-capable interface, like a UART with a terminal on the other end. :) Although I will agree that in general this isn't a typical use case for embedded microcontrollers in the real world.
- monocasa 6y ago
  I'd say a lot of UARTs are running debug consoles, but you don't want that for a hello world typically because it can be pretty complex to initialize when the whole point of a hello world is to get something happening with the minimum of setup. The UART will have pin config, the clock tree, and the UART itself that all need to be initialized, and can be finicky when setup incorrectly (particularly the clock tree). Blinking an LED with a busy wait loop square wave is way simpler and gives you externally visible code execution with less that can go wrong than printing to the UART.

d-sc 6y ago

Can personally voice for the Nordic series chips. Their Sdk has allowed for some of the most pleasant coding I have ever done.

snvzz 6y ago

Article has good points, but for some reason does choose to ignore the alternative, open SDKs many µC families have available. The likes of avr-libc, energia, stm32-base, stm32duino or libopencm3.

las_balas_tres 6y ago

Microchips MplabX is maybe not the worst I have used but what irritates me about it is you have to purchase a license for the c compiler to get it to produce optimized code. Even though it is a gcc based compiler. You would think a hardware company like them would give away the development tools to encourage people to use their hardware. The funny thing is, is that it's relatively simple to bypass their license check

slezyr 6y ago
> The funny thing is, is that it's relatively simple to bypass their license check That's a business decision. You don't need a secure DRM for products that are intended for other companies and it's waste of money to make one. No sane company will pirate it anyway.

jbirer 6y ago

The best SDK for me is no SDK. I have been playing around with these new Sipeed Longan Nano things that have an LCD display attached and you just stick it in the USB port. I have been doing mostly low level work writing my own LCD and interrupt handler routines and it's been good so far. There's of course a small amount of work to be done but I don't have to deal with the things mentioned in the article.

00deadbeef 6y ago

No mention of ESP8266/ESP32?

rapjr9 6y ago

I used Nordic SDK's for years and didn't like them. There were many problems: - They released new versions often, and they were tied to new versions of the hardware. So you HAD to upgrade your SDK to use the new hardware. And they would drop support for the old hardware so if you wanted to be able to buy chips you had to upgrade. - They changed the API's often which broke all my software. Not little changes either but major ones. - They have lots of examples programs but the examples can't be combined. Want to use the interrupt handling example with the timer example? It doesn't work and you have to reverse engineer their code to find out why. - The example programs are not updated until long after the SDK changes. Because the changes in API's are large the examples often don't work. - Some features didn't work. We specifically chose the nRF51822 because it was supposed to be able to do simultaneous send and receive of BLE on multiple channels. Turns out that was marketing hype, the feature was experimental, and they didn't deliver a complete working example for years. - The debugger was useless. It worked for simple programs but this chip is a real time system and turning on the debugger broke the real time operations. Often it didn't even work at all, returning random values for variable contents. It's difficult to find out things like this when all you have is the spec sheets and forums to rely on. It's only when you get deep into the system you find them out. That's why developers often stick with one microcontroller forever; they know it inside out and all the tricks to making it work. I have a suspicion that some of the problems were intentional to get people to buy their development services. Microcontrollers themselves are still stuck in the dark ages. Atmel introduced some positive changes but most MCU's are still really primitive and difficult to use. A 5000 page manual? You've got to be kidding! And critical changes to the info in the manuals is published in errata sheets? Unusable! If I turn on a UART why doesn't it default to a standard configuration instead of making me set bits in registers? Perhaps it would increase cost slightly but there should be much more standardized automation in MCU's and more should be done in hardware rather than requiring software. There should be autonegotiation of communication protocols. MCU design hasn't changed much in decades and is ripe for disruption.