Archive

Posts Tagged ‘open source’

NodeMCU is both a Breadboard-Friendly ESP8266 Wi-Fi Board and a LUA based Firmware

April 18th, 2015 4 comments

NodeMCU is a LUA based interactive firmware for Expressif ESP8622 Wi-Fi SoC, as well as an open source hardware board that contrary to the $3 ESP8266 Wi-Fi modules includes a CP2102 TTL to USB chip for programming and debugging, is breadboard-friendly, and can simply be powered via its micro USB port.

NodeMCU_Development_BoardLet’s checkout the hardware first. The latest version of the board (V1.0) has the following specifications and features:

  • Wi-Fi Module – ESP-12E module similar to ESP-12 module but with 6 extra GPIOs.
  • USB – micro USB port for power, programming and debugging
  • Headers – 2x 2.54mm 15-pin header with access to GPIOs, SPI, UART, ADC, and power pins
  • Misc – Reset and Flash buttons
  • Power – 5V via micro USB port
  • Dimensions – 49 x 24.5 x 13mm
NodeMCU Headers' Pinout

NodeMCU Headers’ Pinout

The hardware documentation for the board can be found on nodemcu-devkit repo, including schematics and PCB layout designed with Altium Designer, but they should also be compatible with the cheaper Altium CircuitStudio. Sadly, the files have not been updated for 3 to 4 months, so they don’t completely match the latest hardware shown above, and some pins were not connected in the earlier version.

NodeMCU can be purchased for $10 and up on Aliexpress or Seeed Studio. However, it’s not entirely clear which version of the board is sold… The Aliexpress shop shows hardware v0.9, but says they will send the latest version, while Seeed Studio mentions NodeMCU “v2″,  and shows picture of v1.0 hardware, which should be the one you want. The new board will also be up for sale in Europe on nodemcu.eu for 15 to 18 Euros including VAT.

NodeMCU firmware is build with ESP8266 SDK v.0.9.5, based on Lua 51.4 without debug and os modules, lua-cjson, and relies on spiffs (SPI Flash File System) file system. The quick start guide is written on the bottom of the board:

  1. Install CP2102 driver (not needed in Linux)
  2. Use 9600 baud rate
  3. Connect Wi-Fi and enjoy!

Once you are connected, you can just type the command in the terminal. For example to connecting to your Wi-Fi router:

wifi.setmode(wifi.STATION)
wifi.sta.config("SSID","password")
print(wifi.sta.getip())
--192.168.18.110

You can also toggle or/and read GPIO status in a similar way to what you’d with Arduino:

pin = 1
gpio.mode(pin,gpio.OUTPUT)
gpio.write(pin,gpio.HIGH)
gpio.mode(pin,gpio.INPUT)
print(gpio.read(pin))

To get the board automatically run a script right after boot is complete, you can edit init.lua as follows:

file.open("init.lua","w+")
file.writeline(print("hello world"))
file.close()

You can find the firmware source code and documentation on Github, as well as nodemcu-flasher, a Windows only tools to flash the firmware to a module. There’s also a separate tool called esptool that will let you flash nodemcu from Linux. In case you find the documentation is all over the place, you might want to checkout NodeMCU video tutorial below.

Nodemcu.com is the official website for the project, but you’ll find more information on Github. You can also get answers to your questions on their BBS or ESP8622 community forums.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

RaidSonic Releases Firmware and Source Code for Atheros AR9331 Wi-Fi Audio Streamers

April 16th, 2015 4 comments

RaidSonic is a German company releasing products such as media players and multimedia accessories under their ICY BOX brand. One of those products is ICY Box IB-MP401Air music streaming received based on Atheros AR9331, and that looks very similar to SoundMate M2 I reviewed last year.

SoundMate M2 (Click to Enlarge)

SoundMate M2 (Click to Enlarge)

But if you look on their product page, you’ll find out a few download links:

So I’ve downloaded the source code file (IB-MP401Air_Sources_and%20License_Terms.rar) to have a look. It has two compressed files, one with the license, and IB-MP401Air_Sources.tar.gz with the source code.

tar xzvf IB-MP401Air_Sources.tar.gz
cd dns320B_GPL20150212/
ls -l
total 12
-rwxr--r--  1 jaufranc jaufranc 1400 Apr 16 16:49 building-the-firmware.txt
drwxr-xr-x 14 jaufranc jaufranc 4096 Feb 12 10:54 dns320B_GPL20150212
-rwxr--r--  1 jaufranc jaufranc  925 Feb 12 08:25 making-u-boot.txt

