Use micropython (or others?) for an embedded system

[brazoayeye]

Hello,

i have to develop an embedded system that

• get informations using an Https web server
• get informations using BLE
• Connect to a server with MQTTs, and exchange data
• Exchange data using a serial port
• Read / write some digital I/O
• can perform OTA

Actions to be perfomed are not many, and the processor is powerfull (running on 4MB WROOM), is it possible to script them using micropython?

In my opinion plain C is a pain-in-the-ass because it lacks of high levels features (you will say, it's C) in order of pain: dynamic strings (passed out from a function without a pointer juggling), error handling (& resulting error return from a function, instead of the functional value), OOP (& resulting over parametrization of the function to keep it reentrant, with a crazy and illogical mixture of in - out - working parameters in the function call), disproportionate use of structs (instead of using parameters list in the initialiation, so a library update needs a partial code rewrite).

I can overcome some of them with C++, even if the base code structure must remain the same (because of the provided libraries), and I whould like to try micropy to reduce development time (I will probably have many low number projects, so buying 8MB version or WROVER is not a problem).

My questions are:

• Can micropy be used to script an entire embedded system?
• From the documentation it seems that it's hardly oriented to the shell scripting, and that event/problem handling is demanded to the serial output, isn't it? Please provide a documentation regarding it
• is there another way to program using an high level library (also not free, or that require more resources) to reduce development time?

Example for what I means for handy library:

Start AP with

Code: Select all

 wifi_startAP(std::string ssid, std::string password, uint32_t base ip = 3232235777, bool withDHCP = true);

and it will perform all actions by himself, with interface that will not change during updates.

Thanks

[willemmerson]

We had to make the same decision and we chose to use the official sdk (IDF) and not micropython for the following reasons:

• IDF is supported by a large number of paid people at a company, whereas micropython is supported by a small number of volunteers. For this reason IDF seems more suited to writing production software whereas micropython is better suited for hobbyist.
• There are (or were when we looked at it) lots of things in IDF that aren't in micropython, for instance OTA update, secure boot / firmware encryption, mesh networking, factory reset, ULP, unit-testing framework, etc. etc. Every feature in IDF needs someone to write some micropython code around it. OTA update and factory reset require about a line of code each in IDF, micropython isn't going to make that simpler.
• IDF is incredibly well made and the documentation is amazing compared to the drivel from the likes of STM, NXP, Atmel, Nordic so you may as well make the most of it. I'm not sure any other manufacturer even has an open source sdk.
• There are loads more drivers and supporting software for IDF. If you need to interface with other chips, there will likely be a driver for it compatible with IDF. Also Esp-iot-solution has a bunch of drivers written by espressif.
• There are literally about a hundred times more official examples for IDF than micropython, so many in fact that you should barely need to write any of your own code. Certainly all the things you've listed have multiple examples for them. C is verbose but it really doesn't matter if most of that is just code taken from examples.
• IDF has much better support including this forum, I'm not sure micropython has any support other than the github repo.
• C is way faster and more efficient. Speed might not be a problem now but could be in the future.

I agree with you that C is an abomination, but it's a kind of fun abomination. I am a python/django programmer and had to learn C recently but it isn't that bad, and at least it's simple compared to C++. All the problems we've had have been hardware problems, not software, because we are using custom hardware. You should rarely have to use dynamic strings, and even when you do you can use asprintf. It's much easier to use json everywhere with the built in cJson library and avoid strings entirely (almost).
There is loads of useful stuff built into IDF for tracking down memory problems, e.g. https://docs.espressif.com/projects/esp ... debug.html

Having said all that, we used micropython to prototype a driver from some hardware because the repl was so convenient. But once it was written, it was ported to C.

You might be interested in this, I haven't used it:
https://github.com/PerMalmberg/Smooth

[brazoayeye]

Thanks for the reply, I will try Smooth soon.

I agree regarding the number of the examples, but documentation is improvable regarding interlinking, specially regarding enum and struct definitions (my current approach is to declare a variable in eclipse, and then ctrl+click them to jump to the definition because in the documentation is much harder). I feel the underlying engine warp and twist, structs and functions change very frequently, and that's not good for long therm projects. C++ libraries are very handy and well documented, and can make the code simpler (see string, deque, etc), even if you can reach a similar result with C tecniques (ex. FreeRTOS)

I disagree regarding code recycling, if the structure is not very simple the example can be only used to have an idea of the function calling order, the constructor and so on.

I agree that writing C is not so bad, but it's far from optimized since (at the end) most of users will perform exactly the same block of actions to make it run.

[willemmerson]

This is the wrong forum for this question by the way, it'd be better in the ESP-IDF forum and more people will see it.