1 2 3 Previous Next


306 posts

Regular users of PSoC Creator probably already know about our useful Document Manager tool. We added this utility a couple of years ago and many users commented that it was really great for finding information and keeping tabs on your go-to PSoC documents. So we have taken the product to a new level.

This week we released a completely new version of the tool that supports all of the Cypress product lines. The search is much improved with filters for product, application, document type, and language (as well having access to a LOT more documents – over 60,000!). You can download local copies of web-based documents for off-line access. And you needn’t worry about them going out of date because the tool can check for updates at the press of a single button. And if this is not enough to find the information you want, there is a simple keyword Internet search.

Here is a screen shot of our fancy new GUI. You can see that we have 231 documents that match the keyword ARM in PSoC categories!


The Cypress Document Manager is available for download today and will also be distributed with the next release of PSoC Creator.

I often need to do a bit of programming – normally C or C++. I am not generally writing a real software application, as that is not my job, but I often need to produce chunks of code to illustrate a point in an article, presentation or blog post. This code can be anything from a single line to a few dozen. Obviously, all I need to do is create a text file for the code and build it using a suitable toolchain for execution on my PC or for inspection of the resulting assembly language output.

Recently, I was introduced to an interesting alternative …


Since I work for a company that supplies embedded software development tools, I have no shortage of compilers etc. And, of course, I will make use of these when the need arises. The problem is that I am intrinsically lazy and, if there are a just a few lines of code, I may not bother building/testing it. I just type the code into the article/slide/blog and hope that I have made no errors [or that, if there are, nobody will notice]. I am reasonably confident with C/C++ syntax, so I get away with this most of the time. However, I am not not totally immune to guilt and, particularly with electronic media, I would like to be 100% confident that I am providing my readers with [at least] syntactically correct code.

Just recently, my colleague Jon Roelofs drew my attention to a really interesting online tool: codepad.

To read the rest of this entry, visit the Colin Walls blog on Mentor Embedded.


Google's Project Ara, the so-called "Lego" smartphone architecture unveiled in April, means intriguing new design options and opportunity for IP providers in the near term and raises profound questions for open-source hardware in the long term.


If you missed the buzz, here's some background: Project Ara, which was initiated at Motorola Mobility, uses the MIPI Alliance UniPro and M-PHY protocols as the backbone for a modular electronics architecture inside a smartphone "endoskeleton." Using electro permanent magnets (they don't need a permanent charge to keep the bond), designers and consumers can affix various functional modules to build a customized smartphone--say one with special radios or more powerful imagers or other sensors.


Google Project Ara modules displayed

"Designs will have to be done modularly to work with the endoskeleton of the phone," said Arif Khan, product marketing director with Cadence. "Modules will need to play nice with each other, but if you can get it to work, the ideas and opportunities could be limitless."


MIPI UniPro is a multilayer protocol designed to enable the tunneling of multiple communications protocols within the system. Layer 1/1.5 include the M-PHY and PHY adapter; Layer 2, the data link layer for error correction, among other features; Layer 3 includes ID-based switching; Layer 4 is the transport layer interface to the application.


UniPro's Unique Opportunity

David Rutledge, chief technologist at Lattice whose FPGAs are being leveraged in the Project Ara Mobile Development Kit, as--among other things--the low-power programmable interface for UniPro, said:


"Project ARA is using (Lattice FPGAs) exactly as intended: high-speed communications of multiple protocols in an extremely low-power device. Ara is a good application of the technology, and it's exactly why UniPro was built. I think this is a major endorsement of the UniPro standard."


Khan said that for semiconductor makers, Project Ara will be about building chips that will be low power and work over the endoskeleton using the MIPI M-PHY and UniPro stack to communicate. At the same time, there is still the challenge of adapting the UniPort (UniPro + M-PHY) to be used with the adapter/connectors. However, beyond the use of UniPro for just the UFS and CSI-3 protocols, this is a great statement of the intended use for UniPro - a unified protocol bus, he added.


"Chip designers will need to understand the implications of using UniPro for system connectivity," he said. "As this is not widely used as yet, there will be a learning curve."


Some UniPro resources include:


Project Ara also raises intriguing design questions both near and long term.

Expanding IP Opportunity

On the IP front, it likely means renewed interest in MIPI and other IP, soft and hard, Khan said. If the module market takes off, the number of design starts will rise, potentially leading to increased IP consumption. "IP makers will renew their commitment to the mobile chip space with increased emphasis on low-power designs and technology," he added.


On the hardware front, consider the role of either an FPGA or an ASIC as part of the design. Paul Eremenko, head of Project Ara, who spoke at the developers conference April 15, described two variants his team examined, one design FPGA-based, the other ASIC-based.


Using the Motorola RAZR MAXX HD as a baseline, Eremenko showed FPGA and ASICs variants that were larger in size, weight, and power consumption:



















"Taking that (design) to a custom variant, with custom ASICs, we can shrink the modularity penalty down to about a quarter of the size, weight, and power consumption as compared to a traditional tightly integrated device," Eremenko said.


Lattice's Rutledge, however, sees plenty of opportunity for makers of small-size, low-power FPGAs since each module contains a standard interface to the backplane:


"On one side is MIPI UniPro. On the other side is the module developer's playground. Who knows what they're going to want to do? It's a perfect place to allow people to innovate. It's an ideal opportunity for FPGAs."

Long-Term Implications