SoundMate_M2_Make_Menuconfig

The file showing how to build the firmware (OpenWRT) explains you should not use a newer Linux distribution:

Please note that this is an older OpenWrt version that might not build on newer distributions like Fedora 19 or later. If you want to build the firmware on a newer distribution you might need to get extra patches from OpenWrt to work around compilation errors. As an alternative you can install an older Linux distribution to build this firmware on.

Fedora 19 was released in July 2013, but I’ve still tried to build it on an Ubuntu 14.04 machine, and it failed:

cd dns320B_GPL20150212/
make
….
x86_64-linux-gnu-gcc -std=gnu99 -I. -O2 -I/media/hdd/edev/sandbox/soundmate/dns320B_GPL20150212/dns320B_GPL20150212/staging_dir/host/include -O2 -I/media/hdd/edev/sandbox/soundmate/dns320B_GPL20150212/dns320B_GPL20150212/staging_dir/host/include -MT clean-temp.o -MD -MP -MF .deps/clean-temp.Tpo -c -o clean-temp.o clean-temp.c
In file included from clean-temp.h:22:0,
from clean-temp.c:23:
./stdio.h:477:1: error: ‘gets’ undeclared here (not in a function)
_GL_WARN_ON_USE (gets, “gets is a security hole – use fgets instead”);
^

It might build better on older Linux distributions, although you may still have to be ready to fix build errors on the way.

Thanks to dhead666 for the tip. Via OpenWRT Forums.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

lowRISC Open Source SoC Project Announces its First Release with Tutorials for Simulators and Zedboard

April 14th, 2015 4 comments

lowRISC project aims to produce a completely open-source SoC (System-on-Chip) based on the 64-bit RISC-V instruction set architecture, as well as a corresponding development board, thus eventually producing a fully open hardware systems. The project has now announced its first release “tagged memory preview release” with a tutorial explaining how this has all been designed, and how to run simulations with software tools, or FPGA boards such as Zedboard.

lowRISC_Rocket_Chip

Rocket Chip Block Diagram

 

The project is based on Rocket core, written in Chisel language by the RISC-V team at UC Berkeley. Chisel can generate code to produce a cycle-accurate C++ emulator, Verilog optimised for FPGAs or Verilog for use in an ASIC flow.If you want to try it out, you’ll need a Linux machine, preferably running Ubuntu 14.04 64-bit, with GNU GCC 4.8 installed, and follow the tutorial in order to get the source code, and build tools such as riscv64-unknown-elf-gcc compiler, and Spike simulator, as well as a RISC-V Linux kernel. Finally, they’ll show you how to run various simulations using Spike, the C++ emulator, or an FPGA board.

This is only a first step, and much more work is needed, with the organization expecting to provide more features in the next releases including “tag support in the Spike simulator and support for the L2 cache, as well as a better ISA and core support for tags”, and later on, the development of an “untethered version of the SoC with the necessary peripherals”.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Allwinner CedarX Media Codec Library GPL/LGPL Compliance Update

March 23rd, 2015 27 comments

Last month, I wrote about potential open source licenses and VP6 copyright infringement by Allwinner with their CedarX media codec library, and then since there’s been a few developments.
Allwinner_GPL_LGPL

First, Allwinner sent me an email saying they’ve now updated Cedarx library and referring my previous article. Here’s an extract:

Here, I have some update of the Allwinner’s open-source status.

We have done a lot of discussion with the developers from the linux-sunxi communication about the software license of CedarX. For each question or requirement asked by the developers, Allwinner has identify and try to give the best solution.

Now, we believe Allwinner’s CedarX license is fully compliant and resolves concerns from the community. And you can take the announcement https://www.mail-archive.com/[email protected]/msg10597.html as a reference.

Allwinner is always supporting the open-source, and try to do better and better. You can see some update on the github https://github.com/allwinner-zh, and some feedback from developers: https://github.com/allwinner-zh/bootloader/issues/5.

It’s difficult to make everyone happy, but we believe Allwinner will do better and better, and give more and more help to the developers, and we believe Allwinner will be accepted by more and more developers.

The announcement claims “the CedarX media codec framework is now released with full open source code under the LGPL license”. That actually means there’s an open source API to access the closed source binaries that’s released under the LGPL license. The good news is the VP6 code that could infringe on On2/Google copyrights has now been removed and they are using ffmpeg instead.

So I asked on linux-sunxi IRC channel to find out if there was real progress made, and soon after some more details were released on linux-sunxi mailing list, and the part that looks really bad is:

264FillDefaultRefList() and a lot of code around it is straight out of the libavcodec h264 decoder. The original name for that function is ff_h264_fill_default_ref_list() in libavcodec/h264_refs.c: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_refs.c#L115 This is new, as some totally different code for h264 was available in the previous versions of the cedarx binaries.

This looks like Allwinner reached a new low, as it would mean Allwinner purposely renamed some function from LGPL code to make it look like it was their own. However, another email on arm-netbook mailing list by a soon-to-be Allwinner’s software engineer gives some more light to what actually happened here:

I can explain the whole process in a whole detail, because I was directly involved in the process of this decision and I can tell where this is going right now:

The rename was done to fix the LGPL violations by adding a wrapper for the GPLed libraries which will be LGPLed and published. This way we have Binary<->LGPLed open source code<->GPL libraries

Next step will be to drop the whole “we ship our own SDK”-thing and move over to stream our code into the existing open source alternatives.

But until the FOSS libraries have all the functionality from the shipped SDK we can not just stop supporting our customers in China. Also we can not suddenly make it open source for the following reasons:

  • Some engineers and managers do not fully comply with the GPLing of their code yet.
  • The code has awful coding style and my armcc refuses to compile at least 2/3 of the code because of the Chinese comments.
  • Also some of the engineers obviously have never heard the term “revision control” which makes it even harder to locate the actual version of the source code from which the binary was compiled from… -.-‘

So Allwinner has not make it right just yet, but at least they are trying, and even hiring western engineers to try fixing the licensing issues. I’m just not sure the current plan for binary<->LGPL wrapper<->GPL is actually valid, but at least they have longer term plan to upstream changes to open source project, at least that’s the way to understand the email above. Beside legal and technical work, moving from closed source “license infringing” code to properly licensed code is also a social engineering task, as all stakeholders in the company and possibly their customers must be convinced proper licensing is the way to go, and not the business as usual “just copy code from the net” and ignore licensing terms as Allwinner and many other companies have done in the past.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

TechNexion Introduces Intel Edison Compatible PICO-iMX6 SoM and DWARF Board

March 16th, 2015 No comments

Intel Edison is a board made for wearables featuring an SoC with Intel Atom and Quark CPU cores. TechNexion, an embedded systems company based in Taiwan, has decided to make a mechanically and electrically compatible system-on-module featuring Frescale i.MX6 Solo or Duallite ARM Cortex A9 processor called PICO-iMX6. The company is also providing a PICO-DWARF baseboard that’s both compatible with PICO-iMX6 SoM and Edison board. DWARF stands for “Drones, Wearables, Appliances, Robotics and Fun”, so that pretty much explains what the platform is for.

PICO-iMX6 System-on-Module

PICO-iMX6-SD Module (Click to Enlarge)

PICO-iMX6-SD Module (Click to Enlarge)

Two version of the modules are available: PICO-iMX6-SD and PICO-iMX6-EMMC, the former with a micro SD slot for storage, and the latter a 4GB eMMC. Both share the followings specifications:

  • SoC – Freescale i.MX6 Solo / Duallite  single/dual core ARM Cortex A9 @ 1Ghz with Vivante GC880 3D GPU and Vivante GC320 2D GPU (Composition)
  • System Memory – 512MB or 1GB DDR3
  • Storage – PICO-iMX6-SD: micro SD slot;  PICO-iMX6-EMMC: 4GB eMMC
  • Connectivity
    • Gigabit Network RGMII Signals routed to board-to-board connector
    • Broadcom BCM4335 802.11ac Wi-Fi
    • Broadcom BCM4336 Bluetooth  4.0
  • Connectors – 1x Intel Edison compatible connector (Hirose 70-pin); 2x Hirose 70-pin connectors
  • I/O Interface Signaling
    • Edison I/O @ 1.8V
      • 9x GPIO
      • 4x PWM
      • 2x I²C, 1x SPI, 2x UART
      • 1x I²S
      • USB-OTG
      • SDIO (4-bit)
    • Additional I/O @ 3.3V
      • Display I/F – Single Channel LVDS; 24-bit TTL RGB; HDMI 1.4; MIPI DSI Display
      • Camera – MIPI CSI Camera
      • PCIe
      • RGMII (gigabit LAN)
      • CAN
  • Video – Decode: 1080p30 + D1; Encode: 1080p30 H.264 BP / Dual 720p
  • Power Supply  – 3.3 ~ 4.5 VDC input
  • Dimensions – 36 x 40 mm
  • Weight – 8 grams
  • Temperature Range – Commercial : 0° to 60° C; Extended : -20° to 70° C; Industrial : -40° to 85° C (no WiFi possible)
  • Relative Humidity – 10 – 90%
  • Certification – CE, FCC, RoHS, REACh

PICO-iMX6_Block_DiagramIntel Edison board measures 36x25mm, so PICO-iMX6 module is a little bigger, and it might not always be 100% compatible depending on your application’s mechanical requirements. Edison Board comes with 1GB RAM, 4GB eMMC, and features a similar Broadcom BCM43340 wireless module. Beside the 70-pin “Edison compatible” connector, TechNexion SoMs also add two hirose connectors for additional signals.

The company can provide BSP for Linux 3.x, Yocto, Android 4.3, Android 4.4, Android 5.0, and Ubuntu. These are not available for download yet, but you should eventually be able to get the necessary files via the Download Center.

PICO-DWARF Carrier Board

If you think PICO-DWARF baseboard looks familiar, it’s because it’s heavily inspired from Wandboard development board, replacing RS-232 DB9 connector by a MIPI connector, removing optical S/PDIF, and a few other modifications.

PICO-DWARF (Left) vs Wandbaord (Right)

PICO-DWARF (Left) vs Wandbaord (Right)

While on the other side of the board, the larger EDM module, as been replaced with the tiny PICO-IMX6 SoM.

PICO-DWARF specifications are listed as follows:

Bottom of PICO-DWARF Board

Bottom of PICO-DWARF Board

  • Supported System-on-Module
    • Intel Edison connector (1x 70-pin Hirose Connector)
    • TechNexion Pico connectors (3x 70-pin Hirose Connector)
  • External Storage – 1x SATA data + power connector, 1x micro SD slot
  • Connectivity – Gigabit LAN (Atheros AR8031) with RJ45 connector
  • Video Output / Display
    • HDMI
    • Single Channel LVDS (expansion header)
    • 24-bit TTL RGB (expansion header)
    • MIPI DSI Display on 33-pin FPC Connector
  • Camera – MIPI CSI signals on 33-pin FPC connector
  • Audio – Freescale SGTL5000 audio codec; Three 3.5 mm jacks for stereo audio in, stereo audio out, and microphone
  • Sensors – Altimeter (Freescale MPL3115A2), 3D Accelerometer (Freescale FXOS8700CQ), Gyroscope (Freescale FXAS21002)
  • USB – 1x USB 2.0 Host connector,  1x USB 2.0 OTG connector
  • Expansion Headers with access to signaling for single Channel LVDS,  24-bit TTL RGB, PCIe, CAN, GPIO, PWM, I²C, SPI, and UART
  • Misc – RTC DS1337+ with backup battery
  • Power
    • 5V DC +/- 5% via 5.5 / 2.1mm barrel jack
    • LiPo Battery with Freescale MC32BC3770CSR2 based battery charging circuit; 2-pin header for battery
  • Temperature – Commercial : 0° to 60° C
  • Relative Humidity – 10 – 90%
  • Dimensions – 95 x 95 mm
  • Weight – 40 grams
  • Certification – CE, FCC, RoHS, REACh directives
Block Diagram for the DWARF Platform (Click to Enlarge)

Block Diagram for the DWARF Platform (Click to Enlarge)

Please note that SATA won’t be supported by i.MX6 Solo or Duallite processor, so this would only work on future modules featuring Freescale i.MX6 Dual or Quad processor. PICO-DWARF carrier board will be open source hardware, as the company plans to release the schematics, design files, board files and bills of material for the board, just as they’ve done for their previous products.

