Twitter removed http basic auth from the api in august 2010, but this
underlying code is a good example of doing http basic auth in contiki.
The app has been renamed, and some fixes applied to make it build
cleanly.
- For the CC2538, simplify handling of USB_CDC_ACM_LINE_STATE
events. Ignore the Carrier Control (RTS) bit when receiving
a SET_CONTROL_LINE _STATE request, we are a full duplex device.
- Improve behaviour of the CC2531 USB stick when there is no
process on the host to read IN data. Basically, we adopt the
CC2538 approach and we only send data when a DTE is present
Since ncurses also defines COLOR_BLACK and friends, and we want
to avoid including curses.h in contiki-conf.h, define CTK_COLOR_*
constants and map them to curses colors in ctk-curses.c.
It seems TARGET_LIBFILES is used at the end of the link command,
unlike LDFLAGS, which should help when only a static curses lib is
available, like on Haiku.
It was added to avoid getting garbage keyboard input in some cases,
however it seems not to happen very often and might be the cause
of hang in OSX. If garbage input happens again we can always try
to pump a single event each time instead of looping anyway.
This is a temporary fix for #183, so that things can
build cleanly until the issue is fixed properly.
If RIMESTATS_CONF_ENABLED is 0, rimestats.foo will always
read as 0, since RIMESTATS_ADD(foo) doesn't do anything
Unfortunately, some platforms don't properly drop unreferenced functions,
so on these broken platforms we can save a significant amount
of space by skipping the definition of the convenience functions.
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
