Skip navigation

Blog

1 2 3 Previous Next

Embedded

653 posts

Simply put, security for Embedded  IoT devices is about protecting assets from malicious attack. Typically this protection is thought about in terms of keeping some assets, such as crypto keys, secret and controlling how software and data is modified. In order for the Internet of Things (IoT) to be successful it is important that devices and services are appropriately protected.

 

As IoT products become successful they will become increasingly attractive for attackers and so appropriate security must be baked into every system and at every level. This will require a scalable “building block” approach where designers can use established security approaches that can scale from low cost microcontrollers through to high performance application processor based systems.

 

However, understanding how to protect devices, data and services can be an overwhelming task for developers who are new to security and who must focus on other challenges such as battery life, form factor and user interfaces, just to name a few.

The Internet of Things is vulnerable to attack from many angles

 

The above diagram shows the breath of the attack surface along with some of the vulnerabilities that can be exploited within connected systems. These can be categorized as:

  • The network attack surface
    • Every point of network interaction from the end device nodes to the server is a potential part of the network attack surface.
  • The software attack surface
    • All running code has the possibility of having exploitable vulnerabilities - from the end device, through the network and all the way to the server.
  • The physical attack surface
    • If not protected, an attacker can gain the highest level of access to a device through physical attacks. This can be in the form of debug probing or more invasive hardware attacks.

 

Attackers have the privilege of selecting where to attack so we need to think carefully about countermeasures across the entire system.

 

Security is a balance between economic cost and benefit

Given enough time, money and expertise any system can be hacked, so it is important to design a system to deter an attacker by making it uneconomic (i.e. the cost or effort of an attack far outweighs any benefit to an attacker).

 

Types of attacks can be classified in terms of investment, the type of attacker and equipment used. These range from:

  • expensive invasive attacks (such as reverse engineering, or sophisticated micro probing a chip)
  • to lower cost:
    • passive software attacks (exploiting unintentional security vulnerabilities in the code)
    • communication attacks (e.g. exploiting weaknesses in the internet protocols, crypto or key handling)

 

Hacks can be categorised by the cost and effort involved

 

Security is always a balance between economic cost and benefit, dependent upon the value of assets on the one hand and the cost of security features on the other.

The success of the Internet of Things will depend on data and services being protected, and when the security balance is right, it can open up new opportunities and markets.

 

So how can we relate to the needs of a secure application or service?

 

Secure digital payment

One way is to consider an example so many of us perform; a digital payment transaction. If you are paying by credit card, smart phone or over the web, you are a participant in a secure application. As a card holder or in the case of mobile phone payment with NFC, you are the holder of a unique identification linking what you have in your possession to your ability to pay. During the payment process there is a confirmation of the parties involved in the transaction. Payment networks are built to provide assured service, for example, supporting transactions without a network connection. The networks involved are protected by strong firewalls and the communication between all stages of the transaction are protected by strong cryptography. Secure content is also managed as records of the transaction are protected. In addition, to protect the most critical data in the payment application, there is tamper resistance built into the devices.

 

Requirements for secure digital payment

 

A great deal can be learned by considering payment applications, the associated standards and the ARM® powered ARM Processors that are essential to supporting these solutions. Unfortunately, as we can see from numerous reports on data breaches, we also learn that this high value transaction is subject to attacks. With a direct link to a financial benefit, attackers seek out every opportunity.

 

IoT devices are hugely diverse

IoT covers many applications and includes everything from wearable fitness bands and smart home appliances to factory control devices, medical devices and even automobiles. These market segments have many different types of IoT devices from ultra-low cost battery powered devices with tiny sensors that can last years to hub and base station devices that can act as an aggregation point, providing connectivity to the cloud and are normally connected to the mains power.

IoT devices are different from one another in almost everything: their hardware, their operating system, their type of software, their level of assurance, and their ability to support different security protocols.

Devices can be highly varied across architecture, software and security capabilities

 

The type and level of security applied in a device will vary according to the functionality of the device and the impact that an exploited device can pose. In the ultra-low cost segment, some devices may not require the capability to have their software upgraded, may not enable any third party software to be downloaded and may not store sensitive data; hence, the security applied may just involve locking down debug ports and encrypting the data on the radio link between the client and the host. Many more devices within the segment will have link encryption, hardware backed trusted execution environments, secure data storage, root-of-trust, and device security lifecycle management.

 

Even though a device may appear to be simple, and therefore require minimal security, the level of security applied, the impact on the system of a device being hacked must be considered. A good example of this is a simple connected light bulb. At first consideration the value of exploiting this would appear low, however looking deeper, if an attacker were able to take command of thousands of light bulbs, the impact of turning these on or off at the same time could potentially bring down the power grid. Equally, if an attacker were able to access crypto keys from a simple device the attacker may be able to use these to attack other parts of a system.

ARM and the ARM partners are building layers of security (hardware & software) into IoT devices, balancing cost and security across these segments.

Three key areas that need to be considered are device, communications link and product lifecycle.

 

Device security

Trust starts with devices that have hardware based trust anchors (known as roots of trust), a trusted boot process to get those systems into a known good state and layers of hardware and software based security that can be used to protect assets of differing value.

