The Freedom board and mbed

This post will be short and simple:

If you don’t know what the Freedom board is, go to: www.freescale.com/freedom and find out. I’ll summmarize it: a low-cost Freescale Cortex M0+ enabled development platform that’s just awesome.

 

If you want to check out some awesome things that can be done with the Freedom board, go and visit my buddy Erich Styger’s blog mcuoneclipse.com

 

If you want to start developing with this board right away and without major hassles go and visit mbed.org

 

mbed is a development platform on web. Yes, web, your IDE is on the web browser, there’s libraries, code samples, a version tracker on the browser. Documentation is clear and thorough, no need for licenses, you just create an account and write code.

 

I’ve been waiting for a chance to post about this for a while (being a Freescale engineer I knew about this some time before it was release to the public) now it’s here, and it’s awesome and you should go and check it out!

I pay rent with some engineering

There’s a song from a blues band here in Guadalajara (yes, there are blues bands in Mexico) called “I pay rent with some blues”. I love playing blues, but I pay rent with some engineering, that’s what I would say. Of course, paying rent with some engineering is not as romantic as paying with blues. Still, that’s what pays the bills.

 

Why do I say all of this? Because this blog has been forgotten for some time. It’s been some crazy months I should say. I’ve been working on the launch of the wonderful new Kinetis L-series family of MCUs. This new low power family, with the ARM Cortex M0+ core has been all I’ve thought about for the past 4 months. Don’t get me wrong, I’ve loved every minute of it (most of it, anyway), but it’s been demanding, and so, Embedded Stories has suffered. Worry not, though, work load has gone back from CRAZYOMGTOOMUCH to “so much to do today”.

 

I’ll leave you with a little video that was made with the demo my team and I worked on to showcase the low power capabilities of the L-series, hope you enjoy it:

 

 

One of the coolest things that have come out of the L-series (so far) is the new Freedom board. This development board with embedded debugger will soon be available for a really low price and will be compatible with Arduino shields. It will also be supported by a bunch of software enablament, I can’t give more details now, but I can tell you it’s gonna be cool and you should be clicking on the link and preordering your board right about now.

 

Expect more posts soon!

My great end of 2011 with an interview on EEWeb and what’s coming up…

2011 finished very suddenly for me, I have so much work going on that February has just started and I still feel that 2011 has just ended. Either way, it did end in December and it ended quite nicely, with an interview done to me being published on December 29th on the EEWeb site, about which I have previously written here. Many of you have probably already read the interview if you follow my twitter account, EEWeb’s twitter account or even Freescale’s twitter account and many others who tweeted about it, thank you so much to everyone and to EEWeb. If you didn’t read it and you’d like to know so many more things about me and my passion for engineering, read it here.

 

I’m having trouble starting to write for my blog this year, it’s just so much exciting work that I wish I could tell you about…I’ll probably tell you in little snippets when my company (Freescale Semiconductor) releases stuff that I’ve worked on.

 

One example is the Xtrinsic Touch Sensing Software (TSS). I have been working with this library for some time now. I’m do not write the source code for the library, but I do help with definition of requirements, enablement (the demos and code that show it working), support, etc. It’s a fun thing to work on, as it has many of the elements I like: software, analog, weird noise-related issues (all touch sensing applications deal with noise issues). Because touch sensing is now an important part of many HMI (human-machine interfaces), I get sent questions from customers around the world, so I get to learn about many interesting applications. The latest version of the library has been announced and should be released in March. Among other things, it supports our first family of 8-bit microcontroller with a hardware touch interface, the S08PT family. For further information check out the TSS fact sheet.

 

I’ve also written a paper for a German conference on display technology. The conference is on display technology, my paper is on touch sensing, it goes hand in hand because displays need input devices to interact with the external world. It’ll be published soon, I’ll let you know 😉

Web stuff that’s actually good

While project awesome robot is still on-going, I want to let you know about a site I recently ran into (because they started following me on twitter, and so should you). It’s called EE Web and it’s awesome awesomeness. It’s got some really great resources (click on the Tools tab and you’ll see), great articles and (best for last) a great comic depicting some EE’s on the job. Not IT people, not fake geeks, this comic (Return to Zero) I can actually relate to, check it out!

This is the kind of stuff I want to see on the web even more, a fresh interface, good information that’s not cluttered and stuff I, as an EE and embedded developer can relate to, kudos to EE Web!

Check ’em out at:

http://www.eeweb.com/

And follow them on Twitter: @EE_Web

Touchy video!

I’m back after a few months of intense work. I have some fun things in the oven. While some new posts are baking, I’d like to leave with a video I made for Freescale touch sensing technology during the 2011 Freescale Technology Forum in San Antonio last June. Enjoy!

More playing around with RTOS, to task or not to task

So back in November 2009 I posted an article about my starting to play around with RTOS to grow in my technical knowledge. I must confess something: I haven’t really played with MQX or others as much as I would have liked…at least not during 2010. But then something happened: Freescale’s Kinetis family of ARM microcontrollers was launched and now my worked has forced me (in a good way) to work with the MQX RTOS quite a lot more. It’s been great fun.

In my self-training of MQX I’ve run into basically two ways of doing things. One way is to subdivide all functions into tasks, using all sorts of RTOS goodies like semaphores, priorities and mutexes (is that the right plural? How about mutexii?). This way, as far as I understand RTOS, is the right way to do it, it’s elegant.

On the other hand, I’ve seen code were the author basically creates two or three tasks and then proceeds to manually do the application control manually i.e.: switch-case statements with binary flags and stuff. Almost as doing a bare metal application where the RTOS is only there for the drivers. Correct me if I’m wrong, but, doesn’t that beat the whole purpose of using an RTOS?

My intent is not to criticize whoever writes code that way, I’m mostly interested in considering the caveats of doing the code one or the other way. For example, I can imagine a situation in which going crazy with OS tasks could result in an overly complex system, so probably a balance between tasks and manual control makes most sense. On the other hand, an overly complex system would probably be more the result of improper RTOS usage rather than an RTOS having a chaotic nature (which makes sense, now that I’ve written and read that).

So what’s your take on RTOS software? Do you think all RTOS resources should be exploited as much as possible?

Is learning a new language sexy?

Embedded software engineers only need to know one programming language to get through life: C. Most embedded software projects are written in C. So that leaves most other languages out of use (I insist, for embedded programmers). I always wonder if I need to start learning a new language, and if so, which one. With so many things to keep learning about, I usually barely have time to read up on the latest developments in the technologies I work with, so learning a new language has been constantly left “for later”.

 

C++ seems to be a pretty obvious choice as a next programming language, as far as I know, it’s the second most used language in embedded systems. There are also some less obvious choices out there like Ada or B# (yes, you read correctly).

 

The main issue with other programming languages is a combination of adoption and the benefits of C. It is well-known that C has very little overhead. Having compiler companies adopted C as the de-facto standard for embedded systems, optimization technology has completely focused on C for at least 2 decades, leaving any other language far behind. Ok, so C++ is nearby, it’s still C (I am now hiding my head under the desk waiting for some rocks to be thrown my way).

 

I’ve also played around with languages that aren’t at all related to embedded systems (at least that I know of). I’ve studied some Python, for the purpose of creating automated test GUIs and just for the fun of it, I like it a lot. That’s another practical aspect of other languages, they may be used as support for our embedded projects.

 

What is your opinion? Will C reign in embedded systems forever? Towards which language will embedded systems turn in the future? Should I start learning a new language? Which one?

 

A note, I should thank  Coding Horror (@codinghorror in twitter) for posting The Pragmatic Programmer Quick Reference Guide, it got me thinking about this and other things I’ll post about in the future.

One of my favorite things in electronics

I’ve been underposting, sorry about that…hope you faithful readers understand where my blog is coming from: an embedded engineer, meaning: overworked. I’m not complaining, I like it that way, as long as it’s not ridiculously excesive.

 

For your reference, these are my definitions for engineers:

 

• Half-time: 4-8 hours a day
• Underworked: 6-8 hours a day
• Normal: 8 hours a day
• Tolerably overworked: 10 hours a day
• Extremely overworked: >10 hours a day
• Ridiculously overworked: gets home and says “wow, I forgot about this bed!”

 

