Archive

Posts Tagged ‘mbed’
Orange Pi Development Boards

FOSDEM 2018 Open Source Developers Meeting Schedule

January 23rd, 2018 5 comments

FOSDEM (Free and Open Source Software Developers’ European Meeting) occurs every year on the first week-end of February, where developers meet for two days discussing about open source software projects. FOSDEM 2018 will take place on February 3-4 this year with  652 speakers, 684 events, and 57 tracks, an increase over  last year 608 speakers, 653 events, and 54 tracks. There will be 8 main tracks namely: Community, History, Miscellaneous, Performance, Python, Security and Encryption, Space, and Global Diversity CFP Day.

There will also be 33 developer rooms, and since the full schedule is now available, I’ll make a virtual schedule mostly based on sessions from the Embedded, mobile, and automotive, Hardware Enablement, and Internet of Things devrooms.

Saturday 3, 2018

  • 09:50 – 10:15 – Turning On the Lights with Home Assistant and MQTT by Leon Anavi

In this presentation you will learn the exact steps for using MQTT JSON Light component of the open source home automation platform Home Assistant for controlling lights through the machine-to-machine protocol MQTT. Practical examples for low cost devices combining together open source hardware with free and open source software will be revealed. The presentation will provide general overview of Home Assistant, details about the software integration of new devices to it through the MQTT protocol and open source MQTT brokers such as Mosquitto. We will do a code review of an open source Linux daemon application for Raspberry Pi, written in the C programming language and based on the Paho library for MQTT client and the piGPIO library used for pulse-width modulation (PWM) control of a RGB LED strip. We will compare it to an implementation of the same features for the microcontroller with WiFi ESP8266 written as a sketch for the Arduino environment. Furthermore, the presentation will include details about reading data from various sensors and their setup in Home Assistant.

  • 10:25 – 10:50 – Accessing your Mbed device from anywhere using Pagekite by Bert Outtier

When looking at home automation solutions available in the market nowadays, one of the most important and expected features is to be able to control your home automation installation from anywhere in the world using a smartphone app. A vendor of a low-cost home automation solution requested us to add such a feature to their existing IP gateway product, which only allowed for users to control their home automation system with their smartphone while they are connected to their local network at home. We were asked to make it possible to let the smartphone app connect to the IP gateway from anywhere in the world. This vendor’s IP gateway hard- and software was based on the Mbed platform, so they needed a solution that could fit within Mbed.

Since our client wanted an open-source, secure, low-cost and easy to set up solution that he could host himself, we opted to go for Pagekite. However, since Mbed does not support OpenSSL, Linux sockets or libev, the existing libpagekite C library was not an option to start from. So we started to implement a Mbed flavour of the library ourselves, and decided to make it open-source

  • 11:00 – 11:30 – The free toolchain for the STM8 by Philipp Klaus Krause

The STM8 is a popular 8-bit architecture by ST Microelectronics commonly used in household electronics, automotive application and industrial controls. For quite a while there were no free tools, and the irregular architecture makes it hard to support in GCC or LLVM. In recent years free tools for it started to appear and now form a free toolchain that surpassed preexisting non-free ones. The most important part is the Small Device C Compiler (SDCC). New tree-decomposition-based algorithms from recent compiler research have been implemented in SDCC, including a new register allocator particularly suited to irregular architectures with few registers. SDCC quickly surpassed the non-free compiler in standard compliance and OS support and generates substantially faster integer code. Programs can be flashed by stcgal (via a serial link on STM8 devices that have a bootloader) and stm8flash (via the SWIM interface of ST-LINK hardware). OpenOCD and GDB allow on-target debugging via the ST-LINK. IDEs complete the development environment. However, stcgal still needs non-free binary blobs for use with some devices and the ST-LINK has non-free firmware. SDCC still falls short in floating-point performance. While there are some ports of free RTOSes that use the free toolchain for the STM8, more would be desirable.

  • 11:30 – 12:00 – Building RT Linux distribution with Yocto by Pierre Ficheux

The conference will describe how to use PREEMPT_RT and Xenomai with Yocto build system – building image and SDK – developing simple application – testing performances.

Using RT extension with Yocto is not that easy because linux-yocto-rt kernel is not usable on main embedded target such as ARM (as it works on QEMU target only). Using Xenomai is much more complicated as it needs several steps (patching the kernel, installing user-space libraries, building an extended SDK).

During the conference we will describe how to build a Yocto Linux image using PREEMPT_RT for famous boards such as Pi 3 or BeagleBone Black.

Some Xenomai support is provided by meta-eldk from DENX but it supports only Xenomai 2.6. We will describe meta-xenomai as we maintain it for our customers (available on GitHub). That new meta-xenomai layer is based on Xenomai 3.x and very recent kernel.

Then we will explain how to build a simple Xenomai application based on a periodic task. Finally we will compare performances of both extension (PREEMPT_RT and Xenomai) on same hardware.

  • 12:00 – 13:00 – How to keep your embedded Linux up and running? by Krzysztof Opasiak

