4 PROGRAMMING TIPS AND PITFALLS

In this final chapter we discuss some programming tips and common pitfalls which should be avoided when programming such microcontrollers.

4.1 RAM SIZE

The C8051F040 development target board has 64KB of flash memory (On-chip ROM) for code and constants and a 4K of RAM (On-chip XRAM). Thus the KEIL IDE should be setup as shown in Figure 4-1 to make use of this on board memory.

By 2020, wind could provide one-tenth of our planet’s electricity needs. Already today, SKF’s innovative know- how is crucial to running a large proportion of the world’s wind turbines.

Up to 25 % of the generating costs relate to mainte- nance. These can be reduced dramatically thanks to our systems for on-line condition monitoring and automatic lubrication. We help make it more economical to create cleaner, cheaper energy out of thin air.

By sharing our experience, expertise, and creativity, industries can boost performance beyond expectations.

Therefore we need the best employees who can meet this challenge!

The Power of Knowledge Engineering

Brain power

Figure 4-1 Screenshot of the Keil Target setup

4.2 SFRS

SFRs are used to control the way the 8051 peripherals functions. Not all the addresses

above 80h are assigned to SFRs. However, this area may not be used as additional RAM

memory even if a given address has not been assigned to an SFR. Free locations are reserved

for future versions of the microcontroller and if we use that area, then our program would

not be compatible with future versions of the microcontroller, since those same locations

might be used for special additional SFRs in the upgraded version. Moreover, certain unused

locations may actually be non-existent, in the sense that the actual cells for that memory

would not form part of the memory mask when being manufactured, and hence even if

we do write the code to use these locations, no actual data would be stored!

If we write a program that utilizes the new SFRs that are specific to a given derivative chip (and which therefore were not included in the standard basic 8051 SFR list), our program will not run properly on a standard 8051 where those SFRs simply did not exist. Thus, it is best to use non-standard SFRs only if we are sure that our program will only have to run on that specific micro-controller. If we happen to write code that uses non-standard SFRs and subsequently share it with a third-party, we must make sure to let that party know that our code is using non-standard SFRs and can only be used with that particular device. Good remarks, notes and warnings within the program source listing would help.

For the C8051F040 in particular, since we have more than one page of SFRs, it is important to make sure that we are in the correct page when reading or writing to the SFRs. See Table 1-3 and section 1.5.1 for exact details about the SFR paging technique.

4.3 SETUP FAULTS

The setup during the initialisation is very critical and basically we would need to initialise the system clock, watchdog timer, crossbar registers, any input/output ports and whether we need to use them for digital or for analogue signals. And then of course, any timers, serial ports, ADC, DAC, SPIs etc would need to be initialised if they are going to be required in our application program. We now list some common faults which are easily made during this setup process.

4.3.1 SYSTEM CLOCK SETUP

The System clock should be setup and initialised at the start of your program. Forgetting to set it up or not setting it up correctly is a common initial fault for new comers. Checking for the clock stabilisation during a simulation run can cause problems in cases where the simulation of the clock is not well implemented as mentioned in section 1.8.1.

4.3.2 WATCHDOG TIMER SETUP

Another very common fault with newcomers to this device is setting the wrong configuration of the crossbar SFRs: XBR0, XBR1 and XBR2. Consulting the manual and reviewing the examples would help a lot to enable the user to become familiar with the initialisations required, and at which pins to expect the input or output signal to be available. (See Table 1-4, Figure 1-10, Figure 1-11 and Figure 1-12)

4.4 SERIAL PORT (UART0)

To use the ‘printf ’ command, the on-board serial port or UART0 must be correctly setup at the required baud rate. It is generally necessary to initialise at least the owing four SFRs:

SCON0, PCON, SCON0, and TMOD. See section 2.5.4 for a complete listing and remarks

of the UART0_T1.c program and also section 4.4 in (Debono, 2015).

4.5 INTERRUPTS

Some common problems encountered with interrupts when using assembly language are addressed here:

Forgetting to re-start a timer: We might turn off a timer to re-load the timer register values or to read the counter in an interrupt service routine (ISR) and then forget to turn it on again before exiting from the ISR. In this case, the ISR would only execute once.

Forgetting to clear the Timer 2 interrupt flag: When using Timer 2 interrupts, the Timer 2 overflow flag TF2 is not cleared automatically when the ISR is serviced. We have to clear it in the ISR software (using CLR TF2). The same problem occurs if we forget to clear the RI or the TI flags when using the Serial Interrupt. In this case, the ISR keeps on being called repeatedly.

4.6 RTOSS PITFALLS

The PaulOS F040 co-operative RTOS is a robust and secure RTOSs which we have used extensively throughout the years with our students. This is mainly due to the fact that being a co-operative RTOS, the task changes occur when we want them since there cannot be any forced pre-emptive task changes. However there can still be hidden problems. We should take special care when handling global variables which are accessible to all the tasks. We have to make sure that these variables are allowed to be manipulated only when we want them to. Otherwise it might happen that a task starts with one value of a global variable, then it goes on to a wait state, and when it later on resumes to run, it might end up using the wrong value of the same variable simply because it was modified in the meantime by another task.

The same problem exists in the RTOS with register banks and tasks which use the same functions which are non re-entrant.

4.7 C TIPS

• We should always try to keep functions (or tasks) as simple as possible.

char data * xdata str;

/* pointer stored in xdata, pointing to char stored in data */

int xdata * data numtab;

/* pointer stored in data, pointing to int stored in to xdata */

long code * idata powtab;

/* pointer stored in idata, pointing to long stored in code */

• In order to improve the performance during code execution or to reduce the memory size requirement for our code, we should analyse the generated list files and assembly code so as to determine which routines can be improved in speed or reduced in size.

• We should always try to minimize the variable usage by scoping.

• Set the NUMBER_OF_TASKS, TICKTIME and TICK_TIMER definitions in the PaulOS_ F040_Parameter.h header file to correspond to your application program. This is often a common mistake to make.

• Ensure that if you are using interrupts, make sure that they are enabled.

• Remember that the timer used for the RTOS tick timer cannot be used also for say the baud rate generation of a UART.

• Remember to use the correct ISR parameter in PaulOS_F040_Parameter.h

header file when you are using a stand-alone ISR.

APPENDIX A PAULOS_F040.C