So I’m between normal and tolerably overworked right now, which is fine, but my blogging time takes a hit.

 

Anyway, I’m at the lab working and I saw this thing that I like so much, that I work with everyday and I though I’d share it with you:

 

Big, beautiful terminal block connector

Yes, that’s it, a terminal block connector. Did you think it would be an oscilloscope? Signal analyzer? Debugger? My computer?

 

Nope, I love terminal connectors, they’re big, robust, easy to work with (I’ve got the gorilla hands), simple, practical…oh wait, they’re everything embedded software should be…and isn’t. My philosophy regarding building great software is that, build it like a terminal block. Ok, probably not the “big” part, but, if it has to be big, then all the more reason to make it robust, easy to use, simple, etc.

 

I didn’t have one nearby, but I love the two-part terminal blocks even more, the ones that you insert the cables into one end and then plug the whole thing into the board-soldered end. Those are AMAZING, I wanna marry them!

 

(Breathing in and out)

 

Ok, not so much, but they’re cool. Again, a really nice metaphor for great software, software that you can easily split apart and then integrate back. That you can seamlessly take away one layer and integrate another layer without big changes to the system…that’s the dream.

 

That’s it for my post today. Leave a comment, what’s your favorite thing in work?

EETimes virtual conference: Integrating Touch Interfaces

As I’ve written before, I’ve been doing touch sensing applications for most of this year. A really fun market with a bunch of new innovation opportunities.

I’ve been invited to be a panelist in the EETimes Integrating Touch Interfaces virtual conference. The panel I’ll be in is called “Concepts of Touch Software” at 12:30ET on December 9th. It’ll have some really experienced fellows from several companies innovating in touch sensing. The panel will be moderated by Robert Cravotta, Principal Analyst for Embedded Insights (visit his blog!)

Conference is December 9th and registration is free, if you are interested in learning about current trends in HMI and touch sensing you should definitely register and attend (you can do it from your desk! Pop-up your favorite compiler in one monitor and the virtual conference in the other). Go here:

http://www.eetimes.com/touch

One last thing…I’d like to know what my readers are working on…drop a comment down here and let me know.

Kinetis is…(try to pronounce that)

Kinetis, Freescale’s new line of ARM-based microcontrollers is finally out.

Part of my job as a Freescale application engineer was validation, and let me tell you, it has been fun. Coming from an 8-bit microcontroller background, I’ve usually dealt with small microcontrollers, slow bus speeds and limited memories. Kinetis, while not a high-end processor, is a big difference. I’ve worked with some other 32-bit devices, mainly Coldfires. Now I’ve gotten to dive deeper into the world of 32 bits, it’s fantastic. ARM is also fantastic, and the amount of integration in Kinetis is also fantastic, I can’t wait to get my hands into an actual, full-on project. Validation is a different job than developing an actual finished product, the software is not as complex and is focused on bringing out features rather than using one or two features and building on them. For me, it was al about the touch sensing functions embedded into Kinetis. Being touch sensing such a big thing right now (read all about it in the Embedded Insights blog, mainly in Robert Cravotta’s blog posts, highly recommended) it was important for Kinetis to include a fully functional and robust touch sensing interface, and we did it. The touch sensing input module (TSI) is a 16 electrode, 1 pin-per-electrode module that takes care of capacitive touch sensing from the analog signaling all the way to the scanning and outputting of interrupt signals. User software only needs to worry about waiting for interrupts and storing measurements. Post processing can be as simple as comparing measurements to a baseline capacitance, consider the electrode touched if the capacitance goes above a certain threshold. Most applications will want to do baseline tracking (constantly measure the electrodes to check if capacitance varies over time, mainly from environmental changes) and filtering. For that purpose, Freescale also provides the touch sensing software library (TSS), which in Kinetis supports both the TSI module and the GPIO scanning mode based on RC measurements driven by an external pull-up.

Of course, Kinetis doesn’t end there, as I wrote above, the amount of integration is amazing:

– DMA

– USB

– Ethernet

– Lots of serial ports (including I2S for audio codecs)