Userspace software is imperfect and we all know about this. Running it for 5 minutes seems to be easy but what about days or weeks? This problem already gave server guys a lot of sleepless nights. Nowadays also IoT and embedded Linux world is facing very the same problem. Unfortunately solutions known from server world (Nagios and friends) usually cannot be directly applied.

During this talk, Krzysztof will discuss problems related to monitoring and “healing” embedded Linux distribution. First, most common server approaches will be described. After that, Krzysztof will try to identify key problems of applying this solution to embedded platform. Then Krzysztof will introduce faultd – small but extendable daemon for system monitoring and CPR;). How to use it? What can it do? What are the advantages and disadvantages? All those questions should be answered in this part. Last part is going to be a discussion on a presented idea and experience sharing.

  • 13:05 – 13:30 – A Guided Tour of Eclipse IoT: 3 Software Stacks for IoT by Benjamin Cabé

Whether you’re looking at the constrained devices that make for the “things” of the IoT, gateways that connect them to the Internet, or backend servers, there’s a lot that one needs to build for creating end-to-end IoT solutions. In this session, we will look at the typical software features that are specific to IoT, and see what’s available in the open source ecosystem (and more specifically Eclipse IoT) to implement them. A live demo of the Eclipse IoT Open Testbed for Asset Tracking will allow the audience to see some of the projects (such as Eclipse Kura, or Eclipse Kapua) in action.

  • 13:45 – 14:10 – Tizen:RT A lightweight RTOS platform for low-end IoT devices by Philippe Coval

The Tizen software platform has been designed to target consumer electronics, since 2013 the OS is powering many products on the market (from smart watches to TVs, cameras or even white goods). Even if this Linux based platform is very flexible, the Linux kernel has minimum size requirements, so Tizen can’t be deployed on constrained devices (ubiquitous microcontrollers).

To also target low end devices part of Tizen’s technology was rebased on NuttX RTOS. Seamless connectivity is still provided by IoTivity, while a new IoT features are becoming available to application developers too, this whole stack is Tizen:RT!

This presentation will give an overview of Tizen ecosystem, and explain how to get started with Tizen:RT using QEmu, SDK, finally an IoT scenario will be demonstrated on trusted system on module ARTIK 055s.

  • 14:25 14:50 – Eclipse IoT FOSS Platform for Cloud Based IoT Solutions by Steffen Evers

It is expected that in the next years billions of devices will be connected to the Internet of things (IoT). Many of them will interact with cloud-based solutions to provide additional services on the devices or in the web. To bring IoT to the next level technologies for supporting cross-domain/cross-vendor solutions are needed. There is already a lot FOSS available to provide a technological base for building IoT solutions (e.g. Kubernetes). However, on top of it, software is needed for the connectivity challenges, support of domain-specific protocols, large scale messaging and device management and integration with existing infrastructure. Eclipse IoT aims to address these needs and provide an FOSS IoT framework that makes IoT development fast and simple. In the last year Eclipse IoT has made a lot of progress and the underlying environment in cloud technology has seen a lot of changes. In addition, upcoming challenges like automated driving and connected vehicles have resulted in new projects for better support for the automotive domain. This talk gives you an overview of major Eclipse IoT projects and illustrates its capabilities with a short demo.

  • 15:05 15:30 – IoT.js – A JavaScript platform for the Internet of Things by Ziran Sun

IoT.js is a JavaScript platform that aims to provide inter-operable services for IoT world. Powered by JerryScript, an ultra-lightweight modular JavaScript engine, the platform is designed to bring the success of Node.js to constrained IoT devices. To address interoperability, IoT.js has provided a Node.js friendly architecture and comes with a subset of Node.js APIs. Since Samsung OSG first presented IoT.js in FOSDEM in 2016, the platform has been through a rapid growth in last couple of years. With a lot active high-quality contributions from the IoT.js and JerryScript open source community, IoT.js has released version 1.0 in July 2017 which presented a rich set of features, hardware and tool supports for developers. In this talk, we are looking at recent developments in IoT.js and share our vision for future plans. The talk is supported by a demo of iot.js running on constrained device seamlessly connects to node.js for third party cloud access.

  • 15:45 – 16:10 – The dark side of Internet of things by Dipesh Monga

With the advent of the Internet of things, monitoring and controlling everything such as coffee maker, lights, TV, Fridge,etc. over the Internet has become a child’s play. But are we really making our lives simpler or diving ourselves in a vast ocean which is getting deeper and deeper? In today’s world where the security of our data of a major concern, the number of websites are always tracking what we search for, what we watch, our location and now when things are limited to only data, adding another dimension i.e. physical entities is really a big question.

From this talk audience will take away an understanding of the privacy concerns related to IoT, and how they may be putting their personal information at risk by connecting my physical entities to the Internet. Is it really safe to connect things to the Internet?

  • 16:30 – 17:00 – Facing the Challenges of Updating Complex Systems by Enrico Jörns

Over the past three years, the growing zoo of Open Source update frameworks made updating an embedded Linux system much easier. But, the availability of a robust update tool solves only one step in the complex chain from a software artifact to an updated and working system on your devices.

Starting with a modern system consisting of a recent bootloader, kernel, init system and update tool, this talk ventures beyond the basic and already solved topics of A/B redundancy, atomicity, or simple update verification.

Enrico will present strategies for creating a robust update chain from automated testing up to full rollout management and show how to solve these challenges with recent Open Source software such as barebox, RAUC, systemd, hawkBit, casync and labgrid. You will learn how to deal with more modular and complex system setups, restricted systems, error recovery, product variants, resigning for deployment, updating the bootloader itself and interaction with verified boot.

  • 17:00 – 18:00 – Multitasking on Cortex-M class MCUs, A deep-dive into the Chromium-EC OS by Moritz Fischer

We’re gonna look at multi-tasking on small Cortex-M class MCUs like the ARM Cortex-M0. After a brief general overview of the Cortex-M0 programming model, exception handling and other basics required, we’ll start our deep-dive into one specific implementation in the Chromium-EC firmware. We’ll look at startup code, how tasks are implemented, how to deal with priorities and peripheral interrupts.

The Chromium-EC firmware is a little (RT)OS that runs (mostly) on ARM cores of the Cortex-M class (M0/M3/M4), and powers Google’s Chromebooks as well as other devices (Project Sulfur SDR). It’s permissive license makes it attractive for (ab)use in other projects, since Kernel and U-Boot integration are already existing.

  • 18:00 – 18:30 –  The Chromium project’s Way to Wayland by Maksim Sisov

Wayland is the most advanced X11-alternative display protocol, shipping today in a variety of desktop and embedded environments. Although the Chromium browser on Linux still defaults to use the X11 window system, there have been efforts to port it to different environments.

This effort happens in various fronts, including the development and stabilization of Ozone, an abstraction layer for graphics and input events, and the transitioning of some ChromeOS-oriented solutions to Linux, for example Chromium’s new “UI service”.

Igalia has been actively contributing to this multi organizational collaboration, aiming at getting a full fledged Chromium browser running natively on Wayland. The work happens on Chromium’s upstream repository so that the greater Chromium community can benefit from it.

  • 18:30 19:00 – GStreamer for tiny devices by Olivier Crête

GStreamer is a complete Open Source multimedia framework, and it includes hundreds of plugins, including modern formats like DASH, HLS or the first ever RTSP 2.0 implementation. The whole framework is almost 150MB on my computer, but what if you only have 5 megs of flash available? Is it a viable choice? Yes it is, and I will show you how.

Starting with simple tricks like only including the necessary plugins, all the way to statically compiling only the functions that are actually used to produce the smaller possible footprint.

Sunday 4, 2018

  • 09:30 10:00 – Programming UEFI for dummies, what I have learned while tweaking FreePascal to output UEFI binaries by Olivier Coursière

With the upcoming end of legacy mode in UEFI firmware on PCs, every alternative and hobbyist operating systems, bare metal programmers and wannabe OS developers will have to deal with UEFI on modern hardware. After presenting the binary format of UEFI applications, I will focus on the use of UEFI APIs through EFI system table and UEFI protocols so you can get started.

  • 10:00 – 10:30 – Rustyarm AKA A project looking at Rust for Embedded Systems by Benedict Gaster (cuberoo_)

Rustyarm is a project in the Physical Computing group at the University of West of England looking at application of Rust on embedded micro controllers. UWE Sense is a new hardware and software platform for IoT, build with ARM micro controllers, Bluetooth LE and LoRaWAN, which runs a software stack written completely in Rust. While UWE Sense is a close to the metal implementation, UWE Audio, a new hardware platform for studying high performance audio using ARM micro controllers, uses Rust to implement a monadic reactive graph, supporting both an offline compiler and and Embedded DSL. UWE Audio uses safe Rust, for example, describing domain clock as generic associated types, providing both compile time guarantees that multiple streams will not be incorrectly sequenced at different sample rates, and the ability to dynamically compile for different parts of the system.

In this talk I will provide a high-level overview of the Rustyarm project, including how using Rust has made this project interesting, but also enabled providing guarantees with respect to the audio scheduler, for example. However, Rust has some short comings in the embedded domain and we provide details on some of these and what we and the wider community are doing to address them. As an example of Rust’s application in the embedded domain we present early work on UWE Audio and hardware and software platform for building digital music instruments, which as already noted is programmed with solely in Rust.

  • 10:30 – 11:00 – How to build an autonomous robot for less than 2K€ by Miika Oja (PuluMan)

Telepresence, Delivery Boy, Security and Follow Me in one PULUrobot. PULUrobot solves the autonomous mobile robotics complexity issue without expensive parts, without compromise. By fearless integration and from-scratch design, our platform can do SLAM, avoid obstacles, feed itself, and carry payload over 100kg, for less than 2000EUR.

Application ecosystem can be born around it, as we offer a ready-made Open Source (GPLv2) solution in a tightly coupled HW-SW codesign. Pulu Robotics Oy was founded in July, 2017, in Finland, to solve our own needs, with an efficient team of three. No one had prior knowledge on robotics.

By studying the market and other startups, we realized the common mistake is to use “robotic modules” as building blocks. They are highly expensive, provide little bang for buck, often are inefficient, and require complex software middleware (such as ROS) as the glue inbetween. Due to our combined background in mechanical, electrical, software and manufacturing design, we took the approach of designing as much as possible by ourselves.

We are now selling the very first generation of robots for the early adopters, hoping to give a kick start to the open source community as soon as possible. Behind the curtains, we are focusing on the development of our next 3D sensor system, which will replace the current scanning 2D lidar with a 360×90 degree full 3D distance data, and do it for the same price we currently pay for the Scanse 2D lidar used in the first small-scale production batch.

  • 11:00 – 11:30 – … like real computers! Making distributions work on single board computers by Andre Przywara

Installing an operating system on single board computers (SBCs or “Fruit-Pis”) is very board specific and requires a lot of hand holding. If at all, standard distributions support only a small number of them explicitly, which leads to a lot of board specific images and distributions. This talk will show how this situation can be improved, to the point where off-the-shelf Linux (or BSD) distributions can be installed on those boards, without those distros knowing about each and every one of them. Key ingredients are standardized firmware interfaces like UEFI, stable device trees and on-board memory like SPI flash. This should make using ARM based SBCs as easy as using (x86) PCs today: like “real computers”. On top of this, ways to simplify and speed up mainline Linux kernel support are explored. Enabling kernel support for new SoCs usually takes a while, especially if the effort is driven by the community. This delays distribution support, up to a point where a certain SoC or board might become slightly dated when it’s finally supported. Using more device tree features and less hardcoded kernel data would reduce the code required to support new SoCs, ideally reaching a point where new SoCs could be at least booted with existing (distribution!) kernels, just by providing the proper device tree blob. This talk describes the idea and gives an example by looking at what can be done on Allwinner SoCs.

  • 11:30 – 12:00 – Booting it successfully for the first time with mainline by Enric Balletbo Serra

While things have gotten a lot better, new hardware bring-up sometimes still feels like pulling teeth. With the right methodology, tools and techniques, a significant amount of time, energy (and sanity) can be saved while enabling a new board to run Linux. In this talk, we’ll discuss the phased process involved in new board bring-up and the challenges it can pose, from reviewing initial schematic design to the successful upstreaming of any necessary bootloader and kernel patches. We’ll also provide some examples of the process based on a board that was recently made compatible with mainline.

  • 12:00 – 12:30 – SITL bringup with the IIO framework, bootstrapping a x86 based drone platform by Bandan Das

This talk aims at an introduction to using the Industrial IO(IIO) framework to initialize sensors and acquire data to feed to a Software in the Loop (SITL) interface of drone software such as iNav/Cleanflight. Most flight controller boards are based on low power ARM microcontrollers and the flight controller software is not usually based on Linux. However, with the availability of increasingly powerful boards with onboard sensors and multicore processors, using a Linux based flight controller software can be used to our advantage. Experimenting with onboard devices and scheduling algorithms can lead to interesting applications with minimal porting overhead to new architectures.

The talk starts with a quick overview of the IIO framework and using it to initialize the drivers for the onboard sensors of the Intel Aero platform, a x86 based flight controller board. Although, not tied to the Aero board in any way, this talk will use this board as an example to describe the onboard sensors and acquire data from them to successfully run a minimal SITL instance. The talk aims to explore how the IIO framework exposes data from these sensors and how users can utilize these interfaces followed by a demo of the setup.

  • 12:30 – 13:00 – Rapid SPI Device Driver Development over USB by Stefan Schmidt

On the quest for a cheap and easy way to connect some simple SPI devices to my laptop it was surprising to not find anything suitable available. The idea is neither new nor innovative and surely there must have been something already.

Maybe the use-case was to special. To connect the SPI device to a Linux laptop over USB in order to develop a SPI kernel driver for it and having a rapid development and test cycle. None of the solutions to access the SPI device over libusb in userspace would work for me. I needed a SPI master controller in kernelspace to work with the variety of devices and kernel subsystems.

After some research I settled on the MCP2210 chip. With its cheap and easy to get development boards and an out-of-tree driver as a good start. Maybe it is also something others are looking for and it is surely worth demonstrating and explaining.

  • 13:00 – 14:00 – Implementing state-of-the-art U-Boot port, 2018 edition by Marek Vasut

This presentation is a practical guide to implementing U-Boot port to a new system from scratch. U-Boot is the de-facto standard bootloader for embedded systems, there is plenty of U-Boot ports, yet vast majority of those are implemented in sub-optimal way. This talk first explains the U-Boot internals, the driver model (DM) and it’s interaction with device tree (DT), as understanding these is vital to understanding the implementation of core subsystems. The core subsystems are explained in detail afterward to allow developers implement drivers the intended way without hacks and workarounds. Unfortunately, not all systems have plenty of resources, but U-Boot caters for those as well. The final part of the talk discusses the U-Boot SPL, the preloader which initializes the hardware, DRAM and starts U-Boot and finer parts of this procedure, which tends to have plenty of pitfalls.

  • 14:00 – 15:00 – Image capture on embedded linux systems by Jacopo Mondi

