1 2 3 Previous Next


296 posts

This week is the first, for me, of the major conferences in the embedded software space this Fall – the ARM TechCon. As usual, it takes place at the Santa Clara Convention Center in California. And, as usual, I will be attending.

The exhibition runs over two days: Wednesday and Thursday. I will be at the Mentor Graphics booth [#201] for most of the day on Thursday. So, if you want to stop by and say hello, you will be most welcome.

The conference continues on to Friday, when I have a paper at 2:30 entitled How to Measure RTOS Performance. If you are attending the event, do come along. If you want a copy of my slides or have any queries, please email.

A complete guide to the Mentor Graphics participation in ARM TechCon may be found here.

ARM are running an interesting activity at the show, in which sponsoring companies [like Mentor Graphics] have been invited to participate. A representative of each company will be provided with a FitBit movement tracker and real time logs of these people’s number of steps will be on display at the RAM booth. There are prizes for the most energetic. It seems that I was nominated to represent Mentor Graphics. Wish me luck!

I will be reporting and commenting during ARM TechCon on the major social media channels [links on my blog homepage]. If you have any questions or comments, do get in touch. Find me on Twitter: Colin Walls (@colin_walls) | Twitter

ARM TechCon is upon us again! And despite all the prep work we collectively put into it, the big industry event arrives faster than we always expect.


This year's edition is going to be busy. My colleague, Richard Goering, and I will be covering it from beginning to end. And our colleagues on the Cadence team will be working nonstop at the company's demo pods and in an excellent array of training sessions.


Goering has posted a handy guide to what's not to miss at ARM TechCon 2014 already. Frank Schirrmeister, who I swear never sleeps he's working so much, has posted his own guide to the major issues we'll address (think verification, low-power design, mixed-signal trends) during the event as well as key Cadence training sessions:  Getting a Glimpse at the Future Early – Cadence & ARM at ARM TechCon 2014!


And lastly, ARM TechCon 2014 marks the return of the celebrated ARM Step Challenge. Wearable Fitness Step Challenge Returns for ARM TechCon 2014. I'm honored to carry the Cadence banner for the second time this year. During the DAC challenge, I was lucky enough (oh, ok, I walked my butt off!) to make to the medals podium. The Aftermath of the ARM Step Challenge at DAC. This time around the competition is much broader (John Heinlein and Phil Dworsky, I'm still gunning for you!) and I don't have the luxury of being able to walk from home to the Santa Clara Convention Center (well, I could but it would take 14 hours each way).


So we'll see you at ARM TechCon and watch for updates here on the Connected Community!

ARM TechCon is just around the corner! We've been working on a fun developer workshop combining mbed and android (see here: Software Developers Workshop | ARM TechCon 2014). I've been testing the set-up this week and if you enjoy coding and playing with peripherals our workshop is going to be the place to be! If you are already signed up I'm looking forward to seeing you there! By now you should have been sent an email on your set up. Here is a step-by-step if you have never worked with mbed or Android before:


Set up of mbed side:


Setting up Eclipse:


Uploading to device:


Setting up app: Go to settings

  • Change server address to ansonworks.com
  • CoAP port: 26395
  • REST port: 24198
  • Domain should remain as domain
  • End point id is cop-0102 (or whatever name that pleases you)
  • Turn on MDS
  • Go back to main app
  • Connect to mbed BLE (mbed should be plugged in and running. It's working if LED1 has a little heart beat flashing)







If you have any difficulties with the environment or any general questions feel free to message me and I will help you get up and running.


If not you can still register for the rest of the conference here: ARM TechCon Passes & Pricing | ARM TechCon 2014.



Nordic Semiconductor android_development Rod Crawford Desiree Joplin Matthew Du Puy Sam Grove Michael Koster

Random HW failures due to radiation strikes occur once every 100,000 odd hours per chip. Divide that by the number of hours we all drive our cars and the likelihood of some failure becomes real.

At ARM TechCon 2014, Joseph Yiu and I will be talking about features in the ARM Cortex-M processors that help mitigate these risks and enables building robust systems.


Please join us at: Session: Utilizing Features in a Cortex-M Processor to Create Robust Systems

Registration: Embedded Systems Week (ESWEEK) 2014

Venue: Jaypee Greens Golf & Spa Resort Greater Noida

Date & Time: 8 AM - 5 PM, Sunday, October 12th 2014


Note: Free Workshop Attendance for 20 faculty folk who have registered for ESWEEK 2014 (First come first serve).

Contact university@arm.com by Oct 1, 2014, with your ESWEEK 2014 Registration Details using your Official university/college Email ID.

The ARM University Program will conduct a faculty workshop around its flagship Lab-in-a-Box (LiB) based on the ARM Cortex-M0+ Freedom Board. This LiB targets courses on microprocessors and embedded systems and is part of our ongoing commitment to share ARM technology with academia globally. The LiB has been designed with academics in mind and will allow participants to gain first hand experience on how to teach the material in their own courses. The workshop will cover topics such as: interfacing with a microcontroller, memory mapped I/O register calls, code reuse to speed up system design and understanding various power modes.

Workshop Agenda:

  • Introduction to ARM Cortex-M0+ based KL25Z MCU on the Freedom Board
  • Setting up the board to work with Keil MDK-ARM software suite.
  • "Hello World" using the on-board RGB LED.
  • Spirit-level simulation using the on-board 3-axis accelerometer.
  • Proximity sensing using an IR LED and a photo-transistor.
  • Making power and energy measurements using an ultra capacitor.


  • Faculty attendees must come with their own laptops already installed with Keil MDK-ARM. This can be downloaded at Keil MDK-ARM.
  • Knowledge of embedded system design and experience in programming microcontrollers will be helpful.
  • Attendees are expected to make their own travel and stay arrangements.


If you require any further information please write to university@arm.com. We look forward to seeing you on the 12th of October!


Kickstarter at TechCon

Come and see my talk with Kickstarter at ARM TechCon next week. With over 1,800 technology Kickstarters successfully funded and ARM technology in many of them (you may remember Oculus VR: from Kickstarter to $2 billion...), I'm pretty excited to be talking with Nick Yulman of Kickstarter on Thursday, 2 October 12.30pm. Session: Kickstarter and ARM It's All About Opportunities


MakerCon New York 2014

Last week I had the privilege of speaking at MakerCon New York. MakerCon is by and for entrepreneurs, educators and start-ups emerging from the Maker Movement. I got to see some great talks including those from co-founder of Arduino, Massimo Banzi and also Raspberry Pi's head of hardware James Adams. If you're interested, you can even hear my perspective on how accessible technology is changing the Internet of Things in the talk I gave (below). Pity the Cortex-M7 was still under wraps at this point!

As you will see, I had fun comparing the Apollo Guidance Computer to a Cortex-M microcontroller...



There are few things worse than that sinking feeling in the pit of ones stomach when a prototype or production intent system is tested and lone and behold it is discovered that the battery life is far less than what is required.  Either through oversights in the design, size constraints, a rapid development cycle or any number of other circumstances the product and potentially the company is at risk of having nothing to sell.  Thankfully there are a number of embedded software techniques that can be used to help minimize the energy consumption of a microcontroller based system.

Before getting too far into the details of how to minimize power or how to analyze how much power the system uses, it is important to understand that in most low power systems, the microcontroller not only is one of the larger power consuming devices but also has the most flexibility to control how much energy it uses and even to some extent how other on-board devices use energy.  There are two primary types of power consumption within a microcontroller, static and dynamic.  Dynamic power is directly related to what the microcontroller is doing, switching ports, talking over USB, reading sensors, etc.  Static power on the other hand is the power that is used even if the microcontroller is placed into sleep mode, stops talking and is idle. 

Static power is inherent to the microcontroller manufacturing process and there is very little that can be done to affect it.  It is essentially the bottom baseline of energy consumption of the microcontroller which leaves the developer with only the dynamic power consumption to focus on.  Luckily, there is quite a bit that can be done in this area to minimize power consumption. 

First, effective use of sleep modes is absolutely critical.  Every microcontroller has at least three levels of operational modes, Run, Stop and Sleep.  An example of some sleep modes can be seen in Figure 1.  Advanced microcontrollers such as the ARM Cortex-M parts often have additional sub layers that include low-leakage power modes. The sleep modes start out being relatively straight forward to enter into and exit from but the most superficial of them save very little power.  The significant power savings comes from entering into the low leakage sleep modes but configuring them can be complex.  Understanding how to transition between them, how wake-up times affect the applications real-time performance and many other factors can make development interesting.




Figure 1 – Example Power Modes

Second, there are really exciting architecture related techniques that can be used to help a developer maximize the amount of time that is spent in a low power mode. For example, the use of Wait for Interrupt (WFI) can put the system to sleep until an interrupt fires and wakes the system up.  Another useful technique is using sleep on exit which forces the microcontroller into sleep mode immediately at the end of the interrupt service routine (ISR). This saves the ISR overhead from having to be executed on wake-up and power down, saving precious computing cycles that could have been spent in a low power state. 

Third, there are system level techniques such as using autonomous intelligent peripherals that can be configured to perform work on their own without the interaction of the CPU.  UARTs, Direct Memory Access (DMA) controllers and another of other peripherals are picking up the work load and only waking the power hungry core when it is necessary. Even then, using clock throttling strategies can also help minimize the power used by the system. 

These are just a few of the tools that are available to developers as they try to tame their systems and squeeze every milliamp hour possible out of their batteries. A great way to begin the journey of understanding how to use the ARM Cortex-M processor Cortex-M processor in a battery operated environment is to attend “Squeezing the most out of battery-life using the ARM® Cortex®-M Processors” at ARM TechCon on Friday October 3rd at 10:30. 

In the session, attendees with learn how to configure a Freescale Kinetis-L Freedom Board with an ARM Cortex-M0+ core, create a power mode API that utilizes the various power modes, in addition to learning about additional techniques that can be used to lower microcontroller energy usage.  The session will examine real world techniques and examples so that engineers can walk away with strategies that can be implemented on their own development projects with little effort.

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

Once again, I am mining a backlog of interesting questions that came up during an online C++ class. Of course, as is inevitable, not all the questions are about [or at least specific to] C++…

What is the idea behind the provision of multiple constructors for a class?

A constructor is a function that is executed automatically when an instance of a class [an object] is created. It has the same name as the class itself. A constructor may optionally take one or more parameters, which are passed values in parentheses after the object name when it is declared. As with any function in C++, a constructor may be overloaded – there may be multiple variants with different combinations of parameters.

Imagine a class which handles angles in some way. Perhaps an object needs a starting angle. The value of an angle may be expressed in a number of ways – degrees/minutes/seconds and radians are the obvious options. So the class might look like this:

class angle_stuff { ... public: angle_stuff(float radians); angle_stuff(int degrees, int minutes=0, int seconds=0); ... }; 

One constructor handles radians and the other degrees etc. Note the use of default parameter values to provide further flexibility. So, possible object declarations are as follows:

angle_stuff first(3.141); // radians angle_stuff second(45, 30, 30); // degrees/minutes/seconds angle_stuff third(50, 11); // degrees/minutes angle_stuff fourth(90); // degrees

How does the double colon operator – :: – work?

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

Multiple constructors  the    operator and memory speed   more questions answered   Mentor Graphics.png

You can still purchase selectPSoC 4 silicon for $1.00 through the end of September. Cypress has been offering specially-created PSoC 4 part numbers from our Cypress Webstore or our catalog partner websites (Digikey, Mouser, Newark) for $1; however, this special ends in two weeks at the end of the month. The special promotion part numbers are listed below:PSoC_1Dollar.jpg


Promotion MPN Base MPN







Now is a great time to purchase your first PSoC 4 silicon for your prototype and accelerate your design to production.

This price is only valid through the specified catalog distributors. These special part numbers do not reflect in the Cypress Quoting System and cannot be quoted by any other distributor.

[re-posted from Cypress Developer Community]


The KickStarter campaign for the RPiSoC is about to end. If you're interested in the board go take a look at some of the videos and pledge a few bucks to get one.

RPiSoC is made by Embedit Electronics. It's a nifty, Cypress PSoC 5LP-based board that gives you easy access to lots of I/Os and is compatible with Arduino and Raspberry Pi. Hop over to the their KickStarter page to see some videos on cool things the inventors, Robert Barron and Brian Bradley, have already done with it. As far as I can tell, they give away all the source code for their projects so you can modify what they have done to your heart's content.


This weekend they were at the Maker Faire in New York, where they received a Maker Faire editors choice award! This is a really nice platform for PSoC development that is so much more than the hardware. Embedit have added support for Python and Scratch, and the board is pre-programmed with some seriously powerful analog functions than you will never find on other board like this.


Did I mention that you can sponsor them on KickStarter?


[Re-posted from Cypress Developer Community]

AN89610.pngI’ve been writing about memory optimization for a few weeks now, both here and on the Cypress developer community site. In all those posts I (hopefully) provide a useful tidbit of information but it’s not a forum for all the details, options and consequences of a given technique.


Some colleagues of mine published an Application Note discussing PSoC 4 and PSoC 5LP ARM Cortex Code Optimization and it is a fantastic resource for engineers looking to become proficient at writing embedded application on ARM devices, like PSoC.


Unlike my posts it covers performance optimization as well as code size concerns. It explains some good coding habits that ensure you get the results you want and really delves into the linker script options for both GNU compilers and the ARM MDK.



PSoC 5LP users should particularly benefit from the sections on bit-banding (which is only available on Cortex-M3) and Cypress DMA. There is also a great section on embedding assembler instructions and using compiler intrinsic for things like the Cortex-M3 saturation functions.

I could go on and on. I’ve been in embedded software for more years than I care to admit, and this document definitely clarified a couple of things for me. I highly recommend giving it a read. And keep it handy as a reference for when you need to get a little more from your toolchain.

About a week ago I wrote about how we try to respond to user feedback at Cypress. As a result of one such interaction we discovered that, with debugging enabled, the v4.8 GNU ARM compiler optimizes for code space far more efficiently than the prior versions. We’ll be updating the compiler in our next release.


Another thing that came out of our tests was that there is a new command-line flag, “-Og”. This flag turns on debugger-friendly optimizations so that the code size can be compressed even closer to the fully-optimized value, while still allowing the use of the debugger (debugging fully optimized code is worse than listening to Coldplay – believe me, it's really painful!). Re-running last week’s tests, I found that the new option brought the code size down from 36710 to just 23798 bytes, which is pretty close to the best case (all optimization enabled) of 21534! The work being done on Launchpad for this compiler toolchain is really yielding good results right now!


We’ll be starting an “early access” program for PSoC Creator 3.1 in a few days. You will be able to get a sneak peak at the new software a couple of months before it goes on general release. The main change is actually support for new PSoC devices (I’ll post more on those soon) but the new GNU ARM compiler is included and we’d love to hear from you about that.


The default GNU compiler remains v4.7 but you can choose the new one from the Build Settings (shown) and re-build to see the code size savings (note that this improvement is in the DEBUG mode, with most optimizations disabled). If you like the results you can also add the –Og flag and get even better code compression. And you will still be able to debug!


Please give this a try and let us know how you get on. I watch for comments here and you can email us directly on psoc_creator_feedback@cypress.com. Let us know what you think – good or bad – it all helps to make our software better.

It's that time again! It's what you've been waiting for all week (just kidding, I know better than that). This 'Friday Finding' isn't finger friendly, it's all thumbs! This week's question hails from the ARM Connected Community: Difference between thumb machine directives by techguyz. The question is:


"What is the key difference between the following directives







What is the exact use case where the above things can to be applied ?"


Let's take these one at a time:


1) .thumb

This directive is important when you want to tell the assembler to interpret instructions as Thumb (16-bit) as opposed to the 32-bit ARM instructions. This can also be done with the directive ".code 16" and is the same as a Thumb directive at the start of your source file. It is important for you to include either this directive or ".arm" / ".code 32" at the time of a branch or return: the processor doesn't automatically know which instruction set is used after a procedure call, a procedure return, or after a branch so it needs to be told ahead of time.

2) .thumb_func

The ".thumb_func" directive specifies that the following function is Thumb encoded and implies a ".thumb" directive. This declaration is necessary for the processor to allow the assembler and linker to generate correct code for inter-communication between Arm and Thumb instructions. Even if inter-working is not going to be performed for that particular case it should still be included or else you will have to set the least significant bit before branching which will add more code.

3) .force_thumb

The .force_thumb directive forces the processor to select of Thumb instructions regardless if the processor does not support thumb instructions. A use-case of this function is to switch the code to correct instruction set before a procedure return.

4) .thumb_set

The .thumb_set is the equivalent of calling the .set directive since it creates an alias symbol for another symbol. It also marks that alias as a thumb function in a similar way as the directive ".thumb_func". A good use of this directive is to provide weak aliases for exception handler to the default handler so any function with the exception name will override the default.


.weak SysTick_Handler

.thumb_set SysTick_Handler, Default_Handler



ARM Information Center

assembly - When are ELF directives needed? - Stack Overflow

Read my past 'Intern Inquiry' posts intern_inquiry

I have written before about multicore systems – here for example – and looked at AMP vs SMP and various other aspects of the technology. As the use of multicore designs has become increasingly mainstream, the options and possible configurations available has increased drastically.

A particular facet is the incorporation of a hypervisor in an AMP system …