One of the most intriguing questions surrounding Project Ara is the notion of open hardware architectures, applied on a broader scale. Open hardware to date has largely been confined to the "Maker" market through platforms such as Arduino and Raspberry Pi.


Khan sees potential but also challenges:


"Open hardware implies that there is no phone maker per se but an endoskeleton maker and module makers. This might seem interesting, but system compatibility challenges remain. One of the issues in the Android world is the fragmentation of the OS and customization done to it by various OEMs."


He added that in an open hardware platform, engineers are going to have to consider module compatibility with the other devices throughout system and OS upgrades:


"Anyone who has run into device driver issues after OS upgrades on a Windows system will know how challenging that is. This may make the phone brand meaningless per se, but it's more than likely that a single phone maker may build an endoskeleton and a line of modules that are optimized to run with it."

Module Movement

The longer term implications of such an open hardware platform could be significant. Imagine, for example, the modularity philosophy ported to design in the Internet of Things or automotive design and so forth.


Lattice's Rutledge said we're seeing it already. A device teardown may identify a number of ICs in a given smartphone, but they're really modules, he said.


"They're pre-built systems in an SIP that provide dedicated functionality--WiFi, antenna management, or touchscreen management modules. People don't recognize that," he said.


"The module ecosystem is developing like the IP ecosystem, and over time different standards will evolve," Rutledge added.


Motorola's Project Ara allow people to build them own phone. Do you think it is a good idea?


Related stories:

--MIPI Protocols-Making Mobile Happen at MWC

-- Cadence Announces Verification IP for MIPI SoundWireTM and C-PHY

-- Whiteboard Wednesdays - How the MIPI Alliance Works to Enhance Mobile Devices

-- Mobile World Congress: It's (Almost) All About IP

Creating applications for the Internet of Things is surprisingly easy yet not without challenges. But don’t worry – you don’t have to go at it alone.


Are you ready to turn your ideas into an Internet of Things hardware-software reality? Here’s my simplified, friendly guide to building an IoT application, followed by a more detailed explanation of the ARM mbed.org development platform provided by Sam Grove, Staff Applications Engineer. -- JB

I. How to Make an IoT Application

Step 1. Bring your Passion

To play in the space, it’s best to have a desire to make something. Perhaps you've heard the sirens call to innovate - or you just like to tinker. Either way, you need to start with a passionate idea.

Step 2. Add Some Hardware

To play in the IoT world you’ll need a mix of hardware and software, but this isn't your dad’s pre-Internet transistor-resistor-capacitor component-based world. Today, you simply pick from an inexpensive (starting at $10) set of pre-configured hardware and begin coding.

Step 3. Jam and Compile Online

And by jamming I mean creating the software that brings your hardware to life. You’ll need some hardware experience, but not much. Naturally, all of the tools needed to create your software are free.

Step 4. Ask Questions

There is no way around it. Sooner or later, you’ll run into problems and that’s where an active, online community can make all the difference. This is especially true in today’s globally connected collaborative development team environments. So go out and make new friends while you fix those problems and say “Hello” to the world.

Step 5. Document or Perish

OK, this isn't academia. Still, you need to document your work. Or do you?


II. How to Make an IoT Application – The Rest of the Story

Step 1: Bring your Passion

This is just another way of saying to come with an idea.

Step 2: Add Some Hardware

Sam Grove.jpgGrove: There are all sorts of pre-configured hardware platforms on the ARM mbed.org site. Typically you start by looking for the performance you want based upon your requirements. The site allows you to select the requirements that are most important to you.  For $10, you can easily create a microcontroller based project with a 50MHz ARM processor. On-board connectivity options range from Bluetooth® to Ethernet or other separate component. The unique hardware comes from the competitive suppliers of the actual ARM-based microcontroller silicon, so they have incentives to keep the costs low.


Also, each one of the mbed boards has a mass storage device interface. Once compiled, you can drag and drop your application onto the board’s microcontroller. This means that you can develop embedded systems from anywhere with just a USB cable, a laptop and an Internet connection.

Blyler: Most IoT applications need some wired or wireless connectivity. How is that done in an mbed design?

Grove: Many of the hardware boards have built in wired (ethernet) and wireless (Bluetooth, WiFi and cellular) connectivity. If not, it can be added as a component, say a radio module. APIs are available to provide a common interface via a standard Berkeley Sockets Interface (BSD). That way, you can focus on writing your application – like pulling in libraries - instead of worrying about the transport mechanism. For example, if you need an ethernet connection, you just pull the library down into your program.

Blyler: What do you mean by components?

Grove: Components are the artifacts or modules that you need to make your design functional, e.g, sensors, radios, interfaces, etc. Typically, components are add-ons to the board and not part of the microcontroller system. You pick the components based upon your requirements and the base platform. The components come with all of the documentation, data sheets, and purchasing/buying information that you’ll need to get started.

Step 3. Jam and Compile Online

Grove: mbed is a free development platform. It doesn't cost the developer anything to set up an account or to use the software tools like the hosted integrated development environment (IDE) and online code compiler. You can write your code in a web browser, compile it and then download the binary result onto your hardware board.


(Click image to enlarge)


The mbed Software Development Kit (SDK) – the software package to develop applications – is native to all mbed projects or boards. When you create a new program, the SDK incorporates the needed dependencies for component libraries, device drivers and the like. That component will be compatible across all 20 or so platforms that have the required resources on the microcontroller to drive that peripheral or module.


The online IDE has all the revision control and collaboration tools that are expected for modern software development. Of course, you can export your project with Makefiles to any of the major off-line tool chains, e.g., GNU Compiler Collection (GCC).


(Click image to enlarge)

Blyler: Why work online?

Grover: The online development tools remove many of the configuration hurtles that typically trip up programmers, i.e., numerous compiler and linker options. The idea is to make the make code development extremely productive by encouraging developers to focus exclusively on writing code and using the collaboration tools.

Blyler: Does mbed support Java?

Grove: mbed is programmed in assembly, C or C++ languages. If you are coming from Java, then C/C++ concepts like constructs and object oriented programming should be fairly simple. Learning the syntax shouldn't be a huge learning curve, either. But without a run-time environment to handle memory allocations and usage will mean that Java programmers must appreciate the memory constructs of C.


We see an interesting trend from our events and workshops. Programmers that come from higher-level languages (like Java) and script-based text languages tend to jump feet first into embedded development. They are not afraid to dive in and focus on making API calls. They are less concerned about the nitty-gritty details of the microcontroller or the peripherals.

Step 4. Ask Questions

Blyler: Collaboration is seldom easy - but it is a necessity for larger project. How is collaboration handled on mbed?

Grove: It doesn't matter where your team is located. Actually, since we publish the schematics, anyone can make any of the boards from scratch to fit their size and shape requirements. So all of the team can have the same hardware, software development tools and project settings that allows them to work on different parts of the project. As the day goes on, people can continuously pull updates and changes from each other.

Blyler: How would your secret algorithm or code be protected?

Grove: There are multiple ways, even though the IDE is in the cloud it is not part of mbed.org. All of the code and changes that you do in the IDE are completely private, located in a totally separate work space. Only when you decide to publish do you need to decide who has access and permissions to your work. In a collaborative space, it will be up to the team to manage members and decide how they choose to do a development with their intellectual property (IP). Repositories hosted on mbed.org can be set as public, public(but unlisted) or private.

Blyler: What happens when you need help?

Grove: We have a very vibrant online community. Over 75% of the questions asked on the site are answered by other community members. There is a vibrant ecosystem of developers on the site daily, helping each other out and sharing knowledge about some of the work they are doing. The goal is to break down barriers to rapidly build an embedded project.

Step 5. Document or Perish

Blyler: Few people like to document their work. Does the mbed platform automate this task?

Grove: We try to encourage good practices, both in code and documentation. Many people get focused on little distractions like the number of code indention spaces or the use of paths instead of spaces and that’s why we provide an automatic code formatting button. With a single click, you can automatically format your work to mbed approved good coding and style practices (K&R style).


The same approach is used in the generation of documentation. By inserting a couple of extra hash lines or symbols before and after your comments in your code, you’ll be able to generate some nice HTML, linkable documentation. For example, if you write a library and want to include a link to a datasheet, then the tool will automatically generate an HTML document. This way, when other people look at your code, they don’t have to get into your source to see what it is doing.


Another benefit of documentation is dependency tracking. On the public site, you can track the source of code published by others. You can find out if the code has been forked/sourced from another project and how many dependencies it has. That way you can follow the dependency tree or follow the fork history to find the original piece of code. This will help you determine whose code is best to use. For example, let’s say you’re trying to figure out whether to use John’s or Sam’s code. It may be that John’s code is a fork of Sam’s code, so you decide to look at the revision history. Since everything is under version control, you would see that John wrote a note concerning bug fixes, bus overflow, etc. You would actually see the “diff” of what lines of code have changed. From this, you’d quickly realize that Sam did a quick and dirty job to get something working but maybe didn't write as many tests as he should have to make sure his code was robust.

Blyler: That’s raises another point, namely, the availability of test suites.

Grove: We are working to bring that capability to the mbed site. Look for continued progress in the future.

Blyler: Thank you.

As I have talked about before, I am particularly interested in programming languages, with a strong focus on embedded, of course. So, I always take a look when I see a survey that looks at what developers are using and what the trends are. When I saw that the IEEE were publishing some results, they really had my attention.

However, all was not what it seems …

The IEEE results may be viewed interactively here. If you filter on Embedded [by clicking on the other categories to exclude them], then show Show Extended Ranking, the ranking order is like this:

  1. C
  2. C++
  3. Assembly
  4. Arduino
  5. D
  6. Haskell
  7. VHDL
  8. Verilog
  9. Erlang
  10. Ada
  11. TCL
  12. Ladder Logic
  13. Forth

The top of the list is fine. C/C++ are dominant and assembly matters. Arduino is essentially C/C++ like. Later on there is Ada, Erlang and Forth – I am OK with those. But then there are so many anomalies...

To read the rest of this entry, visit the Colin Walls blog via Mentor Embedded.

Another programming language survey – what are you using  « The Colin Walls Blog.png

I have made a number of recent postings focused on C++ issues, responding to a number of questions. I have a few more planned, but I was intending to give this topic a rest for a while. However, my eye was caught by one question, which I felt had some potential:

I learned that Objective C objects are not complete copies of the class object. In other words, only the data and certain static structures are independent for each instance of a class. The methods are kept in a central location for all objects to use. Is there any C++ implementation for embedded systems that use this feature?

This sounds simple, but this question raises quite a few issues …

First off, Objective C is of limited interest to embedded developers. So a comparison with C++ may be of limited value.