Image capture is one of the most broad and complex fields of today’s computing applications. Capturing and displaying images with an embedded platform poses additional challenges, introduced by the rapidly increasing complexity of dedicated hardware blocks often found on modern Systems On Chip designed for mobile and industrial computing. Using real world examples of image sensors, connection buses and processing blocks this presentation provides an overview of current industry standard technologies with an introduction to Video4Linux2 kernel framework for driver development and its userspace APIs.

  • 15:00 – 16:00 – ARM64 + FPGA and more: Linux on the Xilinx ZynqMP by Luca Ceresoli

The Xilinx Zynq UltraScale+ MPSoC (aka ZynqMP) is a powerful and complex chip featuring 64-bit cores, 32-bit realtime cores, a large FPGA, a GPU, video codecs and dedicated power management and security units.

The main topics covered will be:

  • Overview of the hardware.
  • Available software support from Xilinx and from the community.
  • How the peculiar CPU+FPGA design effectively allows to design “your own SoC”, with the technical steps to implement this with Linux.
  • Why booting is nontrivial on this SoC and the currently available ways to boot Linux.
  • Handling the H.264/H.265 hardware codecs.
  • GPU support issues.

Focus will be given to how much open source technologies can be used with the ZynqMP SoCs, why this matters, and the current status of open source resources with respect to the alternatives.

  • 16:00 – 16:50 – New GPIO interface for linux user space by Bartosz Golaszewski

Since linux 4.8 the GPIO sysfs interface is deprecated. Due to its many drawbacks and bad design decisions a new user space interface has been implemented in the form of the GPIO character device which is now the preferred method of interaction with GPIOs which can’t otherwise be serviced by a kernel driver. The character device brings in many new interesting features such as: polling for line events, finding GPIO chips and lines by name, changing & reading the values of multiple lines with a single ioctl (one context switch) and many more. In this presentation, Bartosz will showcase the new features of the GPIO UAPI, discuss the current state of libgpiod (user space tools for using the character device) and tell you why it’s beneficial to switch to the new interface.

FOSDEM 2018 will take place at the ULB Solbosch Campus in Brussels, Belgium, attendance is free of charge, and no registration is required.

$1 RDA5981 WiFi IoT Arm Cortex-M4 SoC is Designed for Smart Home Devices, Smart Speakers

January 11th, 2018 10 comments

RDA Microelectronics processors are found in a few cheap smart and not-so-smart phones, as well as the even cheaper Orange Pi i96 board. But the company does not only design cellular chips, but their portfolio also includes solutions for the Internet of Things and TV & radio tuners.

RDA5981 is a WiFi IoT chip specifically designed for smart home & audio application, such as smart speakers, and it’s found in devices running Baidu DuerOS, the Chinese equivalent of Amazon Alexa or Google Assistant. The company explains it can be widely used in televisions, set-top boxes, smart appliances, wireless monitors, and other products.

RDA5981A Block Diagram

RDA5981 A/B/C processor specifications:

  • CPU – Arm Cortex-M4 @ up to 160 MHz with integrated MPU and mbed uvisor
  • System Memory  – Up to 448 KB SRAM for network stack and application, external PSRAM interface
  • Storage – Up to 32Mbit SPI flash
  • Connectivity
    • WiFi
      • 2.4 Ghz 802.11b/g/n WiFi up to 150 Mbps with 20/40 MHz bandwidth
      • WPA, WPA2, WEP, TKIP,CCMP security
      • STA, softAP, P2P, STA+softAp, STA+P2P modes
      • A-MPDU, A-MSDU, HT-BA
    • TCP/IP stack with SSL (TLS?)
  • Host Interfaces – SPI / UART (AT command set) / USB2.0
  • Peripherals – GPIO, 2x UART, 2x I2S, 1x I2C, 8x PWM, 4x SPI, 1x SDMMC, 1x USB2, 2x ADC
  • Security – Hardware crypto accelerator AES/RSA, true random number generator (TRNG), and CRC accelerator
  • Misc – Watchdog, 16×16 bits eFuse configuration
  • Package – 5×5mm2 QFN package, 0.4mm pitch QFN-40

The company provides support for FreeRTOS and mbedOS5.1 for the chip. You could get a very basic datasheet from the company’s product page, but if you don’t want to leave your contact details, there’s even more information on Electrodragon Wiki.

The features looks interesting and could become a competitor to Realtek RTL8710AF or even Espressif ESP8266, especially Electrodragon sells their RDA5981X1 WiFi module based on RDA5981A for just $1.92 plus shipping.

Specifications for the module:

  • SoC – RDA5981A with 8Mbit internal flash, 288+160 KB RAM
  • 24 castellated pin exposing
    • Up to 16 free GPIOs
    • 2x UART up to 4Mbit, 3x ADC, 1x USB, 1x I2C, I2S in, I2S out, 1x SPI, up to 4x PWM, etc… (Pins are multiplex with up to 6 different function per pin)
    • VCC (3.0 to 3.5V), GND
    • Reset
  • Dimensions – 17.60 x 15.50 mm

The module also comes with a red breakout board (with 2.54mm pitch) included in the price. The company says RDA5981A IC itself sells for around $1 with price obviously depending on quantity.They also mention the SoC still have bugs without expanding. The board can be programming with AT commands or using mBed as explained in the Wiki linked above.

