Background
Bare metal programming has a back to nature feel about it. We have unimagineable amounts of software, interacting in complex ways when we want to use computer hardware.
On 8-bit processors such as PIC or Atmega you are very close. A processor chip has a data sheet which you can use to see how you place instructions in memory so they will execute. You add your own peripheral devices and are responsible for programming them.
On 8-bit processors such as PIC or Atmega you are very close. A processor chip has a data sheet which you can use to see how you place instructions in memory so they will execute. You add your own peripheral devices and are responsible for programming them.
The Arduino IDE allows you to program in C on small systems like Uno or ESP8266. They are not far removed from the hardware, but have thorny implementation details removed and a simple setup/loop framework provided for your C programs.
For "real computers",32-bit or 64-bit devices which run linux (or Windows), and are capable of running many tasks simultaneously you are far, far removed from the hardware.
Bare Metal computing on RPi allows you to rediscover the hardware in all its gory glory.
Programming in assembler is a mugs game but in fact only a tiny amount of standard assembler code is required. Once the C environment is setup and you have a cross comiler to hand, you can write C programs without an OS.
Programming in assembler is a mugs game but in fact only a tiny amount of standard assembler code is required. Once the C environment is setup and you have a cross comiler to hand, you can write C programs without an OS.
Environment
My starting point is a RPi 1B. RPI2 or RPI3 would be suitable but I don't need their extra power or complexity.
Not all startup steps on RPi devices are open source, we do know that after initialising hardware an RPi1B loads a program kernel.img from a FAT formatted SD card and starts the ARM processor.
Our focus is to compile an appropriate program, name it kernel.img and place it on an SD card so that it will execute.
Our focus is to compile an appropriate program, name it kernel.img and place it on an SD card so that it will execute.
We need a cross-compiler that will generate ARM code so I find it most practical to use GCC on Windows under WSL.
A variety of like-minded people have kindly provided tutorials. They include valvers, Jake Sandler, osdev, S Matyukevich, BZT and David Welch have put a lot of work into explaining the intracacies to help you get started.
For RPI1B David Welch's tutorial is absolutely perfect. His writeups are short but packed with pertinent details and his examples work faultlessly.
Blinking LEDs
Our first problem, as we start our program is that our bare RPIB has no software drivers. As is traditional on embedded systems our objective will be to make an LED blink.
David Welch's example blinker01 provides an assembler code stub and linking script so that the program is loaded at location x8000 and initialises stack pointers and registers for C. The C program then takes over and initialises GPIO16 (connected to "OK ACT" LED on board).
GPIO header details need to be included in the program to provide appropriate addresses for controlling the GPIO sub-system. Finally GPIO16 is configured, enabled and set to 0/1 causing the LED to blink.
GPIO header details need to be included in the program to provide appropriate addresses for controlling the GPIO sub-system. Finally GPIO16 is configured, enabled and set to 0/1 causing the LED to blink.
This is a huge step forward; we are running a program without any external threads or libraries, directly controlling the hardware. In fact the executable kernel.img is only 148 bytes.
Hello World
This is the traditional first program for most environments, printing out a message on the screen. It is so much easier to develop programs when you have a method of communicating back to the user what is happening. Flashing LEDs quickly lose their sparkle when they are the only way you have of understanding what the processor is doing.
Of course we don't have a screen to write output to. We certainly don't want to delve into controlling the RPI HDMI output and GPU at this stage, but luckily we can use the RPI inbuilt UART (GPIO14/GPIO15) to send to a terminal/minicom/Putty session. The GPIO TX/RX and GND pins were connected to an FTDI connector with a USB cable attached to Putty on the PC.
My first attempts at programming the UARt failed to work, I don't know why. I tried different tutorials, RPIs, compiler options, terminal connections, all without success.
On reading that the mini-UART is easier to program I tried this instead. I was relieved and amazed when I put David Welch's UART01.bin on the SDcard and started it up to find it works perfectly, displaying digits as fast as it can. The C program includes UART headers and initialises the UART. It then has a simple putc function to output characters.
It is a small extra job to read input from the terminal session and echo characters out to the screen. We can now do terminal I/O, another huge step forward.
It is a small extra job to read input from the terminal session and echo characters out to the screen. We can now do terminal I/O, another huge step forward.
Bootloader
Each time I want to test a program I have to take it out of the RPI, copy across a new kernel.img, replace in RPI and restart. This quickly becomes irritating. The marvellous David Welch has written a simple bootloader program.
To use this you put bootloader06.bin as kernel.img on the SDcard. Now whenever you power up RPI a bootloader is started. The bootloader waits for a program to be transferred across the serial link using xmodem file transfer. I used minicom or ExtraPutty to transfer the file. Pressing 'g' causes the program to run. To use a different program simply power cycle the RPI and load another executable.
This is another huge step forward for me. It gives me a practical environment to work in.
No comments:
Post a Comment