– Lots of timers (including the FTM module, ready to do motor control)

– CRC

– ADC

– DAC

– LCD

And so much more. Plus the whole ARM ecosystem at your disposal. Kinetis also includes new Freescale IP for flash technology, the TFS (thin film storage), which could (and probably will) take several blog posts to talk about, but I’ll just tell you it’s highly reliable, fast and, mounted on top of it is a module called FlexMemory that allows programmers to assign sections of the memory as code memory and as data memory, including EEPROM emulation (so no more awkward memory drivers, the FlexMemory takes care of it). Visit the Kinetis site for more information, reference manuals, etc.

On a personal, blogger note: the reason I hadn’t posted was that I was just so busy, no excuses, I know I could have posted on a Sunday night as I’m doing right now, but I didn’t, cause I was just so busy and wanted to use my Sunday nights for sleeping and playing guitar and that sort of stress relieving activities. More posts will come, Kinetis-themed, and in other themes as well.

I (heart) cores

The embedded systems conference is going wild this week and I’m not there, I do hope to get there some day, but meanwhile I can’t help thinking about the number of CPU cores that an attendee is exposed to in this event. There are omnipresent cores like the everpowerful ARM, so many MCU/MPU providers have a flavor of it, I dare say it’s like the 8051 of our times. Then there are, of course, the very specific cores of which only a specific company has full ownership, and everything in between like the Power Architecture core, not as omnipresent as ARM, but still favored by many silicon vendors . Oh! And the 8051 is still amazingly around.

I love the fact that there are so many cores around, I believe this is a reflection on our humanity, on our ability to create. If the world were eventually dominated by computers, I bet the world would eventually only have one core (to rule them all, pun intended), it would be gray and boring. Lucklily the chaos that ensues having so many cores is probably avoiding computers of becoming interested in dominating us…maybe we are already dominated by them, I’m not sure (pun intended?).

Anyway, cores are cool. Apart from the inminent information overflow from trying to understand each of their architectures I think it’s important for the industry to keep investing in many options instead of settling for one single core (single core, multicore…well, you get it). I just hope I get to work with as many of them as I can get my hands on…what’s the count now? 11 cores, I’ve worked with 11 cores in my lifetime so far…how about you?

Software engineering and the iPad

Hold on! Don’t browse away, this is NOT a post about the iPad…it’s just my hook 😉

So what is it about then? You ask. It’s my theory about why the iPad was a disapointment to many. Why is it a disapointment?

1. It’s an oversized iPhone that doesn’t do calls.
2. No OSX.
3. Not able to run more than one application at once.
4. Did I mention it’s just an oversized iPhone?

I am not an Apple fanboy as you can see. But I’m also not a detractor, I like their products (though I don’t like the fact they could be doing much more to improve their eco-friendliness). In general, it’s a cool company, with cool products, but the iPad just isn’t one of them. They lost at their own game. The iPhone was revolutionary, it impressed everyone, so when rumors started to surface about a tablet PC from Apple, we expected a lot, and a lot we did not get, sorry Apple, I’m still considering getting an iPhone though.

I said this wasn’t going to be about the iPad, right? Ok, so on to the subject. My theory about the fact that the iPad is not multi-app (I’ll use this made-up term because I don’t like to use multitasking for this concept, multitasking means something else) is that there in fact is a multi-app version deep within the ultra secret Apple software repositories. It’s just waiting to be properly tested, debugged and released. Apple, being the great company that it is, has even made a deliberate plan to get to the market faster than other tablet manufacturers to win market, while finishing development a a way cooler software version. Their software processes are so fine tuned that they are even able to predict when they can come up with the simple version (the one that was just released) and when they will release the next version supporting multiple applications, I bet it’ll even have TabletBand.

Of course the story could be different, they wanted to release a cooler version but their development process was so bad that in a desperate attempt to be able to release it on time, they cut down on all the features and kept just the basic features to be a market-hypeable product (this is my word inventing post)…

I really don’t know why the iPad was designed that way, I bet I just don’t find it useful for me being the geek that I am. I need a bunch of ports, power, compilers, too many applications running at the same time. I need to tweet the latest news or funny pictures while writing this blog, playing a hand of internet poker, compiling some project in the background, hearing music, chatting with 4 different people and keeping the beat of the song in my imaginary drum set…while brewing some coffee. So maybe it’s just not for me, maybe I’m an old-school geek, maybe new geeks will find it useful.

What I do know is that I’ve seen embedded systems projects do this strip-the-requirements-down-to-release-on-time sort of thing and it’s really sad. Mainly because the development team is usually technically able to deliver all the requirements, the failure is not in the capabilities of the team, but rather their management, many times their marketing (yes, being a development type, I tend to blame managers and marketers for the wrongs of the world…or rather, manager for the wrongs of a project and marketers for everything that is wrong in the world :P). In companies where management hasn’t been able to properly articulate and synchronize all the inputs and outputs, this stuff tends to happen. Bad requirements lead to bad development platforms, that lead to bad products. Example: the requirements indicate that I need an 100 MHz processor, management insists in using a processor that barely accomplishes that to save cost, turns out the marketing team forgot to mention some critical characteristics that they thought could later be added, hardware has to be redesigned.

The worst example there is about this is trade shows developing anything with a trade show timeline is about the worst you can do to the project, unless for some magical reason (unbeknownst to mankind) a project is started with enough time to finish by said trade show, the project will invariably be started after this magical date. But that’s not all, it’ll be started late, and while the trade show get near, a funny thing will happen: a double negotiation between the development team asking to eliminate features for the “trade show release” (yes, trade show release) and marketing asking for new features or feature tweaks specially designed to meet some weird desire. The result is a software project completely void of quality, full of holes and just plain ugly. It’ll also be almost impossible to get it back to acceptable standards.

Notes:

– I don’t really think this is what happened to the iPad project.

– I don’t really play online poker while compiling, that’s just wrong.

At last! My motor control MCU!

I am deeply interested in motor control as you can read in my “about” page. I also currently work with 8-bit MCU (though I’m starting to move to 32-bit technologies as well, as you can read in my blog post below). Even with my interest in motor control, I haven’t done a lot of work with DSPs (shame on me),  luckily 8-bit MCU are becoming more and more specialized these days.

Freescale (when it was still Motorola) used to have a really nice MCU called HC08MR, part of the HC08 CPU family, the father of the S08. The HC08MR was an MCU specifically designed for the low-end motor control market, specially BLDC motors and ACIM motor with simple control techniques (V/Hz conversion technique, not fancy stuff like vector control, of which I hope I will eventually talk…when I understand it well enough). The HC08MR has lived a long and happy life, even spawning some curious devices like the MC3PHAC, an analog + MCU + firmware integrated device, basically a plug&play ACIM motor control, very cool indeed.

Now we have the S08 CPU, faster bus clocks and cooler peripherals, so it was only natural that Freescale came out with a new and fresh 8-bit motor control MCU. At last it happened, and last week the S08MP family was launched. The S08MP is a little controller filled with peripherals besides the peripherals you would expect in a current 8-bit microcontroller it has some cool features like: FlexTimer (FTM) module specially designed for motor control with complementary PWM and dead-time insertion (one FTM has 6 channels and a secondary one has 2 channels), 2 programable delay blocks (little timers designed to synchronize two peripherals like the ADC with the timer), programable gain amplifier that can be linked with the ADC, high-speed analog comparators, 5-bit DAC and a CRC generator. All these features help make motor controllers that are both low-cost (1 to 2 dlls at 10,000 pieces, the most expensive ones are automotive certified) and still full of features. Reference designs for both sensorless and sensor BLDC motor controls are expected to be published very soon. Won’t be long before other reference designs come out doing maybe V/Hz conversion for ACIM motors or maybe even steppers. There are also other places where this MCU could shine, like power factor conversion or high brightness LED control (get it? Shine, LED? Ok, a bit lame…get it? Bit? Sorry, I’ll stop now).

In the coming months I’ll be writing more about this fascinating little device. I’ve had it near my heart ever since I first heard of it and now it’s right here in my cubicle happily turning a small motor round and round (pure geek bliss). I’ll probably even post a picture of me and S08MP16 smiling together, or I probably won’t, I wouldn’t want my readers to think I’m a creepy semiconductor freak (though I probably am).