In C++, there is no such thing as a “class object” really. A class [or a struct] is a “recipe” to make objects. Defining a class/struct does not create any code or data. Instantiating the class – i.e. defining objects [or variables, if you prefer] – is when real code and data is created/allocated. It is at that point that some discussion about memory usage makes sense. Here is a simple class definition:

To read the rest of this entry, visit the Colin Walls blog on Mentor Embedded.


Hello ARM community!


This one is my very first blog post in here and I want to share a project I have been working on: a weather station/datalogger reading temperature, humidity and light levels from the surroundings and saving it all inside a microSD card. But before I start I would like to thank Mr. Brad Nemire for inviting me to share my experiences in here. I have been writing and sharing my projects in my personal blog here and in my twitter @ClovisDuino; so if you want to stay always up-to-date with my maker adventures, check those out!


The idea of this weather station came from my need to test my recently-acquired Freescale FRDM-K64F (ARM Cortex-M4) development board; I really wanted to put my Arduino aside and start using the all-new and modern ARM processor. The components I had available were 1x DHT11 (serial temperature and humidity sensor), 1x LM35 (linear temperature sensor from Texas Instruments), some LDR's (Light dependent resistor), 1x 8GB microSDHC card and a DS1302 timekeeping chip from Maxim. What really jump-started my coding was that every component I cited above already have a ready-to-use library on the mBed website. So it was easy to start adapting code for my project.


You can have a look at the preliminar schematics in the sketch below, featuring all the components  cited above. Both the LM35 and LDR are connected to analog inputs of my board, while the DS1302 and DHT11 are connected to GPIO (which I defined in the firmware). You can find my code (the preliminary version) in this Github link.




Since we are talking about a weather monitor there was no need to "rush" in terms of data acquisition, so I decided to save one complete set of data every 10 seconds only. It is enough to capture beautiful and nice data sets as the one seen below (for temperature inside my room). All that data is saved into a '.CSV' file, which makes it spreadsheet-readable and MATLAB by MathWorks friendly as well.




I am already working on a second version of my project, that will feature pressure and rain sensing (to come this August). If you wish to keep updated on this and more projects of mine, just go to Embedded Clovis, of course there is an entire post about this project in there; have fun coding, hacking and designing on an ARM!.

Kickstarter is quite the phenomena nowadays and I love stumbling across projects that incorporate the ARM architecture. oort is one that recently caught my eye as I was searching Prefundia, a new website that showcases projects about to launch on Kickstarter or other crowdfunding websites, and I knew right away it would be one of the few that would successfully surpass their funding goal.


And...what do you know, they just topped their $100,000 goal with less than three days to go in their campaign. Congratulations to the oort team! There is still time to back their Kickstarter project before they begin production.


I had the opportunity to ask their CTO "tech guru" Adam Handzlik a few questions about oort.




What’s oort?

oort is a system of intelligent connected devices that lets users control their whole living environment with a single app on iOS or Android. It is the first complete, universal wireless Bluetooth Smart / iBeacon smart home solution and powers wireless communications for a wide range of devices – beacons, lights and power strips, among others – regardless of manufacturer.


What’s the difference between oort and similar products?

oort lets users build their own IoT system. They decide which devices to purchase and aren’t restricted to one device manufacturer. Although the hub is necessary when you want wireless connectivity to your home devices, it isn’t required if you’re in close proximity because every device can be controlled via Bluetooth Smart. Moreover, everything is controlled with a single app that is available for iOS or Android.


oort Hub works with any Bluetooth Smart compatible device, regardless of the manufacturer. Competitors offerings rely on protocols such as ZigBee or Z-Wave to pair products with compatible devices, which ultimately reduces how many devices can work with their systems.


Can multiple phones be connected to the oort hub at one time?

Yes, an entire family using different mobile devices can connect to the oort Hub. They can even connect via web browser. Of course, you’ll have to figure out the logistics in your own family when one sibling decides the lights need to be really bright and the radio really loud and another wants just the opposite.


What type of analytics and data will oort provide?

oort will provide data to users from any device or sensors connected to their personal oort Hub. Our vision is to enable users to analyze every detail of their environment for limitless potential to dive deeply into their devices’ data to keep making their home smarter.


What was one of the biggest challenges you had in the creation of oort?

Our biggest challenge was deciding what to develop first. There are so many possibilities with the IoT that almost every day the team thinks of new product ideas comes to minds. Eventually we had to make a choice and narrow down the starting point for our IoT adventure.


What use case is oort solving?

oort is for people who want to build their own wireless smart home or business, but don’t want to have to use a different app to control each device individually. Imagine being able to use a phone or wearable device as a remote control for everything in a house or office. We knew that because we were designing a system for everyone to use, it had to be both easy to set up and affordable. Pairing takes minutes and it is easy for people to start building their own connected custom smart home ecosystems with their hubs.


What’s inside oort?

Most of our connected devices use chipsets equipped with ARM Cortex-M0 processing core which controls BLE transceiver on one hand and multiple sensors on the other hand. In most cases this ARM microcontroller offers sufficient processing power while the system power consumption is minimal.


oort hub is a bit different. For it, we use  ARM Cortex-A9 core which is powerful and has a lot of interfaces. Hub offers wireless connectivity (BLE and WiFi) in normal operation but we still use Ethernet, USB and UART communication interfaces for programming and testing as well as SD for data storage.


As a developer, what was your first project?

My first project was one I was really proud of, it was an electronic music synthesizer. It was quite complex and sounded like a true Moog synthesizer. I was a teenager still discovering new areas of electronics.


