Software Engineering involves the design, coding, testing, and debugging of electronic computer software.
This page is intended to provide some history of computer processor architectures used as spacecraft guidance systems and others that are more practical for the student or hobbyist to work with. For those processors that are more practical for students and hobbyists, the page provides pointers to software that can help with the engineering of micro controller software. Any software referenced here is either free, inexpensive, or demo software so it can be tried without initially investing significant money. Where possible we've included a link to the site where you can get the latest version rather than a direct download of a possibly stale version. All CPU software development tools mentioned here will be for 16-bit or 8-bit micro controllers since there are plenty of Linux, Unix, VxWorks, and Windows based tools for most 32-bit and 64-bit CPUs.
The most fundamental development tool you will need to develop software for a micro controller is an assembler. For the beginner, an assembler takes a text source file of processor architecture specific assembly source code and converts it into bytes of that processor architectures machine code. This machine code is typically written to a *.bin file (binary file format), *.hex file (hexidecimal file format), or sometimes a *.s19 file that can be uploaded to the controller or burned into its PROM. The file you can load to a particular microcontroller will depend on the type of memory (PROM, EPROM, EEPROM, flash, etc.) the microcontroller chip or board uses and on the download interface software or PROM programming software you are using.
A higher-level programming language compiler can be used to generate the assembly source code or some will create a machine code binary file directly. Languages such as BASIC or Forth might compile into the machines instructions or they might compile into an intermediate instruction file in which case they will have an interpreter or runtime that will need to be uploaded to the controller along with the file to execute the code. Procedural languages such as Fortran, Pascal, and C are typically compiled into the machines instructions and might have a library of support routines that should be included in the assembly code or binary file if used in the code. Some programming languages encourage object oriented programming where collections of data and code in records, structures, or classes are used to model objects in the world. The concepts or object oriented programming originate from the Simula programming language. On the other hand, data-oriented design is a programming approach motivated by optimizing data access, typically used for video games (usually implemented through the C programming language). This approach is similar to the concepts in the Forth programming language which focuses on data layout in arrays for fast access. C++, an object-oriented programming language (OOP) descended from C and Simula, is also typically compiled into the machines instructions and has a library of support routines that should be included. Other object-oriented programming languages such as a Java or C#, descended from C++, will create an intermediate instruction file that would need their runtime to be uploaded to the controller along with the file to execute the code, and these languages use a memory management technique called garbage collection that also requires their runtime to execute correctly. In all cases software developers need either a compiler that is processor architecture specific or a runtime interpreter that is processor architecture specific.
|Language||Object Oriented (OOP)||Data Oriented||compiled||interpreted||comments|
|Forth||yes||yes||typically||language based on a stack machine, no records, structures, or classes|
|C||yes||language used to write most of Unix, Windows, Linux and other operating systems|
|C++||yes||yes||derived from C language with OOP concepts from Simula|
|Python||yes||yes||requires runtime with garbage collection|
|Java||yes||yes||derived from C++, requires runtime with garbage collection|
|C#||yes||yes||derived from C++, requires runtime with garbage collection|
While it's easier to write source code in a high-level language than in assembly source code, it might be necessary to have more memory in your controller to load an interpreter or runtime or even more to support garbage collection. Along with the language you use, you might also leverage a library or framework of pre coded procedures, functions, or methods to save time from having to code everything from scratch. Additionally, you might want to use a real-time operating system (RTOS), but again these take even more resources on your controller.
Other helpful tools include applications that allow you to test and debug the execution of the machine code you've created. If these tools are designed to work with the controller board, they can be used to upload the binary to the actual controller. Debuggers also exist that allow you to test the code without the hardware. They do this by simulating on your desktop computer most of the behavior of the controller. While a simulating debugger might be easier to configure, you won't know the code really works the way you want it to until you upload it to the hardware. These tools are all specific to the controller or processor architecture family that you're developing for. The links below will help you find what you're looking for.
While assemblers, compilers, and debuggers, are all specific to the controller or processor architecture family that you're developing for, software written in higher-level programming languages does not need to be controller or processor specific. So if you have software for an algorithm written in C, and you have a C compiler for a Z80 processor and a C compiler for an AVR processor, you could compile the same software for either processors by using the appropriate compiler. Some common software items that you might need to code for are listed below.
A real time operating system or executive is different than early desktop or disk operating systems such as CP/M, ProDOS, or MS-DOS. The former allows multiple processes to execute at once and will have a timer to interupt processes and change what is executing. The later focused on allowing users to store and retrieve files from permanent storage, but typically only allowed one process to execute at a time. A real time operating system or executive has defined time constraints. Processing must be done within the time constraints or sensor data might be lost or control actions might not occur at the correct time. Thus, most common older operating systems for small systems are not applicable for control systems. Linux, Unix, and Windows 32-bit and 64-bit operating systems are designed for multitasking and have timers to interupt processes to enable this. This makes them capable of having real time variants that can be used in constrol systems.
Software that uses sensors, possibly combined with maps, to determine a crafts location is navigation software. Simultaneous localization and mapping (SLAM) is the software problem of keeping track of a location in an environment at the same time as constructing a map of that environment. Kalman filters are quite often used in the algorithms used to solve SLAM. Even before SLAM became an acronym, Kalman filters were used in the Apollo Guidance Computer software when navigating on the way to the Moon.
Guidance software takes information from naviagation, and information about a desired goal location or outcome and uses it to guide control software. So while navigation software can tell where a craft is at in an environment, guidance software can tell a craft how to move or what action to take in order to get to a target destination or outcome. For example, Dijkstra's algorithm is an algorithm for finding the shortest paths between nodes in a graph, which might represent waypoints on possible paths through a terrain. Beyond Dijkstra's algorithm, the A* algorithm achieves better performance by using heuristics to guide its search for the shortest path.
This is probably the simplest of these catagories to code for. Control software is the portion of the software that actually turns on or off lights, solenoids, or motors. This is typically done by setting or clearing a bit in memory or IO space or even just accessing a memory address. In turn, this action generates an electrical signal outside of the CPU that turns on or off the light, solenoid, or motor. Sometimes things can be more involved requiring a bit to be pulsed through software in which case a timed task or interrupt might be needed.
Some processor architectures used as controllers are described below. A common question is "what micro controller should I use...?" My advice would be to choose a controller that has a full set of development tools if your strength is electronics and a controller that has all the hardware you need built in if your strength is software. While architecturally the 8096 architecture was one of my favorite processors, the lack of availability of chips and tools makes it impractical to use anymore. I would currently recommend either an AVR processor on an Arduino board or a Z80 processor on any number of boards or on a build yourself board.
Some processor architectures are described as being RISC processors. RISC stands for Reduced Instruction Set Computer. The meaning of RISC is not that the processor architecture has a reduced set of instructions, but rather that the complexity of the instructions is simpler, typically having few if any addressing modes beyond loading memory addressed by a register. Processor architectures designed with complex addressing modes are described as being CISC processors. CISC stands for Complex Instruction Set Computer. A CISC processor will typically have a mix of addressing modes allowing for addressing memory with registers, constants, register + constant, with the value that a register points at, and will have options such as auto incrementing or auto decrementing of registers. The advantage of RISC processors is that without instructions with complex addressing modes, instructions can be pipelined with multiple instructions being executed each at different stage of the processor at the same time. While RISC instructions might not have addressing modes that might be convenient to programmers or compiler developers, they allow instruction parallelism that allows processers to execute instructions faster. RISC processors also typically require fewer transistors to implement than similar CISC processors and thus can consume less power. On the other hand, CISC processors typically provide better code density allowing similar programs to take less memory. Note that because of misunderstandings of the term RISC and because of processor manufacturers trying to market their processors as the more modern RISC architecture versus older CISC architecture, sometimes processors described as RISC aren't really RISC processors. There are other processors types beyond CISC and RISC, such as VLIW or Very Large Instruction Word, but these are not as common and none are represented here.
Processors are also described as 8-bit, 16-bit, 32-bit, and 64-bit. There's even a 15-bit processor decribed below that was used in the Apollo spacecraft and a 24-bit processor that was used in the Viking landers on Mars. This terminology can also be misunderstood because it can refer to different characteristics of a processor. It typically refers to the number of bits a processor handles at one time. However, with the variety of processor designs, many processors don't do everything they do with the same number of bits. A processor might do two 4-bit add operations internally in order to do an 8-bit add, but as far as the programmer is concerned it appears to be an 8-bit processor. Another processor might do two 16-bit add operations internally and externally in order to do a 32-bit add, but as far as the programmer is concerned it appears to be an 32-bit processor. Similarly a processor might also do two 8-bit add operations internally in order to calculate a 16-bit memory address, but since most other math and logic operations are 8-bit, as far as the programmer is concerned it appears to be an 8-bit processor.
Other characteristics of processors describe their memory access or their register layout. Processors with a single memory space for code and data are described as von Neuman architecture. Processors with separate memory spaces for code and data and possibly multiple data are Harvard architectures. Processors where I/O operations don't have a seperate address range are said to use memory mapped I/O. Some processors view memory as a single flat address space, while others have banks of memory or segments of memory. Memory banks and memory segments are sometimes used as ways of increasing a processors memory address space, but can also be used to draw a distinction between code and data memory in von Neuman architecture processors. In desktop and server computers, flat memory is generally prefered, but in embedded systems its preferable to distinguish between code and read only data, which can reside in read only memory (ROM), versus data that needs to be in read write data. Also, some processors address their registers just like they're addressing a particular subset of data memory locations. Others have instruction encodings that specify registers differently than addressing data memory. Further, some processors are a mix that have very few registers, but have addressing modes that use subsets of data memory as additional registers that point to memory. There's examples of each of these below.
AGC (MIT Instrumentation Laboratory, Raytheon - 1966)
The great grand ancenstor of them all. One of the first computers built from integrated circuits. In some ways, the first personal computer, since it had a calculator type keypad called the DSKY. It ran a simple real-time control program with pre-emptive scheduling called the Executive which was cutting edge at the time compared to batch scheduling systems.
The AGC had instructions and data that were 15-bits rather than the 8-bits which is common today. Like the later 8080/Z80 and 8086/8088 series, I/0 has its own address space. The accumulator is 15-bits, but some operations can be done on 30-bits. It addressed its registers like it was addressing low memory address locations. It included integer multiply and divide instructions which many other early processors here don't include.
The AGC computers were:
Here is a Programmer's Manual for Block 2 AGC Assembly Language including processor architecture description.
Apollo missions to the Moon (with the exception of Apollo 8, which did not have a Lunar Module) had two AGCs, one in the Command Module and another in the Lunar Module.
Apollo 11 was the first manned mission to land on the Moon.
The Apollo Guidance Computer: Architecture and Operation (Springer Praxis Books)
Digital Apollo: Human and Machine in Spaceflight (MIT Press)
HDC 402 (Honeywell - ~1971)
teraKUHN has not been able to locate definitive documentation from NASA, Martin Marietta (now Lockheed Martin), Honeywell, nor JPL on the details of the HDC 402. However, we suspect that this was a variant of the DDP-124 computers processor architecture designed by the Computer Control Company (aka 3C). Honeywell had acquired 3C in 1966, well before Martin Marietta subcontracted the Viking computer to Honeywell in 1971. If you have any information that can confirm or disprove this suspicion, please email us at teraKUHN.
The Viking lander Guidance, Control, and Sequencing Computers (GCSC) were described as:
Here is a 3C DDP-124 brochure including processor architecture description. It's processor has a 24 bit word size, 48 instructions including the Halt instruction which would never be used on a spacecraft, 2's complement arithmetic, and up to 3 index registers. This seems similar to the description of the HDC 402 attributes in the Viking landers GCSC computer.
Two HDC 402 processors were used in each GCSC computer that controlled the Viking landers that landed on Mars.
Viking 1 was the first successful lander on Mars.
On Mars: Exploration of the Red Planet, 1958-1978--The NASA History (Dover Books on Astronomy)
8080 / 8085 (Intel - 1974)
The grand dad of all micro processors, the first micro processor or micro controller. Although dated and very complicated in wiring, there is a wide range of software and tools for them. This includes most CP/M (aka CP/M-80) software. The later 8085, Z80, and other descendents had much simpler wiring, so any work done today would probably be on those successors. See the Z80 below. Many manufacturers supply processor variants built on the 8080 or later Z80 architectures.
The 8080 has a von Neuman architecture in which instructions and data share the same space addressed by 16-bits. However, like the later 8086/8088 series, I/0 has its own address space. The accumulator is 8-bits, but some operations can be done on 16-bits. It has and handful of 8-bit explicit registers, which can be paired up to be used as 16-bit registers.
The 8080 was used in the Altair 8800 which was designed in 1974 by MITS. The Altair is recognized as the first commercially successful personal computer. The 8080 was also used in the IMSAI 8080 which was the first clone computer. These machines, and others based on the 8080, could run the CP/M operating system which meant that they could share software written for CP/M.
The 8080/8085 processors had:
Further the Sojourner rover Control and Navigation Subsystem had:
A radiation hardened 80C85 was used on the Sojourner rover that flew with the Mars Pathfinder spacecraft.
Sojourner was the first successful rover on Mars.
Unlike the executives for the Apollo AGC and the Viking GCSC or VxWorks used in later Power based spacecraft control systems,
the core software in the Sojourner rover 8085 code did not use a 'time sharing' or multi-tasking executive.
This was possible because the Sojourner rover Control and Navigation Subsystem didn't control time sensitive space navigation or landing which those other systems did.
Instead the Sojourner rover 8085 code had a simple control loop that executed commands sequentially.
An 8085 was also used in the Fast Auroral Snapshot Explorer (FAST) satellite,
and in each of the 5 Time History of Events and Macroscale Interactions during Substorms (THEMIS) satellites,
including the 2 renamed as Acceleration, Reconnection, Turbulence and Electrodynamics of the Moon's Interaction with the Sun (ARTEMIS) spacecraft which were moved into Lunar orbits.
Sojourner: An Insider's View of the Mars Pathfinder Mission by Andrew Mishkin (2003-12-02)
Z80 (Zilog - 1976)
If the 8080 is the grand dad of all micro processors, then the Z80 is grand dad's brother. Zilog was started by engineers who left Intel after working on the 8080 microprocessor. The Z80 is capable or executing the same binary code as the 8080/8085, but the Z80 has a lot of additional instructions and addressing modes. The Z80 isn't as complicated as the 8080 when it comes to wiring one up. It is also a multi functional chip with a lot of built in hardware options. Although very dated it is still very popular due to its very low cost, availability, and wide range of development tools. This includes all CP/M (aka CP/M-80) software. Additionally MSX home computers used this processor and ran the MSX-DOS operating system. Also the Z80 processor was used in many TI graphing calculators, most Tandy TRS-80 home computer models, the Timex/Sinclair home computers, as well as others.
Here is a Z80 CPU Users Manual including instruction set and processor architecture description.
The Z80 has a similar architecture to the 8080/8085 with code and data sharing the same 16-bit address space but with a seperate address space for I/0.
The accumulator is 8-bits, but some operations can be done on 16-bits.
It has and handful of 8-bit explicit registers, which can be paired up to be used as 16-bit registers, and a couple of 16-bit registers.
Other controllers in this family include: HD64180, Z180, Z380, and eZ80. The eZ80 added integer multiply instructions.
While Zilog went in one direction with the 8080 architecture trying to builds controller chips, Intel went in another. Intel designed the 16-bit 8086 and 8088 which could not execute the same binary code as the 8080/8085, but that had similar assembly instructions so that 8080/8085 code could be translated to 8086/8088 assembly code. The 8086 and 8088 lead to the 80286 (or just 286), the 80386 (or just 386), the 80486 (or just 486), and then to the Pentium. Decendents of this architecture, often just called x86, are used in most PCs and laptops.
6800 / 6801 / 6802 / 6803 / 6808 (Motorola - 1974)
The grand mother of them all, the main competitor in the days of the 8080 micro controller. Although very dated, the basic design lived on in later 68 hundred series processors from Motorola. It's quite often possible to assemble code written for a 6800 to run on later 68 hundred processors. It's even possible to execute some code built for a 6800 on later 68 hundred processors since most have super sets of the 6800 instruction set. Variants of this processor were used in GM automotive computers that control fuel injection.
The 6800 has a von Neuman architecture in which instructions and data share the same space and I/0 is memory mapped all in the same 16-bit address space. There are two 8-bit accumulators, and some operations can be done on 16-bits. While it has explicit registers, some instructions can use low memory address locations as other registers or pointers to other memory.
6811 (Motorola - 1985)
The once popular 68hc11 is an 8-bit data, 16-bit address micro controller from Motorola with an instruction set that is similar to the older 68 hundred parts (6800, 6805, 6809). This is a multi functional chip with a lot of hardware built in.
The 68hc11 has a von Neuman architecture in which instructions, data, and I/O all share the same memory space addressed with 16-bits. Depending on the variety, the 68hc11 has built-in EEPROM, RAM, digital I/O, timers, A/D converter, PWM generator, pulse accumulator, and synchronous and ansynchronous communications channels. There are two 8-bit accumulators, and some operations can be done on the 16-bit pair of these two accumulators. While it has explicit registers, some instructions can use low memory address locations as other registers or pointers to other memory. It includes integer multiply and divide instructions.
6502 / 6507 / 6510 / 65c02 / 65802 (MOS Technology - 1975)
MOS Technology was originally started to provide a second source for electronic calculator chips. However, similar to how Zilog formed from engineers who left Intel, MOS Technology had an influx of engineers who left Motorla after working on the 6800 microprocessor. Cheaper than the 8080 or 6800 when introduced, this is the processor that ended up in a number of early home computers. Chips from this family were used in Apple II, Commodore 64/128/Vic20, and Atari 400/800/1200 home computers and Atari 2600 and and Nintendo NES game consoles. Although dated, the basic design lived on in the later 65816 from Western Design Centers which was used in the Nintendo Super NES game console and Apple IIGS. Since the 6502 ended up in so many inexpesive home computers it was quite often the first processor a lot of assembly programmers learned to write code for.
The 6502 has a von Neuman architecture in which instructions and data share the same space and I/0 is memory mapped. There is just one 8-bit accumulator. While it has explicit registers, some instructions can use low memory address locations as other registers or pointers to other memory. The 6510, found in Commodore 64 computers, has a built in I/O port.
While MOS Technology went in one direction making the 6502 architecture cheaper than the 6800, Motorola went in another. Motorola designed a number of variants to the 6800 for different controller chip applications. While it was quite often possible to assemble code written for a 6800 to run on later 68 hundred processor variant, they could not always execute the same binary code. Ultimately engineers at Motorola designed the 68000 (or 68K) which was a 16-bit processor that could do 32-bit math by doing two 16-bit operations internally. This made it seem like a 32-bit processor. It was not possible to execute the same binary nor assemble code written for a 68 hundred to run on a 68 thousand. The 68000 eventually lead to the 68020 which was a true 32-bit processor based on the same architecture. This architecture, often just called 68K, was used in most early Macintosh PCs and computer workstations, used as a coproceesor in a number of Tandy TRS-80 computer models, and it was and still is used as an embedded controller.
CDP 1802 (RCA - 1975)
The successor to the 1801 which was the first processor implemented in CMOS. In 1976, the two chips making up the 1801 were integrated together creating the 1802. The 1802 could be considered a RISC microprocessor.
Here is a 1802 Datasheet including processor architecture description.
Some variants of the 1802 were built using Silicon-on-Sapphire which is radiation hard. Since there were radiation hard versions, it was used on spacecraft including the Space Shuttle display controller, NASA Magellan, NASA/ESA Ulysses, and the NASA Galileo spacecraft. The 1802 has often been incorrectly claimed to have been used in the earlier Viking and Voyager spacecraft, but it was not. Variants of this processor were used in Chrysler automotive computers for electronic spark control.
PIC12* / PIC14* / PIC16* / PIC17* (General Instrument Microelectronics, MicroChip - 1976)
The PIC series are 8 bit processors and were very popular with hobbyists. They started off as a peripheral interface chip for General Instrument Microelectronics CP1600 16-bit processor; however they were found to be very useful in other control applications. The letters PIC were later changed to mean programmable intelligent computer. The PIC series have Harvard architectures and are RISC like. PIC processors typically have between 128 and 512 bytes of data RAM on chip addressed directly as 128 byte banks or through indirect addressing. However, unlike other processors, the PIC series can not easily address a full 64K of external data memory. The processors used in earlier VEX Robotics were PIC architecture processors.
The military standard document MIL-STD-1750A (1980), is the definition of a 16-bit computer instruction set. Since the architecture was a military standard, many manufacturers supplied variants of this processor.
The MIL-STD-1750A processor architecture was used in many spacecraft. A MIL-STD-1750A was used in the ESA Rosetta, NASA Cassini, NASA Mars Global Surveyor, and the Naval Research Laboratory Clementine Lunar Orbiter.
Here is a MIL-STD-1750A Datasheet including processor architecture description.
8051 / 8052 / 8031 / 8032 (Intel - 1980)
The 8051 was Intel's second generation of micro controllers. Although featuring a some what unique design from other processors, it is a very popular processor. A lot of software is available for the 8051 line. Many manufacturers supply what must be a hundred different processor variants of the 8051 architecture for any requirement.
The 8051 has a Harvard architecture with separate address spaces for program memory and data memory.
The program memory can be up to 64K.
The lower portion (4K or 8K depending on type) may reside on chip.
The 8051 can address up to 64K of external data memory, and is accessed only by indirect addressing.
The 8051 has 128 bytes (256 bytes for the 8052) of on-chip data RAM, plus a number of special function registers (SFRs).
I/O is mapped in its own space.
The 8051 typically would not be used as a flight control computer on a deep space spacecraft, but it has been used in satellites and in instruments carried by deep space spacecraft. For example, an 8052 was used in the Lunar Reconnaissance Orbiter LAMP instrument. Other controllers in this family include: MCS-151, 80C320, AT89 series, CY8C3xxxx, HT85FXX, and XC800 family.
8096 / 80196 (Intel)
The third generation of Intel micro controllers, the 80c196 is a 16 bit processor. Don't confuse it with the 8086/8088 line of processors common in desktop PCs. This is a completely different processor. It is also a multi functional chip with a lot of hardware built in. The 8096 originated as a variant of the Intel 8061 which was used in Ford automotive computers.
The 8096 has a von Neuman architecture in which instructions and data share the same space addressed by 16-bits. Among the many features it includes of the 8096 are high speed I/O, A/D, serial communications channel, up to 40 I/O ports, 8 source priority interrupt controller, PWM generator, and watchdog timer. The accumulator is 16-bits. It addresses its registers like it is addressing low memory address locations. It includes integer multiply and divide instructions.
ARM (Arm Holdings - 1985)
While not a 16-bit or 8-bit micro controller, ARM architecture processors are included in this list as an example of the processor that is used in most smartphones. ARM doesn't fabricate chips, they just license the architecture of the processor to electronics manufacturers. Since the design is available for license, many manufacturers fabricate their own variants of this processor with custom capabilities. The processors used in later VEX Robotics, later Lego Mindstorms, and some CubeSats are also ARM architecture processors.
RTX2000 (Harris - 1988)
The RTX2000 and RTX2010 were decendants of the Novix N4000 processor. They were all processors designed based on the Forth programming languages stack machine. The RTX2000 architecture was used for a number of spacecraft. An RTX2000 architecture processor was used on the Near Earth Asteroid Rendezvous - Shoemaker (NEAR - Shoemaker) spacecraft to the near Earth asteroid Eros.
Here is a RTX2010 Datasheet including processor architecture description.
Power (IBM - 1990)
While not a 16-bit or 8-bit micro controller, Power architecture processors are included in this list as an example of one of the currently most used processors in deep space spacecraft. Other 32-bit and 64-bit CPUs that might be used include SPARC architecture typically in ESA and ISRO missions or SuperH architecture typically in JAXA missions. The 32-bit and 64-bit processors tend to be RISC processors although CISC 386/x64 architecture processors sometimes get used in spacecraft.
The Power processor architecture was used in many NASA rovers and spacecraft.
A radiation hardened RAD6000 was used on the Mars Pathfinder lander, the MER rovers (Spirit and Opportunity), the Phoenix Mars Lander, and the DAWN spacecraft.
A radiation hardened RAD750 was used on the Mars Reconnaissance Orbiter (MRO), Lunar Reconnaissance Orbiter (LRO), LCROSS, Mars Science Laboratory (Curiosity), GRAIL, LADEE, MAVEN, and OSIRIS-REx missions.
Most of these NASA spacecraft used the VxWorks real-time operating system (RTOS) and software developed in C or C++.
The processors used in the Gamecube, Wii, Wii U, PlayStation 3, and XBox 360 game consoles are also Power architecture processors.
Roving Mars: Spirit, Opportunity, and the Exploration of the Red Planet
Mars Rover Curiosity: An Inside Account from Curiosity's Chief Engineer
AVR (Atmel - 1996)
The AVR series are becoming very popular since it is the processor used in most Arduino boards. It is also a multi functional chip with a lot of built in hardware options. It is also used in many reprap 3D-printers. Atmel has released a radiation hardened AVR for space applications. The radiation tolerant version of the ATmega128 is the ATmegaS128.
Here is an AVR Assembler Instructions listing including details of the processor architecture.
The AVR has a modified Harvard architecture with separate address spaces for program memory and data memory.
I/O has separate instructions, but is mapped to a subset of the data memory space.
It addresses its registers like it is addressing low data memory address locations.
It includes integer multiply and divide instructions.
ATtiny13A-PU picoPower AVR Microcontroller
Assemblers for 8 and 16-bit CPUs
Compilers for 8 and 16-bit CPUs
Debuggers for 8 and 16-bit CPUs
KPC (teraKuhn integer Pascal Compiler) are 8096, 6811, and 6502 Pascal Compilers that might be helpful to the hobbyist who wishes to generate code for an 80x96, 68HC11, or 65x02 architect CPU. The current implementation only supports a very limited subset of the Pascal language. The grammar for the compiler is based on the grammar presented in the back of the book "Compilers" by Aho, Sethi, and Ullman (the dragon book). However, we have not yet implemented all of this grammar. The compiler does not support strings, constants, or structures. The compiler should generate correct code for integer ASSIGNMENT, IF, and WHILE statements.
This is a preliminary release so if you do find any bugs, please let us know. The previous update fixes bugs in the code generated for relational operators.
The version 0.81 update adds support for a -S command line option that allows initialization of the stack pointer, and this update fixes bugs related to parameter and local variable access in the 6811 version.
The version 0.82 update adds support for repeat and until keywords and recognition of implementation, interface, unit, and uses keywords. If you do find any additional bugs, please let us know.Download 96KPC10.ZIP for 16-bit DOS (should work on 16-bit and 32-bit Windows)
If you use any of these tools on a regular basis you are encouraged to register them. With a full registration you will receive the next version of the software when it becomes available.
Email bug reports and feedback to teraKUHN
DebugCPUs (Debug CPU) are simulated 8096 and 6811 CPU Debuggers that might be helpful to the hobbyist who wishes to develop and debug code for an 80x96 of 68HC11 CPU. The current implementation supports commands similarly to those in DOS debug.
The version 1.1 DebugCPUs include a simple unassembler feature in the Windows version that will show you the opcode for the location you are at and the bytes that make up that instruction when you type 'u' in the command window. There are also a number of bug fixes to the simulation of instructions in the 6811 debugger. There were no bug fixes to the 8096 debugger since it seems pretty robust.
The version 1.11 DebugCPUs include a 'b' command that allows you to dump the breakpoints that are set. There is also an additional bug fix to the simulation of instructions involving the carry flag in the 6811 debugger. If you do find any additional bugs, please let us know.
The most recent update fixes bugs related to incorrect simulation of the subd instruction in the 6811 version.Download Debug 8096 (96Dbg11.ZIP) for 16-bit Windows (should work on 32-bit Windows)
If you use any of these tools on a regular basis you are encouraged to register them. With a full registration you will receive the next version of the software when it becomes available.
Email bug reports and feedback to teraKUHN
This page was previously hosted on geocities as www.geocities.com/rjkuhn_2000/software.htm. That old page has been copied and replicated in a number of other locations on the world wide web, but those other locations are snapshots and are not updated.
Text Copyright (C) 2000-2002, 2017-2019 R. J. Kuhn. Please note that you are not allowed to reproduce or rehost this page without written permission.