size LARGE_BUFFER_SIZE If this scheme is not proper applied, memory corruption may occur.
6 Application and stack configuration
6.1 Build switches
6.1.1 Global stack switches
6.1.3.6 ENABLE_HIGH_PRIO_TMR
AT86RF230 transceivers need to have an ED sampling timer running in case Energy Detect scanning is used. This timer is implemented by means of a unique and very accurate hardware timer (High priority timer). In other transceivers (Atmel
AT86RF231 or Atmel AT86RF212) this hardware timer is not required for Energy Detect scanning, since additional hardware support is provided.
On the other hand the provided standard software timers have limited accuracy, since several software timers share one hardware resource. An application may want to use this timer if desired for their own purpose. In this case this build switch has to be set. But the application has to make sure that it is not using this hardware timer concurrently with the stack.
All provided example applications within the MAC package do not use this feature, so in order to save code space this timer is not enabled.
Usage in Makefiles:
CFLAGS += -DENABLE_HIGH_PRIO_TMR
enables the code for the high priority timer. Usage in IAR ewp-files:
ENABLE_HIGH_PRIO_TMR
enables the code for the high priority timer. 6.1.3.7 EXTERN_EEPROM_AVAILABLE
Each node needs to have a unique 64-bit IEEE address (extended address) to identify itself within the network. All example applications delivered within the MAC software package are only working if the node has such an IEEE address.
This address is usually stored in an EEPROM, either in the internal EEPROM of the MCU or in an external chip on the board. If the hardware board has such an external EEPROM where the IEEE address is stored, this build switch has to be enabled. The actual implementation of the code for reading the address from an external EEPROM is board dependent and might be adapted by the end user depending on their hardware.
If the IEEE address is stored within the internal EEPROM of the MCU (located in the first eight octets of the internal EEPROM), this build switch should to be omitted. Usage in Makefiles:
CFLAGS += -DEXTERN_EEPROM_AVAILABLE
enables reading the IEEE address from the external EEPROM. Usage in IAR ewp-files:
EXTERN_EEPROM_AVAILABLE
enables reading the IEEE address from the external EEPROM. 6.1.3.8 NON_BLOCKING_SPI
Currently, for all transceivers connected to the microcontroller via SPI, the SPI frame download or upload is done blocking, that is, while the controller is access the transceiver no other action can be on the microcontroller.
Since more powerful microcontroller may require performing other application or stack tasks while accessing the transceiver via SPI, an option to perform non-blocking SPI access has been implemented. This access makes use of interrupt driven SPI access for downloading frames. In between the microcontroller is able to do other tasks as required.
The non-blocking SPI can be controlled via the build switch NON_BLOCKING_SPI. Usage in Makefiles:
CFLAGS += -DNON_BLOCKING_SPI
enables non-blocking SPI frame download. Usage in IAR ewp-files:
NON_BLOCKING_SPI
enables non-blocking SPI frame download.
6.1.3.9 F_CPU (formerly SYSTEM_CLOCK_MHZ)
Currently each supported platform (that is, each supported board) has a specific clock speed set for the system clock. This clock speed might need to be changed for certain applications.
For the platform Atmel ATxmega128A1 with Atmel AT86RF231 on REB_4_1_600 the clock speed can be changed at compile time (4…32MHz).
The current system clock speed can be controlled via the build switch F_CPU. If the build switch is omitted, the standard system clock speed is used.
Usage in Makefiles:
CFLAGS += -DF_CPU=4/8/32
configures the system clock to 4/8/32MHz. Usage in IAR ewp-files:
F_CPU=4/8/32I
configures the system clock to 4/8/32MHz.
Example Makefiles and IAR project files are provided for the MAC example application Star_Nobeacon.
For more information please see Section 11.1. 6.1.3.10 BAUD_RATE
This build switch allows for changing the used UART baud rate. The default UART baud rate is 9600 bps. This may be changed by setting this build switch to a different meaningful value.
Usage in Makefiles:
CFLAGS += -DBAUD_RATE=38400
configures the UART baud rate to 38400 bps. Usage in IAR ewp-files:
BAUD_RATE=38400
configures the UART baud rate to 38400 bps.
Omitting this build switch sets the default baud rate of 9600 bps. For USB this build switch has no meaning.
Pease note that the proper working of the UART with certain baud rates is depending on the current system clock speed (see build switch F_CPU) and the error in the used
oscillator frequency. As a rule of thumb the error of the oscillator frequency shall not be more than 2%.
For example, in case the Atmel ATmega1281 is used with F_CPU = 8MHz, the error for 38400 bps is 0.2%, which is perfectly fine, but for 115200 bps the error is -3.5% which may lead to improper functioning of the UART. For more information about the UART oscillator frequency error please check the data sheet of the utilized MCU type. 6.1.3.11 VENDOR_BOARDTYPES
This build switch allows for the support of customer specific hardware boards which are directly supported within this software package without the need to change any single file.
If this switch is set in the application, the known boards defined in the corresponding files pal_boardtypes.h are ignored. Instead a file vendor_boardtypes.h searched in the current include path. If such a file is found, the boards defined in vendor_boardtypes.h are used during the build process. For example, see file PAL/AVR/ATMEGA1281/Boards/pal_boardtypes.h, where the following code is included:
#if defined(VENDOR_BOARDTYPES) && (VENDOR_BOARDTYPES != 0) #include "vendor_boardtypes.h"
#else /* Use standard board types as defined below. */
In order to enable the utilization for customer specific board types, the compile switch must be set in the corresponding project files. If this
Usage in Makefiles:
CFLAGS += -DVENDOR_BOARDTYPES
or
CFLAGS += -DVENDOR_BOARDTYPES=1
enables the utilization of customer specific board types.
Usage in IAR ewp-files:
VENDOR_BOARDTYPES
or
VENDOR_BOARDTYPES=1
enables the utilization of customer specific board types.
If this build switch is omitted or set to zero in the corresponding project files, the board definitions from the current file pal_boardtypes.h are used as usual.
Figure 6-3. Inclusion of vendor_boardtypes.h.
// board types vendor n #define ...
…
#define ... #if defined(VENDOR_BOARDTYPES)
#include "vendor_boardtypes.h"
#else
// standard board types are used #define ...
…
#define ... #endif
pal_boardtypes.h
vendor_boardtypes.h
// board types vendor 2 #define ...
…
#define ...
// board types vendor 1 #define ...
…
#define ...
For more information about how to use this switch and how to enable customer specific boards, please refer to Section 11.3.1.1.