some discussion about the "traditional Arduino" vs "doing things the MbedOS way" of coding

[jerabaul29]

That is tightly related to #332 and some discussions in #324 . This is not really an issue, rather a discussion / thinking loud to try to get ideas clear (andmaybe get some help in the process).

I think that we are several users being a bit confused about where the line goes between the Arduino core and MbedOS. I was at the beginning skeptical to the whole MbedOS thing (mostly because I was lazy and did not want to learn about RTOSes which is something new to me), and then I read a bit more of MbedOS documentation and changed opinion: having a good RTOS with all the facilities it provides is really nice ^^ :) . I have a feeling now that embracing a "truly MbedOS style" would help a lot in writing better, higher level code, that is "good enough" the vast majority of the time, while being much more flexible and less error-prone.

For example, compare the power management main ideas of MbedOS:

https://os.mbed.com/docs/mbed-os/v6.6/apis/power-management-sleep.html

Which means, if I understand it right, that MbedOS does all the work for us, and chooses the lowest sleep mode possible depending on what peripherals etc are used,

with:

https://github.com/adamgarbo/Arduino_Apollo3/blob/58124ed237f910d56ec183a601d6bdab048dc0bf/libraries/WDT/examples/Example3_WDT_LowPower/Example3_WDT_LowPower.ino#L91-L116

where everything is done explicitly by hand (with all the possibilities for mistakes that brings in, but also full control as a gain, and probably a bit better power savings).

Now, I do not think that one approach is uniformly better that the other, and I think that for truly very low power applications, it probably will be worth / necessary to go all the way to the second approach. But still, for me, I would prefer to stick to the high level approach.

I think this is illustrative of the "traditional Arduino" vs "doing things the MbedOS way" of coding. Any thoughts about that? Where does the line go? How much should a programmer rely on MbedOS facilities / how much of it is actually available, vs how much should be done by hand?

Another point is with the choice of APIs. MbedOS seems to have very good documentation, so I would really love to be able to use "full MbedOS APIs" rather than need to dig to find the "Arduino Artemis API" way of doing things :) . Thinking about that after the work around #324 .

@adamgarbo I think this is very related to some of the discussions we were having.

[jerabaul29]

I wonder if getting an MbedOS person interested in this project would help a lot on clarifying these questions.

[jerabaul29]

@Wenn0101 @oclyke would be very interested to hear your explanations / thoughts here. Wonder if having some sort of "technical document" describing how these things work would be useful to both power users and people who would be willing to contribute.

[idea--list]

@jerabaul29
Arduino is great for those who are new to the world of microelectronics. Until recently the whole Arduino line-up consisted of super cheap, low performance boards, which are perfect to demonstrate blinkies and get people understand the basics and awaken their interest. Even the documentation of Arduino is really good.
The downsides however of Arduino are:

• Worst IDE ever, that always just gets in your way
• Has it's own C dialect with non-standard var types, also the .ino files are just renamed .c files... which i can hardly understand. I mean the main target audience of Arduino are newbies. But exactly newbies will get confused the most if they try any other framework and find out how many things Arduino just makes different, which does not simplify anything in reality.
• Which pins you can use for which purpose is craved into stone with Arduino.

So to sum it up: if you are doing DIY projects for your own and development speed is key then choose Arduino. Simply because there are HW libraries for almost every HW. Even the community is huge if you get stuck, you get answer really fast.

However if one wants to actually learn embedded programming (not just playing around) or you want to do something more advanced beyond just DIY, then choose Mbed. But with Mbed be prepared to one of the worst documentation ever made and for an ever changing core which breaks things too often. Also there are less HW libraries...and be also prepared for outdated examples which all make your way hard at the beginning.

Because all of this i am actually considering trying Zephyr (i just do not have compatible boards) or going to learn AmbiqSDK which seems to be really alien at first glance and is also extremely HW specific...

[oclyke]

closing in favor of this discussion #352