Assembler Course projects (ARM architecture)

Well, I do know writing ARM assembly is about as pleasant as punching yourself in the kidneys repeatedly. So there's that.

Kamakaze pilots and ARM compiler writers have a lot in common.

I can understand wanting to _understand_ assembly language for embedded processors, and maybe use it on some 8 bit architectures, but as even the lowliest ARM Cortex is like 50MHz and 64k of RAM it seems like a very self-punishing exercise to write an entire project in assembly.

I even use C++ on some 8 bit AVR projects. So long as you're careful/clever about your memory management and don't use a ton of very heavyweight STL containers or a lot of runtime polymorphism/virtual methods (runtime polymorphism is bad) it works fine. std::vector is nice to have and works fine.

Even modern 8 bit processors are not yer dad's 8 bit processors.

Except in the cases of very small processors (like, less than 1K of ROM) or very C-unfriendly processors, I think it's better to just stick to C.

Even for a sub 1K-ROM processor that's C-friendly it may be better to use C that's carefully written to avoid pulling in any library code.

Allow me to cross post this to a nearby friendly pi group.

Thank you,

Allow me to cross post this to a nearby friendly pi group.

Thank you,

I'm fortunate enough to have never had to do a serious project using one of those itty bitty ones.

The AVR Mega series usually has like 32 or 64k of program memory and a couple K of SRAM. It's pretty luxurious, even for C/C++! You can fit a lot in there...

I've done a tiny bit with a PIC12. But what was needed could have been done just as well with a PAL -- it's just that I had a PIC12 development kit in my junkbox.

Is there even a C compiler available for the PIC12 series? Using ASM for those devices is probably sensible as IIRC the ISA for that line isn't really optimized for C, while all the AVR devices share a common core architecture which was intended from the outset to lend itself to compilers generating optimal ASM from C for it. But the PIC will usually beat AVR on price/product longevity last I checked. (the old debate)

Some of the abstractions that C++ provide are really nice to have in the embedded world. For example "policy based design":

lets you do things like the thing I did with a display driver I wrote a while ago: you have a common "core" class for the particular architecture you're targeting that handles all the generic "low level" stuff for driving any kind of display (essentially, timing and bit-banging the pins/sending data over a I2C/SPI bus), and then you can write "plug ins" at a higher level of abstraction for different types of displays.

So if on one project you need to use a 7 segment display, and on another a 2 line LCD, etc. you only need to rewrite the higher level policy, and plug it in to the base class. The base class functions as an "abstraction" of any type of display that you can stream characters to the same way you would a terminal console, and the policy handles the specifics.

Yes to all of that. In addition, at least the last time that I went shopping for parts, the PIC parts could drive about five times more current on each pin than an AVR.

Thank you every one of you folks. Pace !