RDA5981A “Arduino” Development Board

There’s also an RDA5981 board with Arduino header, which I could only find on Taobao for under $50. Somebody also setup a new Github account with more information, and beside the RDA5981A/B/C models listed in the datasheet,  there seems to be an RDA5981AM chip as well. All RDA5981 variants are shown to be suitable for smart home, but RDA5981C can also be used for smart speakers and WiFi toys, maybe because it comes with 32 Mbit SPI flash? We’ll have to see how things evolve, and whether the solution will gain traction.

Via Olimex

LittleFS is an Open Source, Low Footprint, Resilient File System Designed for Tiny Devices

January 2nd, 2018 2 comments

Most devices need to store data either configuration files, sensor data firmware updates, and while it’s in theory possible to write directly to the storage device, it’s normally not a good idea to do so due to issues such as wear, which could lead to a premature death of your storage…

LittleFS is an open source file system specifically designed for small devices such as IoT nodes for SPI NOR flash and SD card storage, and introduced in Mbed OS 5.7. The “high-integrity embedded file system” is resilient to power-cuts, supports wear-leveling, and comes in a small memory and storage footprint.

Mbed support both FAT and LittleFS, so the latter was compared to the former with the following key highlights:

  • Footprint – Code for LittleFS takes 13KB less storage than FAT, and 4KB less RAM
  • Power loss resilience – The file system has strong copy-on-write guarantees, and storage on disk is always kept in a valid state. FAT has no such resilience
  • Wear-leveling – LittleFS file system provides a form of dynamic wear leveling for systems that cannot fit a full flash translation layer. FAT has no wear-leveling capabilities.

FAT vs LittleFS RAM+ROM Footprint

FAT vs LittleFS wear-leveling demo

One of the downsides of LittleFS is that if you use (micro) SD cards for your project(s), you’ll lose compatibility with your computer, although if you run Linux there’s a FUSE wrapper that will allow you to mount littleFS in your computer.

The documentation and source code can be found on Github, with everything released under an Apache 2.0 license. Reference documentation is also available on Mbed website.

Categories: mbed OS Tags: file system, IoT, littlefs, mbed

WizziKit is a DASH7, LoRa and Sigfox Wireless Sensor & Actuator Network Kit

September 13th, 2017 2 comments

Over the last few years, I’ve written several article about LoRaWAN, Cellular IoT, and Sigfox based long range low power IoT solutions. DASH7 is another LPWAN (Low Power Wide Area Network) standard that operates on the same 868 and 915 MHz ISM bands as LoRa and Sigfox, but has much lower power consumption, and the cost of a shorter range up to 500 meters, instead of the 5+km associated with LoRa or SigFox.

The DASH7 Alliance Protocol (D7A) is an Open Standard, and if you want more details you can download version 1.1 of the specifications on DASH7 Alliance website. I’m writing about DASH7 today thanks to an article on ST blog about Wizzilab’s Wizzikit, an evaluation kit and framework for DASH7 with a gateway, and several nodes that can also optionally support LoRaWAN and Sigfox protocols.

Click to Enlarge

The kit is comprised of the following items:

  • WizziGate GW2120 Ethernet/Wifi/Dash7 gateway – based on GL-iNet AR150 router –  with antenna for the selected band (868/915 MHz) and USB power cable.
  • 2x Nucleo-L432KC STM32 development board compatible with Arduino. mbed, and ST morpho
  • 2x D7A SH2050 Nucleo Shield with a multimode Murata Lora Module supporting LoRa, DASH7, and Sigfox, as well as four sensor chips: light sensor,  magnetometer & accelerometer, humidity and temperature sensor, and a pressure sensor.
  • 2x mini USB cable to power up and program the Nucleo boards

DA7 SH2050 Shield

You’ll also need to add you own USB power adapter for the gateway. The kit also comes with access to the company’s DASH7Board cloud service. The Wiki includes some information, including a quick start guide explaining how to register the gateway, and start loading the demo code using mbed. Since DASH7 is much more power efficient than LoRaWAN it can either be used to prolong battery life, or to send more frequent messages for example to control actuators. With LoRaWAN, downlink access can only be initiated by the end node, but DASH7 is bi-directional allowing for OTA firmware upgrades. The solution was showcased a few months ago at ST Techday with two demos: sending a message to a single node, and OTA code upgrade (actually picture upload) to multiple boards with a broadcast message.

Wizzilab’s Wizzikit is sold for 299.00 Euros with either 868 and 915 MHz band. Further details on be found on Wizzilab website.

RadioShuttle Network Protocol is an Efficient, Fast & Secure Alternative to LoRaWAN Protocol

September 6th, 2017 6 comments

LoRaWAN protocol is one of the most popular LPWAN standards used for the Internet of Things today, but some people found it “lacked efficiency, did not support direct node-to-node communication, and was too costly and far too complicated for many applications”, so they developed their own LoRa wireless protocol software called RadioShuttle, which they claim is “capable of efficiently sending messages in a fast and secure way between simple LoRa modules”.