All embedded systems have finite resources, which need to be managed. It may be argued that this is the crux of what embedded software development is all about. For the purposes of this discussion, I want to consider a hypothetical example system which has a single serial port. There are various ways that this port may be managed, depending on the configuration of software and CPU hardware.

On a single core system, the operating system can manage access to the serial port and arbitrate between multiple tasks that might wish to make use of it. There are lots of ways that this might be achieved and this is a well trodden path.

If the system has multiple, identical cores, it might be useful to configure it as SMP – a single operating system instance running across all the cores. SMP versions of many RTOS products [like Nucleus] are available and Linux with SMP support is also an option. This approach is ideal if the application benefits from the OS being able to distribute CPU power as needed. The OS can manage access to the serial port in much the same way as on a single core system.

On many systems SMP is unattractive, because more precise control is required or the system has so many cores that performance degradation is likely. On others, SMP is impossible, because the cores are not identical. In these cases, an AMP configuration, with a separate OS instance on each core, makes sense. This presents a challenge: how might the single serial port be managed?

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


A few years ago I was working as an embedded systems contractor for a small company that made chemical analyzers. The code was written in PALASM and involved a bunch of timers and if/then statements that controlled an autosampler(a rotating tray of test tubes with a needle that would lower to extract a sample, lift, and then move over to dispense the sample into an analyzer).  I remember thinking to myself how the same instructions were being used over and over again with increasingly cryptic numbers. What did all these numbers actually refer to in the context of this hardware?(job security)


A few years later, I started playing around with Arduino/Energia on embedded platforms and realized that all those cryptic numbers had been abstracted to describe the behavior of specific pins on a micro-controller. With these abstractions, what had previously taken me a week to understand could be understood(and modified) in a few hours!  I realized that these abstractions could enable anyone with a computer to become an embedded systems developer.  I decided to virtualize these abstractions over a wireless connection to a smartphone in an open source project "rekam1" - mirrorwrite(rekam1);  Come check out my talk: "The Consumer Programmable IOT" to see where I believe we're going with Cortex-M wireless embedded system development and how the maker community could change the way we all write and share embedded systems code.  If you're at the World Maker Faire in NYC this weekend, drop me a note to see a demo!

Filter Blog

By date:
By tag: