1 2 3 Previous Next


315 posts

     Now wearable design become more and more popular around the world. Lot's of designers choose ARM Cortex-M series core. Why choose Cortex-M, not the most famous Cortex-A series core? What is the real benifit for the designers? You can find answers from this blog:


AnandTech | ARM's Cortex M: Even Smaller and Lower Power CPU Cores


     Package , Power Consumption and Performace, you will find the part attract you easily.


RPiSoC is a PSoC 5LP-based electronics development platform that allows your software to interact with the physical world in a way that emphasizes power, flexibility, and accessibility.


It started life as a senior project for Robert Barron and Brian Bradley at Rensselaer Polytechnic Institute, who have now formed Embedit and launched the platform on Kickstarter.


They are running a Webinar tomorrow on the Element14 site.

RPiSoC can be used as a standalone embedded board for instrumentation, data acquisition, and mixed signal projects. But it really gets interesting when you hook it up to a Raspberry Pi. The Cypress PSoC 5LP makes RPiSoC much more than a typical fixed-function expansion board; providing access to PWMs, high resolution DACs and ADCs, Opamps, DSP, Pmod and Arduino Shield interfaces, and much more! You can replace a bunch of peripheral boards with a single RPiSoC.
I really recommend taking a look at this new platform. Robert and Brian just launched the kickstarter project and there are some nice videos of the platform in action. I particularly like the face recognition one but there are a number of others on YouTube.

Although I enjoy writing articles and blogs and giving presentations – I am always hoping that I can impart some useful information and help engineers with their projects – the Q&A session after a presentation is often the moist interesting part. If I am doing a Web seminar, for example, I normally have a one hour slot; I try to talk for no more than 20-25 minutes, leaving plenty of time for Q&A. I find that so often it is the questions that trigger ideas for articles, blogs and further presentations. So, please keep them coming – comment here or email are always options.

I attended a recent Web seminar at which there were lots of interesting questions …

As is my common experience, there were far too many questions to cover in the available time, but my colleague made a fine effort to address as many as she could. I obtained a list of outstanding queries [to which she may well have sent replies by email to the appropriate attendees] and found a few that I though worth some discussion here:

If Linux is installed on two cores in an SoC, will processes be allocated to each core as needed/available?

The simple answer is: maybe. It depends on what software configuration you choose. If you use an SMP [Symmetric MultiProcessing] version of Linux, a single instance runs across both cores and processes will be allocated to a core on which to execute. The way this allocation is performed is a configuration issue. On the other hand, if Linux is installed individually on each core [it is now an AMP - Asymmetric MultiProcessing - system], code execution is managed separately and each process “belongs” to a specific OS instance and, hence, on a specific core.

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


I have always liked writing. From an early age, I had an ambition to write a book. My first attempt, in my mid-teens, was a science fiction novel. It was not a success. I wrote about 100 pages and I may even still have the typescript. I remember being embarrassed last time I looked at it. One of the best days of my life was back in 1986, when a jiffy bag arrived in the mail containing a book with my name on the cover.

Since then, I have never really stopped writing …

With a few exceptions, just about everything I have written has been about electronics and/or software. Until the last few years, much of my output has been in print – lots of collateral materials, countless magazine articles and another book. Nowadays, the vast majority of what I do is online. This blog is a prime example. I post frequently on a wide range of topics, but, to some extent, I feel rather constrained – both by time and space. It takes time to write a few thousand words and a blog post is necessarily quite brief. So, I welcome opportunities to get into more detail and explore a topic in more depth.

I publish articles – many of which pick up on themes of blog posts – in a number of places. I have a “column” on embedded.com – that means that they publish my pieces on a fairly regular basis. I realized that I do not do a very good job of publicizing those articles, so I figured that it might be useful to provide a guide to some of my recent work on that site:

Binary Anyone?

Embedded software developers quite commonly need to think about individual bits. This is most commonly the case when working with CPU or peripheral device control registers. High level languages, like C, do not accommodate developers’ needs very well in this respect. This article outlines an approach whereby developers can code low level routines using binary in a natural, intuitive way.

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

Embedded software articles – from assembly language to software IP « The Colin Walls Blog.png