Some of the key features of the protocol include:

  • Support for secure or insecure (less time/energy) message transmission, multiple messages transmission in parallel
  • Unique 32-bit device ID (device number) per LoRa member, unique 16-bit app ID (program number for the communication)
  • Security – Login with SHA-256 encrypt password; AES-128 message encryption
  • Air Traffic Control – Nodes only send if no LoRa signal is active on that channel.
  • Optimized protocol –  Message delivery within 110 ms (SF7, 125 kHz, free channel provided); default LoRa bandwidth 125 kHz (125/250/500 kHz adjustable), as narrow bandwidths allow for a longer range; Automatic transmitting power adjustment
  • Operating modes
    • Station, constant power supply recommended –  12 mA in receiving mode, transmitting mode (20 to 100 mA)
    • Node Online (permanently receiving), constant power supply recommended – 12 mA in receiving mode, transmitting mode (20 to 100 mA)
    • Wireless sensor (Node Offline checking) – Node reports back regularly. 1 µA in standby mode, battery operation for years.
    • Wireless sensor (Node Offline) – Node only active if events are reported. 1 µA in standby mode, battery operation for years.

The Radioshuttle library has a low memory and storage footprint with current requirements of

  • 100 kB Flash for RadioShuttle library with SHA256 & AES
  • 10 kB RAM for Node Offline/Checking/Online mode
  • 10 kB RAM for Station Basic mode (RAM depends on the number of nodes)
  • 1 MB RAM for Station Server mode (Raspberry Pi, 10,000 LoRa nodes)

The solution supports various Arduino boards, some ARM Mbed boards (e,g, STM32L0, STM32L4), and Linux capable boards like Raspberry Pi or Orange Pi (planned). Semtech SX1276MB1MAS and SX1276MB1LAS (SX1276-based), MURATA CMWX1ZZABZ-078/091 (found in STM32 Discovery kit for LoRaWAN), and HopeRF RFM95 transceivers are supported.

LonRa Board – Click to Enlarge

The developers have also designed their own LongRa board, compatible with Arduino Zero, based on Semtech SX1276 LoRa radio chip with a 168 dB link budget and support for 868 MHz & 915 MHz frequency. The board can be powered by its micro USB port, or by two AA batteries if you’re going to use the board as a wireless sensor node.

RadioShuttle protocol is not open source for now, and while it support multiple devices as stated previsouly, if you are not using LongRa board, a 25 Euros license is required per device.

 

NXP i.MX RT Series Crossover Embedded Processor is Based on an ARM Cortex-M7 Core @ 600 MHz

August 17th, 2017 3 comments

Microcontrollers (MCUs) provide real-time processing, low power, low cost, and plenty of I/Os, but with security and user interface requirements of recent embedded devices, the processing power may be a limitation, and embedded systems designers may have to use an application processor instead gaining performance, but losing some of the benefits of MCUs. The bridge the gap between performance and usability, NXP has launched i.MX RT series of Crossover Embedded Processor which uses the powerful ARM Cortex-M7 MCU core clocked at up to 600 MHz, a frequency partially made possible by eliminating on-chip flash memory.

Block Diagram

The first member of the family is NXP i.MX RT1050 with the following key features and specifications:

  • MCU Core – ARM Cortex-M7 @ up to 600 MHz; 3015 CoreMark / 1284 DMIPS
  • Memory – Up to 512KB SRAM/TCM (Tighly Coupled Memory) with response time as low as 20 ns
  • Storage – 96KB RAM; interfaces: NAND, eMMC, QuadSPI/HyperBus NOR flash, Parallel NOR flash
  • GPU – 2D graphics acceleration engine with resize, SCS, overlay, rotation functions
  • Display I/F – 24-bit LCD display controller supporting up to 800×480 resolution
  • Camera I/F – 8-/16-bit parallel camera sensor interface
  • Audio I/F – 3x I2S, S/PDIF Tx/Rx
  • Connectivity – 10/100M Ethernet with IEEE 1588 support, interfaces for WiFi, Bluetooth, Zigbee and Thread
  • Other Peripherals
    • 2x USB 2.0 OTG with PHY
    • 8x UART, 4x I2C, 4x SPI
    • GPIOs
    • 2x CAN bus
    • 8×8 keypad
    • Dual 20-ch ADC, 4x ACMP
  • System Control – eDMA, 4x Watchdog timers, 6x GP timers, 4x Quadrature ENC, 4x QuadTimer, 4x FlexPWM, IOMUX
  • Security – Cipher & RNG, secure RTC, eFuse, HAB
  • Power
    • Integrated DC-DC converter
    • Low power mode at 24 MHz
  • Package – 10×10 BGA package with 0.65mm pitch

The company claims i.MX RT processor provide twice the performance &  power efficiency, half the cost, and allows for faster development time. NXP also explains the BoM cost is reduced due to the high integration of the solution, and the embedded processor can be used in 4-layer PCB designs.

Click to Enlarge

Software development for the i.MX RT crossover processor can be done with MCU tools like MCUXpression, IAR and Keil, and it also supports FreeRTOS, and ARM mbed.  There’s an evaluation kit, but no details were provided.

