The electrical connections between the modules of a microcontroller (e.g. CPU, pe-ripherals, memory, I/O modules, external bus modules) are referred to as busses.
Design
Busses generally consist of two groups of connections:
a data bus for transferring data,
an address bus for transferring the ad-dresses of data, and
a control line for controlling communica-tion between the sender and receiver of the data.
Harvard architecture Von-Neumann architecture
Extended Harvard architecture (dual-ported data memory) Extended Harvard architecture
(two data memories)
c d
a b
Microcontroller core Data memory
1
Instruction memory
Peripherals External bus controller Data memory
2
Microcontroller core
Instruction memory
Dual-ported data memory
Peripherals External bus controller Data memory Microcontroller
core
Instruction memory
Peripherals Peripherals External bus controller
Data memory Microcontroller core
Instruction memory
Peripherals Peripherals External bus controller Common bus architectures for embedded microcontrollers
5
æ
SAE0885EOperating concept
The transfer of data involves the following sequence of operations:
The data is specified by a signal placed on the address bus.
Signals on control lines indicate the valid-ity of the address.
The address is read by the receiver/sender of the data element (data source).
The sender places the data element on the data bus.
The sender of the data element signals the validity of the data element.
The receiver of the data element reads the data.
In order to achieve faster cycle times, these operations can be performed simultaneously on some busses (interleaved or pipelined busses). With interleaved busses, only the unidirectional runtime (drain➝ source or source➝ drain) has to be considered, rather than the bi-directional runtime (drain➝ source➝ drain).
Common bus architectures Von-Neumann architecture
If a microcontroller has only one bus via which the instructions for the CPU are read and the data is exchanged, this arrangement is referred to as the “Von-Neumann archi-tecture” (Fig. 5a). This architecture is char-acterised by the small amount of space it requires on the semiconductor chip.
The data memory, the program memory and the I/O modules are arranged across a linear address range. Because the bus is shared, only one signal, one item of data or one instruction can be read from the mem-ory at a time. Instructions that read data from the memory therefore require at least two cycles.
Harvard architecture
Where a microcontroller has two busses (for data communication and transfer of instructions), it is said to have a “Harvard architecture” (Fig. 5b).
The Harvard architecture uses separate ad-dress areas for data memory and peripherals on the one hand and program memory on the other, with each area being accessed by a separate bus. This means that an instruction can be read at the same time as an item of data is read or written. For embedded appli-cations, however, it has become evident that separation reduces performance. Most Harvard architectures therefore incorporate bridges which allow transfer of data between the busses.
Digital signal processing generally involves operations performed on two operands (e.g.
filter coefficient, item of data). In order not to have to read these two operands one after the other via the same bus, multiple data bus arrangements referred to as extended
Harvard architectures were introduced. With such arrangements, two items of data can be read simultaneously.
Extended Harvard architectures may also have two different data memories connected to the two data busses (Fig. 5c) or one data memory with two simultaneous access paths (dual-ported data memory) as illustrated in Figure 5d.
The interaction between a circuit and mi-crocontrollers (µC) is best explained by means of an example. The circuit used in the example chosen is referred to as a devel-opment circuit because it is used to test user programs developed on a PC. Such circuits are sometimes also called evaluation boards.
Overview
A development circuit is part of a develop-ment system used in conjunction with a PC.
Figure 1 shows the overall layout of a devel-opment workstation with the circuit de-scribed in this example.
The advantage of a development circuit is that all components are easily accessible. In addition, the signals of the various inputs and outputs can be tapped at the terminals.
In that way individual signals can easily be checked.
Development environment Program development
The user program is created on a PC using a text editor (source code, Fig. 2a). A compiler then translates the source code from the programming language in which it is written (e.g. C++) into an assembly language based on mnemonics. The assembly language is the preliminary stage to the machine lan-guage and is still easy to read. An assembler is then used to convert the assembly lan-guage into a digital code that can be under-stood by the development circuit’s micro-controller. The precise memory addresses are specified by a linker. The machine code or object code can then be transferred to the circuit by the PC.
Assembler programs can also generate list-ing files in which each line of the original source code is shown alongside the corre-sponding object code. This is useful for locating errors.
Fig. 1
1 Circuit signal on the oscilloscope 2 Output indicators
(LEDs)
3 Development circuit 4 Connection to PC
(connector X2) 5 19-inch module rack
system with power supply unit 6 Circuit layout 7 Circuit diagram 8 Example program
1
7
6 5
4 3 2
8
Components of a development workstation with the development circuit
1
æ
UAE0846YTransferring the object code
The object code is transferred (downloaded) by starting a program on the PC that trans-mits the file containing the object code via the PC’s RS232 interface. This interface is connected by a lead and the connector X2 to the circuit (Fig. 2b).
Monitoring program (basic program) A fixed monitoring program running on the microcontroller reads the data sent by the PC and stores the object code in the devel-opment circuit’s RAM (external RAM).
The monitoring program is stored in the ROM (external EPROM) and is started when the power supply is switched on. It can also send data back to the PC if requested to do so by the PC.
Control units used for automotive appli-cations do not require a monitoring pro-gram. They run an invariable program that is stored in the non-volatile memory (e.g.
EPROM).
Hardware configuration
Following download, the user program is stored in the external RAM module. Nor-mally this type of memory module is used only for data storage. In development cir-cuits, however, the components are con-nected in such a way that the RAM can op-erate as a program memory as well. This makes it possible to download the user pro-gram from the PC and store it on the devel-opment circuit without having to alter the actual program memory (the EPROM).
Starting the user program
To start the user program, the monitoring program that the microcontroller runs has to branch to the RAM. The start command and start address are entered on the PC and transferred to the development circuit (“g address”; e.g. g 8000, i.e. go to address 8000).
The monitoring program reads this infor-mation and then executes the instruction to go to the user program (Fig. 2c).
Stopping the user program
The user program can be stopped by press-ing the reset button which forces the micro-controller to revert to the monitoring pro-gram (Fig. 2d).
Fig. 2
a Program creation b Transfer of object
code
c Starting and running the program d Stopping the
program
1 PC
2 Development circuit 3 Microcontroller 4 EPROM with
monitoring program
5 RAM
6 Interface module 7 Connector X2 8 Connector X1 9 Reset button c
"Moving lights" program 8000: MOV RO 8002: MOV R1, #80 8004: MOV RO 8005: MOV P4, A Working with the development circuit
2