04.Contiki

Contiki

6.1

The Internet of Things (IoT) is a system where objects can be uniquely identified and communicate with each other over the internet without human intervention. These objects are embedded with technology that allows them to interact with their surroundings and make decisions. IoT is also considered a market with devices used to gather and analyse data to provide more information and knowledge to people.

However, developing software for these IoT devices is challenging. They are usually small in size, comparable to a matchbox, with limited capabilities compared to larger computing machines. They contain a core processing unit, memory systems, data exchange radios, and power sources, some of which may be integrated together. An example is Texas Instruments’ CC2650 system, with minimalistic applications due to its limited memory.

Battery-powered IoT systems also face energy efficiency issues. Developers need to cleverly manage power use to extend the battery’s life.

In software development for IoT, a primary challenge is the fragility of wireless data packets. IoT relies on cloud-centric architecture and frameworks for data processing. When writing software, cross-compilation is often necessary; you compile the software on one machine while it runs on another.

In summary, major concerns in IoT are power management and the reliability of wireless data transmissions. The use of open-source IoT operating systems can offer valuable insight into navigating these challenges.

Contiki NG

Contiki NG is a fork of original Contiki This text discusses a unique design of concurrent and networked systems that builds upon the original Contiki model. It focuses on IPv6 networking compliant with RFC standards and is compatible with modern 32-bit platforms. With a development history of almost 15 years, its main features include an event-based kernel, an easy to adjust configuration, portability, efficient IPv6 networking, and a small memory footprint. It is used in both academic and industrial settings.

The system uses a version of the C programming language, with development environments and tools typically found in C programming. However, the debugging process is notably different. The programs are capable of running on actual hardware as well as natively on your computer or through the COOJA simulator and MSPSim emulator.

Photothreads is the effort to maintain a sequential semantic with a single stack but also to manager asynchronous calls (like the ones from the sensors)

There is anology between photothreads “local continuation” to continuations in scheme? Is it the same concept?

Photothreads can share data and achieve cooperative scheduling using “Events”.

COOJA

• COOJA is a tool used in Contiki-NG for simulations. • “Scenario” means a set of settings for simulations, such as:

• The kind, number, and place of nodes

• A random seed that sets pre-decided behaviors

• A model for wireless channels • Scenarios can be saved and used again, this is helpful for testing with already set seeds. COOJA motes They work as C processes in COOJA JVM’s instance. Unlike native ones, they have network interfaces.

• Node processing doesn’t use up simulation time.

  • But, this could mean that behaviors (and mistakes!) that depend on time may not be shown correctly.
  • However, it does make the simulation faster!

COOJA motes are C processes that run within the COOJA Java Virtual Machine (JVM). Unlike native processes, these have networking interfaces.

In the simulation, local processing on a node doesn’t take any time. This means that behaviors and any potential bugs tied with time are not accurately represented. However, this speeds up the simulation.

There are different wireless propagation models available, which allows for exploring various link dynamics. Factors such as the mote startup delay, the random seed, and the success ratios of packets can all be changed.

Interference can be created with ‘Disturber’ modes. Unit Disk Graph Models (UDGM) come in two types: Constant Loss and Standard. The Constant Loss model features a set communication range with certain probabilities for packet reception and constant power loss. There’s also a steady level of background noise and packets outside the range are not received.

The Standard UDGM is similar to the Constant Loss model, but the power received decreases with distance.

Directed Graph Model

n this system, there are direct links or connections. Nodes that aren’t the destination aren’t interfered with. There aren’t any hidden terminals, exposed terminals, or background noise. It’s somewhat similar to modeling a wired network.

Timers

timer: requires to manually check if generate events for protothreads

• etimer: generates events when timers expire generates
• rtimer: like rtimer for longer periods

Execute callbacks

• ctimer: schedule function executions in time
• rtimer: preempts currently running functions with callback execution

As a result, provides predictable timer semantics

• Timer: You need to manually check if it creates events for protothreads
• Etimer: It creates events when time is up
• Rtimer: This operates like rtimer, but for longer periods of time

Executing Callbacks

• ctimer: This lets you schedule when functions should start. Useful to encode aynchronous execution flows Trigger asynchronous callbacks when expiring Data may be passed to the callback as a byte buffer
• rtimer: This stops the currently running functions and starts the callback execution. Useful to achieve accurate timing Use maximum clock resolution available from the hardware Preempt any other running protothread — “Execute now” semantics!! The rtimer API uses callbacks like ctimer, but works with absolute times! A reference to the rtimer is also passed carrying metadata.