Tip for a beginner developer?

Talk about your ideas a lot and make lots of prototypes.


What is something about yourself that many don’t know?

If I wasn’t an electronic engineer, I would become a musician. My next connected device will be an audio vacuum tube amplifier with BLE monitoring and control – the first connected vacuum tube audio amplifier on the market.

Sensors Expo Pre-Con.jpg

The morning started with a big surprise, my laptop died as I was beginning to load all of the presentations to a flash stick and you can imagine the dismay as I tried to coax the machine back to life. No such luck. I realized there was not much I could do, but rely on my trusty smartphone and began calling and texting all of the speakers to show up early with their presentations and then I finally located a backup laptop for the day’s event.


Despite the bad luck, it was a great symposia!


I want to share some of my final thoughts from each of the presenters.


  • Vestec's Mark Majewski discussed the possibilities of “voice” as the next great user interface after the age of “touch."  He even introduced an on-line tool that enables you to design your own voice recognition system, he called it SLIC which stands for Speech Lab In the Cloud


  • UURMI’s Shanti Swarup talked about computer vision, and said “we are drowning in data, but starving for information." Image processing can also apply to IoT, but the key is to extract meaning or intelligence from a 2D image.


  • ARM’s Drew Barbier showcased mbed, a rapid prototyping platform which is ideal to help create your IoT device by leveraging open source to connect, collaborate and create.


  • Novati Technologies’ David Anderson highlighted that Moore’s law was about miniaturization, but the term “more than Moore," was the concept of how sensing, MEMS, and other analog technologies provided diversification of solutions and innovating packaging technologies such as die on die, or die on interposer, could help with system integration where the process technologies do not allow for a monolithic silicon solution.


  • Logic PD’s Scott Nelson provided a 'new age' look at the classic 'buy vs. make' question. He highlighted one of the key challenges to developing a system approach to evaluate buy vs. make for IoT is “where to compute?”  IoT devices can compute at the sensor device level, the networking gateway, in the cloud or enterprise, and lastly at the user (Smartphone or tablet device) - no wonder this IoT thing is so complicated.


  • Panel discussion on IoT Trends, Blockers, Enablers: As a moderator, I typically get nervous about panel discussions since I don’t want to be the one asking all of the questions. The good news was the audience was into it and majority of the questions came from the audience. We didn’t get a wild debate between the panelists, but we did get some excellent questions. Unfortunately, I did not take any notes, so you had to be there to capture any insights. A big thank you to all of the participants who asked questions, and also to the panelists - Kevin Shaw (Sensor Platforms), Zach Shelby (ARM), Magnus Pederson (Atmel), Mike Stanley (Freescale), and Milan Raj (MC10).


MC10 baby.png

  • MC10’s Milan Raj spoke on wearables and shared how his company was making electronics flexible, thin, and stretchable.


  • Freescale’s Mike Stanley went through a use case of using vibration monitoring for Condition Based Maintenance - truly amazing what you can do with an accelerometer and some software! It is an absolute no brainer the industrial use case for IoT to do either prognostics health management systems or condition based maintenance can save millions of dollars a day in down time for heavy equipment.


  • Atmel’s Adrian Woolley provided some IoT insight that “contextual computing will be the driving force behind the next wave of new technologies." He shared how fusion of data has changed the simple device like a pedometer from a step counter to an activity monitor and health coach.


Zach Shelby.jpg


  • ARM’s Zach Shelby educated on how IoT is really about the internet, the evolution of M2M to IoT, and what standards and organizations will be critical to enabling this, such as the IPSO Alliance, web objects and web protocols.


  • Sensor Platform’s Kevin Shaw highlighted how IoT devices are very much about how smart sensors are enabling devices to service humans, which means evolving from sending data to sending understanding.


Our goal of the symposia was to help provide more insight into the IoT market, and provide critical knowledge to help companies develop the business models of tomorrow that create value from connected devices over the internet such as software as a service. If you attended the symposia you had the opportunity to listen to some tremendous speakers and gained a wealth of knowledge from industry experts. ARM is certainly at the center of the IoT as we provide the scalable computing capability from the sensor to servers, as well as a broad ecosystem that will help enable developers.


Sensors Expo 2015 will be in Long Beach, CA on June 9th and June 11th - so start your planning and join us at the ARM hosted Pre-Conference Symposium on IoT.

Another interesting blog by Steve Nelson of Freescale  (I was bummed to miss IoT World a few weeks ago!  Lots of interesting discussion.)  The Embedded Beat: The Five S’s of IoT | Freescale Community


A familiar debate in Silicon Valley.  Do we look to the technology leaders/ early adapters/ outliers as the ones who will create the market?  FiveSsofIoT.jpgWhile I agree that many of these early adopters aren't 'normal' and won't create 'the' market, I do believe that it's from these behaviors that comes out which apps/ behaviors are going to be most readily adopted.  Or to phrase it a different way, it takes the early adopters to be able to teach their Mom how to use the device.  The early adopters also have lots of experience with what works when they try to explain the new devices/ apps to the 'normal' people.  I think these early adopters will help to define and drive these 5 Ss.



It is for Boardcon Idea6410 SBC

1.1 Notes

1 please use standard SD card, within 2G Bytes, suggest selecting 1G/2G Kingston or Sandisk's genuine card.


2 Please via the USB card reader to write SDboot to SD card, try not to use the built-in notebook card reader; there are some built-in notebook SD card readers which can not write properly, even if successful to write, it will not boot correctly.




