[ Programmer | Kernel Driver | Programming Software | Assembler/Linker | (Debugger) ] | (Simulator) ]
Currently, I'm working at a tool chain for providing powerful and easy support for Linux development of Atmel AVR 8-bit RISC software. Some tools are already available, some others are still under development. It is sufficient for me so far and I never had to find any Windows machine for AVR programming. :-)
The goal is to have all the things described below.
If you are interesting in these projects, please contact me under contact@theiling.de. I was simply too lazy so far to compile packages of the things that already exist (shame on me).
Status: documentation available
The hardware serial programming interface is very simple for AVR microcontrollers. I built a small interface for the parallel port. It currently only supports 5V designs. The hardware is protected with bus-line drivers to prevent burning the PC hardware when the first big bug occurs, and to feature in-system programming.
 |
 |
| Fig.1: Laptop interface (parallel port) | Fig.2: Self-powered board with some sockets |
Additional to the 6-pin standard interface that Atmel defines, the programmer I built supports three independent clock (SCK) signals so that up to seven devices can be programmed through one plug (and three without additional hardware). It is small and nice when mounted in cabinets for external access. Further, the design allows to power the programmed circuit if that is desired.
  |
  |
| Fig.1: Atmel 6-pin interface | Fig.2: Own interface with 3 SCK signals |
Currently, I have no parallel programmer, since the larger chips that I use more extensively even let you write and read the fuses and locks using the serial bus.
Status: software available
This consists of two parts: a kernel driver and a user-space application. Both are available in source code as free software and both are tested on some chips (1200, 2313, mega8, mega16). I built some projects with this software, using the tavrasm as assembler. The program can currently read, erase, and program flash and ee-prom.
Most chips (including newer ones and missing some older ones) have been entered into the programmer software so that it knows about fuse and lock bit names, locations, etc. You can program the fuses very easily from the command line:
muprog -program -fuses -cksel0:1 -cksel1:1 -cksel2:1 -cksel3:1
The MPU type is automatically detected, so it need not be specified on the command line.
The kernel driver can be configured from user space with a small configuration file describing the particular programmer hardware. It allows negation on each pin and features assignment of multiple (output) pins to one signal (e.g. for programmers using parasitic power from the host). My programmer is described as follows:
d1 -> mosi d4 -> sck0 d5 -> sck1 d6 -> sck2 /select_in -> reset /autofd -> power /init -> ! enable /ack <- miso busy <- ! power_sense * = 1 # All other lines should be 1.
Kernel Driver
Download Programmer Application
Status: software available (alpha)
I never tested any Win software for the AVR, I did not even unpack the Atmel development tools. I assumed that tavrasm is at least weakly compatible with Atmel's macro assembler. However, I needed more features than tavrasm provides, especially concerning program structure (.begin/.end/.proc/.module), scoping (.export/.local/.global), macro expansion (named parameters, export of .set/.def and labels), conditional assembly e.g. for recursive macros (.if/.else/.endif/.unless/....), and assembly-level message handling (.error/.warning/.assert). All the above features are implemented already. Further, the scanner/parser tavrasm uses does not parse the ‘official’ *def.inc files (due to the 'OR' definition), which I also did not like, and it does not provide for .def commands on the X,Y,Z registers. There are many small thingies that made me want to program my own assembler.
Further, I plan to be able to do the code generation in two step as usual: assemble + link. However, my smart linker is not yet finished, but currently, the assembler uses its simple internal linker.
One feature that I want to have for my current project is a cycle checker: I want to state that relative a certain label, another label is within a to b cycles.
a:
nop
nop
.cycle pc - a == 2 ; ok
b:
nop
nop
nop
.cycle pc - b == 2 ; Error: Cycle difference is 3, not 2.
I also want to state that all instructions inside a given block are in sync with a cycle counter, so that the following sequence raises an error:
.cycle tolerance = 0 ; must all be in sync.
sbrc r16, 0
rjmp a ; takes 1 cycles if skipped, but 2 if taken.
a:
nop ; Error: Instruction might be reached 1 cycle out of sync.
The precise syntax is still in flux. The technique to implement this easily with is Abstract Interpretation.
Status: planned
This is a long term goal. I want the simulator to be cycle-correct and to support descriptions of port activity to really simulate the environment as closely as possible. A future project.
Status: planned
This is also a long term goal. The debugger should attach to the device either via JTAG or via new debugWIRE port. Talking of which, the programmer should be able to use the JTAG bus, too.
|