The ‘ctimer’: This feature sets a schedule for when functions should start. It is useful for encoding the flow of asynchronous execution, which means it triggers asynchronous callbacks when needed. The data for the callback can be passed as a byte buffer.

The ‘rtimer’: This feature stops any running functions and starts the callback execution. This is useful for accurate timings. It uses the highest clock resolution available from the hardware. It replaces any other running protothreads immediately.

Just like ‘ctimer’, the ‘rtimer’ API also uses callbacks, but operates with absolute times. A reference to the ‘rtimer’ is also passed along which contains metadata.

rtimer preempts anything . The timer preempts any currently running functionality, which is resumed later.

With this, you get predictable time control.

Certainly! The functions you’re asking about are part of Contiki-NG, an operating system designed for Internet of Things (IoT) devices. These functions are used to manage timers, which are crucial for scheduling tasks in such systems. Here’s a detailed explanation of each function:

1. void ctimer_set(struct ctimer *t, clock_time_t interval, void (*callback)(void *), void *ptr)
   • Purpose: This function starts a timer.
   • Parameters:
     • struct ctimer *t: A pointer to the timer structure.
     • clock_time_t interval: The duration of the timer in clock ticks.
     • void (*callback)(void *): A pointer to the callback function that will be called when the timer expires.
     • void *ptr: A pointer to data that will be passed to the callback function.
   • Usage: You would use this to set a timer that calls a specific function (callback) after a certain period (interval). The ptr can be used to pass additional data to the callback.
2. void ctimer_reset(struct ctimer *t)
   • Purpose: To restart the timer from the time it was previously set to expire.
   • Parameters:
     • struct ctimer *t: A pointer to the timer structure.
   • Usage: This is used to reset the timer to its original duration, essentially restarting it from the beginning of its interval.
3. void ctimer_restart(struct ctimer *t)
   • Purpose: To restart the timer from the current time.
   • Parameters:
     • struct ctimer *t: A pointer to the timer structure.
   • Usage: This function is similar to ctimer_reset but the key difference is that ctimer_restart sets the timer to expire after the specified interval from the current moment, not from when it was originally set.
4. void ctimer_stop(struct ctimer *t)
   • Purpose: To stop the timer.
   • Parameters:
     • struct ctimer *t: A pointer to the timer structure.
   • Usage: If you no longer need the timer or want to prevent the callback from being called, you use this function to stop it.
5. int ctimer_expired(struct ctimer *t)
   • Purpose: To check if the timer has expired.
   • Parameters:
     • struct ctimer *t: A pointer to the timer structure.
   • Usage: This function returns a non-zero value if the timer has expired, and zero if it has not. It’s useful for checking the status of a timer.

In summary, these functions provide a way to manage time-driven events in Contiki-NG, allowing you to schedule and control actions in IoT applications efficiently.

Iot networking

In the realm of Internet of Things (IoT) networking, multi-hop networks where multiple intermediate nodes are used are quite usual.

There’s no single IoT protocol stack in place. The bottom-layer radio technology mostly dictates this, but the application requirements can also influence the application and transport layers. Two common ones at the transport layer are RPL and Thread.

In terms of routing, RPL is used. It creates a tree-shape structure with the root being the node that has direct Internet access. This is called a Destination-Oriented Directed Acyclic Graph (DODAG). This structure enables easier many-to-one communication. There are special packets called DODAG Information Objects (DIO) which carry data downwards from the root. These DIOs contain information about which objective function to use in order to pick the parent in the tree. Every node, then, has one preferred parent and may also have several backup parents.

This supports group and individual communication. Every node announces itself using Destination Advertisement Objects (DAO).

In the storing mode, each node in-between makes local routes for the nodes that are downstream. This means a common parent route can be reached faster. However, this may take up a lot of memory.

In the non-storing mode, only the main node stores downstream routes. All routes must pass through the main node. The main node usually has a lot of memory.

RPL has an adaptive behaviour in case of topology changes

MQTT in Contiki-NG

Message Queuing Telemetry Transport MQTT stands for Message Queuing Telemetry Transport. It is an extremely simple and lightweight messaging protocol (subscribe and publish) designed for limited devices and networks with high latency, low bandwidth or unreliable networks. A lightweight messaging protocol for small sensors and mobile devices, optimized for high-latency or unreliable networks

Contiki-NG and MQTT

MQTT, which stands for Message Queuing Telemetry Transport, is a simple and easy-to-use messaging system. It allows small devices such as sensors and mobile devices to send and receive messages even in areas with slow or unreliable internet connections. This system is designed to work efficiently even with low bandwidth and high latency.