idea--list
commented
3 years ago My thoughts are: I began learning C/C++ 3 years ago as i really wanted to write a firmware for my project on my own. I had some experience with Basic (on Commodore), PHP, JS, so there were some concepts i was familiar with.
Despite these i realized i just can not start with embedded C. So first i started with "plain" C/C++. Then in the first 2 weeks or so i was completely lost between all the different C/C++ standards, char/string handling was super confusing...
Then soon came the time to try programming an embedded MCU... as a newbie i found Arduino by googleing around and i also had my very first target: an MCU8266. So it seemed to be a good idea to try Arduino. I was excited that my first blinky actually ran on an MCU. But on the same day i noticed Arduino does a bunch of things completely off-standard. I also noticed most Arduino hardware was just super cheap, really low-end MCUs with 16KB RAM that would just keep raise problems. The IDE itself was crap... so i immediately knew i simply do not want to invest any time in Arduino for learning an off-standard dialect of C, despite the huge community and good documentation (which is on par what really happens behind the scenes).
So went back googleing and learned about Mbed OS. It also promised it would work on any ARM chip, which was really compelling! However that time it was not clear to me what actually Mbed is: an opensource, community maintained collection of a bunch of commonly used libraries, which they adopted to run on ARM based MCUs. It also was not clear that it has an Agile life-cycle meaning the core gets updated frequently that also tends to bring new bugs because of premature release. I also had to learn how BAD Mbed's documentation is! It is 99% generated automatically by Doxygen, thus many important things simply are not even mentioned... then also many times you find outdated examples, which simply will not work on recent OS versions you are probably using to learn Mbed...
So Mbed is great if you want to use more capable MCUs, are about to write standard C/C++ code, even the very first steps are easy (with the online compiler you do not even need to install anything locally!)
However things get complicated with Mbed rapidly if you try to use more then 5-6 APIs in parallel as there are almost always some glitches that are not mentioned in the docs...so you will end up reviewing core code... but at least that is yet another thing you can easily do in Mbed Studio (with linting!), but you can not do in Arduino IDE.
Lately Arduino recognized it would not have any future with all the low-end MCUs and introduced some advanced boards piggybacking on Mbed, so they came up with a hybrid Arduino/Mbed core... and exactly such a thing is the V2 Arduino core for the Artemis boards by Sparkfun. Well i can understand the PR side of that by saying it is as easy to use as Arduino while you also have all the advanced features of Mbed...well the reality is: you mix standard C/C++ and non-standard C together hoping it will not have any adverse effects. Such hybrids may help the transition from Arduino to Mbed, but in reality you just expand your useless knowledge that way. And chances are high that going that pathway you will still end-up going the pure Mbed way meaning you will need to learn yet another framework.
I wish there was a framework with a good documentation, no new releases every month that just bring more issues than bug fixes while supporting also many targets... ;-)
Zephyr looks interesting, but i have no HW they support. I am also considering Ambiq SDK, however that HAL looks really alien for me, however if i knew Sparkfun is about to release boards based on the Apollo4 Blue MCU, i would absolutely learn Ambiq SDK even if that is extremely HW specific.
I am also playing with the idea of trying some boards from MAXIM Integrated and start using Eclipse (it seems their newer MCUs are not even ported to Mbed). Well again... this route is also HW-specific but Eclipse seems to have superb features, and i do not mind going a HW specific path if the docs are good and the HW is capable so i will not need to learn a new framework every second year.
I also mentioned Arduino does not have a bright future IMHO, well here is why: Python and Micropython seem to be more standard and with them you can just forget compilation time. Your code is immediately interpreted by the HW...exactly that is why Python capable HW needs to be more advanced then low-end Arduino HW. While many tell that even the language is easier to learn than Arduino. So school kids/newbies will rather start with Python nowadays.
And for small children there are also things like MicroBlocks where you do not have to touch any bit of code, you just build your logic based on blocks and it will run bug-free as expected.
Wenn0101
This may be a bit off-topic, but trying myself anyways :) . That may spark a discussion for some Sparkfun blog posts / videos / tutorials or else.
Some people complain that the Arduino ecosystem has in average quite low quality code, with very much "C++ written as C with classes". We may or may not agree with that, but it is true that the community uses in average quite little "modern c++ best practices". I think an explanation for that is the root in 8-bit AVR controllers with very little resources available, so each byte counted in the original days of Arduino.
With the Artemis line of product, this changes (and this is one of the appeals about it). While we still do not want (most likely) to use plain C++ STL et co. with lots of dynamic memory allocation, using some stuff like the Embedded Template Library (https://github.com/ETLCPP/etl), which has lots of nice fixed-size containers, could / maybe should be the default on Artemis boards, rather than the old plain C arrays and C-style strings. That would solve so many buffer overflows / undefined behavior, and help users capitalize on lessons learnt by C++ since the C++98 release...
I wonder if a way to pushing this may be to consider including the ETL (or similar, but seems like ETL gains a lot of traction and may become a de-facto standard) into the Artemis core (or very strongly recommending users to install the ETL Arduino library and using it), and creating some examples about the ETL use to push new users in this direction. This may be a bit pushy on the users, but meh, nobody will actually be forced to use it for their projects.
Any thoughts?