The CC2538 currently has two addressing options: a hardcoded address set
at compile time or the address stored in primary address section of the
info page. This commit adds the option to choose the secondary location
of the ieee address from the info page, or any memory address.
To use, define `IEEE_ADDR_CONF_USE_SECONDARY_LOCATION` in `project-conf.h`
or similar.
For example:
#define IEEE_ADDR_CONF_USE_SECONDARY_LOCATION 1
Some CFLAGS and LDFLAGS previously only enabled with SMALL=1 have
now been enabled for all builds, regardless of the value of SMALL.
Therefore, from now on, SMALL only chooses between -Os and -O2
As discussed in #503, -Os was broken with one of the toolchains
recommended in the platform's README and for that reason we were
using -O2 by default.
This commit sets the default to -Os and updates the README to no
longer recommend the toolchain in question
lpm.c needs to #include lpm.h in order to get the definition of
lpm_periph_permit_pm1_func_t, which made the replacement macros conflict with
the function definitions for the LPM_CONF_ENABLE == 0 case. This change fixes
this issue by #if-ing out the code in lpm.c in that case. Also, the replacement
macro for lpm_register_peripheral() was missing in that case, which is fixed
here.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
If a project needs to use some libraries at link stage, then the corresponding
linker options (e.g. '-lm') have to be passed after any .o file depending on
these libraries. Hence, LDFLAGS cannot be used to add such options when invoking
$(LD) in Makefile.cc2538, or it should be moved to the correct location.
Instead, this change adds TARGET_LIBFILES to the correct location, like most
other Contiki targets.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
- The default mouse driver is now always named 'contiki.mou'.
- Alternative mouse drivers are present in the disk images.
- Users can select their mouse driver by renaming the files.
Some SoC data requires huge alignments. E.g., the µDMA channel control table has
to be 1024-byte aligned. This table was simply aligned to 1024 bytes in the C
code, which had the following consequences, wasting a lot of RAM:
- As this table could be placed anywhere in .bss, there could be an alignment
gap of up to 1023 bytes between the preceding data and this table.
- The size of this table was also aligned to 1024 bytes, regardless of
UDMA_CONF_MAX_CHANNEL, making this configuration option supposed to save RAM
just useless.
- .bss was also aligned to at least 1024 bytes, creating a huge alignment gap
between .data and .bss.
Instead of relying on the compiler to force this alignment, and on the linker to
automatically place data, this change places carefully such SoC data in RAM
using the linker script. A dedicated section is created to place such SoC data
requiring huge alignments, and it is put at the beginning of the SRAM in order
to ensure a maximal alignment without any gap. In this way, the alignment of
.bss also remains normal, and the size of this table is not constrained by its
alignment, but only by its contents (i.e. by UDMA_CONF_MAX_CHANNEL).
In the case of the µDMA channel control table, the data is still zeroed by
udma_init() (instead of also being zeroed as part of .bss).
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
