SoylentNews is people
SoylentNews
Microcontrollers are wonderfully useful things, but programming them can be a little daunting if you’re used to the simplicity of compiling for regular PCs. Over time though, this has become easier. Communities have strayed away from assembly code and created higher-level languages such as Micropython, to allow these devices to be programmed in a more accessible manner. Unfortunately, Micropython has historically lacked a decent high-level GUI library. Thankfully, that’s no longer the case, with [amirgon] porting LittlevGL to the platform.
Putting a GUI into a project with a screen seems simple, until one actually gets down to brass tacks. A simple button can consist of a background color, text, and a symbol – and that’s not even considering the use of shading or other visual effects. Having a library to handle the grunt work can massively cut down development time.
[...] There are other approaches to this problem, too – with MyOpenLab being a particularly versatile example.
(Score: 2) by The Mighty Buzzard on Monday March 04 2019, @12:54PM (12 children)
Have to disagree. It would take me less time to write easy to use abstractions for handling all of the above than it would anyone to figure out how to trim down a python script to fit demanding space and responsiveness requirements. And once you've written the abstractions once, you never have to again until you change chips unless you're a very silly consultant and don't keep the rights to reuse libraries you write for other customers.
My rights don't end where your fear begins.
(Score: 2) by janrinok on Monday March 04 2019, @04:01PM (11 children)
The important consideration that you are missing is selecting the most appropriate language for the task.
MicroPython contains provides dictionaries, lists, and many other higher-level data structures out of the box. In C they are not available in the minimum language specification so that that have to be written. True, there are libraries available to provide such capabilities, but such things are built into MicroPython. Why spend time writing such things when they are available - and have been widely tested - in the basic language?
In the comments above, several people including yourself have mentioned the superior operating speed of C/C++ compared with MicroPython. So what? That is an important consideration when dealing with real-time systems in which as-fast-as-possible responses are required. In fact, is such cases you might even choose a real-time OS to meet the requirements. However, there are far more problems that can be resolved by using a microcontroller board that do not require such response times. The IoT is full of devices that use WiFi/LoRa/Bluetooth LE where more time is spent waiting for a response from the device that the board is communicating with than actually doing calculations. I have several devices that use LoRa comms which are low power, long range but relatively slow i.e. ideally suited to low power microcontroller boards. For example, the status of remote radio devices is updated regularly to my main computer and I can control the radios by sending commands back using the same microcontroller device. The time taken to write the software can be measured in minutes because all of the libraries I require to use LoRa are included in MicroPython. Why would I want to spend more time writing my own libraries to achieve something that can respond faster than I can decide what commend to send to the radio?
You yourself write in Perl, Rust and I guess several other languages. You haven't rewritten slashcode in C. Why? You could surely do everything that you write in those other languages in C/C++? I would suggest it is because it makes more sense to evaluate the task, the response and processing requirements, and existing software and then decide on the most appropriate language for the task at hand. Libraries for all of the abstractions for the microcontroller boards are already available in MicroPython and meet many users' requirements perfectly. Writing one's own libraries in C would be a waste of time for no gain.
I too have written real-time software for real-world applications in military aircraft. Some have been written in languages specifically written for such functions e.g. CORAL or ADA. Others have been written in other common languages. None of them have been written in C/C++. But I wouldn't choose any of those languages to write something for a microcontroller that is telling me the contents of my freezer, updating my weather data or controlling my remote radio devices.
And if I am going to write those programs in MicroPython and needed a GUI, then I might as well take a look at a library that provides GUI functionality.
(Score: 0) by Anonymous Coward on Monday March 04 2019, @05:53PM (7 children)
It's twice the size of elua [eluaproject.net] with tables, pattern matching and a clean C API. Why would anybody use a microcontroller in place of a SBC if you're intending to code primarily in an interpreted language?
(Score: 2) by janrinok on Monday March 04 2019, @06:21PM (3 children)
I use a small microcontroller board that is provided by Pycom (Lopy4 [pycom.io]). Read the specification [pycom.io]. I can program it in MicroPython, Lua or other languages. The cost is €34.00. Please tell me of the SBC that can match that specification for the same price or less.
(Score: 0) by Anonymous Coward on Monday March 04 2019, @07:51PM (2 children)
Raspberry Pi 3 A+ [ebay.com]
(Score: 2) by janrinok on Monday March 04 2019, @08:07PM (1 child)
The Raspberry Pi does NOT have LoRa nor SigFox built in, nor does it have most of the specification that I linked to. The WiFi and BLE are significantly less capable. It doesn't have a sleep mode which requires only 25 microamperes but is still capable of responding to interrupts from the GPIO pins. It is possible to run the LoPy4 on lithium batteries for weeks or months without needing recharging. You have read the spec, haven't you? The Raspberry Pi, of which I have 11 at present, is nothing like the same device.
(Score: 0) by Anonymous Coward on Monday March 04 2019, @11:03PM
Never heard of SigFox and I never claimed anything about power consumption which doesn't seem as relevant if you're scripting a UI with python as it would for a datalogger.
Do that on an Arduino nano if you bypass the voltage regulator and you can pick them up for $2 each. Depends on your use case.
Not in depth just skimmed over stuff like Wi-fi and bluetooth. I typically have little use for these on microcontrollers but if I did want something more advanced than a little OLED, I'd employ networking to run the GUI on a phone, tablet or SBC.
(Score: 2) by janrinok on Monday March 04 2019, @06:52PM (2 children)
You are, I think, confusing MicroPython with Python. MicroPython also runs on bare metal in exactly the same way as eLua. If all you are arguing about is the choice of language then that is surely a matter of personal preference assuming that both have the same choice of libraries for the various functions (GPS, LoRa or whatever).
http://micropython.org/ [micropython.org]:
'Interpreted'? - I think not.
(Score: 0) by Anonymous Coward on Monday March 04 2019, @11:17PM (1 child)
I've not worked with lua for about 15 years but it was designed to be small and embeddible. I mentioned it in response to your C comment because you get strings, tables, pattern matching and a simple C API. With eLua, I do know you can build without the parser (etc) to reduce binary size. Size seems to be my preference when writing embedded code.
It is a bytecode interpreter is it not ;P
(Score: 2) by janrinok on Tuesday March 05 2019, @08:20AM
From http://micropython.org/ [micropython.org]
However you asked:
No. it appears not....
(Score: 2) by The Mighty Buzzard on Tuesday March 05 2019, @02:59AM (2 children)
Everything I have ever written for a microcontroller has had at least one bit that is time sensitive and ran on bare metal; no OS, realtime or otherwise. Every microcontroller I've ever programmed for also has had a fairly limited set of specs. No amount of prebuilt widgets can make up for everything you write in a language being slow bloatware in an environment where time and size are of the essence.
Because our servers have a gerzillion times more system resources than a microcontroller does and because we're not trying to read pulses off of a 24DCV digital line without missing a single one. Time is not critical for what we do below a very forgiving limbo bar and we have a good bit more ram than we currently need on the web frontends. Yes, there are probably microcontroller applications that also fit this bill but programming in a less fit language because it's easier is a very bad habit to get into.
Quite a few of them, yes. And I add more all the time just to learn their capabilities, strengths, weaknesses, and the proper places and ways to use them. Which is how I generally know which languages are best suited for most any task I'm looking to perform.
If you're playing with a toy program like an IRC bot or something at home, by all means use whatever language you like. Choosing a language ill suited for its purpose if you're on the job is cheating whoever you're working for though.
My rights don't end where your fear begins.
(Score: 2) by janrinok on Tuesday March 05 2019, @07:43AM (1 child)
Ad Hominem? Not really your usual style, TMB. However, the point stands. You should match the language to the task at hand, not suggest that everything should be written in C/C++ because that is the only 'true' language. There are millions of microcontrollers out there and I'll bet that the vast majority are not written using C, regardless of your own experience. I've written programs that controlled radars and processed the data for display, or that received, analysed and automatically countered electronic emissions; they were not toy programs. They were all real-time and had to work as advertised. C/C++ was not used in any of them.
(Score: 2) by The Mighty Buzzard on Tuesday March 05 2019, @11:41AM
That's not an ad-hom. It's not even an insult. I have written quite a lot of code for myself over the years and I consider every bit of it that wasn't for a job or isn't going to a serious OSS project to be of the "toy" variety. MrPlow is absolutely a toy, for instance. So is most everything in the ~/bin/ directory of my desktop.
Yeah, folks can mandate a language for their own hardware or the boss can mandate one for a project. I'm saying that if you're doing the choosing, you need to choose the language that's going to give you the best results. For a microcontroller that's generally going to be C/C++ or another very tight, compiled language. Maybe a few years down the line Rust will be a viable choice, especially if your team isn't great at memory management. It's never going to be anything that packages a runtime environment in every executable though. Not even a tiny one.
My rights don't end where your fear begins.