1.2 Steps

1 Insert SD card to USB card reader, and format the SD card to FAT32 in WindowsXP / Win7.






2 Open moviNAND_Fusing_Tool.exe in Windows XP / Win7.


3 Write SDboot.bin to SD card.

At the place of “SD/MMC Driver”, select the SD card’s mapped disc path in Windows XP

click “Browse” at the place of “Image fileadd SDboot.bin

Click “START


It will pop-up "Fusing image done" if successful to write, then click "OK" to finish the programming.

Notice: After successful programming, the written data can not be seen, and the capacity of the SD card does not change.


Idea6410 specifications:

SoC – ARM11 Samsung S3C6410, ARM1176JZF-S@up to 667MHz.

System Memory – 128MB Mobile DDR SDRAM, 266MHz, Samsung K4X51163PC

Storage – 256MB NAND Flash + SD/MMC card slot

Display 4.3″ / 7″ resistive touchscreen


  • Audio I/O (3.5mm audio jack)
  • 100M Ethernet interface (RJ45)
  • USB2.0 Host
  • USB2.0 OTG
  • UART(RS232/TTL)
  • Camera interface (2x10-pin header, supporting the mode of ITU-R 601/656 8bit)
  • 2x5-pin JTAG

Optional module: GPS, WIFI, Camera, USB Bluetooth,USB HUB+4x4 Matrix Keyboard and USB 3G Modem

Operating system: WinCE6.0, Linux2.6.28, Android2.3 and Ubuntu


Source: www.boardcon.com

Hackathons are created to be fun, but can have very serious purposes. The recent ARM-sponsored AT&T Public Safety Hackathon is a great example of this. AT&T Hackathons bring together developers, designers, marketers, and entrepreneurial types to launch projects and startups in just 24 hours. Attendees pitch ideas, form teams and build prototypes within that time period and guest judges help pick the winners. The best part is that many of these aspiring entrepreneurs continue the pursuit long after the weekend is over and strive to launch a business from the concept.


This time around, we focused on public safety related projects with the intent of looking at solutions that help first responders, as well as those in emergency situations. Projects revolved around mobile apps (not surprising), communication, AT&T's M2X Data Service (currently in beta) and included embedded solutions like Freescale Freedom boards.


The winning teams clearly communicated the problem and the solution. This was followed by a demo of the prototype that walked the audience through the solution. The judges assessed the potential of each team, provided candid feedback to the presenters and selected the winners. Awarded prizes include the Best AT&T M2X App ($500 to Team Stealth Saver).

Team Stealth Saver's Pitch - "Focusing on emergency auto-texting with voice command, our app sends an SMS, customized by the user, to an emergency contact number, which is also customized by the user. We use a custom voice recognition service that is able to run on the background with high-performance. Besides voice command, we also implement a motion command, so the emergency message could also be sent if a certain action (i.e., clap hands three times) occur.   After an emergency situation is detected, a user's real time location along with user's name will be sent to our AT&T M2X server every minute. So police and a user's family could track the user's location in real time."


Easy development tools, ARM's on-line compiler, and the on-site support were all this team needed to build something useful, practical, and focused on public safety. What are you going to hack today?

I am continuing to mine the rich vein of questions from my online C++ lectures, which I started two weeks ago. I am always pleased to receive questions about any aspect of embedded software by comment,email or through social media.

Another three questions to consider today …

I just wondering how the compiler and linker optimize C++ code. How do we compare the this optimization in different tool chains?

For the most part, a C++ compiler will just do the same kind of optimizations that all compilers do. Of course, if it is designed for embedded use, there will be fine control over those optimizations. A compiler does have the possibility to add some “hints” to help the linker. A linker, which is designed to optimize C++ utilization can do a number of things, for example:

  • elimination of redundant code where template instantiation has been done on a per translation unit basis
  • removal of unused out of line copies of inline functions
  • elimination of redundant copies of a base class subobject, when a class is based on multiple classes with a common base
  • on ARM EHABI, the exception handler table entries can be combined for adjacent functions whose unwind opcodes are the same; this can save quite a bit of space because most functions have very simple unwind opcode sequences, and a lot of them end up being the same

What would be the difference between C++ and C# ?

To read the rest of this entry, visit the Colin Walls blog on Mentor Embedded.

C     yet more Questions and Answers   Mentor Graphics.png

Microcontrollers have proliferated into every nook and cranny of our daily lives from simple 8-bit devices that control our toaster ovens to powerful 32-bit DSP’s that provide us with the rich media and entertainment that we have all become accustomed to. Without microcontrollers, our lives would not only be less exciting but we would lose a level of control over our world that we can no longer live without. Billions of microcontrollers are sold each year with the number continually climbing.


What happens to these microcontroller based products when millions of units have shipped and a software “enhancement” needs to be made? Does every unit need to be returned to the manufacturer every time the software is updated? Are televisions, blue-ray players and other devices returned to the manufacturer periodically so that the customer can continue to have the latest and greatest software operating on their device? The obvious answer to these questions is absolutely not and the primary reason why is that most systems ship with a boot-loader on-board.


A boot-loader is an application whose primary purpose is to allow a systems software to be updated without the use of specialized hardware such as a JTAG programmer. In certain cases, it can also be the earliest point at which the integrity of an embedded system can be checked. The boot-loader manages the systems images. There are many different sizes and flavors to embedded boot-loaders. They can communicate over a variety of protocols such as USART, CAN, I2C, Ethernet, USB and the list goes on for as many protocols that exist. Systems with boot-loaders have at least two program images coexisting on the same micro-controller and must include branch code that performs a check to see if an attempt to update software is in progress.


