I really like Micro Python and have been using it for commercial products recently. It is a Python emulator that is totally independent of CPython, but to the programmer you hardly notice. I was very skeptical at first, fully expecting a very resource heavy interpreted language experience but it is rather efficient all things considered.
If you get into a performance bind, you can use inline C with much more direct access to the hardware system. So far, I have not needed to do that but rather glad the option is there if I need it.
I am looking into this. The fact it is running on an ARM Cortex M4 aroused my interest. If I run into any time critical functionality that needs the speed of C I can always create a library and expose it to python.
I am going to order one of their development setups. I love how cheap embedded development has gotten. It used to be ridiculously expensive to do anything in this world, now it is virtually free.
If you are looking for an excellent, inexpensive C arm development environment that is not tied one one particular manufacturer's chips, I recommend you check out Rowley Crossworks ARM. I have been using it for 12 years now and love it.
Commercial licensing is reasonable (a named developer license is $1500 a seat plus $400 a year for maintenance). They have a personal, non-commercial license for $150. It is the full thing, they just ask that you be honest. I retired in 2012 (for a while) and I bought a copy of the non-commercial version for my own use. When I returned to the workforce, I bought a couple of seats of the commercial version for my team to use. The text editor is their own and it is every bit as good as Microsoft's Visual Studio (which is fantastic in my opinion).
Rowley Crossworks ARM uses GNU compilers except they make it work seamlessly, without frustrations. The result is every bit as good as Keil's MDK-ARM or IAR's Embedded Workbench for ARM (I have licenses for both and use them when I have to). Crossworks supports everybody's ARM processors and development boards and their technical support is fast and excellent. It is worth paying for if messing about with ARM processors pays your salary.
CrossWorks for ARM features, supported devices and frequently asked questions
www.rowley.co.uk
I think that Silicon Labs toolchain is one of the better GNU based vendor locked toolchains. If they have the chips you need this is a painless and free option. Really no complaints. I like their radio technology and they make fantastic galvanic isolation ICs.
I have used NXP's MCUExpresso and the main thing holding it back is it still uses Eclipse as a editor. The chip configuration tools are fantastic. I just wish they would switch to a better text editor. At least its not VI, I guess that is something. The example code in the SDK is excellent. Written by people who understand how to get stuff done. An amazing, mature ecosystem. I have been using NXP's processors since the 90's. 8051, 51XA, ARM-7, Cortext M0, M3, M4 and now M33. Absolutely some of the best IC's you can use.
Nordic Semiconductor's is a mixed bag, very best in some ways, but the SDK is infuriatingly bood/gad (good and bad?). The silicon is fine. Best in class power consumption. The crosspoint switch is wonderfully flexible, you can configure every digital function to any GPIO (I like that a lot).
The Nordic Semi SDK is the 800 pound turd floating in the bathtub. All of the radio related stuff is really excellent. Everything else is cumbersome, inefficient and opaque: [Nordic Semiconductor Diatribe/Rant]
- Every non-radio specific code example is almost unusable because way too much of the magic is hidden behind the scenes which makes comprehending what you need to do to use the hardware resources is entirely up to you (pore over the data manual and figure it out for yourself). Basically there is no point to even providing this code, it is that bad.
- It is very difficult to merge tutorials together in order to do real work because the SDK uses a configuration wizard that disables access to everything except what that particular tutorial needs to use and they don't give you the configuration wizard. "Oh you want to use the Radio AND the SPI port in the same program. Why would you ever want to do that?"
- Everything non-radio specific is painfully slow and unoptimized. Just flipping a GPIO bit high or low took 6 nested function calls if done through the SDK. I traced it painful step, by painful step one day to see why it was so flipping slow.
- An example: I needed to read a 24 bit ADC at 5000 Hz (read a sample every 200 microseconds). Their SPI routine took so long to return data that it was was falling behind the 200 microsecond timer interrupt function. It was 3 times faster to just bit-bang the SPI data in (not using the SDK GPIO routines of course) than it was to use the SDK to access the SPI hardware. Arggg.
- Great silicon. Terrible SDK. Real shame that.
[/Nordic Semiconductor Diatribe/Rant]
Dallas and STMicro I really haven't even looked at their stuff since the 8051 days. The MicroPython development board is going to get me to buy an STMicro development board, so I may turn into a fan.
In case you can't tell I am a major NXP fanboy. I think their asymmetrical dual core parts are amazingly powerful. I have used the LPC4357 and LPC55S69 now and they both knocked my socks off.
The LPC4357 primary core is an M4 with floating point coprocessor. The second core is an M0 that you can dedicate to whatever tickles your fancy. I used the M0 to handle communication duties with the high speed sensor input and to service the high speed analog outputs. The M4 core did all the DSP and host communication functions. Both processors were essentially loafing (worst case bandwidth utilization peaked at 25%).
The LPC55S69 has two M33 cores. The primary M33 core has the floating point/DSP coprocessor and the second M33 core is again available for any special time sensitive task you might need done right now. This part has 9 flexible serial ports and all ports are available to either core. Each port can be a USART, SPI, I2C or I2S port. There is one additional dedicated high speed SPI port that supports 50 MHz clock speed. I am using the second M33 core as a data pump dedicated to running the high speed SPI port. Let just say, I am never waiting on the SPI port now.
/cdn.vox-cdn.com/uploads/chorus_asset/file/22250299/Screen_Shot_2021_01_21_at_9.08.49_AM.png)
www.theverge.com
the number of times I had to correct bugs in arduino libraries (or even the core code)... Now, most of the time, I don't even try to use the existing libs anymore and I directly write my own libs --> a lot less bugs and edge cases, lower memory usage, higher perfs, ...