RTOS for dummies

This week, Collin Walls from Mentor Graphics, published an article from guest columnist Meador Inge in his blog. The blog post is called “C is great, but…“, and it goes on to highlight how embedded software programmers should get into languages other than C, the premise is that doing only C will make you a bad programmer. I agree and I have a lot to learn. I’ve played with Python in the past (not with embedded software purposes) and it’s been fun and educative.

On a similar note as Meador’s post, I believe developers should not limit themselves to a single software architecture. so I’ve also been learning the pleasures of RTOS. Coming from the low-end embedded world and having worked with 8 and 16-bit microcontrollers for most of the last 6 years, I’ve become used to forcing myself to do resource constrained software, with bare-schedulers at most. While this has been fun, I think I really need to get going with bigger systems. So I started playing around with MQX by Embedded Access, which is currently being offered by Freescale on several MCU and MPU. I believe MQX is a really nice step towards bigger and more complex RTOS, it has all the basic functionalities an RTOS is supposed to have as well as integrated communications stacks (ethernet, USB) that make suitable for a lot of projects. Freescale is putting a lot of effort into releasing a lot of enablement material.

Even with such a nice option, many of us are less than beginners in the world of RTOS. If you are one such case you should take a look a the Friendly Little Interrupt Tasker (or FLIRT), it’s a very small and simple RTOS ported to Freescale’s S08 architecture. The author, Dave Armour, published an article on Embedded.com about it, the article explains the operation of this great little RTOS in clear and simple language so that even the least knowledgeable of us can understand. A recommended read.

 

How about you? What’s your experience with changing your development paradigms? Leave a comment and let me know your experience with new languages, software architectures, RTOS, etc.

Is pair programming for the embedded folk?

I just read an article in Obbie Fernandez’s blog about pair programming and how it is not for every company (10 Reasons Pair Programming Is Not For the Masses). I don’t usually read his blog cause I’m not a web developer, but my brother (who does do web development) tweets the articles he likes and I read them…(except when they talk about high level ruby code that my lowly embedded-C brain can’t or doesn’t want to understand).

Aaanyway, pair programming has always been something that intrigues me. The article basically states why it is difficult for most development teams to adopt the pair programming method. It just requires too much commitment and so much non-traditional focus that most shops are just not ready to do it. Even so, I bet there are embedded software companies out there willing to try the model out and that actually have the resources and commitment to make it happen. This leads me to (dreamily) wonder, is embedded software development adequate for pair programming? Most of my reasoning points towards yes, embedded software is, for all purposes, software, so the model should work even if it is not the ideal world of web (for more on why pair programming is so good for the web software folk, read this article by Rod Hilton). I felt particularly devastated by “the no-asshole rule” cause, let’s face it, the embedded development community is full of these types (all of them, the prima donnas, the smelly ones, the antisocial ones).

I also see a big problem with the overall maturity of the embedded software industry. From my very personal point of view, there are currently two types embedded software shops:

• The stick-to-the-process, extremely formal type of place: these are the places where they are making really “important” software, for example: automotive, aero-space or networking (some) industries would be here. These types of shops have a rigid process and way of doing things all focused on clearing all sorts verification, validation and tests. Would they be willing to commit to the big change that would be jumping to a pair programming model?
• The rest: sorry for the ambiguity but most other shops (again, from my perspective) are just completely random, with all sorts of people following all sorts of processes and/or not following any at all. There are of course varying degrees of truth to this, but the fact is that as an industry, we are way behind in jumping to an actual “software engineering” culture, most people come from an electronics engineering background, which doesn’t help either, and most of the people don’t really know or care about the benefits of formal processes (and I’m not talking about the IEEE, RUP, ISO type thing, but just a set of light and easy-to-follow steps like requirements-architecture-design-code-test). In this (admittedly) gruesome and negative panorama, does it even make sense to throw in a paradigm changing model? Not sure.

What do you think? Are embedded developers mature enough to pull pair programming off?