Pros of TinyOS-main

• Highly modular architecture, allowing for easy customization and component reuse
• Extensive documentation and community support
• Efficient power management capabilities

Cons of TinyOS-main

• Steeper learning curve due to the use of nesC programming language
• Less active development compared to Contiki-NG
• Limited support for newer hardware platforms

Code Comparison

TinyOS-main (nesC):

module BlinkC {
  uses interface Timer<TMilli> as Timer0;
  uses interface Leds;
}
implementation {
  event void Timer0.fired() {
    call Leds.led0Toggle();
  }
}

Contiki-NG (C):

#include "contiki.h"
#include "dev/leds.h"

PROCESS(blink_process, "Blink");
AUTOSTART_PROCESSES(&blink_process);

PROCESS_THREAD(blink_process, ev, data) {
  static struct etimer et;
  PROCESS_BEGIN();
  etimer_set(&et, CLOCK_SECOND);
  while(1) {
    PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));
    leds_toggle(LEDS_GREEN);
    etimer_reset(&et);
  }
  PROCESS_END();
}

Pros of RIOT

• More extensive hardware support, including a wider range of microcontrollers and boards
• Better support for standard networking protocols like IPv6 and 6LoWPAN
• Modular architecture allowing for easier customization and feature selection

Cons of RIOT

• Larger memory footprint, which may be a concern for extremely resource-constrained devices
• Steeper learning curve due to its more complex architecture and feature set
• Less focus on power efficiency compared to Contiki-NG

Code Comparison

RIOT example (main.c):

#include "thread.h"
#include "msg.h"

int main(void)
{
    msg_t msg;
    msg_receive(&msg);
    return 0;
}

Contiki-NG example (main.c):

#include "contiki.h"
#include "sys/etimer.h"

PROCESS(example_process, "Example Process");
AUTOSTART_PROCESSES(&example_process);

PROCESS_THREAD(example_process, ev, data)
{
    PROCESS_BEGIN();
    etimer_set(&timer, CLOCK_SECOND);
    PROCESS_END();
}

Pros of Zephyr

• Broader hardware support and device drivers
• More extensive documentation and community resources
• Advanced features like real-time capabilities and power management

Cons of Zephyr

• Steeper learning curve due to more complex architecture
• Larger memory footprint, which may be challenging for resource-constrained devices

Code Comparison

Zephyr example (main.c):

#include <zephyr/kernel.h>

void main(void)
{
    printk("Hello World! %s\n", CONFIG_BOARD);
}

Contiki-NG example (hello-world.c):

#include "contiki.h"
#include "sys/log.h"

PROCESS(hello_world_process, "Hello world process");
AUTOSTART_PROCESSES(&hello_world_process);

PROCESS_THREAD(hello_world_process, ev, data)
{
    PROCESS_BEGIN();
    LOG_INFO("Hello, world\n");
    PROCESS_END();
}

The code examples demonstrate the different approaches to application structure and initialization in Zephyr and Contiki-NG. Zephyr uses a more traditional main() function, while Contiki-NG employs a process-based model with PROCESS macros.

Pros of FreeRTOS

• Wider industry adoption and support
• More comprehensive documentation and learning resources
• Better suited for real-time applications with strict timing requirements

Cons of FreeRTOS

• Larger memory footprint
• Less focus on IoT and wireless networking features
• Steeper learning curve for beginners

Code Comparison

FreeRTOS task creation:

void vTaskFunction(void *pvParameters) {
    for (;;) {
        // Task code here
    }
}

xTaskCreate(vTaskFunction, "TaskName", STACK_SIZE, NULL, TASK_PRIORITY, NULL);

Contiki-NG process creation:

PROCESS(example_process, "Example Process");
AUTOSTART_PROCESSES(&example_process);

PROCESS_THREAD(example_process, ev, data) {
    PROCESS_BEGIN();
    // Process code here
    PROCESS_END();
}

FreeRTOS focuses on traditional RTOS task management, while Contiki-NG uses a unique process-based approach tailored for IoT devices. Contiki-NG's code structure is more event-driven and suited for low-power operations, whereas FreeRTOS provides a more familiar multitasking environment for developers coming from traditional embedded systems backgrounds.