Target applications include audio Subsystem such as professional microphones & guitar pedals, consumer products like smart appliances, cameras, LCDs, home and building automation,  IoT gateways, industrial computing designs such as PLCs, factory automation, test and measurement, HMI control, and motor control and power conversion, for example for 3D printers, thermal printers, UAV, robotic vacuum cleaners, etc…

NXP i.MX RT1050 processor is sampling now, with broad availability expected for October 2017, and pricing starting at less than $3.00 per unit for 10k orders. More information can be found on the product page.

Thanks to Lucas for the tip.

Categories: FreeRTOS, Hardware, NXP i.MX Tags: cortex-m7, mbed, mcu, nxp

Aspencore 2017 Embedded Markets Study – Programming Languages, Operating Systems, MCU Vendors, and More

August 15th, 2017 2 comments

Aspencore media group asked readers of their EE Times and Embedded.com websites to fill out an online survey about their embedded system projects. They got 1,234 respondents mostly from North America (56.3%), followed by Europe (25.2%), and Asia (10.6%). This resulted in a 102-page market study which you can download here. I’ve extracted a few slides to have a look at some of the trends.

My current embedded project is programmed mostly in:

C language is still the most used language in embedded systems, but other languages like C++, Python and even assembly language are gaining traction.

Please select ALL of the operating systems you are currently using.

Operating system is more spread with Linux being the most used via Embedded Linux distributions, Debian, and Ubuntu. FreeRTOS comes in second place, while Android registers fourth with 13%.

Which of the following Version Control software systems do you currently use?

Git has finally supplanted Subversion in 2017, with all other version control software losing ground.

Did you start your current embedded design with a development board?

Switching to some hardware slides, 44% used a development board to start their embedded design with ST Microelectronics, Texas Instruments and Xilinx at the top three.

Which form factor boards are you currently using, and considering using ?

Most used custom or proprietary form factors in their designs, and I’m actually surprised at the rather large number of designs using low cost boards form factors such as the ones used in Arduino, Raspberry Pi, or BeagleBone boards. The “considering using” for Raspberry Pi is particularly high. The question does not clearly states whether it’s for evaluation / prototyping only, or in the end product however.

Please select the processor vendors you are currently using.

The chart is a little confusion due to the recent M&A activity, but Texas Instruments, Freescale (now NXP) and Atmel (Now Microchip) take the top three spots. You cannot add Freescale (26%) and NXP (17%), or Atmel (26%) and Microchip (25%), since some respondents may have already selected both. Renesas is only at 9%, but it was only second to NXP (Freescale + NXP) in MCU market share in 2016, so maybe the apparent discrepancy is due to the sampling in the survey with the majority of respondents from the US & Canada, which may also explain why Greater China companies like Holtek, or CEC Huada Electronic Design do not register at all.

You’ll find many more interesting slides in the full study.

GR-LYCHEE Development Board to Combine Renesas RZ/A1LU Processor, ESP32 Module, and a VGA Camera

June 23rd, 2017 9 comments

Japanese semiconductor vendors have mostly stayed away from the maker market, at least outside Japan, as most people would be hard-pressed to come up with a hobbyist development board powered by processor or micro-controller from Toshiba, Sony, Renesas or other Japanese companies, despite the three aforementioned names being in the top 20 semiconductors companies. I can only remember having written about Fujitsu F-Cue 96Boards, as well as Renesas GR-PEACH mbed board since I started this blog 7 years ago. Renesas seems to be the only company to have a real community behind with their “Gadget Renesas” pink-colored development boards, and the latest and seventh board is GR-LYCHEE powered by Renesas RZ/A1LU ARM Cortex-A9  processor, and equipped with a WiFi & Bluetooth module, and a camera.

GR-LYCHEE Prototype – Click to Enlarge

Renesas GR-LYCHEE board preliminary specifications:

  • Micro-processor – Renesas RZ / A1LU (R7S721030VCFP 176-pin QFP) ARM Cortex-A9 Processor  @ 384 MHz with 3MB on-chip SRAM
  • Storage – 8 MB flash+ micro SD card
  • Connectivity – 802.11 b/g/n WiFi, Bluetooth 4.1 LE via ESP32 wireless module
  • Audio – 3.5mm audio jack (heaphone + mic)
  • USB – 1x USB host port
  • Camera – 1x camera interface for VGA (640×480) camera
  • Expansion – Arduino UNO headers
  • Debugging & Programming – 1x micro USB port, JTAG interface
  • Misc – 32.768 Hz RTC clock, 2x user buttons, reset button, 4x user LEDs
  • Power Supply – 5V via 1x micro USB port; operating voltage: 3.3 V / 1.18 V

The board is mbed compatible so at launch you’ll be able to use the mbed compiler with the board. The board is still in beta version, documentation is still being worked on, and launch is scheduled for the end of November 2017. While most Gadget Renesas’ users are likely in Japan, Renesas also organized events in India, ASEAN, and Oceania with GR-PEACH board earlier this year as you’ll find out by visiting the community’s English page.

Documentation and more details about GR-LYCHEE board should eventually surface in the product page (in Japanese only for now).