[David] is building a project with an OLED, a keyboard, and an RP2040. He’s perfected a scanning routine in C to work with the keyboard, but he still had some places he wanted to use even lower-level instructions. That was as good an excuse as any to experiment with inline assembly language inside the C program.
The goal was to grab the keyboard’s input and stick it into a memory address register so the data at that address could be shown on the display. However, there was a complication because memory access of this type has to be word-aligned.
Sure, you could mask the low bits of the address, do the read, and then set an index to pick the specific byte, but assembly is easy, and it is good to know how to put it in your code, anyway.
[David] only needed one instruction that is meant for byte access, so as assembly embeddings go, this was quite simple. We’ve done similar things for Linux, although, of course, the Arm assembly language here is different than what we used.
You probably don’t need assembly for every project. But it is nice to know how to do it when you need it. Many people think you don’t need to learn assembly these days, but we mostly disagree.
David tutorials about are fantastic! The Pico PIO series are the best I found about such peripheral.
I love his PIO series. Agreed, very much worth watching.
The datasheet / manual is surprisingly good on that subject too. Great worked examples, etc.
PIOs are super fun.
what”s wrong with wiggly = *(char *)booger?
for real. if you want to know the answer to this question, you’re going to have to read a C programming blog in its worst possible format, youtube.
i will do without knowing until/unless this alignment problem bites me directly, unless someone wants to summarize for us in the comments here.
haha i genuinely wanted someone to tell me the answer to this question, i wasn’t just being snarky.
since no one did, i looked. i seeked around in the video until i found the functions in question – readOneByte() and writeOneByte() which are each single-instruction inline asm blobs, wrapping ldrb and strb respectively. and then i verified that the rp2040 compiler i use — arm-none-eabi-gcc (version 10.3.1, with and without the -mcpu=cortex-m0plus -march=armv6-m for rp2040) generates ldrb and strb for regular (char *) dereference.
so this use of inline asm is entirely gratuitous. the compiler already provides readOneByte and writeOneByte primitives, they’re pronounced *(char *). and looking at the code style, i find a lot to disapprove of. so, kind of vexingly low quality content imo.
but otoh it is good to show people that inline asm isn’t that hard.
oh and i should be the change i want to see in the world, and provide something genuinely useful!
if you don’t know it, you should: gcc -S will generate the assembly. like “gcc -S buh.c” will create buh.s. gcc doesn’t generate the most readable assembly of any compiler i’ve used but it’s nonetheless pretty usable / useful. and especially if you’re tentatively stepping into using gcc for an ’embedded’ platform like rp2040, it is a godsend to be able to verify your assumptions. in my experience, it’s very hard to trust a compiler when you’re used to controlling everything directly (the handicap that seems to have led youtube David astray)…and nothing will help you get over that distrust faster than actually looking at what it’s done.
there are definitely surprises to be discovered when looking at gcc-generated asm!
(stands up, clears throat) My name is Jeremy, and I am an assembly language programmer. Assembly is my favorite programming language, by far.
I /was/ a professional assembly programmer working on embedded processors for over two decades. Then C came along and I have never looked back. C can be considered as an assembly language for a generalised virtual machine, with additional program structures like IF, FOR and CASE built in. Of the few occasions I needed to look at the compiler’s C language output I only once needed to make a change to improve execution times.
I can now write algorithms without having to count the fenceposts*. FWIW I still enjoy assembly programming, so long as I am not compelled to do it!
(*) Obscure reference to ‘off-by-one’ errors.