2022-01-26
1. Preparation
1.2. Setup review
Here is a single video and page that walks through setting up our assembly (and later C) development environment (WinAVR and avr_sim).
2. Class time
Create a new project in avr_sim and somehow obtain assembly code from the video from § 1.3 (see also Figure 1).
-
Change the inner delay loop count to 3 and outer delay loop count to 2.
-
Simulate the execution of this code using avr_sim.
-
Create a graphical flow chart that matches the behavior of this code.
-
Translate the assembly code into an equivalent C program.
-
Modify the code to use
BRNEinstead ofBREQbranch instructions.
3. Lab preparation
Become familiar with the available content at RJHcoding.com - AVR Assembly Tutorials.
Notice that we’ve effectively looked at Example Programs #1 and #3 already, though those are for the ATmega328P MCU instead.
Part of the Lab 1 activity has to do with how you create “functions” in assembly, which are called subroutines.
You will also work on toggling an output pin as fast as possible while maintaining exactly 50% duty cycle.
4. More reading
4.2. HEX files
A programmer is a device which accepts a description of machine code for a particular MCU and takes the actions necessary to put that code into the MCU’s program memory space. There is no particular need for a programmer to be the same software as an assembler or compiler and therefore it makes sense to have a file format specific for its input.
4.2.1. Intel HEX
A common format for these files is called Intel HEX, which dates back to the 1970’s, along with the first microprocessors and need to describe and transfer this type of information.
There are many tools to read and write this format, but its simplicity also makes it easy to write your own tool, such as rcf2ihex.py demonstrated in the recent video.
4.2.2. Universal Hex Format
The micro:bit project is on its second generation of hardware, with a different MCU. Therefore, code compiled for micro:bit V1 is not compatible with micro:bit V2. To still maintain the project’s objective of easy code upload, they needed to design a solution to have one "code file" that is compatible with both boards.
micro:bit Universal Hex Format Specification describes an extension of the Intel HEX file format that allows a V1 board to read the new file without problems while also containing the code for running on a V2 board.
While creating a new or variation of an existing file format is possible, such a decision also therefore means that the developer needs to create or modify all of the tools which interact with the file. Perhaps that time and effort would be better spent achieving the main objectives!
Please read through that document, as it does a good job of describing the requirements, legacy constraints, and testing and experimentation to verify the solution. It lays out the case for creating such a custom format and the good reasons that the solution is better than some of the alternatives.
4.3. Memory
The class videos showed the simple memory layout of the ATtiny85 from its datasheet. Since the examples were directly specifying the machine code bits and the memory location directly, there was no need for a more abstract mapping of entities to their address locations.
We will cover linkers and memory maps later, but you should first watch this video as an introduction to the subject:
4.4. PlatformIO
PlatformIO forum: Pure AVR Assembler programming