#embedded systems

[moose-mousse]

I have once again caused panic in an entire firm( not the one I work for ) :3

Every. Single. Microcontroller. They have ever made have errors in the bootloader. This will cost them a few millions at least.

Which I discovered via the hidden technique of *checks notes* reading the manual...

I will say this always. The tech industry on the whole is incompetent. They follow only the regulations they have to, and there are nearly none for software.

If you can write sentences without undocumented abbreviations and read the manual, you are in the top 20% of software developers.

While I was working I was asked several times if I had used chatGBT to try to solve the problem I was having at that time. And always answered "No. I need garantees that the info is correct".

Like, no. The problems that have come from people not reading the manual and just guessing if things worked will not be improved by asking the propaganda malware machine that spies on me, and studies have found makes you worse at anything you use it for.

[merklehellman]

So today i finally sat down to the SPI modules i bought recently. I was most interested in the SD card slot, because i think having removable flash storage is better than having flash storage soldered on board and on the other hand the LCD screen seemed kinda scary.

I wrote some code, the way i usually like by making references to datasheet chapters etc. Everything was going well but the card did not work. I knew it was ok since it worked when plugged to my PC, but it was not responding to my init commands over SPI.

I googled and googled but nothing seemed to work. I tried my no-name logic analyzer but for some reason linux didnt recognise it - it used to work a few years ago but no more i guess.

Eventually i decided to check all the data that is being transmitted to the STM32 chip by changing all the writes into read/writes. Turns out MISO line was high all the time, non stop. This activated some alarm bell in me since it looked like an electrical error.

Eventually i found some random thread about arduino with what seemed to be a similar problem. What i did not mention is that SD cards work with 3.3v (afaik) which is not a big deal since stm32 also works on 3.3v. Sometimes one might want to plug them into a 5v circuit though and to accommodate that, the board i bought contained a voltage level regulator type of chip forgot the name. Essentially converter between 3.3. and 5v signals.

Apparently, in some cheaper no name modules like mine, this type of chip bugs out and keeps on holding the MISO line high despite the fact that SD card has let it go long time ago. This sounds like exactly what is happening to me.

Solution? Glorious:

Bypass the voltage converter. 3.3v should still be considered high state even by 5v circuits, so it should work.

I appreciate the random person who just bumped into a random thread after 2 years of inactivity and just dropped this knowledge. These folks are the backbone of the internet and im glad to have been in his position once or twice myself.

I myself did not feel like soldering that wire, especially since the pad on the socket is super small and these modules are very cheap. Since STM32 works on 3.3v anyways, and atmegas also have low voltage versions nowadays i decided to just buy another module which has no additional ICs on it - no voltage regulators, converters etc, just plain SD card socket and routed connections, maybe a resistor or two.

Funny thing in the end, but also kind of irritating, since it took me long enough to finally sit down and start tinkering with this stuff. Also it might turn out there's a different problem at play and i just bought some more electrojunk for no reason. But then again, i put some more sensors and SPI fun stuff into the basket when i was orderign the new module, so there's always new stuff to look forward to.

Oh also im using rust for this with rust-embassy, just because stm32 HAL is ugly and i dislike it very much. Rust has been great so far but it's kinda hard to find out how to do stuff outside of examples in their repo.

[verilog-official]

Gentoo on the Arduino Uno Q

Yesterday, after perusing through Micro Center, I stumbled across an Arduino Uno Q. At the time, I had no clue what it was. It seemed very interesting on the box, so I decided to buy it.

I'm gonna skip everything about the unit itself, but it's basically a Raspberry Pi Zero strapped to an STM32 with glue logic.

Now, I am a huge fan of low level hardware shenanigans. Unfortunately, the preinstalled OS has a lot of that abstracted away. Which is great for most users, but I wanna get down and dirty.

It seems that I must be the first one to attempt to install Gentoo on this silly little thing, which is honestly surprising.

There's.... very poor documentation on how one would begin going about this. The manual mentions a USB boot jumper, which one would think allows it to boot from USB mass storage, but really just puts it in firmware download mode.

This means that in order to install an OS onto it, I need to install it elsewhere, like in a VM or chroot, create an image file that is compatible with the flashing software, and then upload that to the unit.

The documentation has a tendency to say "just use the software we made." Everywhere. They don't even have direct links to the firmware image, I had to dig through the source code of the flasher utility to get it.

Speaking of the flasher software, it seems to be not much more than just a fancy frontend to the "qdl" utility. All it does is gets the image, extracts it, and runs qdl.

I have very little experience with qdl, so I decided to just use the pre-existing image as a template.

There is a bunch of small partitions I decided not to mess with because I don't wanna brick the thing, and three very large partitions: one for root, one for home, and one for the ESP.

In the source code, it chooses between two program files to pass to QDL to tell it what to program -- one for a separate root and /home (rawprogram0.xml) and one for a single rootfs (rawprogram0.nouser.xml). I decided to go with the latter, for reasons that will become apparent later on.

Luckily, once you extract the tarball for the image, all the partitions are just plain raw image files, meaning that I can easily mount them. (mount disk-sdcard.img.root /mnt/gentoo)

Now that I have the target drive mounted, I installed and set up qemu-user for aarch64, to prepare for a chroot. This is necessary if you're using a computer that isn't aarch64.

I completely wiped the rootfs (rm -rf --one-file-system /mnt/gentoo/*) and extracted an aarch64 musl gentoo stage3 in its place (cd /mnt/gentoo; curl <url> | tar -xpJf - --numeric-owner --xattrs-include '*.*').

I mounted the ESP partition as well (mount disk-sdcard.img.esp /mnt/gentoo/boot) and entered the chroot (arch-chroot /mnt/gentoo).

From here, I installed a very quick and dirty basic install. If you want to replicate this, just follow the Gentoo AMD64 Handbook, it's close enough.

Finally, once I was done, I exited the chroot, unmounted the ESP and rootfs.

Now, to flash it, I placed a jumper on the bottom pins of the JCTL header (the side away from the USB port), plugged it into my computer, and flashed it with the following command, executed within the "flash" directory:

qdl --allow-missing --storage emmc prog_firehose_ddr.elf rawprogram0.nouser.xml patch0.xml

Note that I'm not sure what most of this means or does, that's just what the flasher software does under the hood.

Upon next reboot, I was greeted with Gentoo! Except... It's still using the old kernel and old bootloader. Still have to figure that out.

There's... some problems with that, namely that it doesnt have the kernel modules required for a lot of the functionality, so you have absolutely no network, bluetooth, or anything really. Unfortunately it seems that the EFI variable subsystem is locked read-only or something, so changing the bootloader is a little harder than just "grub-install"

[yingyoyingsh]

My mentor for electronics and embedded systems is sooo good at teaching istg. I walked up to this man after his class and I asked him and he explained the basics in 15minutes and when I thanked him he said “thank YOU for your queries “ bro he almost made me tear up cuz Engineering professors/mentors have been real rough 🙌

[just-my-insufferable-existance]

Should I actually make meaningful posts? Like maybe a few series of computer science related topics?

I would have to contemplate format, but I would take suggestions for topics, try and compile learning resources, subtopics to learn and practice problems

interest?

yes

tbh not interested

Voting ended onMar 13, 2024

[andmaybegayer]

I got these ultra-cute little ESP-32-C3 micros the other day, they have teeny tiny 0.42" OLED displays built in, fantastic for putting a little sensor data or debugging info on. This is written on the Rust for ESP32 ESP-HAL using the embedded_graphics library.

That's a USB-C cable it's plugged into, for scale. You sacrifice some IO on this model but my plan is to use this to talk to my little air-quality sensor and have it report back to a server somewhere. This board takes battery power but I don't think it has battery management, I'll need to see how that works. I have lipo chargers lying around.

These are also the first RISC-V processors I've programmed. Fortunately as the guy who was my boss for like three months one time told me, you mostly don't need to care what the underlying architecture is unless you're doing really heavily optimized code or writing compilers. The ESP-RS project also works for the older Xtensa chips, which is handy especially because some of those are dual-core.

Unfortunately I've had trouble getting ESP-IDF-HAL to work, which is what you need to talk to the wi-fi side of things, but that is probably just me being absentminded somewhere. I'll figure it out, without wi-fi the ESP32's are much less interesting. There is an experimental wifi library for this HAL but if you're going to be doing networking you probably want the stdlib on your side anyway.

[itrunsdoom]

Your bootloader? Yeah, it runs Doom.

Freshly sent in by Ahmad over at Pengutronix: A port of Doom to Barebox, an open-source bootloader for embedded devices. Quoting the submission message:

I’ve since seen it running on a x86 Laptop under UEFI, on an ARM-powered tractor panel and even on a RISC-V emulator compiled to WebAssembly.

A porting guide has also been made available to aid others in the cause of making Doom run on heavy bare metal. Not the first time this has happened, oddly enough...

Thanks again to Ahmad for making, documenting and submitting this!