These secure devices need to

  • Protect themselves and recover from untrusted software attacks through isolation, ensuring untrusted code cannot access these secure domains.
  • Prevent attackers from accessing or copying data, with on chip memories to protect firmware from theft and cryptography to encrypt and decrypt the data.
  • Provide anti-tampering techniques. The level of technique applied will depend on the value of the asset. Typical techniques aim to detect if an attack is occurring and then react to correct that attack. An example of this is to block external access to a non-trusted debug request and/or wipe secure memory spaces once an attack is detected.

 

Communication security

We also need to ensure the link is secure and trusted devices can connect to the cloud via encrypted links using standard internet protocols (such as TLS – Transport Layer Security, which is the security protocol used for https transport). Consumers will be familiar with this widely deployed technology from the padlock symbol used to secure their online banking. This prevents eavesdroppers (man in the middle) listening by providing the encrypted link between the trusted end point and the cloud.

Using key management the identity of endpoint device can also be authenticated on the server before it is allowed access to the services

Software lifecycle security

During a product’s lifecycle the device will go through a number of updates: from its early days in the factory, where the silicon manufacturer and OEM will inject root of trust keys in ROM or eFuse technologies, to its initial boot up with the consumer, to the many over-the-air (OTA) updates ensuring the firmware is kept up-to-date and secure.

To ensure the device is protected from malicious software attack all software images need to be authenticated before they are used in the system.

 

Software provisioning, such as OTA updates, require a trusted process of authentication

 

Software is protected and authenticated through a process of code signing which digitally signs a software image to guarantee that the code has not been altered or corrupted. To do this, an OEM or service provider first generates an RSA public key and private key pair.

The private key is used to sign the original image and is never shared with the device. The public key is programmed into a secure eFuse or ROM block within the device. This forms a core root of trust.

Once the device receives the signed image, it then compares the decrypted original public key to the signature and, if the values match, the code is considered authentic and the new code is used in the boot process.

These steps within the trusted boot process are also used to ensure any firmware updates are validated throughout the life of the product. For firmware updates the new public key is verified with the original public key before the signature is compared and the result authenticated.

 

 

Security across all of the IoT

For IoT to succeed, we need to consider security as a system problem: how the high value keys are provisioned and protected? How is critical software authenticated and isolated? How is the device managed over its life-cycle? Which security communications protocol is being used to protect data in-flight? We also need to think about what is an appropriate level of protection given the value of the assets and the use of the device.

Given that many IoT devices will be designed by non-security experts we also need to ensure the solutions to these problems are easy to implement and scalable across different use cases. Fortunately, ARM and its partners are creating easy to use hardware and software building blocks that can provide the security foundations for the next wave of connected devices.

 

When security is implemented across the cloud, it opens up new business models

 

We will discuss these in future blogs.

 

In the meantime, if you are interested in learning more about security,  ARM is running a series of security webinars in June.

Register now for

"How to build trust and security into your embedded devices" (June 14th) and

"Meet the experts: ARM TrustZone - understanding system security" (June 28th)

 

Special thanks to Donnie Garcia from NXP for his contribution to this blog.

Donnie has held various roles in his semiconductor career related to embedded processors including applications support, systems engineering and product marketing. He currently works as a solutions architect for payment and access applications.

flo

COMPUTEX Taiwan - visit TechNexion

Posted by flo May 26, 2016

Next week starts COMPUTEX in Taiwan.

 

Of course TechNexion will be there as well and showcase our products.

 

Visit us at:

TWTC NangGang Exhibition Center, Hall 1

Our booth number: K1216 (1F)

 

We will show a live demo of our NXP i.MX7 System.... check our booth for more information

 

Here is the Link for the show:

http://www.computex.biz/ComputexTaipei/

 

And here how oversee exhibitors can apply for a last minute ticket:

http://computex.leadexpo.com/EN-index.html

Tibbo Technology Inc. has recently announced a Linux version of its popular Tibbo Project System (TPS).

 

LTPP is a Linux-based Tibbo Project PCB (TPS mainboard) based on the powerful 1GHz Cortex-A8 Sitara CPU from Texas Instruments. Carrying 512MB of RAM and 512MB of flash memory, the new LTPP3 board runs Tibbo’s own, highly polished distribution of Linux that is updated with the latest and greatest kernel and drivers.

 

LTPP may be programmed and managed in several different ways: the Tibbo-supplied Embedded AggreGate (purchased separately), NodeJS (comes pre-installed), TiOS (not yet fully ported). Tibbo also says that LTPP may be used and programmed as any other generic Linux board. For developers who have at least some Linux coding experience, the company supplies the LTPS SDK.

 

Is it hard to develop native C applications for LTPS? We don't think so! If you have ever written a Linux program, it will be easy for you to figure out how to do this for the LTPP board.

 

Doubtful? OK, let’s see how to write a simple C application for the LTPP. Here is the list of steps: get the cross-compiler, install the SDK, build a program, and load it into the board.

 

----------------

Please note how the user input below is highlighted in green. Root (supervisor) credentials are NOT required for installing the SDK and building programs.

----------------

 

We will assume that you are using a Linux PC or that you have previously created a Linux virtual machine on your computer. If you don’t have a Linux PC yet, please install any popular Linux distribution under Oracle VM VirtualBox, QUEMU or Vmware.

 

1. Getting the Cross-compiler for LTPS from Tibbo Website

 

*Note: the download location may change in the future. Please, search our website (tibbo.com) for updates.

Open the terminal emulator on your Linux host, make sure you are connected to the Internet, and download the LTPS SDK

from http://tibbo.com/downloads/TPSL_tmp/SDK/ .