During the initial stages of product development it is very common for the boot-loader to be overlooked by the development team. The primary reason for this is that the boot-loader is not the primary end product that is going to be sold to the customer but the boot-loader is potentially the most important part of that product. The boot-loader allows a company to launch their product with software that only fulfills a portion of their final feature set and then add features to their product once it has been launched into the market. It also allows them to fix bugs that are discovered after the system has been released into the wild.


For an embedded software engineer, a boot-loader requires a full understanding of how a processor works, how to utilize its memory and how to work on the processor at the lowest levels. Boot-loader development can be an extremely challenging endeavor to undertake but absolutely a rewarding one. Once a developer has gone through the process, each additional boot-loader becomes easier and easier to implement by following a common and consistent approach to boot-loader design.


The purpose of this paper is to break down the components necessary to develop a boot-loader and present it in an easy to understand methodology that the reader can then use to implement their own boot-loader. While boot-loaders are small programs, they often bring out the worst and nastiest bugs that can be very intimidating to a developer. Not only does the programmer have to dig into flash programming but there is also a need to do a deep dive into memory maps, re-locatable vector tables, copy down functions, flash partitioning, code branching and a number of other tasks which can at first seem monumental and nearly impossible to overcome on a short development schedule.


To download and read the complete paper, “Bootloader Design for Microcontrollers in Embedded Systems”, visit http://beningo.com/index.php/design-articles/white-papers/122-bootloader-design-for-microcontrollers-in-embedded-systems.html



Jacob Beningo is an embedded systems consultant and lecturer who specializes in the design of resource constrained and low energy devices. He works with companies to decrease costs and time to market while maintaining a quality and robust product. He is an avid tweeter, a tip and trick guru, a homebrew connoisseur and a fan of pineapple!  Feel free to contact him at jacob@beningo.com or at his website www.beningo.com.

Avoiding M2M pitfalls will require an open, internet-based approach that decouples IoT devices from services. But what role will standards play?

In Part I of this interview, Zach Shelby, business development guru at ARM, discussed ways that the IoT developers could avoid the pitfalls of the M2M market; the key role played by start-ups in the IoT; and why permissionless innovation was important. In Part II, Shelby speaks directly to embedded developers to make a case for open systems with a modicum of key standards; decoupling of devices from services; and an IDE software development environment in the clouds. What follows is a portion of that interview. -- JB

Blyler: Previously, you talked about the preponderance of start-up applications that are just beginning to appear on the IoT landscape. This trend suggested the need for IoT standards. Why do standards matter?

Zach Shelby.png

Shelby:  One of the major growth inhibitors of the Machine-to-Machine (M2M) silo era was a lack of useful open standards. The M2M community did embrace the Internet but maintained silos for all other aspects of their business, e.g., services and such (see Figure 1). That’s why there was very little real growth in the M2M market and the growth that emerged was linear. M2M remains primarily an enterprise application business for car tracking, vending machine, etc.


Figure 1: Traditionally, M2M worked in silos when accessing the Internet.

One of the major reasons for the limited growth of M2M was a lack of real open standards. This lack hindered the creation of a new value chain of relationships because the technology didn’t allow for it. This time, for IoT, we need to provide standards that allow businesses (startups) to create devices that are decoupled from services.

Blyler: Why must IoT devices be separated from services?

Shelby:  It is a proven approach, one that worked well on the Internet and the web. Any web-browser in the world works on any web server, thanks to a few basic HTTP, HTML and image standards. The reason for this success is that web-browsers applications were decoupled from the Internet services. By contrast, AOL and CompuServe were non-standard, proprietary ways to use the services of the internet - that was like the M2M days.

Today’s emerging IoT standards must enable the same kind of decoupling of devices from services. The goal is not to break down every value chain. We don’t want to commoditize (cheapen) all devices and make all the services generic. Rather, devices and services need to be decoupled from a technology perspective. Of course, a given service provider may bundle a cool sensor device with a free service that can only be used with that provider. There will always be these business (promotional) constraints. The point is that, from a technology point of view, the devices/apps should not be tied to the services. That will eliminate the costly need to completely redesign the technology for each company’s service.

Blyler: What standards are needed to help decouple IoT devices from services?

Shelby: At Sensinode, and now at ARM - we’ve made sure that there are Internet Protocol (IP) networks available to do this. 6LoWPAN is an example of one of those standards. [Editor’s note: 6LoWPAN is an acronym of IPv6 over Low power Wireless Personal Area Networks.] This standard ensures that any low power radio can speak to the Internet. That ensures that existing and newer low power radios can talk to the Internet, e.g., 804.15.4, Bluetooth low energy (see Dave Bursky’s article), Z-Wave and DECT Ultra Low Energy. The last two are interesting:  Z-Wave is a wireless communications protocol designed for home automation, specifically to remotely control applications in residential and light commercial environments. Conversely, DECT Ultra Low Energy is an older standard that was originally developed for business phones- it is based on old DECT chip architectures.

Blyler: How does 6LoWPAN relate to the existing ZigBee standard?

