Some microcontroller projects require the generation of random numbers. The first thought is to simply use the random() call provided by the compiler libraries. That function provides psuedorandom numbers which will probably seem random enough at first pass.

Unfortunately, you may realize that after some usage, the random numbers generated by this function always gives the same sequence of results. This is caused by the microcontroller always using the same seed for the generator. If you want the numbers to no longer be completely deterministic, you will need to provide a seed to the random number library. This is typically done with srandom(uint32_t). By providing a seed, you can initialize the random library with a different state.

The question becomes, “what can you use as a seed?” If all your devices have unique serial numbers, those could be used. Then at least each of your devices should have a different sequence of random numbers. Unfortunately, those sequences would still be the same on each reboot for a single devices. Below I will present a method for getting enough entropyon an Atmel AVR to seed the generator for what I call “usefully random.”

The Atmel AVR Mega series has several different oscilators which are not phase locked. This means that you can use the interference between these oscilators to provide some variability. The easiest way to do this is to setup an interrupt off of one oscillator and count the ticks of another oscillator. For example you can setup a Timer/Counter to run from the main high speed oscillator, and have the Watchdog Timer running from the 128kHz oscillator trigger an interrupt. From the interrupt the counter can be queried. There is quite a bit of jitter between the oscillators which means that the lowest few bits in the counter can be used for entropy. Just do this a few times and rotate in the bits to a 32 bit value. Then that value can be used as the seed.

An additional source of entropy can be obtained by sampling a floating analog pin repeatedly. The bottom couple of bits can be used as noise measurement. By mixing both approaches, it is pretty easy to have enough entropy to seed the generator in less than 100ms after booting, allowing for use of the ADC and Timer/Counter for other application purposes.

I wanted to write down my notes for getting Ubuntu Linux fully running on an Asus H87M-E with a Intel Haswell processor. I use this on a media center, so I needed HDMI video and audio support.

• Ubuntu 13.04 is required for support of the Haswell GPU.
• Linux kernel 3.10 is required for HDMI audio support.
• I used Upubuntu to install 3.10.7 for my system.
• Never use an older (1200/1500 series) Sandforce Controller SSD with Haswell Motherboards.
• The hardware controller is a NCT6791D. You will need a very recent version of the nct6775 driver. It will probably be merged in Linux 3.12.
• If you use Western Digital Green Drives on Linux be sure to look at idle3-tools.

Here is a script that I wrote to setup the fans in a way useful for my system. One fan sits on my HDs, so I wanted to regulate it based on their temperature.

When the ARM architecture made its way into micro-controllers it also made the von Neumann architecture more common in firmware development. The main effect that this has is allowing execution of instructions from memory. The unified memory model allows jumping into Flash or RAM. Some processors even load the entire Flash into RAM before on boot and execute only from RAM. This allows for the potential to have self modifying code. Which while dangerous from a safety standpoint, allows for some cool tricks. Sometimes the RAM and Flash are different speeds which allows either faster execution when code is in RAM or a shallower pipeline to flush on branches. This architecture also means that data in Flash can be read as easily and often as quickly as from RAM and constant structures compile cleanly.

Most ARM micro-controllers support using the ARM Thumb instruction set which is a subset of the ARM opcodes which only use 16 bits instead of the normal 32 bits. The reduced instruction set still provides all operations but limits the number of registers that can be accessed. It does sometimes require more instructions to do the same work, but for the most part the code density is much higher in Thumb mode. ARM thumb instructions can often have even higher density than 8 bit micro-controllers due to the ability to handle 32 bit math operations with a single operation.

The addition of ARM also brings lots of options for compilers. GCC, LLVM, IAR, and several others provide varying levels of support for micro-controllers and various levels of optimization for the Thumb instruction set.

In addition to the Flash and RAM on the micro-controller, there is a chunk of address space dedicated to the peripheral registers. These registers provide the interface to all the peripherals which are probably the reason that you chose the mirco-controller. There are two ways that the peripheral registers can be addressed. The first is via memory access. Usually there is a dedicated hole in the memory space which addresses these registers instead of RAM. That means that load and store instructions to these addresses will handle reading and writing to the peripheral registers.

The second approach is via special instructions. The AVR uses this approach to access the lowest registers. The intention is for these to be the most commonly used ones, but it never seems to work out that way. The limited number of registers that can be accessed this way is because there are only a few bits available in the opcode to act as addressing for the instruction. In order to access all the other registers, they must be addressed by the first approach. On the AVR this method only take one instruction while the first can take 3. Two instructions to setup an address pointer and one for the load or store immediate. Thankfully, the gcc compiler will handle figuring this one out for you.

The small PICs have their own oddities as well. Instead of using 16 bit addresses to access RAM, they rely on a concept of memory banks. In order to access memory, a bank has to be set which determines what memory can be addressed using the load and store instructions. For each bank, there is a chunk of addresses devoted to registers, followed by RAM, and a small chunk of common RAM. The common RAM is the only part that is the same no matter which bank is selected. Accessing memory that is all in the same bank is compact, but if several items need to be transfered between pages then a lot of instructions are wasted shuttling the values between banks.

Typically Flash is read only by the instruction fetcher based off of the program counter. However when writing to Flash you often need to consider that it is composed of what are known as blocks and pages. A block is a chunk of Flash memory which has to be erased as one unit. A page is a piece of Flash which has to be written as one unit. Typically a block contains more than one page. If you never plan on writing self modifying code (bootloaders) then you will probably never need to worry about this. But if you need to change portions of the Flash you will need to handle erasing at the block level and writing at the page level. If you wish to modify only parts of the Flash, then you will have to store the previous values, erase the block, and rewrite all the pages.

Modern micro-controllers are basically Systems on a Chip (SOC) with memory integrated into the package as well. The lack of external memory buses allows for smaller packages and pin counts. It also greatly simplifies the use of these parts.

Many smaller micros (PIC16, PIC24, AVR) are setup in what is known as the Harvard Architecture. This means that the executable memory and data memory are completely separated. Instructions cannot be executed from the data memory, and the different memory sections can be addressed in completely different ways.

Usually the executable memory is on Flash or ROM (rarely now days). While the processor is able to directly fetch instructions from Flash, there is typically no way to directly read variables from it. Usually special retrieval instructions or address remapping are needed. Some compilers will automatically use the constructs for any constant variable reads.

Furthermore, Flash and RAM don’t even need to have the same line size. The PIC16F series has 14 bit instruction lines and 8 bit data lines. The PIC24F series has 24 bit instruction lines and 16 bit data lines. The AVR has 16 bit instruction lines and 8 bit data lines. The odd flash word sizes can often make constant storage complicated. The compilers for the two PICs usually store constants in just the bottom 8 or 16 bits of a line thus wasting big chunks of Flash if you use lots of constants. If you want to make full use of the storage, you must use the Flash peripheral registers instead of the simpler address remapping that the compiler uses. While the alignments are much cleaner on the AVR, all Flash data reads have to be done with a special load instruction. So it falls in between the two PIC methods in complexity.

Details on these operations are a topic for a future post. Next time I will cover Peripheral Registers, Flash Pages, and Memory Banks.

I plan to write several articles on the core concepts of firmware development and move into more advanced topics. For the simple concepts I will probably be mostly referring to AVR processors due to Atmel’s freely available toolchain and their common use in Arduino designs. As I move into the more advanced concepts I will probably move on to other processors including various ARM processors.

Planned Core Concepts

• Micro-controller Architectures
• Assembly and C Compilers
• Registers
• Common Peripherals
• Interrupts

Planned Advanced Topics

• Direct Memory Access
• Asynchronous Programming
• Real Time Operating Systems
• Power Management
• Fixed Point Math

There are plenty of other resources for getting started with micro-controller programming for all kinds of chips, so I plan to skip any kind of introduction to coding in C and examples on getting started with a particular micro-controller. Instead I will mainly be going into the theory of operation on these topics in the hope that with that knowledge it will be easier to take the examples available in the wild and tame them to your needs. The intended audience is expected to have a software engineering background.