Coffee is placed by default at the beginning of the flash memory, right
before the firmware. This avoids the memory gaps that there could be
before and after Coffee if it were placed after the firmware, because it
is unlikely that the end of the firmware is aligned with a flash page
boundary, and the CCA is not flash-page-aligned. Thanks to that, Coffee
is also always in the same flash area if its size remains unchanged,
even if the firmware changes, which makes it possible to keep the Coffee
files when reprogramming the firmware after a partial flash erase
command.
The default configuration of Coffee is set to use sensible values for a
typical usage on this SoC, i.e. for sensor data logging.
The default size of Coffee is set to 0 in order not to waste flash if
Coffee is unused.
COFFEE_CONF_CUSTOM_PORT can be defined to a header file to be used with
"#include" in order to override the default CC2538 port of Coffee. This
makes it possible to use Coffee with an external memory device rather
than with the internal flash memory, without having to alter the Contiki
files.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Depending on the linker script, the generated .bin file may start beyond
the beginning of the flash memory. However, no target address was passed
to cc2538-bsl.py by the upload make target, so it used the beginning of
the flash memory in all cases.
The load address of the lowest loadable output section is now passed to
cc2538-bsl.py. The start address of the .text output section or the
address of the _text symbol could have been used too, but this would not
have been compatible with all the possible custom linker scripts.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Define the available CC2538 devices and their features, and use them to
define the linker script memory regions. The .nrdata output section is
now always defined in order to trigger an error if it is used but no
memory is available for it. The CC2538 device used by Contiki is made a
configuration option, the CC2538SF53 device being the default.
This makes more sense than defining the flash memory address and size as
configuration options like previously, all the more not all values are
possible and all the features are linked by each device.
This change also makes it possible to:
- use the correct SRAM parameters for the CC2538NF11,
- know at build time if the AES, SHA, ECC and RSA hardware features are
available on the selected CC2538 device.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
This commit fixes nearly all of the reported doxygen warnings.
I tried to not clutter the log with removed trailing spaces.
Removed whitespace and converted tab/spaces for all files affected by this commit
are in a separate branch.
CC_FASTCALL was introduced many years ago for the cc65 tool chain. It was never used for another tool chain. With a798b1d648 the cc65 tool chain doesn't need CC_FASTCALL anymore.
Recently support for 80 column CONIO based on 320x200 graphics was added to the cc65 C library for the C64. This change leverages this for the IRC client and the web browser. Because not everybody prefers this 'soft80' display with its small 4x8 charbox the 40 column programs are still available as before (with the new programs called 'irc80' and 'webbrowser80').
So far 80 column display was an attribute of a cc65 platform. Now each cc65 application can ask for 80 column display by defining WITH_80COL. Of course this is ignored by platforms incapable of 80 column display.
I see three types of application:
* Applications not benefitting from 80 column at all and in fact looking better with 40 column display. These are now using 40 column display. Examples: ethconfig, ipconfig
* Applications taking advantage of 80 column display if it is available without drawbacks. These stay as they were. Examples: Telnet server, web server, wget
* Applications needing 80 column display so urgently that it is likely desirable even if the display becomes harder to read. These come now in both flavors allowing the user to choose. Examples: IRC, web browser
Note: This change doesn't actually introduce any 80 column display with drawbacks. This if left to a subsequent change.
The cc65 memory map for the ATARI XL has two holes so the linker needs hints which object files go where. Source changes lead to object file size changes requiring now and then to rearrange the object files.
On the raven, the battery and temperature readings are available
from the companion 3290 cpu over the serial line.
Modify the existing raven-lcd-interface application to export
these sensors.
Previously, the Cooja mote assumed that its file was always initially empty (file.endptr == 0). Therefore, a file uploaded to a mote's CFS could never be read by the mote, as the mote would prevent reads from going past the EOF (indicated by endptr).
By tracking the file size and making it accessible to Cooja, the correct size of the uploaded file can be reported to the mote and allow it to read the uploaded file.
For the SPI
* We improve the return semantics of _read() and _write()
* We set speed based on the value returned from ti_lib_sys_ctrl_clock_get() instead of using a hard-coded value
External flash changes:
* Rename macros to match instruction names
* verify_part(): Return a different value when the device is powered down and when communication fails
* Change return value semantics of static functions
* Adjust checks of board_spi_ return values
* Wait for BUSY to clear before attempting to send PD
* Accept two possible flash parts: W25X40CL (4MBit) as well as the W25X20CL (2MBit)
This commit updates the srf06-cc26xx platform by adding support for the CC1310EM.
We generalise the way this platform selects CPU/board so that we can easily add more combinations in the future. These changes have implication on how to build for different devices, so make sure to have a look at the updated README
