Show newer

Every time I have to crack open the books on Intel's x86 ISA I remember why I use a NanoPi Duo (albeit with an I/O extender) as my main workstation for embedded development at home.

My home PC runs hot and isn't particularly suited to testing embedded systems (lacking native SPI, I2C, and even UART ports). The NanoPi Duo rarely exceeds 40°C, is amply fast for the compilation I do, has native pins for UART, SPI, and I2C, and has compiler listings I can read and understand without headache.

This medical paper found in a birdsite reply just made my day:

"Parachute use to prevent death and major trauma when jumping from aircraft: randomized controlled trial"

So, decided to open a Gitee account because if I'm going to use a tool I hate I want the people who have to support it to be within driving distance to choke them at need.

Discussing in the Ada channel another guy and I came to the conclusion that any language made from this point onward should have a) *NO* regexps, and b) PEGs instead to replace them. Whether in the language proper (Awk, Perl, etc.) or in the standard library.

Regexps are awful and need to die in a fire after being boiled in concentrated acid.

Serious props to the developer of this. I'm going to tinker around with it for some private projects that need a committed web server.

Nightmare bug of the day caused by electrical engineers coding and the C family of languages sucking bowling balls through garden hoses.

The RTC peripheral was working fine on sample code when compiled with Keil, but exploding on contact when compiled with IAR. The problem boiled down to time_t being a uint32_t on Keil and an int64_t (note the sign!) on IAR.

This wouldn't be a problem except the engineer who wrote the sample used uint32_t and cast to time_t. One sign conversion later… BOOM!

What's your primary OS?

Boosts appreciated for sample size :)

… and again easily (no, TRIVIALLY) hooked into the debugger.

This is all a very tall order, I know. But it's needed.

So now you know my Dream Project™ that I would like to create in my Copious Free Time™. With only one final step to consider: licensing.

I'm partial to WTFPLv2, myself.

Show thread

… has to be everything that serious embedded programming isn't.

And then it has to work as well with lower-level modules that interface with the Lua environment so that fancier things, or higher-speed things, or more reliable things can be build in a language like C or Ada or whatever. These must be easily wrapped (no exposing the Lua FFI unless the user specifically asks for it--good frameworking is needed here), pushbutton-flashed, ideally as partial uploads into an existing system, …

Show thread

Whatever environment an Arduino Done Right has, it will have to be able to almost transparently load and run user scripts without monkeying around with debugger interfaces. (This likely means that a CMSIS-DAP needs to be on the board and the environment needs to know how to talk to it over USB.) It should also be able to easily reconfigure the runtime (Lua has a lot of dials you can adjust) and reflash it with a single pushbutton. Debugging scripts needs to be easy and GUI. It, in short …

Show thread

… Arduino has excelled compared to its alternatives. The Arduino has an acceptable IDE, and excellent facilities for programming and debugging live programs. Non-Arduino embedded programming is a major chore with a lot of concepts to get through your head like JTAG/SWD/whatever adapters, debug servers, debuggers, flash loaders, memory layouts, etc. This forms a huge barrier that has stopped people I know from progressing beyond that point. It's too difficult. Too alien. In a word: scary.

Show thread

… Lua has a fairly conventional syntax (more Pascal-ish than C-ish) and, as long as you don't poke around in its more advanced weirdness also has pretty basic semantics. You can become a competent and productive user of Lua with an afternoon's introduction if you're familiar with any other imperative programming language, and maybe with a week's instruction and tinkering if you're not a coder.

That being said, we need more than just a language. We need an *environment*. This is where …

Show thread

… that is small enough to not require huge, beefy MCUs to run (which leaves out JavaScript), that has a "common"-enough syntax that skills easily transfer to more "professional" tools (which leaves out Forth, Tcl, and a few other such weirdo languages which would otherwise be a perfect fit), but that also has a powerful FFI that makes enhancing it with low-level features easy (which Tcl would be perfect for, but for its weirdness).

This leaves, frankly, only Lua left of the languages I use. …

Show thread

… narrow line between "dumbed down" and "painfully prone to hard-to-diagnose hardware problems". A picture of an actual board I own (an older one for the ESP8266) shows what I mean.

THIS is what I think an "Arduino Done Right" should look like.

Of course this leads to the issue of software. There are three things to deal with here:

1. Software for beginners.
2. Software for experts.
3. Bypassing the default software entirely.

Beginners should be faced with a high level language …

Show thread

… of some form, likely in the L0 line. Maybe the G0. There are other capable MCUs in Cortex-M0/M0+ space, however, so the key is not to tie yourself into one vendor with your design. Instead make a hardware design that can be easily backed by any MCU with suitable peripherals.

And that segues neatly into the next issue: interfaces. I'm a huge fan of Grove or Grove-adjascent connector styles. They're a good way to easily group and connect peripherals in pre-arranged ways that walk that …

Show thread

I'm back on track for pondering how to Do Arduino Right. Watching the "Maker" community struggle with the limitations of that environment and reaching for an RPi instead (which is like being frustrated using a tricycle to go cross-country so reaching for a Ferrari instead) always gives me the urge to design something better.

The first thing to address is hardware: use a modern, but simple MCU like something from the Cortex-M0/M0+ family. Given my own work experience I'd go with an STM32 …

Nightmare bug from Hell: identical code, identical hardware. Works when compiled under Keil. Fails when compiled under IAR.

The app in question is a vendor-provided "sample app" using the vendor's own (uncommented, undocumented) "application framework" that has more Callback Hell than a Node.js application.

All of it uncommented.

After a week (!) of piecing through the code in Keil and IAR interlaced, finally figured out the RTC isn't firing for some reason in IAR.

Happy happy joy joy joy.

So, I found out that the first person I followed here is an ASN.1 fan. It's been such a lonely existence being the only person who likes ASN.1 in all of my peer group.

Show older

Generic Mastodon server, open for registrations.