Shelby: The original ZigBee standard was designed like an automated local bus. 6LoWPAN interfaces to ZigBee when a bus is needed, but extends ZigBee with a low-power interface to the internet. Even the ZigBee Alliance has come on-board by offering standardize 6LoWPAN protocol stacks for 4G, called ZigBee IP (see Figure 2). There is another adoption called ZigBee NAN (neighborhood area network), which is a 6LowPAN stack for outdoor use – sub-gigahertz, for very long range applications. It’s for street lighting and smart meeting applications and we will see some other really exciting things that will be announced later this year.



Figure 2: The low power, Internet 6LowPAN standard interfaces with many other protocols.

Blyler: At a physical level (PHY), a low-power connection to the internet seems critical for the evolution of IoT devices. Don’t you also need to provide an associated low-power mechanism at the protocol level (MAC)?

Shelby: Yes, the physical connection is important, but it's one piece of the standards puzzle for IoT. You also need a very efficient, low-power binary web protocol for the internet - that’s why we created a low overhead version of the web protocol called the Constrained Application Protocol (CoAP). [Editor’s Note: CoAP is an application layer protocol that is intended for use in resource-constrained internet devices such as small low-power sensors, switches, valves and similar components that need to be controlled or supervised remotely, through standard internet networks. (see Figure 3)]


Figure 3: CoAP runs on most devices that support the standard User Datagram Protocol (UDP) Internet protocol, which enables computer applications to communicate via the Internet.

The current HTTP Internet protocol is great, but has a large overhead. The M2M community addressed this issue with a proprietary binary protocol. It was the “silo” game again, i.e. always creating a new proprietary thing to address each new problem. To avoid creating these custom protocols every time a new system was needed, we (at Sensinode and ARM) focused on the open CoAP standard.

One the security side, we’ve also helped make the existing TLS-based security standard more efficient for IoT applications. Further, we’ve brought in a device management standard to make devices useable in IoT services. Such a standard helps to decouple the device from the service - that standard is called Open Mobile Alliance (OMA) Lightweight M2M. There is also a OMA-Device Management (DM) standard for low-power IoT cellular devices (see Figure 4).


Figure 4: CoAP is central to many other IoT standards.

Blyler: Why is device management important?

Shelby: Device management is needed to manage these devices remotely. For example, cellular device management is used to configure the phone and upload all the operator settings - most users don’t even notice it. This process will be very similar for IoT devices, i.e. getting the device configured for the needed services.

Device management is also needed to secure devices and configure who’s allowed to use the device. When a device gets older, it often goes without needed software and firmware updates. These issues are addressed by the Open Mobile Alliance (OMA) Lightweight standard.

Blyler: How are ARM and the Sensinode group engaged with these standard bodies?

Shelby: We participate in these standards with the ARM ecosystem partners or with a bigger industry group. For example, we are working with the core internet standards body – the Internet Engineering Task Force (IETF). On the device management side, we work with all the operators, telco vendors, and such via the Open Mobile Alliance (OMA). For IoT device semantics, we participate at the IP Smart Object (IPSO) Alliance.


The IoT community now has a good set of standards in place. Now the challenge is how to make these things easily available for developers who are building IoT devices for the marketplace.

Developers have many questions. For example, how will a device work with services? How do you find service and cloud software that works with the devices? Where does one find a service provider to host a device? These are all the kinds of questions we have to solve for the developer.

Blyler: Does this mean that ARM plans to offer technologies or services to address all of these issues?

Shelby: ARM can not do everything. Instead, we focus on the device ecosystem and enabling the cloud. mbed is a web-based development environment for Cortex-M designers. It has a directory-like structure that contains all your projects. GitHub is integrated so you can share projects. A designer simply selects an mbed-supported device from one of 20 or so platforms, secures an online account, imports a project and compiles that project. We supply a free commercial compiler. The end result is an executable binary that is downloaded to the flash drive of the device.

This cloud-based IDE approach is revolutionizing the way people think about embedded development. Compare this cloud-based approach to embedded development of the last decade. Then, the designer needed a specialized compiler that cost anywhere from $5k to $15k. Further, the necessary hardware – e.g. a flashing tool, a JTAG interface and a debugger - were typically locked onto one dedicated PC in the embedded lab.

Blyler: Earlier you talked about all of the open standards supported by ARM. How do those standards actually affect the embedded development process?

Shelby: We are starting to bring all of these open IoT-related standards to the mbed development platform, for the application layer (CoAP), security and device management standard support. There will be even more help in the future.

Blyler: Will most of the coding for future IoT designs be done in the C language?

Shelby: By various estimates, there are around 300 to 400,000 embedded C developers in the world today. Meanwhile, there are a million Java developers. Obviously, we need to make general development a lot easier. That is why we have been adding more support for Java-script on mbed. Look for Java ME support in the future. Our goal is to make IoT development via mbed easier for a larger range of people and start-ups. [Editor’s Note: Recall Shelby’s earlier comment that 80% of the actual value of the IoT will come from the software application.

Blyler: How will embedded developers incorporate cloud-based services into their device designs?

Shelby: In the past M2M siloed world, developers would have had special servers created and hosted in their own data center or on a cloud server. There was no decoupling of devices.

For IoT, we favor the approach proven by the Internet model where designers build web services out of the web infrastructure. For embedded development, designers can go to an ISP provider to get a web server. Similarly, to access a cloud-based infrastructure, designers can go to Amazon, Rackspace and the like for cloud hosting and related services like load balancers, database applications, etc. Of course designers still need to develop their actual web pages and functionality, business logic, etc - but the base infrastructure is there.



Filter Blog

By date:
By tag: