4 ms·

This looks like a lot of effort was put into it, but what pain point / problem does it address? Embedded applications (bare metal) is usually not that complicat

This looks like a lot of effort was put into it, but what pain point / problem does it address? Embedded applications (bare metal) is usually not that complicated, and when they are they are usually developed either on a RTOS, or on embedded linux which gives you almost all the advantages of desktop application development. Coming back to embedded applications not being that complicated, now you also need to get your developers to learn another framework and IDE while they are already under pressure to develop their current feature set. Like codehero states elsewhere it only adds another abstraction layer between you and the silicon, in a field where exact control of the silicon is paramount (Low power, response latency in real time, limited resources etc). Furthermore what guarantee do you have that Mbeddr will support the latest processor you are working on. At least with C being a defacto standard in the industry you have that guarantee. Furthermore most processor manufacturers supplies demonstration code to use their latest processor features, how easy is it to pull that into Mbeddr? I'm afraid this is a very fancy and polished solution looking for a problem.

dkarapetyan 12y ago
It's all C. It is all syntactic sugar on top of C so if at the end of the day you want to go back to C then just compile it down and take it from there. Your comment reminds me what people were saying when assemblers were first developed. Real programmers did not use assemblers because it was too high level or too far removed from the hardware or any number of other excuses. The fact is that plain C is inadequate for delivering correct software in high assurance environments. This tool addresses that problem and then some.
- ArkyBeagle 12y ago
  'C' is perfectly adequate for delivering safe and correct* code. Just because it's possible to have 'C' code that is unsafe is not a blanket indictment of the language. Micheal Barr, the MISRA team, Valgrind all exist to aid and abet delivery of safe and correct systems. *whatever that means in context... As we say - "doctor, doctor it hurts when I do that!" "Well, don't do that!" Tools like this simply automate or add leverage to that process. And unless there's considerable community support for the use of something like this, it'll remain a smaller thing than raw 'C'. But many embedded projects are small enough that there's little pain in reinventing the wheel.
- errordeveloper 12y ago
  I'm sure one can use any libraries/SDKs from Mbeddr, right? And my other impression is that the aim is not to support boards or chips at all, it's just a tool, in my understanding. Are there plans to support C++?

dkarapetyan 12y ago

It's all C. It is all syntactic sugar on top of C so if at the end of the day you want to go back to C then just compile it down and take it from there. Your comment reminds me what people were saying when assemblers were first developed. Real programmers did not use assemblers because it was too high level or too far removed from the hardware or any number of other excuses. The fact is that plain C is inadequate for delivering correct software in high assurance environments. This tool addresses that problem and then some.

ArkyBeagle 12y ago
'C' is perfectly adequate for delivering safe and correct* code. Just because it's possible to have 'C' code that is unsafe is not a blanket indictment of the language. Micheal Barr, the MISRA team, Valgrind all exist to aid and abet delivery of safe and correct systems. *whatever that means in context... As we say - "doctor, doctor it hurts when I do that!" "Well, don't do that!" Tools like this simply automate or add leverage to that process. And unless there's considerable community support for the use of something like this, it'll remain a smaller thing than raw 'C'. But many embedded projects are small enough that there's little pain in reinventing the wheel.
errordeveloper 12y ago
I'm sure one can use any libraries/SDKs from Mbeddr, right? And my other impression is that the aim is not to support boards or chips at all, it's just a tool, in my understanding. Are there plans to support C++?