[dv@dvh hello_world]$
wget

http://tibbo.com/downloads/TPSL_tmp/SDK/tps-systemd-glibc-i686-TPS-agent-cortexa8hf-neon-toolchain-1.8+snapshot.sh

--2016-05-16 22:02:01--

  http://tibbo.com/downloads/TPSL_tmp/SDK/tps-systemd-glibc-i686-TPS-agent-cortexa8hf-neon-toolchain-1.8+snapshot.sh

Resolving tibbo.com (tibbo.com)... 93.174.104.89

Connecting to tibbo.com (tibbo.com)|93.174.104.89|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 443644550 (423M) [text/plain]

Saving to: 'tps-systemd-glibc-i686-TPS-agent-cortexa8hf-neon-toolchain-1.8+snapshot.sh'

 

100%[======================================>] 443,644,550 4.61MB/s   in 99s   


2016-05-16 22:03:40 (4.28 MB/s) -

'tps-systemd-glibc-i686-TPS-agent-cortexa8hf-neon-toolchain-1.8+snapshot.sh' saved [443644550/443644550]


[dv@dvh hello_world]$ ls -l

total 433256

drwxrwxr-x 2 dv dv      4096 May 16 22:00 html/

-rw-r--r-- 1 dv dv 443644550 Apr  4 14:07

tps-systemd-glibc-i686-TPS-agent-cortexa8hf-neon-toolchain-1.8+snapshot.sh

 

2. LTPS SDK Installation

 

Full SDK image weighs around 0.5 Gb. It is not just a binary file; it is an installation script with an archive inside. Make it executable and run it to install the SDK.

 

[dv@dvh hello_world]$ chmod 0755

./tps-systemd-glibc-i686-TPS-agent-cortexa8hf-neon-toolchain-1.8+snapshot.sh

[dv@dvh hello_world]$ ./tps-systemd-glibc-i686-TPS-agent-cortexa8hf-neon-toolchain-1.8+snapshot.sh

TPS (Tibbo Project System) SDK installer version 1.8+snapshot

=============================================================

Enter target directory for SDK (default: /opt/tps-systemd/1.8+snapshot): ~/tpsC/

You are about to install the SDK to "/home/dv/tpsC". Proceed[Y/n]? Y

Extracting SDK................................................................................done

Setting it up...done

SDK has been successfully set up and is ready to be used.

Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.

$ . /home/dv/tpsC/environment-setup-cortexa8hf-neon-tps-linux-gnueabi

 

3. Setting up the Environment

 

Run the environment setup script as advised by the installer.

 

[dv@dvh hello_world]$ . /home/dv/tpsC/environment-setup-cortexa8hf-neon-tps-linux-gnueabi

 

4. Testing the Installation

 

In the same terminal emulator window, try to run the GCC compiler.

 

[dv@dvh hello_world]$ gcc --version

gcc(GCC) 4.8.2

Copyright (C) 2013 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

Oops, this looks like the default compiler, not the compiler we want. This compiler is the GCC from your Linux distribution, and it can only build for the x86 CPU.

Our cross-compiler is in the environment variables $CC, $CXX, $CPP.

 

[dv@dvh hello_world]$ echo $CC

arm-tps-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a8

--sysroot=/home/dv/tpsC/sysroots/cortexa8hf-neon-tps-linux-gnueabi

[dv@dvh hello_world]$ $CC --version

arm-tps-linux-gnueabi-gcc (GCC) 5.3.0

Copyright (C) 2015 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

That is what we needed! Ok, let’s write our first LTPS "Hello World!" program and build it.

 

5. Write a Simple Program

 

[dv@dvh hello_world]$ mkdir test_0

[dv@dvh hello_world]$ cd test_0/

 

Create the "Hello World" program using any editor you like. We prefer MC (Midnight Commander) editor, but here I will use VI, just as an example.

 

[dv@dvh test_0]$ touch ./test_0.c

 

test_0.c contents (get source there):

 

#include

int main( int argc, char *argv[]) {

printf( "Hello world from LTPS!\n");

return( 0);  }

 

Now create Makefile for our program. This is an old, traditional way of building anything in UNIX.

 

[dv@dvh test_0]$ touch ./Makefile

[dv@dvh test_0]$ vi ./Makefile

 

Makefile contents (get source here):

 

all:

        $(CC) -o test_0 test_0.c
clean:

        rm -f test_0        rm -f *.o

 

* Lead whitespaces are not the whitespaces, they are 2 (two) tabs.
Here is the Makefile syntax.

 

 

6. Building your Program with Cross-compiler

 

Run 'make' command in the same terminal emulator window where you previously ran LTPS SDK environment setup script.

[dv@dvh test_0]$ make

arm-tps-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8

--sysroot=/home/dv/tpsC/sysroots/cortexa8hf-neon-tps-linux-gnueabi -o test_0 test_0.c

[dv@dvh test_0]$ ls -l

total 20

-rw-r--r-- 1 dv dv   64 May 16 22:28 Makefile

-rwxr-xr-x 1 dv dv 9144 May 16 22:28 test_0*

-rw-r--r-- 1 dv dv  110 May 16 22:27 test_0.c

[dv@dvh test_0]$ ./test_0

bash: ./test_0: cannot execute binary file

Program build starts from "test_0.c" to "test_0". It is an executable binary. I tried to run it but it failed with the "cannot execute binary file" message. Why? Because it was built for a non-Intel CPU.