ARM University Program (AUP) and Freescale University Program, as part of their joint activities in India, conducted two one-day workshops (ODWs) for faculty on the Freedom board (ARM® Cortex®-M0+ FRDM KL25Z) on June 9 and 10 at the ARM office in Bangalore. The participants were from universities and colleges across India, including the Indian Institute of Science (IISc), the Indian Institutes of Technology (IITs) and the National Institutes of Technology (NITs). The workshops were aimed at bringing AUP’s flagship Lab-in-a-Box (LiB) on the ARM Cortex-M0+ based Freedom board from Freescale to faculty, students and researchers, targeting the area of Microprocessors and Microcontrollers and Embedded Systems in a university curriculum. An LiB of this type consists of 10 x Freedom boards donated by Freescale, 100 x licenses of Keil MDK Pro microcontroller software development tool donated by ARM and a full suite of teaching materials developed and donated by AUP. Participating faculty showed significant interest in the full suite of teaching materials around the ARM Cortex-M0+ based Freedom board which includes lecture notes and slides, exercises with solutions, lab manuals with solutions, sample pieces of code, projects with solutions, and even sample exam papers with solutions.


Professor Dasiga of Nitte Meenakshi Institute of Technology (NMIT) Delivering Workshop


The workshops started off with an introduction to the ARM Cortex-M0+ architecture followed by hands-on lab sessions. Operating at near-single-digit µA current levels and selling at a student-affordable list price of 762 INR (9 GBP or 13 USD) at element14 India, the Freedom board is the perfect piece of lab hardware for students interested in the up and coming areas of study and research, such as sensor motes for wireless-sensor networks (WSNs) and wearable computing. The lab sessions used the onboard tricolor (RGB) LED and the onboard 3-axis accelerometer extensively, demonstrating the board’s considerable standalone utility. The on-board connectors compatible with off-the-shelf Arduino shields captured the imagination of those enquiring about ways to expand the board’s capabilities in a neat and compact way. Last, but not least, the participants appreciated the board’s mbed interface for providing them with a unique capability to rapidly prototype complex projects using the same Freedom board.


Flashing RGB LED
Hello World on LCD


The lab sessions started with an introductory lab in which participants learnt how to enable the board with firmware to be able to program the on-board flash and perform runtime debug using the Keil software-development tool. The following labs were engineered to impart the elements of programming microcontroller peripherals using their memory-mapped registers including GPIO, analog IO, PWM and I2C to name a few. These included a spirit-level simulator using the on-board accelerometer to detect changes in the position of the board and a bubble on an LCD peripheral as well as a lab demonstrating various power modes available in the Cortex-M0+ based microcontroller by configuring the microcontroller in various sleep modes, disabling parts of the board’s circuitry not relevant to the microcontroller’s operation.

Spirit-level Simulator - Balanced
Spirit-level Simulator - Left Tilted
Spirit-level Simulator - Right Tilted


The workshops ended each day with a message of continuity with each participant being given a Freedom board and a full box of accessories, such as a breadboard, resistors, IR diode, IR phototransistor, 2x16 LCD and jumper wires, to enable the participants to carry their experiences into their teaching roles.

I'll be posting on my wall some conclusions and studies I have done based on the readings for my AAME.


Today I studied a bit about ARM exception and behavior especially in Cortex-M0, the interesting thing is that there is not much to optimize the Assembly, the registers R0 to R3, R12 and R14, XPSR and PC are automatically stored in the Stack current, leaving only the need to reserve the remaining registers if this were to be used.


Stacking and unstacking besides, there are two interesting features in dealing with exceptions:


"Tail Chaining" where an exception is called right after the other when the same level / priority, without having to make the "stacking" and "unstacking" right now, just finished the first Exception, returning the EXC_RETURN value for LR, without being interfered with registers mentioned above, and then the next interrupt will already be ready to be handled by the Exception / interruption Handler.


The other feature is the "Late Arrival" where an exception occurs and then immediately Stacking occur during other higher priority, the process continues until terminated Stacking store registers, cited above, the Stack, then the second highest priority exception is called, to be terminated as standard (EXC_RETURN returning to LR) then the first exception occurs normally.

