Developed On Hackaday: Sometimes, All You Need Is A Few Flags

October 1, 2014 by Mathieu Stephan 26 Comments

The development of the Hackaday community offline password keeper has been going on for a little less than a year now. Since July our beta testers have been hard at work giving us constant suggestions about features they’d like to see implemented and improvements the development team could make. This led up to more than 1100 GitHub commits and ten thousand lines of code. As you can guess, our little 8bit microcontroller’s flash memory was starting to get filled pretty quickly.

One of our contributors, [Miguel], recently discovered one compilation and one linker flags that made us save around 3KB of Flash storage on our 26KB firmware with little added processing overhead. Hold on to your hats, this write-up is going to get technical…

Many coders from all around the globe work at the same time on the Mooltipass firmware. Depending on the functionality they want to implement, a dedicated folder is assigned for them to work in. Logically, the code they produce is split into many C functions depending on the required task. This adds up to many function calls that the GCC compiler usually makes using the CALL assembler instruction.

This particular 8-bit instruction uses a 22-bit long value containing the absolute address of the function to call. Hence, a total of 4 flash bytes are used per function call (without argument passing). However, the AVR instruction set also contains another way to call functions by using relative addressing. This instruction is RCALL and uses an 11-bit long value containing the offset between the current program counter and the function to call. This reduces a function call to 2 bytes and takes one less clock cycle. The -mrelax flag therefore made us save 1KB by having the linker switch CALL with RCALL instructions whenever possible.

Finally, the -mcall-prologues compiler flag freed 2KB of Flash storage. It creates master prologue/epilogue routines that are called at the start and end of program routines. To put things simply, it prepares the AVR stack and registers in a same manner before any function is executed. This will therefore waste a little execution time while saving a lot of code space.

More space saving techniques can be found by clicking this link. Want to stay tuned of the Mooltipass launch date? Subscribe to our official Google Group!

Learning Assembly With A Web Based Assembler

March 23, 2014 by Nick Conn 47 Comments

AssemblyOnline Very few people know assembly. [Luto] seeks to make learning assembly just a little bit easier with his “fully functional web-based assembler development environment, including a real assembler, emulator and debugger.”

These days, you can be a microcontroller expert without knowing a thing about assembly. While you don’t NEED to know assembly, it actually can help you understand quite a bit about embedded programming and how your C code actually works. Writing a small part of your code in assembly can reduce code size and speed things up quite a bit. It also can result in some very cool projects, such as using Java to program microcontrollers.

With high quality example code, it is very easy to get started learning assembly. The emulator consists of a microcontroller with 32 registers, hooked up to three LEDs, two buttons, and a potentiometer. This is way better than painfully learning assembly on real hardware. Be sure to check out the online demo! Being able to step through each line of code and clearly see the result help make assembly easier to use and understand. It would be great to see this kind of tool widely adopted in engineering programs.

Have you used assembly in any of your projects? Let us know how it went and why you choose to use assembly

Macro Assembly For AVR Chips

December 12, 2012 by Mike Szczys 20 Comments

avr-macro-assembly

Here’s an interesting tip that can help improve your ability to write assembly code. In an effort to remove the complexity of assembly code for an AVR project [Quinn Dunki] figured out how to use macros when writing AVR code with the GNU toolchain. Anyone using AVR-GCC should keep this in mind if they ever want or need to pound out a project in assembly language.

If you look at the code snippet above you’ll see two commands that are obviously not assembly; PulseVRAMWrite and DisableVRAMWrite. These are macros that direct the assembler to roll in a hunk of code. But avr-as, the assembler used with this toolchain, lacks the ability to handle macros. That’s too bad because we agree with [Quinn] that these macros make the code easier to read and greatly reduce the probability of error from a typo since the code in the macro will be used repeatedly.

The answer is to alter the makefile to use GNU M4. We hadn’t heard of it, but sure enough it’s already installed on our Linux Mint system (“man m4” for more info). It’s a robust macro processor that swaps out all of her macros based on a separate file which defines them. The result is an assembly file that will play nicely with avr-as.

Her implementation is to help in development of the GPU for her Veronica computer project.

Hardware XOR For Output Pins On AVR Microcontrollers

July 9, 2011 by Mike Szczys 30 Comments

Did you know that most AVR chips have a type of hardware exclusive OR (XOR) option when it comes to the logic levels of the output pins? If you look in the datasheet (the image above is a screenshot from an ATtiny13 datasheet) you’ll find a section on Toggling the Pin. It turns out that if you set a PORT as an output, writing logic one to the corresponding PIN register will toggle the logic levels of that out. This is really easy to overlook if you’re writing in C, but I’ve been working on learning a bit of assembler language and found this to be very useful. Keep reading after the break and I’ll tell you how I happened upon this info and what it’s good for.

Continue reading “Hardware XOR For Output Pins On AVR Microcontrollers” →