[dv@dvh test_0]$ objdump -f ./test_0

 

./test_0:     file format elf32-little

architecture: UNKNOWN!, flags 0x00000112:

EXEC_P, HAS_SYMS, D_PAGED

start address 0x000102f4

 

[dv@dvh test_0]$ $OBJDUMP -f ./test_0

 

./test_0:     file format elf32-littlearm

architecture: arm, flags 0x00000112:

EXEC_P, HAS_SYMS, D_PAGED

start address 0x000102f4

 

Yes, you understand this correctly: we have TWO 'objdump' executables: our traditional x86 'objdump' program that can be found in the default $PATH and 'cross-objdump' from LTPS SDK that can be found in the $OBJDUMP environment variable.

First (intel) objdump says it can't detect the architecture.
The second one (cross-objdump) says it is an ARM 32bit little-endian executable.
Everything looks correct. Let's copy the program into LTPS and try to run it...

 

[dv@dvh test_0]$ scp ./test_0 root@192.168.75.217:~/

root@192.168.75.217's password:

test_0                                        100% 9144     8.9KB/s   00:00   

[dv@dvh test_0]$ ssh root@192.168.75.217

root@192.168.75.217's password:

X11 forwarding request failed on channel 0

root@tpp:~# ./test_0

Hello world from LTPS!

root@tpp:~# uname -a

Linux tpp 4.4.3-tpp #1 Sat May 14 14:28:50 MSK 2016 armv7l GNU/Linux

root@tpp:~#

Success!

 

SAN MATEO, Calif.—The Maker movement has exploded thanks to forces like open system software and hardware and accessible, affordable components and design tools. Now, the great minds behind Arduino have just added a new item to makers’ innovation tool kits, this time with an eye to driving IoT design.

 

Luca Cipriani Arduino CIO

At Maker Faire 2016, Arduino announced Arduino Create, an online platform that Makers can use to write code, access content, configure boards and share projects.

 

“It’s an all-in-one experience for makers,” Luca Cipriani, Arduino CIO (pictured, left), told me at the Arduino booth here (May 21, 2016). “It’s a complete, new platform that allows users to share their projects online, edit them directly online with a new editor and get started with the cloud.”

 

As more design moves into the cloud, a cloud-based design environment makes more sense, Cipriani said. And up to now, developers had to frequently switch back and forth between various tools and screens, from IDEs to cloud services.

 

“Our main goal is to have just one ecosystem to do everything, do your projects, share your sketches,” he added.

 

Users, whether they’re working on a public or private project, are able to write code and upload sketches to any Arduino board directly from their browser with the Arduino Web Editor (IDE), without having to install anything.

 

The user’s sketchbook will be stored on the Arduino Cloud and will be accessible from any device. The getting-started app will allow users to configure and set up tools and boards available around you.

 

Users also can take existing public projects and modify them for their own purposes, Cipriani said.

 

Arduino Create

An excerpt from a recent Arduino blog notes:

“Despite your skill level, Arduino Create features in-depth guided flows to help easily configure online services like the Web Editor and Cloud. There’ll even be an additional learning component via Arduino’s popular Creative Technologies in the Classroom (CTC) educational program in the near future that will spark collaboration between teachers and their students.”

 

The web editor and cloud platform are powered by Amazon AWS. Here's a blog post from our friends at AWS with some additional details.

 

Related stories:

Maker Faire 2016: Accessible hardware, software drives new development

Industrial Makers? BeagleBone, Rasberry Pi and Arduino Move Towards Modules

As you may already know, PSoC Creator 3.3 Service Pack 2 is available for download on the Cypress website (http://cypress.com/creator). The Update Manager will be popping up desktop notifications soon. The release adds support for PSoC 4 S-series devices, a brand new CapSense component, and new EZ-BLE Bluetooth modules.


The S-series devices are the first PSoC chips with the ARM® Cortex™-M0+ core and our fourth generation CapSense technology. The PSoC 4000S devices are sampling now with the intelligent analog PSoC 4100S chips following along soon. Watch this space for development kit announcements!

 

Supporting these devices is a completely re-designed CapSense component that makes widget configuration easier, adds mutual-capacitance sensing for the best possible water rejection and long trace noise tolerance, and an API re-design to improve low power operation. You can even use the CapSense block as a 10-bit Analog-Digital Converter (ADC)!

 

 

PRoC users will be happy to see some new EZ-BLE modules that we're adding to the tool. These modules include the amazing XT/XR (Extended Temperature/Extended Range) device that really pushes the limits with 400m range and extended temperature tolerance.

 

As usual, we’ve also made quality improvements and minor enhancements. I strongly encourage you to install PSoC Creator 3.3 SP2. You can find more information, including the complete Release Notes, on the PSoC Creator product page at http://cypress.com/creator.

 

Product URL

PSoC® Creator™ Integrated Design Environment (IDE)

 

Related Documents

PSoC Creator

PSoC 4

PSoC Pioneer Kits

PSoC Prototyping Kits

The Bay Area Maker Faire is just around the corner, but I find myself casting my mind back to something eye-opening I saw at this year’s Embedded World conference in Nuremburg this February.

 

beagleboneblack.jpg

 

BeagleCore were showing an industrialized SoM version of the popular BeagleBone Black platform. BeagleBone probably runs behind only Arduino and Raspberry Pi in terms of sheer popularity in the Maker scene. This, of course, implies an extremely active and devoted development community ensuring a plethora of up-to-date tools, drivers and libraries, and example projects or how-tos of just about any project you could dream of. A company building an industrial-spec module that could leverage this extraordinarily active community is, possibly, a very compelling move indeed.

 

Raspberry_Pi_Compute_Module.png

 

This is not an isolated example, either. Raspberry Pi introduced their Compute Module in 2014, and in the recent Raspberry Pi 3 announcement indicated they would be releasing an update to this with the new Broadcom BCM2837 system-on-chip featured in the new Pi. Additionally, the new Arduino | Genuino MKR1000 has a form factor more reminiscent of a SoM than a development board. Combined with features like a built in Lithium Polymer battery connector and there’s an obvious intent here to build a device that can be more easily utilized in projects beyond just the prototyping phase.

 

 

The questions of reliability and supply chain guarantees, and the decades of experience brought by the traditional industrial embedded compute market, are still very relevant. Some applications will continue to have demands that rule out these community platforms – but for many, Arduino, Raspberry Pi, Beaglebone or others will satisfy that ‘good enough’ criteria, and at that point their accessibility and ease of use become serious competitive advantages. It will also be fascinating to watch how this influences the traditional embedded Single Board and module market – from my observations at Embedded World I’d say it already has, and to the advantage of developers and designers using these devices.

 

woodsy-co-maker-makerfaire-raspberry-pi-supercomputer.jpg

 

In San Mateo next week, at the Bay Area Maker Faire, I expect to see the usual fantastic set of projects existing at the cross section of art, multi-disciplinary engineering, practicality and fun that defines this movement. I’ll also be keeping an eye out for further signs that ‘Maker’ platforms are maturing, growing up and perhaps looking to further disrupt the incumbents in both old markets and new.

Tibbo Project System (TPS) is a highly configurable, affordable, and innovative automation platform. It is ideal for home, building, warehouse, and production floor automation projects, as well as data collection, distributed control, industrial computing, and device connectivityapplications.

 

Suppliers of traditional “control boxes” (embedded computers, PLCs, remote automation and I/O products, etc.) typically offer a wide variety of models differing in their I/O capabilities. Four serial ports and six relays. Two serial ports and eight relays. One serial port, four relays, and two sensor inputs. These lists go on and on, yet never seem to contain just the right mix of I/O functions you are looking for.

 

Rather than offering a large number of models, Tibbo Technology takes a different approach: Our Tibbo Project System (TPS) utilizes Tibbits® – miniature electronic blocks that implement specific I/O functions. Need three RS232 ports? Plug in exactly three RS232 Tibbits! Need two relays? Use a relay Tibbit. This module-based approach saves you money by allowing you to precisely define the features you want in your automation controller.

Here is a closer look at the process of building a custom Tibbo Project System.

 

 

Start with a Tibbo Project PCB (TPP)

 

 

A Tibbo Project PCB is the foundation of TPS devices.

Available in two sizes – medium and large – each board carries a CPU, memory, an Ethernet port, power input for +5V regulated power, and a number of sockets for Tibbit Modules and Connectors.

 

Add Tibbit® Blocks

 

Tibbits (as in “Tibbo Bits”) are blocks of prepackaged I/O functionality housed in brightly colored rectangular shells. Tibbits are subdivided into Modules and Connectors.

Want an ADC? There is a Tibbit Module for this. 24V power supply? Got that! RS232/422/485 port? We have this, and many other Modules, too.

Same goes for Tibbit Connectors. DB9 Tibbit? Check. Terminal block? Check. Infrared receiver/transmitter? Got it. Temperature, humidity, and pressure sensors? On the list of available Tibbits, too.

 

 

Assemble into a Tibbo Project Box (TPB)

 

Most projects require an enclosure. Designing one is a tough job. Making it beautiful is even tougher, and may also be prohibitively expensive. Finding or making the right housing is a perennial obstacle to completing low-volume and hobbyist projects.

Strangely, suppliers of popular platforms such as Arduino, Raspberry Pi, and BeagleBone do not bother with providing any enclosures, and available third-party offerings are primitive and flimsy.

Tibbo understands enclosure struggles and here is our solution: Your Tibbo Project System can optionally be ordered with a Tibbo Project Box (TPB) kit.

The ingenious feature of the TPB is that its top and bottom walls are formed by Tibbit Connectors. This eliminates a huge problem of any low-volume production operation – the necessity to drill holes and openings in an off-the-shelf enclosure.

The result is a neat, professionally looking housing every time, even for projects with the production quantity of one.

Like boards, our enclosures are available in two sizes – medium and large. Medium-size project boxes can be ordered in the LCD/keypad version, thus allowing you to design solutions incorporating a user interface.

 

 

Unique Online Configurator

 

 

To simplify the process of planning your TPS we have created an Online Configurator.

Configurator allows you to select the Tibbo Project Board (TPP), “insert” Tibbit Modules and Connectors into the board’s sockets, and specify additional options. These include choosing whether or not you wish to add a Tibbo Project Box (TPB) enclosure, LCD and keypad, DIN rail mounting kit, and so on. You can choose to have your system shipped fully assembled or as a parts kit.

Configurator makes sure you specify a valid system by watching out for errors. For example, it verifies that the total power consumption of your future TPS device does not exceed available power budget. Configurator also checks the placement of Tibbits, ensuring that there are no mistakes in their arrangement.

Completed configurations can be immediately ordered from our online store. You can opt to keep each configuration private, share it with other registered users, or make it public for everyone to see.

 

 

Develop your application



Like all programmable Tibbo hardware, Tibbo Project System devices are powered by Tibbo OS (TiOS).

Use our free Tibbo IDE (TIDE) software to create and debug sophisticated automation applications in Tibbo BASIC, Tibbo C, or a combination of the two languages.

To learn more about the Tibbo Project System please visit http://tibbo.com/tps.html

Heya, folks!

 

We’ve just published a very useful MQTT library and a pair of demo projects illustrating the use of the new MQTT library.

 

Showcasing both the publisher and subscriber sides of MQTT, these projects demonstrate the remote control of three LEDs on the subscriber using three buttons on the publisher.

 

More importantly, the projects show how easy it is to create lightweight IoT devices with Tibbo BASIC/C and Tibbo hardware.

 

Unlike many competing platforms, Tibbo OS (TiOS) has TCP/IP networking woven into its core, giving you an unprecedented level of control over your network communications. At the same time, the simplicity of Tibbo BASIC and Tibbo C dramatically shortens the learning process, as well as the time needed to develop robust network-enabled applications.

 

Try the MQTT Library Demo and see for yourself!

More post from Gadget Guru

Pre-GO PPP and the Gumstix BBB Rover Cape

This is not going to be a long post.  Basically, I got the Pre-GO PPP working with the BeagleBone Black almost effortlessly through the Gumstix BBB Rover cape.  Rover was designed to be a remote-controlled robotics cape with dual PWMs for motor control on either side of the board, WiFi and Bluetooth connectivity and a whole lot of GPIO.  Conveniently enough, it has the 5-pin GPS header module on-board as well.

I downloaded the custom Yocto image, loaded it on to an SD card and fired it up.  Right away, I was able to see the raw GPS feed over a serial connection to UART04 but the image I had lacked the GPSD client tools.  After I disabled the IP-over-USB service and the BeagleBone's Ethernet controller and my router stopped arguing, I apt-got the tools and monitored the GPS data for a while.

 

It's confirmed, the Pre-GO PPP works great with the BBB Rover cape.

 

Meanwhile, I've completed my final test for the RPCM + Pre-GO PPP and am in the midst of analyzing the data.  I'll be posting my findings soon...

 

Want to find out how the Pre-GO PPP works with the Raspberry Pi Compute Module through the Gumstix Pi's UART breakout connection read Chapter 5

The Gadget Guru: Gumstix Pi Pre-GO PPP Project Chapter 5

 

See all Gadget Guru Post Here

The Gadget Guru

An RTOS (Real-Time Operating System) is the most universally accepted way of designing and implementing embedded software. It is the most sought after component of any system that outgrows the venerable "superloop". But it is also the design strategy that implies a certain programming paradigm, which leads to particularly brittle designs that often work only by chance. I'm talking about sequential programming based on blocking.

 

Blocking occurs any time you wait explicitly in-line for something to happen. All RTOSes provide an assortment of blocking mechanisms, such as time-delays, semaphores, event-flags, mailboxes, message queues, and so on. Every RTOS thread, structured as an endless loop, must use at least one such blocking mechanism, or else it will take all the CPU cycles. Typically, however, threads block not in just one place in the endless loop, but in many places scattered throughout various functions called from the thread routine. For example, in one part of the loop a thread can block and wait for a semaphore that indicates the end of an ADC conversion. In other part of the loop, the same thread might wait for an event flag indicating a button press, and so on.

 

This excessive blocking is evil, because it appears to work initially, but almost always degenerates into a unmanageable mess. The problem is that while a thread is blocked, the thread is not doing any other work and is not responsive to other events. Such a thread cannot be easily extended to handle new events, not just because the system is unresponsive, but mostly due to the fact that the whole structure of the code past the blocking call is designed to handle only the event that it was explicitly waiting for.

 

You might think that difficulty of adding new features (events and behaviors) to such designs is only important later, when the original software is maintained or reused for the next similar project. I disagree. Flexibility is vital from day one. Any application of nontrivial complexity is developed over time by gradually adding new events and behaviors. The inflexibility makes it exponentially harder to grow and elaborate an application, so the design quickly degenerates in the process known as architectural decay.

 

perils_of_blocking.jpg

 

The mechanisms of architectural decay of RTOS-based applications are manifold, but perhaps the worst is the unnecessary proliferation of threads. Designers, unable to add new events to unresponsive threads are forced to create new threads, regardless of coupling and cohesion. Often the new feature uses the same data and resources as an already existing feature (such features are called cohesive). But unresponsiveness forces you to add the new feature in a new thread, which requires caution with sharing the common data. So mutexes and other such blocking mechanisms must be applied and the vicious cycle tightens. The designer ends up spending most of the time not on the feature at hand, but on managing subtle, intermittent, unintended side-effects.

 

For these reasons experienced software developers avoid blocking as much as possible. Instead, they use the Active Object design pattern. They structure their threads in a particular way, as "message pumps", with just one blocking call at the top of the task loop, which waits generically for all events that can flow to this particular thread. Then, after this blocking call the code checks which event actually arrived, and based on the type of the event the appropriate event handler is called. The pivotal point is that these event handlers are not allowed to block, but must quickly return to the "message pump". This is, of course, the event-driven paradigm applied on top of a traditional RTOS.

 

While you can implement Active Objects manually on top of a conventional RTOS, an even better way is to implement this pattern as a software framework, because a framework is the best known method to capture and reuse a software architecture. In fact, you can already see how such a framework already starts to emerge. Just notice that the "message pump" structure is identical for all thrads, so it can become part of the framework rather than being repeated in every application.

 

This also illustrates the most important characteristics of a framework called inversion of control. When you use an RTOS, you write the main body of each thread and you call the code from the RTOS, such as delay(). In contrast, when you use a framework, you reuse the architecture, such as the "message pump" here, and write the code that it calls. The inversion of control is very characteristic to all event-driven systems. It is the main reason for the architectural-reuse and enforcement of the best practices, as opposed to re-inventing them for each project at hand.

 

But there is more, much more to the Active Object framework. For example, a framework like this can also provide support for state machines (or better yet, hierarchical state machines), with which to implement the internal behavior of active objects. In fact, this is exactly how you are supposed to model the behavior in the UML (Unified Modeling Language).

 

As it turns out, active objects provide the sufficiently high-level of abstraction and the right level of abstraction to effectively apply modeling. This is in contrast to a traditional RTOS, which does not provide the right abstractions. You will not find threads, semaphores, or time delays in the standard UML. But you will find active objects, events, and hierarchical state machines.

 

An AO framework and a modeling tool beautifully complement each other. The framework benefits from a modeling tool to take full advantage of the very expressive graphical notation of state machines, which are the most constructive part of the UML.

 

In summary, RTOS and superloop aren't the only game in town. Actor frameworks, such as Akka, are becoming all the rage in enterprise computing, but active object frameworks are an even better fit for deeply embedded programming. After working with such frameworks for over 15 years , I believe that they represent a similar quantum leap of improvement over the RTOS, as the RTOS represents with respect to the “superloop”.

 

If you'd like to learn more about active objects, I recently posted a presentation on SlideShare: Beyond the RTOS: A Better Way to Design Real-Time Embedded Software

nVIDIA® Tegra® K1 Development Board, Propus has eSOMTK1 - Systems on Module & carrier board. eSOMTK1 is based on nVIDIA's Tegra K1 4-Plus-1 ARM™ Cortex-A15 Quad core processor which can operate up to 2.3 GHz and Integrated nVIDIA Kepler™ GPU with 192 nVIDIA CUDA® cores.

 

 

Today is World IP Day today, an annual celebration and acknowledgement of the vital role that intellectual property rights play in encouraging innovation.

In electronics design, the ARM community has of course played a crucial role in changing the very nature of how we conceive and implement systems and silicon design. And the way we do it changes constantly.

 

We don’t often have the time because we’re busy building tomorrow, but take a moment today to pause and reflect on your accomplishments as part of this global ecosystem. It’s been an astonishing journey.

 

Last year, my colleague neilcooper compiled a history of ecosystem innovation over the past quarter century (Celebrating 25 Years of the ARM Ecosystem). It’s an inspiring story, especially for those of us who covered the rise of a truly unique approach to electronics design way back when.

 

 

Related stories:

Celebrating 25 Years of the ARM Ecosystem

Ten key milestones from ARM’s first 25 years

 

ARM_A540vsHuaweiWatch_v4.png

Berkeley’s Dr. Rabaey predicted trouble with the IOT back in 2008. At the upcoming IEEE IMS 2016 event, he’ll propose an open, scalable human Intranet to deal with the legacy issues.

By John Blyler, Editorial Director

 

History may well repeat itself at this year’s ieee IMS May 2016 event. Berkeley University’s Dr. Jan Rabaey will speak on a subject of “sensor swarms” that he first introduced back in 2008 at a javascript:;Cadence Design Systems Design Network Live (CDNLive) event. [Back then, Ted Vecurevich was still CTO for the company – see image below.]

 

Even before 2008, Rabaey ( javascript:;Sensor Swarm Proponent Predicted IoT Technical Barrier) was a proponent of the concept of a sensor swarm but predicted serious technical barriers to what would later be called the Internet-of-Things (IoT). These earlier warnings by Dr. Rabaey about complexity issues supported later reports on the barriers of immature standards and the high cost of networking infrastructures for IoT – see below.

 

During the early cdnlive event, I moderated a panel where Dr. Jan Rabaey of talked about the coming age of wireless sensor swarms (a precursor to IoT). He noted the growing complexity of sensory networks, adding that, “if you ignore system-level design, you’re toast.”

Figure: Low-power panel at CDNLive 2008 (from left to right): John Blyler (moderator), Ted Vucurevich, Nikhil Jayaram, Juan Antonio Carballo, Jan Rabaey and Carl Guardino.

 

A few years ago, javascript:;Embedded sponsored a report by the the_economist Intelligence Unit, titled; “The Internet of Things Business Index: A quiet revolution

gathers pace.” Among the many findings of the report was a caution about connectivity: “The IoT will not flourish without genuine co-operation. Turning 50bn so-called smart things into a global network requires businesses to agree on standards for inter-connectivity and data sharing.”

 

Two of the top five barriers for companies hoping to increase the use of IoT were; 1) the immaturity of industry standards around IoT, and 2) the high costs of required investments of IoT infrastructure. Both of these barriers relate directly to networking/connectivity issues, including the design of the overall system – from the analog sensor to the digital MCU and up through the individual wired/wireless networks to the cloud.

 

Echoing Dr. Rabaey’s words from many years ago, the technical success of IoT will depend upon the smooth interconnection between the many small sensor networks of individually connected things to the big network of connected things that extended across industries and organizations. This inter-connectivity will involved both wired and wireless protocols and standards.

 

Once this system-level infrastructure is secure, then the business success of IoT will depend upon the free flow of information across all of these networks. But part of the business allure of IoT is the services that companies can charge, e.g., the sale of data. This business model that supports both the free flow of information and the sale of a portion of that information has yet to be developed.

Both of these challenges can – and will – be met, but not without dealing with complex issues on both the technical and business fronts of IoT.

 

Be sure to catch Dr. Rabaey’s update at this year’s IEEE IMS 2016 event: “The Human Intranet- Where Swarms and Humans Meet.”

Originally published on ChipEstimate.com "IP Insider"

ARM TechCon 2016 may be more than six months away, but time is of the essence.

 

ARM TechCon 2015 lecture session.jpg

The 2016 call for abstracts is now open until June 10. ARM TechCon is one of the industry’s premier technical events, attracting an engaged audience of engineers, developers and entrepreneurs hungry for information about technology trends, products and training.

 

For ARM partners, ARM TechCon, held this year at the Santa Clara Convention Center Oct. 25-27, is an effective channel to highlight the ARM ecosystem’s remarkable achievements and inspire future designs.

 

 

The conference welcomes presentations on design ideas, applications, design advancements, process improvements, or innovative products based on ARM technology. Here is the list of this year’s conference tracks and a link to additional details on each

 

  • Embedded Software Development
  • Silicon Design
  • Automotive, Industrial & Functional Safety
  • Graphics
  • Contextual Processing
  • Networking, Infrastructure & Servers
  • High-Efficiency Systems
  • Internet of Things
  • Trust & Security

 

The ARM TechCon 2016 Technical Program Committee reviews all submissions based on quality, relevance, impact, and originality. We hope to see your submission in the mix soon!

 

Click here to submit your abstract!

The 2015 ARM Student Design Contest India finale took place on 26th March 2016 at the International Institute of Information Technology (IIIT), Bangalore, with twenty five teams presenting their working prototype around the theme of Smart Transport Systems. These twenty five teams qualified for the finals from over a 100 teams that were present at the preliminary rounds at the Indian Institute of Technology (IIT), Madras in September 2015. Started in 2014 by the ARM University Program (AUP) in India, the 2015 edition of the contest in a sense provided energy and thought to the local Make-in-India and the Start-up-India initiatives to promote innovation and productivity.

 

Of the hundred and sixty seven proposals received online, the preliminary round at the Indian Institute of Technology (IIT) Madras saw a hundred and fifteen selected teams vying for the top twenty five positions to be able to make it to the finals. The jury panel consisted of a blend of academicians and industry experts (from OEMs, as well as manufacturers in the automotive space such as TVS Motor Company). The proposals were broadly classified into four categories, namely, traffic management, infrastructure, safety and emissions, and general categories. The preliminary round ended with the twenty five top teams being handed an ARM Cortex-M0+ based NXP / Freescale FRDM KL25Z based car kit each, so that they could develop a working prototype for demonstration at the finals. Each team was guided by a faculty mentor and participated in regular review meetings with the organizers (ACCS) and industry experts.

 

Img 1.jpg Img 4.jpg Img 2.jpgImg 5.jpg

The ARM Cortex-M0+ powered Freescale Car Kit

The first prize carrying a cash award of 100K INR went to a team from the National Institute of Technology (NIT) Hamirpur (adopter of AUP's education kit) for a Priority-based Traffic Management System. Using Radio-frequency identification (RFID) tags on vehicles and RFID readers at traffic signals, the system provides a seamless path to emergency services when an emergency service vehicle (tag) comes in the zone of an RFID reader. Additional features include theft and traffic-violation detection mechanisms that could potentially alert law and order agencies closest to a vehicle under observation.

 

The second prize with a cash award of 50K INR also went to a team from the National Institute of Technology (NIT) Hamirpur for designing a Smart Honking System. To tackle the ever-growing problem of unnecessary honking, the team developed an inter-vehicular communication system using RFID. With the RFID, when there is a need for honking, only vehicles within a specific pre-defined range are alerted with a request signal. The system features additional visual support for hearing impaired drivers, in-car infotainment controls that turn down sound volume, enabling a driver to be alerted to an incoming signal requesting path clearance for an emergency service vehicle.

 

The prototype of a child-alert system in parked vehicles put together by the team from Nitte Meenakshi Institute of Technology, Yelahanka (adopter of AUP's education kit), won the third prize carrying a cash award of 25K INR. The child-safety mechanism essentially monitors temperature and oxygen levels inside the passenger cabin of a parked car with a child/pet left inside. As a first level of security, the system alerts the driver of the car initially allowing enough time for the driver to return to the vehicle before anything untoward happens to the child/pet in the car. In case the driver does not respond to the initial system alert, then the system alerts emergency services to the rescue of the child/pet.

 

For a detailed coverage of the even you could visit our social media channels - Facebook and Twitter.

 

 

Second Place
WINNERS
Third Place
Img 9.jpgImg 10.jpgImg 7.jpg
Smart Honking SystemPriority based traffic Management SystemSystem for Child Safety in Parked Vehicles

 

 

Filter Blog

By date:
By tag:

More Like This