The leds API did not work in some cases. E.g. with the following sequence:
leds_off(LEDS_ALL);
leds_toggle(LEDS_GREEN);
leds_off(LEDS_ALL);
the green LED was remaining on after the last call.
This was caused by the toggle feature made synonymous with the invert feature,
although it is unrelated. leds_toggle() is indeed supposed to toggle an LED,
while leds_invert() is supposed to change the active level of an LED. However,
all users of leds_invert() actually meant leds_toggle(), and the invert feature
does not make sense in this module because it is not handy due to successive
calls to leds_invert() changing the intended behavior, and hardware active
levels should be managed in leds_arch_set() (e.g. by XORing the passed value
with a hardware-specific constant before setting the output levels of the pins).
Consequently, this change:
- removes the leds_invert() function,
- makes leds_toggle() behave as expected relatively to leds_off() / leds_on(),
- sanitizes the code in the leds module.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Historically $(OBJECTDIR) was created when Makefile.include is read. A
consequence is that combining "clean" with "all" (or any other build
target) results in an error because the clean removes the object
directory that is required to exist when building dependencies.
Creating $(OBJECTDIR) on-demand ensures it is present when needed.
Removed creation of $(OBJECTDIR) on initial read, and added an order-only
dependency forcing its creation all Makefile* rules where the target is
explicitly or implicitly in $(OBJECTDIR).
The boot loader now knows when to go into bootstrap mode by
looking for a specific EEPROM value. Also updated code style
to match Contiki code style guidelines.
This commit moves the Settings Manager from the AVR codebase
into the Contiki core library. Any platform that implements
the Contiki EEPROM API can now use the Settings Manager's
key-value store for storing their persistent configuration info.
The Settings Manager is a EEPROM-based key-value store. Keys
are 16-bit integers and values may be up to 16,383 bytes long.
It is intended to be used to store configuration-related information,
like network settings, radio channels, etc.
* Robust data format which requires no initialization.
* Supports multiple values with the same key.
* Data can be appended without erasing EEPROM.
* Max size of settings data can be easily increased in the future,
as long as it doesn't overlap with application data.
The format was inspired by the [OLPC manufacturing data format][].
Since the beginning of EEPROM often contains application-specific
information, the best place to store settings is at the end of EEPROM
(the "top"). Because we are starting at the end of EEPROM, it makes
sense to grow the list of key-value pairs downward, toward the start of
EEPROM.
Each key-value pair is stored in memory in the following format:
Order | Size | Name | Description
--------:|---------:|--------------|-------------------------------
0 | 2 | `key` | 16-bit key
-2 | 1 | `size_check` | One's-complement of next byte
-3 | 1 or 2 | `size` | The size of `value`, in bytes
-4 or -5 | variable | `value` | Value associated with `key`
The end of the key-value pairs is denoted by the first invalid entry.
An invalid entry has any of the following attributes:
* The `size_check` byte doesn't match the one's compliment of the
`size` byte (or `size_low` byte).
* The key has a value of 0x0000.
[OLPC manufacturing data format]: http://wiki.laptop.org/go/Manufacturing_data
This magic comes from the `--gc-sections` linker flag, which turns on garbage collection for unused input sections. The compiler flags `-ffunction-sections` and `-fdata-sections` make sure that each function and each static data definition have their own section. The result is that GCC can prune away all unused symbols, reducing the size of the resulting executable.
These optimizations may be disabled by setting the Makefile variable
`SMALL` to zero.
