Is 499 EUR for that BOM fair? Genuinely asking... high end SoM modules with carrier boards and a metric ton of software can be obtained by half of that price, and op-amps aren't that costly.
Please, kill Jira and Confluence. I hate Atlassian tools so much. The user interfaces are sluggish no matter the hardware you're using... it's a shame it became almost a standard in our industry.
I just opened a view mode page in confluence, and it made >400 calls until fully loaded. ~80 XHR calls and >300 js files being loaded, in what world that is acceptable?
>So people who make money from collecting them don't have to dig in trash. Pure humanity.
I've lived in Germany, and this was one of the things I quickly adopted after seeing the locals doing it. An interesting anecdote is that can/bottle collectors always approached me asking if I'm finished with my drink (I had a drink outside almost daily), but I never felt threatened or anything. They were generally super polite, I'd usually reply with "I'll leave it here" and they went along their way. Very different experience than anywhere else!
these tiny languages for MCU by design are not for 'significant complexity" to start with, even Lua might be too large and complex for "tiny iot devices".
Other comments have put better than I could, but I'll add that what people call ecosystems nowadays is completely unthinkable in embedded. Sometimes you have critical applications and you bet you need to certify every single line of code that goes into your application. Small embedded devices are more geared towards engineering than other kinds of development, and in my opinion that's why applications work well, in comparison with the mess we have in the web nowadays, for example.
Nicer from which side? Not OP, but I do like modern languages and great type systems - I’ll be the first to say that TypeScript is fantastic and maybe one of my favorite typed languages.
However, embedding Lua and writing bindings for it is really easy to do. The entire thing fits in a nice, neat single directory of a few ANSI-stone-age-C files and “Just Works”. You can drop it into your codebase, write a couple of simple bindings and be off to the races in no time. And you can easily fit its world model into the model of your application. Lua’s simplicity makes it a very, very powerful tool.
Ecosystems are as much a burden in embedded development as they are a blessing. Either you put in the time to support much of it across all your Tier 1 platforms or you punt on the problem, defeating the purpose of using a language with an ecosystem in the first place.
Take Javascript, for example. Which APIs are you actually committing to support? Are you going to support the Date class? BigInt extension? Node's fs, path, and crypto libraries? The browser's local storage, indexed DB, and other high level APIs? What about setTimeout and setInterval? Or are you only supporting pure-JS libraries, forcing the user to do a manual review of each dependency they consider?
A lot of microcontrollers - probably the vast majority in circulation - wouldn't have the ROM to even support most of those APIs, if they made any sense on an MCU to begin with. Look at MicroPython to see the kind of tradeoffs they have to make - it isn't pretty.
We are slowly getting better at this. Most embedded Linux companies for example have shifted or are in the process of shifting to an upstream-first policy. A lot of the toolchains are open, busybox is used everywhere. A lot of the really good HALs are open source. We're getting there!
I've been using Zephyr lately and have been really enjoying it. It still has the vendor HAL libraries available (e.g. Microchip/Atmel ASF), but the devicetree-based HAL has been fabulous to work with. I've tried a number of different embedded frameworks/RTOSes over the years, but it's the first that I actually feel happy using. There's a few sharp edges for sure, but it's at least an order of magnitude better than anything I've used in the past. One thing that's been particularly good is that the abstractions feel right, and it's allowed our team to collaborate on firmware without constantly tripping each other, because the module boundaries and abstractions are good.
This is good to hear. I'm just getting up and running with tutorials for a Nordic IoT SIP using Zephyr, with plans to develop a new model of an agricultural data monitoring/control product we've been offering for a few years. So far it seems really good. I personally have very little experience with embedded software (many years with web software) but am finding it easy to pick up.
Great to know, Zephyr is on my to-use list and I need move it up the list more. Heard good things about it. It might become the Linux OS for low resource MCUs as the trend goes, it's also a LF(Linux foundation) project and vendor neutral, very promising.
I've been using Zephyr on an Atmel/Microchip SAMD21 for $WORK and it's been awesome.
I have an RP2040 sitting on my desk for a personal project and the plan was to use Zephyr for that as well, but it seems the WiFi is based around a binary blob and a weird interface to it that the Arduino BSP has wrappers for... It's been crunch time at work and I haven't gone back yet to see if the RP2040 port is coming along further, but on the Saturday I was looking at it, it seemed like connectivity was potentially going to be an issue for now.
ESP32 support is currently great for some chips and a WIP for other chips. I got unlucky and the one board I planned to use for a different project was pretty much completely unsupported, but I found a different one in my parts bin that only took about 4 hours to get going with the sensors I had planned on using (I2C or SPI, I don't recall), Bluetooth Central for some different sensors, and WiFi to connect it to the local network. It was really smooth!
There is quite a bit of interesting work in the embedded Rust space on this. The embedded-hal project has made some progress on standardizing traits for peripherals and there are some decent HAL crates that have largely adopted those standards. The stm32-hal crates are fantastic.
rust is too hard to use for me, if I need pick up a modern language for low level it will be zig instead of rust.
while rust might be fine for MCU low level embedded, it does not work for mid-range embedded linux when you have 64MB storage for example, as rust is by default static linked, a few of rust executable will fill up the storage, unlike c or c++ or zig where they can share some libraries _easily_ to save space.
>I would recommend learning and using sh unless you really need Bash.
I don't buy this argument. Ok, it's a standard, but sometimes it's a pain-in-the-hole standard. Bash augmentations lessen some of the pains, and it's just nicer. The only situation is if you're using busybox in a very limited system or you reeeeeally need your script to run on many difference unices, which let's be honest, is not that common nowadays.
All of this was covered in great detail in the 2000s, when Debian and Ubuntu switched /bin/sh to the Debian Almquist shell, which was basically POSIX-only with some 3 things that Debian people simply couldn't live without, and encouraged system scripts to use it. If you weren't around then, go and read the discussions. They're mostly still available, and they cover some important stuff that straw man counterarguments regularly miss.
The Debian people were concerned, for starters, with how much time the Bourne Again shell spent, at process initialization, setting up things for extensions and interactive features that were never employed in non-interactive "sh" mode; a significant cause for concern given how much of the system was executable shell scripts.
But the aforementioned are what Debian people explicitly wanted and couldn't live without. Note that the StackExchange answer is a comparison of a 2022 dash to a 2017 standard, neither of which existed at the time. Debian Policy, the Debian Almquist shell, and the POSIX standard have all been revised since then.
I do small embedded systems with busybox, even that I can squeeze in bash when I need that, it's about 1MB in size and gives a lot more than busybox's sh. Another option is Lua which is also great.
Well, usually I have to decide between „do I look up the magic incantation to install bash in this container and risk fucking up the layer cache“ or „do I modify this script to not use bash-isms and feel like I’m a Unix purist in the process“, and the answer is the latter usually
> Bash augmentations lessen some of the pains, and it's just nicer
Both sh and bash are terrible, ugly hacks. Anything that requires more than 3 lines of them (including the #! line) should be written in a proper scripting language.
Though I do agree that cross-platformity to that level is rarely meaningful, and so things like python are just as likely available/can be made available.
My system Python tree is almost 1GB. That doesn't matter for desktop systems, but most software is published as container images these days and using a language like Python, Ruby or Perl for an image that doesn't already need it is pretty wasteful and pulls in a lot of extra dependencies.
I'm not sure there is a good alternative to sh/bash shell scripts as most dynamic languages have become pretty large dependencies these days.
That surely includes plenty of globally installed dependencies. I looked at the package sizes for debian and it is around 100 kB for the python3 package and on the order of another 100kb for python3-minimal. Couldn’t find a cumulative install size, but it is surely not larger than a few megabytes.
Until someone decides to write something that's only available in X version of Python. While there are certainly v4 and v5 bash-isms, they are far and few between compared to most languages.
...that said, having to support bash 3.2 for MacOS is a horrible thing.
AWK is part of the POSIX standard and is therefore on every UNIX-like. People really need to remember AWK exists and is a real, proper scripting language with a very sane syntax (it's not just for cryptic one-liners, really!)
Add a flake.nix file and you get completely reproducible program versions if you really want.
But I know that you meant it as a rhetoric, so my non-rhetorical answer would be that python3 is almost universally available on distros that are not minified deliberately (containers).
> python3 is almost universally available on distros that are not minified deliberately (containers)
Writing control scripts for use inside containers is currently my biggest application of BASH scripts. What makes BASH (or other shells) handy is the lack of supporting files that are needed - just copy in the script and you're ready to go.
I was going to say something similar. I try to avoid adding anything to my final images. Each extra dependency is something else to update, more surface areas for attacks, another thing to justify, etc. Much rather just use the slimmest base and the tools already available.
The various sub-versions of bash are a lot more compatible than the sub-versions of python 3. Just today stuff was breaking on me because of differences between python 3.6 and 3.8
It depends on what features of BASH that you want to use. If you target v3 (as I usually do), then that or a newer version will likely be already installed. There's very little issue with backwards compatibility.
If you wish require some users to install an interpreter, you might as well go for Korn or a real programming language. If you want to use something that's portable and installed everywhere, that's POSIX sh (or at most dash-like level). Bash is in the poor middle which isn't good enough for either side, unless you really know what's your target and don't care about elsewhere.
Does anybody know something like a translator tool between all the different `yaml`s different CI/CD services use? Or maybe some metalanguage specifically made for that that can run instead of whatever hell dash/bash is.
I wish I could just jump ships altering a `script` tag in whatever `yaml` from whichever service.
Why?