Embedded systems that include hardware that can change as you go (SoC FPGA anyone?), present a moving target during product development. Engineers will likely want the debug setup to adapt to hardware changes. While it may be workable to let the software team debug the processor core, (with their own debug cable, debug tool and debug flow), while the hardware team separately debugs the FPGA hardware, (with their own debug cable, debug tool and debug flow), what happens during software hardware integration testing?


A software debug view that automatically adapts to changes in the FPGA could prove handy at this point. The last thing you want is for the software team to have to learn the hardware design tools. So don't make them. View these videos to learn more about how adaptive SoC FPGA development tools can make a huge difference in getting through the system bring-up and debug phases.


Architecture Matters: Whole Chip SoC FPGA Debug

(make sure to go to the 'Tools' tab if the link doesn't take you there automatically)

Architecture Matters: Whole Chip SoC FPGA Debug

I started a couple of weeks ago, when I received an email from Sandeep Vasant from Ahmedabad University in India. For reasons that he has yet to reveal, he was having trouble with some code like this:

int a=10, b=20, c=0; c = a++ + a++ + b++ + b++ + ++a + ++b; 

He tried this with one compiler and the resulting values of a, b and c were 13, 23 and 96 respectively. He was satisfied with this result. Then he tried a different compiler, which yielded a final value for c of 98, which he found confusing.

I started looking into this, certain that the explanation was simple …

As I work for a company that sell embedded software development tools, I have a natural interest in programming languages and their quirks – even if the code is not specifically embedded. I believe that embedded developers are often more interested in what is going on “behind the scenes” than their desktop computer software development counterparts.

My first thought was that, although the precedence of the +and ++ operators is clear and the functionality of the pre-increment and post-increment versions of ++ is unambiguous, the order of evaluation of the the operators is not defined. Maybe they are evaluated left to right or perhaps right to left. So, instead of using a compiler, I decided to work it out by hand. Going left to right, I got 10 + 11 + 20 + 21 + 13 + 23 = 98; going the other way, I got 21 + 11 + 21 + 22 + 11 + 12 = 98. So it made no difference. In both cases I got the result that Sandeep had been confused by.

Now it was time to try a compiler [I used CodePad]. I wrote this:

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


Software start-ups will dominate growth in the Internet-of-Things (IoT) as demonstrated by MindRDR’s application that combines Google Glass and Neurosky biosensor hardware.

The idea is simple enough. You see something that you’d like to capture with a camera. But rather than reach for your smartphone or tap the side of your smart glasses, you merely concentrate on the image that you want to capture. The sci-fi prediction of using your mind to operate smart electronics is here! More significantly, this application confirms a major trend in electronics and IoT growth.

In a recent interview, Zach Shelby Shelby, Director of Technology at ARM, explained that 80% of the value of the #IoT will come from software applications, while the remaining 20% of value will be split between the devices, the network, and the middleware. The analyst firm of Gartner put it this way: “Half of this activity will be new start-ups and 80 percent will be in services rather than in products.”]

The fact that a sizeable portion of hardware has become a commodity is nothing new – unless it’s unique hardware such as Google Glass or the Neurosky biosensor headset (more on that shortly). But a related observation from Gartner is that, “by 2018, 50% of IoT solutions will be from start-ups less than three years old.” In other words, start-ups that don’t exist today will represent 50% of the market in just three years!


One such start-up may well be a company called MindRDR that has created a software application to control Google Glass with your thoughts. The application connects Google Glass with a device like Neurosky’s biosensor technology to monitor brain activity. One use of this application would be to allow users to take pictures and post them on Twitter or Facebook without the need for any physical interaction. In the medical field, this technology could be used to bring mobility to quadriplegics, suffers of multiple sclerosis, and  other debilitating diseases.

According to the company, the user experience for taking mind-controlled pictures is centered on one’s ability to briefly focus on the task. The MindRDR application appears as a line on the bottom of the Glass’s display. As the user concentrates, the line moves up to the top, at which point it snaps the picture that the user is viewing. The captured picture is then uploaded to a social network by following a similar process.

MindRDR has chosen to freely offer their application on GitHub to encourage new applications by other developers.

It doesn't take a mind reader or though control to realize that the next few years will see the rise of new and innovative application software. These will be exciting times!

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.


Filter Blog

By date:
By tag: