Currently, it is common to see Contiki's core/ interfaces implementations
spread in both cpu/ and platform/. We here take one step further starting
an effort to centralize all of these in platform's code instead.
This commit starts this by adding platform/galileo/core/ and its sys/
subfolder, adding a stubbed mtarch.h and moving clock and rtimer
implementations to this new folder. From now on we should concentrate
implementation from Contiki's core/ interfaces into the appropriate
subfolder in platform/galileo/core/.
Note that this is not the current fashion followed on other platforms
and cpus folders, as most of them add the core interface implementation
into its subfolder directly. For instance, on CC2538DK,
core/dev/button-sensor.h is implemented in platform/cc2538dk/dev/
directly, while on Galileo it would sit at platform/galileo/core/dev/.
We believe ours is a better approach to organize and escalate a
platform's code base.
We also remove previous x86 mtarch.h and mtarch.c since they weren't used
at all - both native and cooja platforms have their own mtarch
implementations.
This patch adds support for rtimer library on Galileo's platform.
We use the PIT to implement the rtimer platform dependent
functionalities. We chose the PIT for mainly two reason: I) its
configuration is very simple II) it has a high frequency which
provides us a good clock resolution (requirement from rtimer
library).
Since we keep track of the number of ticks in software, we define
rtimer_clock_t type as uint64_t. This gives us a good amount of time
til the variable overflows. For instance, a 32-bit type would overflow
in about one hour for high clock resolution (~ 1us).
The rtimer clock frequency (RTIMER_ARCH_SECOND) is setup to 1 kHz.
There is no technical matter regarding this value. It is just an
initial guess.
Just for the record, we might want to use HPET in future to
implement the rtimer library since it seems to be more appropriate.
The reason why we don't use it at this moment is that, in order to
configure it, we need support for ACPI 2.0 which we don't. Once we
have use-cases for the rtimer library we'll probably replace PIT
by HPET or any other timer more suitable for the job.
This patch adds support for the Etimer and Ctimer libraries. To support
the Etimer library, we should poll the etimer process every time the
system clock is updated. To do this more efficiently, by taking advantage
of etimer_next_expiration_time() API, we poll the etimer process only
when an 'Event Timer' has expired.
We don't need any platform specific support in order to enable the Ctimer
library since it relies completely on Etimer.
The others timer libraries (Timer and Stime) don't required any specific
platform support as well since they rely on the system Clock module only.
This patch adds support for Contiki's clock module. All functions from
core/sys/clock.h are implemented, except clock_set_seconds() and clock_
delay_usec(). The CLOCK_CONF_SECOND macro is set to 128. This value
seems to be good enough since several platforms used it. Finally, we
use the RTC driver to track the number of ticks from the system clock.
The Programmable Interrupt Controller is a chip responsible for
translating hardware interrupts to system interrupts. When it
receives an Interrupt Request (IRQ), it triggers the appropriate
interrupt line reaching the appropriate IDT gate, following a
previously setup offset.
There are 2 daisy-chained PICs. PIC1 handles IRQs 0-7 and PIC2
handles IRQs 8-15. If no vector offset is set, an IRQ0, for instance,
would trigger the interrupt 0, clashing with the "Division by zero exception"
handler. Thus the IRQs must be remapped.
This patch implements the PICs initialization through their 4
Initialization Command Words (ICWs) in a very "canonical" way:
- ICW1: the initializing command;
- ICW2: the vector offset for the PIC1 and PIC2 (we add an offset of 32 positions);
- ICW3: the inter-PICs wiring setup (we connect PIC2 to PIC1's IRQ2);
- ICW4: extra systems information (we set PIC1 as Master and PIC2 as slave).
It then masks the Interrupt Mask Register, blocking all IRQs but #2 initially.
These must be unmasked on demand. The IMR is 8-bits long, so setting the n^th bit to 1
would DISABLE the IRQ n while setting it to 0 would ENABLE IRQ n.
As stated, this is an implementation of the legacy 8259 PIC. More
investigation is needed so we decide if it is enough or if we need
the (newer) APIC implementation instead.
This patch also adds the outb() helper function to helpers.h. The helpers
is a wrapper for assembly 'out' instruction.
Finally, since we now properly support hardware interrupts, this patch
also enables IRQs in platform main().
More information:
- Quark X1000 Datasheet, section 21.12, page 898.
- http://wiki.osdev.org/8259_PIC
- http://stanislavs.org/helppc/8259.html
This patch defines the cpu_init() function which should encapsulate
all code related to x86 CPU initialization. For now, this function
initializes GDT and IDT.
This patch adds the helpers.h. This file should contain only x86-related
helper functions and macros. For now, we define the BIT macro and halt()
helpers which will be used in upcoming patches.
Additionally, this patch also changes loader.S to call the halt().
This patch implements the main() function for Galileo platform. At this
moment, only Processes subsystem is enabled. After this patch we are
able to some rudimentary debugging to ensure that process thread from
applications are being indeed executed.
Once we properly support more Contiki subsystems, such as clock, ctimer,
etimer, and rtimer, we will add them to Galileo platform's main() as well.
All we need to provide to C at this point is a region in memory dedicated to
its stack. This is done by allocating a region in .bss and pushing its start
address to esp. Since the multiboot spec says it is not safe to rely on the
initial stack provided by the bootloader, this patch provides our own stack.
Galileo boards have 512Kb of SRAM and 256Mb of DDR3 RAM, so providing 8kb as
a start seems safe. Moreover, stack sizes are very application-oriented
so it may be too early to provide a bigger (or smaller) stack.
This patch changes Galileo's buildsystem to print the elf sections
sizes after a new image is built. This way we can easily track how
these sections increase or decrease after any change.
To achieve that, we define a custom linking rule which is pretty much
the same as the default linking rule define in Makefile.include, but
we run 'size' command after the image is built.
This patch adds a README file which contains general information about
the Intel Galileo board support. The file provides information about
supported features as well as instructions on how to build, run and debug
applications for this platform.
This patch the 'debug' rule to simplify the debugging process. This new
rule runs OpenOCD and gdb with the right parameters. OpenOCD runs in
background and its output will be redirected to a log file in the
application's path called LOG_OPENOCD. Once gdb client is detached,
OpenOCD is terminated.
The 'debug' rule is defined in Makefile.customrules-galileo file (create
by this patch) which is included by the Contiki's buildsystem. So to
debug a Contiki application for Galileo board, run the following command:
$ make TARGET=galileo debug
If you use a gdb front-end, you can define the "GDB" environment variable
and your gdb front-end will be used instead of default gdb. For instance,
if you want to use cgdb front-end, just run the command:
$ make BOARD=galileo debug GDB=cgdb
This patch adds the initial support for Intel Galileo Platform. It
contains the minimum set of code required to boot a dummy Contiki
image.
For Galileo initial support, we implemented a linker script, a minimal
bootstrap code, a set of stubbed functions required by newlib, and a
very simple main() function. Moreover, we also define some header files
and macros required by Contiki.
To build applications for this platform you should first build newlib
(in case it wasn't already built). To build newlib you can run the
following command:
$ platform/galileo/bsp/libc/build_newlib.sh
Once newlib is built, you can build applications. To build applications
for Galileo platform you should set TARGET variable to 'galileo'. For
instance, building the hello-world application should look like this:
$ cd examples/hello-world/ && make TARGET=galileo
This will generate the 'hello-world.galileo' file which is a multiboot-
compliant [1] ELF image. This image can be booted by any multiboot-
complaint bootloader such as Grub.
Finally, this patch should be used as a guideline to add the initial
support for others platforms based on x86 SoCs.
[1] https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
This patch creates the platform/galileo/bsp directory. This directory
contain all files related to Galileo's Board Support Package (BSP). For
now, the BSP consists of libc and bootloader.
Within the BSP directory, we have the scripts build_newlib.sh and build_
grub.sh. These scripts provide an easy and quick way to build the newlib
and the grub for the Galileo platform.
Currently there are only one platform using CPU x86: Cooja. The
elfloader-x86.c is rather a POSIX implementation, so the Galileo port
won't use it for now. This patch fixes this by moving this source file to
be included by the platforms using it instead of the cpu's Makefile.
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
The DNS resolver requires 1/4 sec clock resolution. The retro targets had a 1/2 sec clock resolution (optimized for the 1/2 sec TCP timer) resulting in DNS resolver timeouts being 0. Therefore the retro target clock resolution is now increased to 1/4 sec.
The default Telnetd idle timeout of 30 seconds seems somewhat short. Best to have it user-configurable (incl. the option to turn it off with an config value of 0).
In order to have the wget command make some sense the write command should be present too.
- On the Apple][ reduction of the MTU seems to gain just enough RAM to have the (rather heavy-weight) full-blown C library file I/O working.
- On the C128 there's way too little RAM so there's no wget command but only the file commands.
- On the CBMs a dummy lseek() was necessary to have the read command link.
* The current version of the README points to a wrong URL
for the LUFA Virtual Serial driver.
* A driver is nowadays provided by TI with CC2538
Foundation Firmware
Thus, this pull updates the LUFA driver URL and also provides a
link to CC2538 Foundation Firmware
When using this code:
(int8_t)tmp102_read_temp_x100() / 100
Only the first value is casted into a int8_t type.
tmp102_read_temp_x100() returns the temperature in Celcius * 100. Most of
the time this value will be lower than -2^7 and higher than 2^7 (+/- 1.27°C).
The cast is not needed but a comment about this implicit cast has been added.
Document the URL of the older Sourcery G++ Lite 2008q3-66 arm-none-eabi
toolchain mentioned by README.md so that users can easily find it if
needed.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
* Keep MPU_PWR low when the sensor is not in use
* Deselect the sensor when not in use, in order to restore the I2C ping state
* Explicitly control the MPU_INT pin
* Don't shutdown the sensor when it's shut down
* Remove explicit shutdown-related API extension. It is no longer required
Instead of using a separate data structure to request that a PD remain powered during deep sleep,
we do the same within the main LPM data structure through an additional field.
This allows us to maintain only one linked list of LPM modules and overall improves code clarity
We only power, clock and enable the peripepheral when / if we need it
* We no longer automatically turn on the SERIAL PD when the CM3 is running
* Make sure the I2C peripheral is accessible (powered and clocked) before any operation
* If the peripheral is not accessible, automatically power it up and run the clock
* Put SDA, SCL, SDA HP and SCL HP in a low-leakage state when shutting down
* Don't automatically fire up the I2C controller when we wake up
* Explicitly put in deep sleep on device startup
* Verify that the flash has actually dropped to deep sleep
* Update CLK pin to match the one used on the v1.2 sensortag
Obsoletes and Closes#988
* Query the sensor about its state, rather than using variables in the driver
* Correctly put the sensor to deep sleep
* Fix doxygen comments
* Don't turn off the sensor in examples since it is no longer needed
It seems that this implementation of CoAP in Contiki is no longer
maintained in favor of the `er-coap` implementation. This commit
removes the code to prevent confusion and further bit-rot.
Several platforms defined compressions modes values:
SICSLOWPAN_CONF_COMPRESSION_IPV6
SICSLOWPAN_CONF_COMPRESSION_HC1
SICSLOWPAN_CONF_COMPRESSION_HC01
instead of using the global SICSLOWPAN_COMPRESSION_LEVEL definitions
Note: The raven-lcd-interface and raven-ipso modules in atmega128rfa1
seem to be needles for this platform and might be there only because of
copy&paste from the raven platform. Should be removed in a later patch.
* Added dev/uart1.h header file to cooja platform
* Added slip arch stub
* Suppress examples putchar definition as cooja platform provides its own
Note that the uart1.h file should only be an intermediate solution.
A generic contiki-wide definition for uart handling is required as each
platform defines its own varying set of uart functions.
to allow for creating and securing frames in advance; Create and secure frames in advance when sending bursts; Do neither recreate nor resecure frames that come from phase
The border-router tries to transmit and do other stuff after turning
the radio off, and the radio driver didn't handle that very well.
With this fix, it's no longer necessary to reset the border router
after starting tunslip6.
In order to use the er-server-example Radio resource it is required that the platform defines that it has a radio. This line might be required in other platforms.
type process_data_t. This was an artifact when the choice was
made to use the void * type for the data parameter in processes.
Changed parameter 'void * data' of process_post_synch to
process_data_t for consistency.
Checked all the uses of process_start() in contiki and fixed casts
of the data parameter.
Instead of requiring all calls to `watchdog_start` to be
wrapped inside `#if WATCHDOG_CONF_ENABLE` guards, we control
things from within the WDT driver itself.
This commit also includes some minor documentation and
indentation cleanups
* Decouple 64-bit address from LINKADDR_SIZE
* get and set object from/to the start/end of the src/dest buffer
* We expect size == 8 (rather than size < 8) for both get_ and set_object. Error otherwise
* The RF no longer sets parameters by itself. We let the platform do this, using the extended API.
The type used to store rtimer ticks on this platform is 32-bit integer, but the macro uses 16-bit comparison.
As a result, the output of the RTIMER_CLOCK_LT(a,b) macro was incorrect when used for comparisons between time values with sufficiently large difference.
The code to repeat this problem on mbxxx platform:
rtimer_clock_t a = 6 * RTIMER_ARCH_SECOND;
rtimer_clock_t b = 0;
printf("%d\n", RTIMER_CLOCK_LT(a,b)); // expected output: "0", actual: "1"
This avoids the limitation of having a single UART available at runtime, without
duplicating code.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Because the CC2538 has a multi-byte SPI RX FIFO, flushing the buffer
requires more than just a single read. This adds a loop that empties the
entire RX buffer on a FLUSH().
Different SPI chips needs different SPI settings. This commit adds a
function that allows chip drivers to configure the SPI peripheral before
using it.
The frame pin the driver was using as a chip select does not work as
most devices expect it to. It toggles after every byte, and most chips
interpret that as end of message. To make drivers more reliable, each
chip driver should setup a GPIO and assert it as needed.
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
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
- Up to now the CTK program handler was necessary to start wget and forward the URL. Now alternatively the webbrowser uses the underlying OS to exec wget.
- Up to now windowed CTK was necessary to display the acknowledge dialog. Now alternatively the webbrowser displays the acknowledge text and buttons right in the webpage area.
- For now the targets 'win32' and 'c64' make use of the new capabilities.
- 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.
CFS_WRITE implies O_TRUNC which is implemented on CBM DOS by deleting an
exsisting file. Hoewever this succeeds only if the CBM DOS filetype matches.
We need a working O_TRUNC in order to be able to overwrite the contiki.cfg
configuration file.
Note: Now it has be clarified why overwriting the configuration file started to
fail the CBM PFS (platform file system) can be activated for the recently added
ethconfig program.
Create a dedicated header file with all the definitions for the flash lock bit
page and customer configuration area. This avoids duplicating those definitions
in the startup-gcc.c files of all CC2538-based platforms, and this also allows
to easily manipulate the CCA from outside startup-gcc.c (e.g. for on-the-air
firmware update).
The definitions are now complete contrary to what was in startup-gcc.c:
- Definitions have been added to select the bootloader backdoor pin and active
level if enabled.
- Definitions have been added to access the page and debug lock bits. The debug
lock bit can be used to prevent someone from reading back a programmed
firmware through JTAG if the firmware binary image has to be confidential,
which should be combined with a disabled bootloader backdoor.
- The application entry point is now tied to the beginning of the .text section
instead of to the beginning of the flash. This allows projects using custom
linker scripts to place the application entry point anywhere in the flash,
which can be useful e.g. for on-the-air firmware update.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
SYS_CTRL_EMUOVR is already defined in sys-ctrl.h, so #include this header file
instead of redefining SYS_CTRL_EMUOVR in startup-gcc.c.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
