An 3477
An 3477
Keywords: app note 3477, sdcc c compiler, 8051, 89C450, compiler, microcontroller, firmware Feb 23, 2005
Introduction
The SDCC (Small Devices C Compiler) is a free C compiler developed for 8-bit microcontrollers. Although
compatible with many different architectures, the SDCC compiler has extended support for devices based on the
8051-core. This application note will focus on using the SDCC to develop firmware for the DS89C420/430/440/450
family of ultra-high-speed 8051-compatible microcontrollers from Maxim/Dallas Semiconductor.
The SDCC is a command line, firmware development tool that includes a preprocessor, a compiler, an assembler,
a linker, and an optimizer. Also bundled with the install file is the SDCDB, a source level debugger similar to gdb
(GNU Debugger). When an error-free program is compiled and linked with the SDCC, a Load Module in Intel hex
format is created. This file can then be loaded into the DS89C420/430/440/450 microcontroller's flash memory
using a Serial Loader. (See DS89C420/430/440/450 documentation and application notes for details on
downloading firmware to device).
For the most up-to-date information about the SDCC, visit http://sdcc.sourceforge.net or read the SDCC manual,
sdccman.pdf (copied to your hard drive during installation). Questions can also be submitted to the online SDCC
message forum or mailing list which can be found in the "Support" section of the SDCC webpage.
To install the SDCC, download the latest version from the "Download" section of the SDCC website at http://sdcc.
sourceforge.net. Although nightly builds of the software are available, it is usually safest to download the latest fully
tested release version (currently v2.4.0).
On the "Download" page, builds of the SDCC are available for several different operating systems. If you are
working on a PC running Microsoft Windows, download the win32 self-executing SDCC install file (sdcc-2.4.0-setup.
exe) and run the executable.
When installing the program, a prompt will appear asking to add the directory containing the program binaries to
your path. This is recommended, and the remainder of this application note will assume that the user has done so.
To ensure that the SDCC installed correctly on your hard drive, open a Command Prompt and type sdcc --version.
Press [Enter], and the text displayed in Figure 1 should appear in the window (actual text will depend on the SDCC
version that you downloaded):
Figure 1. Verifying the Correct Installation of the SDCC by Performing a Version Check
To test the include path, create a file called sdcctest.c and copy the following source code into the file.
#include <string.h>
void main(void)
{
if (strcmp(str,"MAXIM") == 0)
flag = 0;
else
flag = 1;
Save the file in plain ASCII format (i.e., using Microsoft Notepad). In the Command Prompt, type sdcc sdcctest.c
and press [Enter]. If nothing appears, as shown in Figure 2, the program compiled successfully.
Many files are created by the SDCC when you compile your source code successfully. In the directory to which you
compiled, you will find the following files:
Other files are also created (many of them for the source level debuggers). Read the SDCC documentation for
further information.
In addition, the SDCC supports a number of extended data types (also called storage classes) to take advantage of
the 8051-architecture. They are presented in the following subsections with examples.
Unlike some commercial 8051 microcontroller development tools, the SDCC is only capable of declaring Special
Function Registers as both bit and byte addressable. Although supported by the 8051 assembly language, shared
bit and byte addressable RAM is not supported by the SDCC. To prove this, observe the following code sample
and compiled assembler code.
C source code:
union
{
unsigned char a_byte;
struct
{
unsigned char bit0 : 1;
unsigned char bit1 : 1;
unsigned char bit2 : 1;
unsigned char bit3 : 1;
unsigned char bit4 : 1;
unsigned char bit5 : 1;
unsigned char bit6 : 1;
unsigned char bit7 : 1;
} a_bit;
} a;
bit b;
void main(void)
{
a.a_byte = 0x05;
a.a_bit.bit6 = 1;
b = 1;
...
159 ;sdcctest.c:21: a.a_byte = 5;
160 ; genPointerSet
161 ; genNearPointerSet
162 ; genDataPointerSet
0031 75 21 05 163 mov _a,#0x05
164 ;sdcctest.c:23: a.a_bit.bit6 = 1;
165 ; genPointerSet
166 ; genNearPointerSet
0034 78 21 167 mov r0,#_a
168 ; genPackBits
0036 E6 169 mov a,@r0
0037 44 40 170 orl a,#0x40
0039 F6 171 mov @r0,a
172 ;sdcctest.c:25: b = 1;
173 ; genAssign
003A D2 00 174 setb _b
175 ;sdcctest.c:27: while(1); // program loop
...
Although the bit fields in declaration of "a" appear to be bit-addressable memory, the assembly listing (taken from
the .rst file generated by SDCC) shows that the variable does not use bit addressing. In the listing do not confuse
"a" and "_a". The "a" refers to the accumulator while the "_a" refers to the variable.
Note that the "Absolute Addressing" section of this appnote presents an interesting way to allocate memory so it
acts as true bit-addressable memory.
near/data
Declaring a variable with the near or data storage class places the variable in directly addressable RAM in the
8051-core. The DS89C420/430/440/450 family of microcontrollers has 128 bytes of directly addressable memory
available. This is the fastest type of memory that can be accessed by the 8051, and the assembly code generated
to read or write data in this area of RAM requires a single MOV instruction.
#include "sdcc_reg420.h"
void main(void)
{
P0 = outPort0;
far/xdata
Declaring a variable with the far or xdata storage class places the variable in external RAM. Although this gives the
developer access to a much larger RAM space, the assembly code generated to read and write to this memory
uses a MOVX instruction which requires loading the external memory address into the data pointer.
The DS89C420/430/440/450 family of microcontrollers includes a 1 kilobyte internal SRAM that can be used for
variables declared with far/xdata. Note that the DME1:0 bits in the Power Management Register (PMR) must be
set for internal SRAM mode before this memory can be initialized or used.
#include "sdcc_reg420.h"
void main(void)
{
PMR |= 0x01; // Enable internal 1K SRAM
ioPorts[0] = 0x4A;
ioPorts[1] = 0x56;
P0 = ioPorts[0];
P1 = ioPorts[1];
idata
Declaring a variable with the idata storage class places the variable in indirectly addressable memory within the
8051-core. Indirectly addressable memory is similar to directly addressable memory as there are 128-bytes
available in the 8051-core (not including Special Function Registers). Accessing idata, however, requires an extra
MOV command to move the RAM address into a working register.
#include "sdcc_reg420.h"
void main(void)
{
while (1) // program loop
{
port0_x2 = P0 * 2;
}
}
pdata
The pdata storage class is used to access paged external data memory. This memory type is beyond the scope of
this application note and interested readers are encouraged to review the pdata section in the SDCC
documentation.
code
Declaring a variable with the code storage class indicates that the variable will be placed in program memory
(specifically flash memory within the DS89C420/430/440/450 microcontrollers). The variables are read-only for the
SDCC, therefore use code to declare constants (such as lookup tables) in your program.
#include "sdcc_reg420.h"
void main(void)
{
data unsigned char i = 0;
bit
Declaring a variable with the bit storage class places it in bit-addressable memory in the 8051-core. The 8051-core
has 16 bytes of direct addressable RAM that can act as bit-addressable memory (bytes 0x20 to 0x2F), providing
128 total addressable bits. Variables of this type are efficient use of memory for flags.
#include "sdcc_reg420.h"
bit esc_char_flag = 0;
void main(void)
{
P1 = 0x00;
while (!esc_char_flag)
{
if (P0 == ESCAPE)
esc_char_flag = 1;
}
P1 = 0xFF;
sfr
The sfr storage class defines a specific Special Function Register (SFR) in the 8051-core. The definition file
presented in Appendix A defines all the SFRs in the DS89C420/430/440/450 microcontrollers using the sfr
identifier.
Note that the following example defines the SFRs. Including the definition file sdcc_reg420.h was therefore not
necessary.
void main(void)
{
P0 = 0x00;
P1 = 0xFF;
sbit
The sbit storage class defines a specific bit inside a bit-addressable SFR. In the 8051-core, all SFRs with an
address that finishes with either a 0 or an 8 (in hex) are bit addressable. The definition file presented in Appendix A
defines all the SFR addressable bits in the DS89C420/430/440/450 microcontroller using the sbit identifier.
void main(void)
{
P0 = 0x00; // P0 = 0x00
P0_4 = 1; // P0 = 0x10
Absolute Addressing
Absolute addressing is supported by the SDCC using the at identifier. The SDCC will not, unfortunately, track
variables declared at absolute addresses and may declare other variables so that they will overlap.
#include "sdcc_reg420.h"
void main(void)
{
for(b=0; b<64; b++)
c[b] = 0xAA;
y = 0xF1;
z = 0xF2;
a = c[5];
Using the SDCC, the example compiles without any errors or any warnings, even though two variables, "y" and "z",
are assigned to the same location. Next, if we were to run this program, we would expert the final assignment in the
program (a = c[5]) to set "a" to 0xAA. But this is not the case. The actual value of "a" after the final assignment is
0xF2.
We can see the reason for this strange result by examining the following lines in the .map file created by SDCC
that show the actual addresses used for each variable.
Value Global
-------- --------------------------------
...
0010 _y
0010 _z
...
Value Global
-------- --------------------------------
0008 _a
0009 _b
000B _c
Note that the underscore placed at the beginning of the variable name is added by the compiler. If "c" will be
located at address 0x000B and will be an array 64 bytes long, it will overlap the "y" and "z" variables at address
0x0010.
A use for absolute addressing is to simulate bit-addressable variables. In the following example, we choose to
define the variable n_byte at the last byte location in bit-addressable memory. Next, we define n_bit0 to n_bit7 in
the last 8 bit locations of bit-addressable memory in the 8051-core. As these overlap, the n_byte variable can be
bit addressed using the n_bit0 to n_bit7 variables.
#include "sdcc_reg420.h"
void main(void)
{
n_byte = 0x00;
n_bit4 = 1;
P0 = n_byte; // P0 = 0x10
Memory Models
The SDCC supports two memory models: small and large. When using the small memory model, the SDCC
declares all variables without a storage class (i.e., data, idata, xdata, pdata, bit, code) in internal RAM. When
using the large memory model, the SDCC declares all variables without a storage class in external RAM.
The small memory model is the default when compiling with the SDCC. To force the SDCC to use a particular
memory model, add the following command line parameters:
or
Never combine modules or objects files compiled with different storage classes.
Interrupts in SDCC
The following format should be used to define an Interrupt Service Routine (ISR):
The interrupt_identifier can be any valid SDCC function name. The interrupt_number is the interrupt's position
within the interrupt vector table. Table 1 shows the Interrupt Numbers for every interrupt supported by the
DS89C420/430/440/450 family of microcontrollers. The bank_number is an optional parameter that indicates to
the SCDD which register bank to use for storing local variables in the ISR.
The SDCC handles many details involved with programming ISRs, like saving and restoring accumulators and the
data pointer to and from the stack. (This is actually done for all functions as well. Refer to the _naked keyword in
the SDCC manual to disable saving these variables to the stack.) Other details are not handled by the SDCC (for
good reason) and present traps to developers new to embedded programming. Many of these issues are advanced
programming concepts beyond the scope of this article, but the SDCC manual as well as embedded programming
textbooks can provide more insight.
● Every global variable that can be written to inside an ISR and that is accessed outside the ISR must be
declared as volatile. This will ensure that the optimizer does not remove instructions relating to this
variable.
● Disable interrupts whenever using data in a non-atomic way (i.e., accessing 16-bit/32-bit variables). Access
to a variable is atomic when the processor cannot interrupt (with an ISR) storing and loading data to and
from memory.
● Avoid calling functions from within an ISR. If you must do this, declare the function as reentrant (see
SDCC manual) which allocates all local variables in the function on the stack instead of in RAM.
Note that if your SDCC program uses ISRs located in source files other than the one that contains your main()
function, the source file containing the main() function should include a function prototype for each of these ISRs.
The example below defines an ISR to handle Serial Communication Interface 1 (SCI_1) Interrupt Service Routines.
The program receives a byte from the SCI_1 receiver, increments the byte by one, and transmits it continuously
through the SCI_1 transmitter.
#include "sdcc_reg420.h"
void main(void)
{
// 1. Init Serial Port
EA = 0; // Enable global interrupt mask
SCON1 = 0x50; // Set SCI_1 to 8N1, Rx enabled
// 2. Initiate SCI_1 Tx
SBUF1 = n;
// 3. Program loop...
while (1);
}
Inline Assembly
Inline assembly is fully supported by the SDCC. To use this feature, enclose the assembly code between the _asm
and _endasm identifiers. Note that inline assembly code can also access C variables by prefixing the variable
name with an underscore character. The following example uses inline assembly to perform nop instructions (used
to waste a clock cycle within the microcontroller) and then increment the variable "a" by one.
#include "sdcc_reg420.h"
unsigned char a;
void main(void)
{
// program loop...
while (1)
{
a = P0;
_asm
nop
nop
nop
inc _a
_endasm;
P1 = a;
}
}
The SDCC is also capable of interfacing C and assembly functions. This is an advanced topic; refer to the SDCC
manual for details.
/*
* sdcc_reg420.h
*
#ifndef __REG420_H__
#define __REG420_H__
/* BYTE Registers */
sfr at 0x80 P0;
sfr at 0x81 SP;
sfr at 0x82 DPL;
sfr at 0x83 DPH;
sfr at 0x84 DPL1;
sfr at 0x85 DPH1;
sfr at 0x86 DPS;
sfr at 0x87 PCON;
sfr at 0x88 TCON;
sfr at 0x89 TMOD;
sfr at 0x8A TL0;
sfr at 0x8B TL1;
sfr at 0x8C TH0;
sfr at 0x8D TH1;
sfr at 0x8E CKCON;
sfr at 0x90 P1;
sfr at 0x91 EXIF;
sfr at 0x96 CKMOD;
sfr at 0x98 SCON0;
sfr at 0x99 SBUF0;
sfr at 0x9D ACON;
sfr at 0xA0 P2;
sfr at 0xA8 IE;
sfr at 0xA9 SADDR0;
sfr at 0xAA SADDR1;
sfr at 0xB0 P3;
sfr at 0xB1 IP1;
sfr at 0xB8 IP0;
sfr at 0xB9 SADEN0;
sfr at 0xBA SADEN1;
sfr at 0xC0 SCON1;
sfr at 0xC1 SBUF1;
sfr at 0xC2 ROMSIZE;
sfr at 0xC4 PMR;
sfr at 0xC5 STATUS;
sfr at 0xC7 TA;
sfr at 0xC8 T2CON;
sfr at 0xC9 T2MOD;
sfr at 0xCA RCAP2L;
sfr at 0xCB RCAP2H;
sfr at 0xCC TL2;
sfr at 0xCD TH2;
/* BIT Registers */
/* P0 */
sbit at 0x80 P0_0;
sbit at 0x81 P0_1;
sbit at 0x82 P0_2;
sbit at 0x83 P0_3;
sbit at 0x84 P0_4;
sbit at 0x85 P0_5;
sbit at 0x86 P0_6;
sbit at 0x87 P0_7;
/* TCON */
sbit at 0x88 IT0;
sbit at 0x89 IE0;
sbit at 0x8A IT1;
sbit at 0x8B IE1;
sbit at 0x8C TR0;
sbit at 0x8D TF0;
sbit at 0x8E TR1;
sbit at 0x8F TF1;
/* P1 */
sbit at 0x90 P1_0;
sbit at 0x91 P1_1;
sbit at 0x92 P1_2;
sbit at 0x93 P1_3;
sbit at 0x94 P1_4;
sbit at 0x95 P1_5;
sbit at 0x96 P1_6;
sbit at 0x97 P1_7;
/* SCON0 */
sbit at 0x98 RI_0;
sbit at 0x99 TI_0;
sbit at 0x9A RB8_0;
sbit at 0x9B TB8_0;
sbit at 0x9C REN_0;
sbit at 0x9D SM2_0;
sbit at 0x9E SM1_0;
sbit at 0x9F SM0_0;
sbit at 0x9F FE_0;
/* P2 */
/* IE */
sbit at 0xA8 EX0;
sbit at 0xA9 ET0;
sbit at 0xAA EX1;
sbit at 0xAB ET1;
sbit at 0xAC ES0;
sbit at 0xAD ET2;
sbit at 0xAE ES1;
sbit at 0xAF EA;
/* P3 */
sbit at 0xB0 P3_0;
sbit at 0xB1 P3_1;
sbit at 0xB2 P3_2;
sbit at 0xB3 P3_3;
sbit at 0xB4 P3_4;
sbit at 0xB5 P3_5;
sbit at 0xB6 P3_6;
sbit at 0xB7 P3_7;
/* IP0 */
sbit at 0xB8 LPX0;
sbit at 0xB9 LPT0;
sbit at 0xBA LPX1;
sbit at 0xBB LPT1;
sbit at 0xBC LPS0;
sbit at 0xBD LPT2;
sbit at 0xBE LPS1;
/* SCON1 */
sbit at 0xC0 RI_1;
sbit at 0xC1 TI_1;
sbit at 0xC2 RB8_1;
sbit at 0xC3 TB8_1;
sbit at 0xC4 REN_1;
sbit at 0xC5 SM2_1;
sbit at 0xC6 SM1_1;
sbit at 0xC7 SM0_1;
/* T2CON */
sbit at 0xC8 CP_RL_2;
sbit at 0xC9 C_T_2;
sbit at 0xCA TR_2;
sbit at 0xCB EXEN_2;
sbit at 0xCC TCLK;
/* PSW */
sbit at 0xD0 PARITY;
sbit at 0xD0 P;
sbit at 0xD1 F1;
sbit at 0xD2 OV;
sbit at 0xD3 RS0;
sbit at 0xD4 RS1;
sbit at 0xD5 F0;
sbit at 0xD6 AC;
sbit at 0xD7 CY;
/* WDCON */
sbit at 0xD8 RWT;
sbit at 0xD9 EWT;
sbit at 0xDA WTRF;
sbit at 0xDB WDIF;
sbit at 0xDC PFI;
sbit at 0xDD EPFI;
sbit at 0xDE POR;
sbit at 0xDF SMOD_1;
/* EIE */
sbit at 0xE8 EX2;
sbit at 0xE9 EX3;
sbit at 0xEA EX4;
sbit at 0xEB EX5;
sbit at 0xEC EWDI;
/* EIP0 */
sbit at 0xF8 LPX2;
sbit at 0xF9 LPX3;
sbit at 0xFA LPX4;
sbit at 0xFB LPX5;
sbit at 0xFC LPWDI;
#endif
More Information
For technical questions and support: http://www.maxim-ic.com/support
For samples: http://www.maxim-ic.com/samples
Other questions and comments: http://www.maxim-ic.com/contact
Related Parts
-- Full (PDF) Data
DS89C420: QuickView -- Free Samples
Sheet