PICO-DWARF baseboard and PICO-IMX6 modules are expected to start shipping in May and June, with the baseboard and PICO-IMX6-SD first, shortly followed by PICO-MX6-eMMC modules, and a quad core version. PICO-iMX6-SD with Freescale i.MX6 Solo will sell for about $50, while kits based on PICO-iMX6 SoM and PICO-DWARF carrier board will go for $130 to $150 depending on configuration. Further details can be found on TechNexion’s PICO page.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Embedded Systems Conference 2015 Schedule – May 6-7, 2015

March 11th, 2015 No comments

The Embedded Systems Conference took the name “Design West” for a couple of years, but this year, there’s no mention of Design West, and the Embedded System Conference 2015 will take place in Boston, MA, US on May 6-7, 2015. The 2-day event will have a demo hall, and well as sessions divided into 8 tracks:Embedded_Systems_Conference_2015

  • Connected Devices and the IoT
  • Embedded Software Design
  • Hardware: Design, I/O and Interfacing
  • Prototyping
  • Embedded Systems Design
  • Software: Design, Languages, & Quality
  • Fantastical Theater
  • Teardowns

The full schedule has now been posted, and I’ll build a virtual schedule with some of the sessions provided.

Wednesday May 6, 2015

  • 8:00 – 8:45 – Understanding Google/Nest Thread by Michael Anderson, Chief Scientist, The PTR Group, Inc.

The IoT will live or die based on its connectivity. In examining existing wireless protocols, Google/Nest found most of them lacking. In order to address the needs for low-power wireless communications in the home, Thread was created. Thread is an implementation of an IEEE 802.15.4 mesh-based network that provides IP connectivity using existing radio silicon. Come to this session to get the latest information on Thread, its capabilities and characteristics and how you can use Thread in your next IoT device.

  • 9:00 – 9:45 – Best Practices for Designing Hardware APIs by Matt Haines, Communications Manager, Electric Imp

We are rapidly heading toward a world in which most of the objects we interact with on a daily basis will be connected to the Internet. What does this world look like, and how do we design Connected Things that will live in this world? This presentation will address the issue of API design; a topic often talked about in web development but just as often overlooked in conversations about the IoT. What should we be thinking about when we’re designing an API for a connected product? Why do our connected products even need APIs? What strategies and best practices can we apply from web API design?

  • 10:00 – 10:45 – Choosing Between Multicore CPU, GPU & FPGA Technology for Vision Applications by Julianne Kline, Systems Engineer, National Instruments

FPGA, GPU, and multi-core CPU processing will be compared and contrasted. Examples will be highlighted on when customers may want to use one technology over the other. A heavier focus will be placed on FPGA technology. This presentation will discuss recommendations for when to integrate FPGA technology into vision applications, such as for image pre-processing, high-speed control, or processing parallelism. Types of algorithms well-suited to FPGA technology will also be discussed, and resources for accessing existing FPGA IP will be provided.

  • 11:00 – 11:45 – Mob Programming for Embedded Systems Software by Nancy Van Schooenderwoert, President, Lean-Agile Partners, Inc.

Mob Programming is a practice where a whole software team works together, at one computer, one line of code at a time, outperforming their previous work significantly in both quality and volume. Impossible? Maybe except for the teams actually doing it now. One team in California began in 2011, and it’s been spreading since. This session tells the story of the first embedded systems teams to use MobProgramming.This session is a double experience report plus a demo: Speaker Simon Clements-Hawes gives his observations as an embedded systems team member starting to use MobProgramming, and Nancy describes how to get a team started in MobProgramming. Thru video clips, the team’s coding of a LeanKit interrogator in C# will be shown using Mob Programming of course!

  • 14:00 – 14:45 – Is There an Arduino Debugger in the House? by Guido Bonelli, President, Innovative Electronic Solutions LLC

Arduino development and the hardware debugging landscape OR THE LACK THEREOF! In this session you will delve into the Arduino developer’s tool chain from a hardware perspective. What hardware debugging solutions are currently available and how Dr.Duino the Arduino hardware debugger can reduce your debugging pain. We shall discuss the blissful highs of easy firmware development on a standard platform while then exploring the lowliest of lows when debugging the hardware/firmware interactions.

  • 15:00 – 15:45 – ARMv8 Kernel Internals by Arun Thomas, Senior Principal Engineer, BAE Systems

This talk is meant to be a quick start guide for embedded developers who are new to the ARMv8 architecture. I will discuss how operating systems interface with the 64-bit ARMv8 architecture and will cover the ARMv8 specific kernel internals of Linux and FreeBSD. I will discuss how booting, memory management, exceptions, and interrupts work using examples drawn from the kernel source.

Thursday May 7, 2015

  • 08:00 – 08:45 – Open Source Software: Tips for Avoiding Licensing Surprises by Jason Kunze, Attorney, Nixon Peabody LLP

A practical, quick hitting summary of the key considerations that anyone developing, purchasing or licensing software should consider. After a brief discussion of legal basics, practical concerns relating to open source software will be explained through the lens of actual cases in this developing area of law. The participant will gain a general understanding of:

  1. The intellectual property rights that may attach to software
  2. The competing ideologies behind open source software and how this drives licensing terms
  3. Some of the leading open source software licenses and their relative level of restrictions
  4. Pitfalls to recognize and avoid in relation to open source software
  • 09:00 – 09:45 – How NOT To Do Embedded Development! Practical Lessons From Real Projects That Almost Went Off A Cliff by Dave Nadler, President, Nadler & Associates

In an interactive (Socratic) discussion, we’ll review some real-world projects in trouble and how they were sorted. Projects include an automated toll-collection system, an aircraft collision-avoidance system (cool movie!), a manufacturing instrumentation product, and an integrated flight computer. We’ll cover a variety of coding and testing techniques used to get these projects on track.

  • 10:00 – 10:45 – Designing for the IoT with Lower Power and Way More Intelligence by Dana Myers, Channel Marketing Manager, Wireless Connectivity Solutions, Texas Instruments

As the Internet of Things (IoT) has changed the way we live, do business and make decisions, it has also impacted engineers’ designs. This presentation will address the benefits and challenges of designing for the IoT in regards to low-power, integration and performance. This will let engineers weigh the tradeoffs of each connectivity architecture and provide a quick pathway to begin designing their products for the fast-growing IoT.

  • 11:00 – 11:45 – Squeezing the Most Out of Battery Life using ARM Cortex-M Processors by Jacob Beningo, Principal Consultant, Beningo Engineering

The proliferation of mobile devices has led to the need of squeezing every last micro-amp-hour out of batteries. Minimizing the energy profile of a micro-controller is not always straight forward. A combination of sleep modes, peripheral control and other techniques can be used to maximize battery life. In this session, strategies for optimizing micro-controller energy profiles will be examined which will extend battery life while maintaining the integrity of the system. The techniques will be demonstrated on an ARM Cortex-M processor.

  • 14:00 – 14:45 – Network Insecurity: Simple Hacks of ARM Cortex-M Devices by Jonny Doin, CEO, Grid Vortex Systems

The IoT is a very new domain of a very old activity: Embedded Systems Design, with a twist: connection to the most toxic of environments, the Internet. One of the main concerns of the IoT is how to cope with the massive amount of unanticipated network traffic and problems. Malformed packets, corrupted messages, specifically targeted attacks, buffer overflow exploits, spoofing, stuxnet emulation messages, denial of service, fake OTAP, and other exploits and attacks can transform your IoT devices into something you did not design for. This situation demands several good practices and programming concerns regarding network safety and security into even the smallest of things. Buffer integrity checks, full parameters domain verification, message authentication, data path integrity verification, and crypto security are among the needed elements of a safe and secure IoT system, and can be implemented on nearly any Embedded System. Examples of simple attacks on ARM Cortex-M devices will be presented, including RET2ZP and buffer attacks.

  • 15:00 – 15:45 – RTOS Smackdown: 7 RTOSes in 45 Minutes! by 7 speakers

There are a lot of Real Time Operating System (RTOS) options out there. Which one is right for your embedded system? Do you even need an RTOS at all? In this feisty presentation, one industry expert will argue that an RTOS is superfluous to requirements, while another will contend that an RTOS is an invaluable, “must-have” asset, even if your embedded application performs only a handful of tasks. After the dust dies down, proponents of seven of the leanest, meanest, coolest, hottest contenders in the RTOS multi-universe will take it in turns to explain why their RTOS is the bestest of the best.

If you’d like to attend the conference you can register online. Access to the demo hall is free, unless you come without registration, in which case you’d have to pay $75 for entry. A pass is required for the full conference and access to sessions with the following pricing:

  • SUPER EARLY BIRD (Ends January 30) – $799
  • EARLY BIRD (Ends March 6) – $949
  • ADVANCED (Ends May 1) – $1,149
  • REGULAR/ONSITE – $1,299

Seven vendors’ sponsored sessions can be attended with a free “demo hall” registration.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Calaos is an Open Source Home Automation Suite for Raspberry Pi, Allwinner A10/A20 and x86 Platforms

March 9th, 2015 No comments

Calaos is a Linux based home automation software released under GPLv3 license that works on Raspberry Pi, some Allwinner platforms like Cubiebaord 1/2, Mele A1000(G)/A2000, as well as x86 / amd64 hardware platforms that allows you control switches & lights in the rooms of your home or office, control your music, and manage security cameras.. The developers have recently released Calaos v2.0, the first stable release, so it’s a good time to have a look.

Calaos WebApp

Calaos WebApp

The software stack is comprised of 6 main components:

  • Calaos Server – Daemon that exports the state of the house via a JSON protocol. It can currently manage the following hardware components and protocols:
    Calaos Mobile

    Calaos Mobile

    • Wago’s PLC, with digital or analog I/O, DALI or DMX light bus
    • IPX800 web relay board
    • GCE Electronics Eco Devices used to monitor power consumption.
    • Web API
    • 1-Wire, X10
    • Zibase I/O
    • GPIO (Linux based GPIO, for direct use of RaspberryPI GPIO header) ;
    • Squeezebox
    • Nabaztag (Karotz). That’s a connected Wi-Fi enabled rabbit :)
    • CCTV IP (Axis, Mjpeg…)
  • Calaos Home –  Touchscreen interface to control the home, developed with EFL.
  • Calaos WebApp –  Web based interface implemented in HTML5 and using Angular JS and Bootstrap. Shown in screenshot above.
  • Calaos OS –  Linux distribution based on Openembedded pre-loaded with Calaos Server, Calaos Home and Calaos WebApp and relevant tools. That’s what you’ll need to get started easily, as you just need to download the image for your hardware.
  • Calaos Mobile – Qt5/QML app for Android and iOS tablet and smartphones that allows you to control Calaos remotely. However, only a subset of functions are available compared to Calaos Home.
  • Calaos Installer – Contrary to what the name implies, this Qt5 app does not install Calaos, but allows you to configure Calaos Server remotely, by adding, removing or modifying inputs/outputs on your PC, instead of editing configuration files manually. It also supports LUA scripts
Calaos Installer

Calaos Installer

You can have a better look at the user interface in the video section of the website, and I’ve also included a short video showing the Raspberry Pi connected to a 10″ touchscreen LCD  running Calaos Home.

You can find more details, and documentation on Calaos website, including a Quick Start Guide for the Raspberry Pi. The source code is available on Calaos github account.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

DonglePi is a USB Dongle with a Raspberry Pi Header for your PC

March 5th, 2015 5 comments

While the newer Raspberry Pi A+, B+ and B2 boards feature the new 40-pin connector, the Raspberry Pi boards Model A and B have a 26-pin expansion header, but both are use to access GPIOs, UART, SPI, I2C and interface with external hardware, and many add-ons boards have been developed for the Raspberry Pi. But what if you’d like to use R-Pi add-ons board on your PC, or instead you are developing your own add-on board, but would like to do so directly on your PC for convenience? DonglePi is the answer.
DonglePiIt’s a small USB dongle with Atmel SAMD21 MCU and a 26-pin Raspberry Pi compatible header, that you could use connect to your Android/Linux/Windows PC to play with GPIO, I2C, SPI, Serial, PWM just like on a Raspberry Pi, and using RPi/GPIO or smbus Python libraries for programming.

The project is still in development, and so far most interfaces are working except PWM which needs to be worked on. The whole software and hardware (Eagle Schematics & PCB) are released under a Creative Commons CC BY-NC 4.0 license.

The hardware can not be purchased (yet), but you could also make a prototype with a breadboard, an Atmel SAMD21 development board, and Pi Cobler kit just like the developer (gbin) started with as shown below.

Atmel_SAMD21_Cobbler_Pi_BreadboardAll connections, hardware and software are documented on github.

Thanks to Zoobab for the tip.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter