The art of (not) multitasking

As you may have read from my previous post and lack of posts, this year has been a busy one.

Although this last month has been nothing compared to the previous ones, I have noticed an interesting trend. Before I was so stressed and focused on finishing just a handful of important tasks that I become sort of “super productive”. I focused on getting the job done and it achieved results.

Now it’s all about everything else that needs to be finished. It’s many many tasks that have about the same priority. Yes, I think I know how to prioritize. The problem is all these tasks seem to have the same importance after some analysis. So the way I’ve been dealing with them is “multitasking”. That is, doing a little bit of each at a time, in hopes that I’ll eventually get them all done, sort of how an OS would do it. Turns out, I feel I’m going nowhere at times, mainly because there’s not much stuff I’m checking off, but there is new stuff piled on top of the old stuff, that I’m also partially starting, and so on, “ad infinitum”.  There’s so much time lost in the “context switching”, plus the distractions that might come in between, like obsessively checking emails, that I feel my productivity is diluted.

So my conclusion is: either I get a clone that focuses, or I do the focusing myself. Since the first option is too expensive, probably impossible and highly unethical (or at least in some sort of moral gray area), I need to do the second one. I need to choose a task and go with it, until it’s finished.

Alright, let’s say I’ve mastered the art of focusing, that doesn’t entirely solve my problem. There are still interruptions, people requesting immediate action. Many times you can say: “hold on”. Other times you just can’t, stuff needs immediate action. I’m still trying to learn how to give those interruptions the appropriate attention without  loosing track of whatever I was doing. What do you do? Do you effectively multitask?

 

Update: my buddy Erich Styger also wrote a really nice post on multitasking in real life. Instead of only complaining he  lists some things he does to keep productive, check his post out, after that, check his blog MCU on Eclipse out.

Primavera forest is burning and technology isn’t there to save it

My city, Guadalajara, Mexico, has a big an d wonderful forest called Primavera Forest (Spring Forest). This forest is one of the most important ecological resources of this side of Mexico. It basically keeps the city from having the crazy atmospheric contamination levels that Mexico City has. The forest is practically the same size of the city and it is a protect natural area.

Sadly, this protection is constantly challenges by groups that are interested in turning the forest into premier housing. So periodically we see news of construction sites popping up where they shouldn’t, and, worse yet, fires intentionally caused to remove the protection status a particular area of the forest has (even though law states that a burnt area is still protected for the following 20 years so that it may be reforested).

Forest fires are also supposed to occur naturally, but natural forest fires have natural patterns and seasons, human-caused fires don’t. In either case, there is technology that can help, if not prevent, at least quickly stop fires. At this date, 5 days after the fire started, it has already consumed 4000 ha, that’s about a FIFTH of the forest, in practical terms, this a environmentally catastrophic, the effects of which we will suffer for many years to come.

I am happy that the city is now gearing up to go and reforest as soon as it is safe to do so. Everyone has a great attitude, all over the internet you can see support, groups informing people, etc., in the city you can see lot’s of place to go and leave donations to the firefighters taking care of the problem. Now it’s about 90% controlled and some guilty people have even been found (yes, sadly, this was caused by people without any consciousness whatsoever).

Even so I feel much more could have been made. Preventive systems could have been there to detect sudden changes in temperature to quickly alert forest rangers. These systems already exist, they live inside of tiny pods, work for year on the same battery and automatically build ad-hoc networks through zigbee. They all report to a base station and can quickly pin-point risk areas where real-time satellite imagery or an actual trip could detect a fire before it spreads. Is such a system even that expensive? No it isn’t, compared to the current fire-fighting costs, the environmental cost, the health risks, etc. No it isn’t to a city that owes it’s usually great weather to that forest. I struggle to understand why such a system isn’t there, in a city that is nicknamed “Mexico’s Silicon Valley”.

It’s absurd. We don’t even need to buy the technology. I know zigbee specialists, I know low power specialists, I know networking specialists. We have small manufacturing houses, we have talent. Technology could have saved our forest.

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

Some tips to fresh-out engineers looking for a job

I’m only in my seventh year out of college, which is not a lot, but it is enough to have seen plenty of résumés. I’ve just been reviewing some new ones and remembered that I’d planned this post.

Here are my tips on making a good résumé. These are my tips, an engineer, not a hiring specialist, so follow at your own will. Also notice that these may not be relevant to fresh-out accountants or dentists, these are things that as an engineer looking for engineers for a technical position either bother me, make me go crazy or simply I would recommend…or simply as a person who appreciates good writing skills, a little bit of both…check ‘em out:

• NO CAPS LOCK. PLEASE, OH PLEASE, NO CAPS LOCK: no explanation needed, just don’t do it, nobody likes it. If you don’t understand this point, may I direct you to one of my favorite web comics, The Oatmeal: minor differences.
• If you’re doing a résumé in a language different than your native language, make sure you research the proper way to express terminology that you’re not sure about. Tip: any word that sounds very similar in both languages is not necessarily the most correct translation. For example, “compromise” in English and “compromiso” in Spanish mean different things. Note: I researched how to write “résumé” for this post.

• No need to put ALL of your personal info there. Your height and weight are not needed. I personally don’t even think your address is needed. A phone and email is more than enough. If you have a unisex name, probably add whether your male or female, most online application systems will have that option already, so it’s also not entirely essential. Extra points: if you have a “peculiar” email like g33k_10RD_666@hotmail.com, use a different email, if you don’t have another one open an account in gmail with your actual name.
• You are applying for an engineering job, your engineering credentials are what’s relevant, unless human resources needs to know for some bureaucratic reason, don’t include you elementary school, junior high, high school or your chef certifications, nobody cares, and if they care they’ll ask in the interview. Include bachelor’s degrees and above. If your high school was a technical high school, then include it.
• Similar to the previous point, I repeat: you are applying for an ENGINEERING job, nobody cares if you are good at MS Office 97, 2003 and 2007. I wouldn’t even put Word in there, it’s a given that you know about basic software. You’ve recently finished college, you wouldn’t have been able to do that if you didn’t know how to use Word. If you have an advanced Excel-something certification, for example, if you can do pivot tables and program VB macros like nobody’s business, then, by all means, put it in your résumé, if you know how to graph something and do some calculations, then DO NOT mention it, everybody assumes you know it. Same goes for HTML, nobody programs in HTML anymore. You can do web applications in javascript? Good, write it down. You know how to add meta-tags in HTML, don’t write it, nobody cares, because if you’re applying for a web-something job, you SHOULD know it and if you’re not, then it doesn’t matter.
• Don’t give specialized tools or knowledge more importance than they actually have. For example: multimeters and oscilloscopes are not particularly important because you should know them (if you’re an EE, at least), logic analyzers, RF signal generators, specialized sniffers, those are things that are actually important to highlight for a fresh-out.
• Also don’t give school projects more importance than they have. If it’s your thesis project or something that actually had some complexity outside the scope of a single subject, consider putting it there. Only include school projects if you don’t have any additional experience, ideally you should have done an extra effort in college and you would have internships, expos, competitions, etc. under your belt, those experiences are more important because they speak of more work and a willingness to go beyond.
• Review your grammar and spelling. If you’re bad at it (cause you’re an engineer and you probably are) ask a friend to review it for you. Pay them with beer.
• Make it easy on the eyes. I don’t mean you need to do some fancy graphical design, but make it orderly, make it easy to read. Have sections in an order that makes sense. Ask someone to take a look at it and tell you if they like it. Look for pre-designed formats on the internet and base your résumé on that. There are many things to say here, but mostly, use a decent format, get opinions and most important of all: DO NOT USE COMIC SANS.
• Put your sections in order of importance. Usually hiring people care more about your work experience than your studies, so put that first. Within special abilities, focus more on the important ones for the job and less on your football tournaments.
• Be truthful, do not make up that you have java experience because you programmed a “hello world” in java.

That’s it, hope my recommendations help you, or at least made you laugh.

Creativity

Yesterday I had an interesting conversation about working in embedded systems with someone who’s not an engineer, turns out I’ll speak to her college sociology class about creativity, how to loose it and how to keep it.

Engineering is a creative career, don’t let anybody tell you otherwise. I could agree that there are engineering variations that are less creative than others. For example, to me quality engineers are probably allowed less creativity as their work is to enforce standards. But I say only probably because I can think of several ways they can be creative, like in designing their testing procedures.

My problem with creativity in engineering is with all the corporate red tape needed to exert creativity. When you work for a company (like I do), many times you have to sign a document that basically gives the company ownership of any ideas you have. I’m not a lawyer so I don’t really understand how far that document goes. For example, I don’t think they own my ideas for better omelets, but they do my ideas for software optimization. I understand the idea behind this type of contract. I’m working under their roof with their equipment and their resources. But the brain that came up with the idea is mine, so, who’s idea is it? I don’t have the answer. What I do think is that companies should have better ways of sharing intellectual property with employees. If IP is so important, than there should be some sort of shared ownership.

Again, I’m not a lawyer and I don’t understand the legal implications of these ideas, but from a personal stand point, this would be very motivational, it would actually mean to “own” my work, which, in practical terms, means that I’m far more committed to the results of the company.

 

As engineers we are motivated by different things. It is common for engineers to pass on a better salary offers if it means a more boring job. Not that engineers don’t want to make money, it’s simply a priority second to the challenge and the thrill of solving a problem or coming up with something new. I think companies that are good at challenging their engineers and making them own their innovations will always succeed in having the best talent. It also helps to make innovating easy as possible. I would love to see more companies out there allow their people some time to just be creative with their work rather than simply making the deadlines.

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

Lessons in motor control

When you do a new motor control board that you’re calibrating for the first time, buy a whole bunch of extra FETs. You’re going to burn at least a set and then you’ll end up “borrowing” them from other boards, true story.

I (heart) ESC (and pictures!)

I traveled to San Jose, California last week for the Silicon Valley Embedded Systems Conference. It was an awesome experience as I had never been to an ESC before.

I don’t really have too much to talk about the keynote speeches, I wish I could, but as a speaker and exhibitor you actually have too much work to do, and when I didn’t have work I was at the Freescale booth showing people demos and talking to other engineers.

This part of the conference was actually really great, I got to meet so many people, from young engineers (one even asked for career advice), which honored me a lot, to seasoned experts who had some really great insights (notice how I say “seasoned experts” to not say “old engineers”, I am so politically correct…wait…)

I have so much to talk about ESC, but I have some pictures to share, so I’ll let the pictures talk.

First some pictures from the theater sessions. The Freescale booth basically had a small theater and we took turns speaking about several new products and technologies.

Eric Gregory showing his awesome creation, the FSLBOT

Clark Jarvis talks about graphics libraries using MQX RTOS

Paulo Knirsch and Phil Drake talk about the new Coldfire+ family (marketing and engineering happily working together, by the way)

From the booth:

Cuau Medina (aka @HealthDevices) spent several hours driving the VGo robot around ESC (http://www.vgocom.com/) He even met some girls (but didn't get their number cause he's a gentleman)

The watt saver (pat. pending) reference design. New technology designed to eliminate vampire power from idling chargers and other permanently plugged-in devices.

Extras:

Stealth picture I took of the attendees at the "Battery Powered, High-Accuracy and Reliable Capacitive Touch Sensing" class just before starting my hands-on portion

"You break you buy, I break I cry." Ok, so this picture wasn't taken at ESC but rather a couple of days later in China Town in San Francisco, but I thought I'd share the laughs

So that’s it for pictures, I usually don’t take too many pictures because I want to appear all cool instead of all touristy (at least that’s what I think I look like, not that anybody looks like a tourist at a conference…unless it’s the tourism conference, then it just gets weird…)

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?

The lab or the cubicle?

Imagine this: you’re done with your lab work. You can go back to your cubicle/office/desk where co-workers can easily find you and distract (albeit, you can also probably have fun conversations) or you can stay in the quiet, isolated happiness of the lab and be super productive. What do you do?

I usually go for my cubicle. I have to admit, I am usually less productive in my cubicle. Mexicans tend to be noisy, nosy and easily distracted, meaning that being in my cubicle there’s a 99.9% chance that someone will interrupt me. On the other hand, just one of those distractions may end up being about something I didn’t know, a new idea, the birth of a project or a reminder of some task I forgot to do. My office works that way, our collaboration is high, mainly due to everyone being able to bother everyone else. It’s a wonderful cooking pot, an engineering stew, and I love it.

 

Except for the insanely brilliant and solitary minds, ideas are born this way. This is why I (mostly) always choose my cubicle. This has it’s downside, I’m so easily distracted that I usually have to make up for lost time after hours. It’s not a complaint, it’s just a fact, I prefer my work to happen this way. Why would I like to be an engineer in a stale environment without any idea exchange?

 

Of course I do sometimes need to be productive, after ideas are born someone has to turn them into a reality, that’s when I’ll take my headphones and isolate myself, either in my cubicle or in the lab. I also like that, to be so absorbed by something that it’s suddenly 7 in the evening and I didn’t even notice. I just can’t do it all the time, I’d probably wear my brain out.

 

My view is that collaboration is always better than brilliant over-productive single minds. An interesting mix of these two happens at Facebook. We’ve all seen it, either by seeing The Social Network movie (I do recommend it, by the way, great acting) or from the pictures in articles, the Facebook offices don’t even have cubicles, just desks, everyone can see everyone else. Even Mark Zuckerberg (Facebook creator) can be seen in one of those desks, coding away, instead of in some fancy corner office. But also, as can be seen at the beginning of the movie, Mark Zuckerberg is also a brilliant lonely coder. So it’s an interesting mixture, they hire brilliant minds but they enforce an environment in which collaboration is key, they even use modern practices like Xtreme Programming, where programmers pair up and work together (I’ve written some stuff on pair programming here).

 

So what are you? The isolated type or the collaborative type?

Some funny stuff engineers say…

Embedded systems engineers are usually creative people, we need creativity to keep innovation flowing and to solve problems in optimal ways. We also use creativity to cope with stress. Over the years I’ve heard some funny things come out of the mouths of over stressed engineers, causing generic group laughs that release tension in the room, at least for a little while. Causing it’s been a stressing day for me, I’ll share some of the funny things I’ve heard over the years:

• “No problem, if one fails, both will fail”. A desperate engineer assuring that at least he’s sure his bugs are repeatable.
• “A tester has to do what a tester has to do”. Some zen knowledge about software testing, I told this to a guy complaining that tests where too stressing on his code.
• “Users are always wrong”. I don’t endorse this point of view, but you would be right if you guessed that this phrase came as a reply to a phone call reporting a customer had found a bug.
• “Real programmers don’t comment their code. It was hard to write, it should be hard to understand.” The guy that said this actually does document his code pretty well.
• “Use a timer to turn on the RTC”. We where looking for a way to turn on the system in a specific timing and someone suggested a timer from the controller (which was off) should be used to turn on the RTC which would later turn on the MCU, luckily we discarded the idea and went to sleep.
• “That’s bad for the hard drive”. Said a guy to another who was desperately pounding his computer out of frustration.
• “Stop thinking and program”. Someone said this to me, I tend to overthink my code before writing it.
• “Software is always right”. I wish this were true.
• “It’s not a bug, it’s a design error”. Design bugs do exist, this guy just didn’t believe in them.

There you have it, hope you had fun, I did remembering all those incidents. Is your office as funny as mine?

If you doubt the power of laughter to cure stress and maybe even other things, read this article:

http://stress.about.com/od/stresshealth/a/laughter.htm

Building a freak guitar (of embedded systems and the arts)

For some months now I’ve been planning on doing a bunch of stuff to one of my guitars. A couple of years ago I bought a very old (built in 1977) guitar. The guitar was heavily modified (which meant the “original” value was not very high) and had a funny little sound. But I fell in love with it kind of how some embedded folk are in love with the 8051 CPU even being such an old CPU. It has this beautiful wood colors and the neck is amazingly easy to play. Those of you who play guitar should understand, those of you who don’t, imagine the best compiler that could ever exist…and it’s incredibly well documented as well – nay! Imagine the documentation is so good that you only have to think about what you want, and the document will pop up in your computer screen, in the exact page and paragraph you need to read…that’s how much I love this guitar. There’s also the fact that it’s old and uncommon, kind of like bragging that you can program in COBOL.

Yesterday I decided to start this project. I had bought some things in advance and was now basically ready to start soldering.

1977 Ibanez Musician in the process of being rebuilt

Sorry for the bad picture quality, I’m a engineer/guitarist, not a photographer. This picture was taken when I had removed mos of the internal electronics and was fitting the new pickups (or pups as we guitarists call them). Pickups are the magnetized coils used in electric guitars to sense the string vibration (just a cultural note). The old pickups on this guitar were particularly bad, I don’t know if it’s the kind of sound they liked in the seventies, or if they were too old, probably the input impedance in old amplifiers was different as today’s amplifiers (because of valve technology vs semiconductor technology), I don’t really know. The important thing here is that the original sound sucked to my ears (and that, of course, is subjective) so I wanted to change the pickups. Sorry to disappoint those of you extreme home-project builders: I didn’t wind my own pickups, I want this guitar to sound awesome, so I bought some pickups that I know will sound awesome. Now I’m looking into the right combination of potentiometers and filtering capacitors to get everything sounding as cool as it sounds in my head.

But I noticed something: there’s some extra room inside of my guitar back panel. The guitar used to have a bunch of switches to configure the pickups in all sorts of ways, I won’t be using all of the switches as the original configuration because I find some of the attainable sounds a bit redundant so now I’ll end up with some extra holes that will not look so nice. But then I got thinking about this effects pedal that I own that is some sort of audio signal processing development platform created by Freescale Semiconductor and Line6 (a guitar effects and accessories company which specializes in guitar amplifier and effect digital modeling). This little pedal (called the Tone Core) I own has an integrated USB bootloader with which you can load DSP code to the on board Freescale audio processor. The USB bootloader is controlled by an 8-bit USB MCU also from Freescale. The Audio DSP platform is a free Eclipse-based compiler and Line6 provides some example code to build an equilizer or a tremolo (volume swirl) effect. Based on those codes you can start writing your own effects from scratch. There is even an independent Tone Core wiki where people can post their effect code, and some videos on YouTube of people playing with the effects they’ve made.

So now I’m thinking that if I remove the metal chassis and just find a way to stick the effect pedal electronics into the guitar electronics chamber and use the extra holes that are already there to put the effect pots there, I might get to have some sort of freak reprogramable guitar…and I’m a fan of freak embedded stuff! Before you start telling me not to do the freak thing, consider this: Gibson, one of the most important guitar companies out there, has it’s own flavor of freak guitar, the Dusk Tiger. It’s not only a freak guitar, in my opinion, it’s one of the coolest embedded systems out there. Just a little bit of the specs:

- Robot guitar: this is what Gibson is calling their automatic string tuning system. It’s crazy, each tuner has a tiny stepper motor, and at the other end of the string there’s a piezo-electric sensor. You play all the strings at the same time and a processor inside the guitar determines the tuning on each string and adjusts the littler stepper motors accordingly. The guitar can be completely out of tune and re-tuned in seconds.

- Digital EQ with presets: a little knob allows you to choose from a bunch of EQ presets to output different sounds.

- Configurable: if the previous characteristics weren’t enough, you can plug the guitar into a computer and, via custom software, load new settings to the guitar, different equalizer settings or tunings.

Please visit the link to the Dusk Tiger, it’s such a weird and amazing guitar full of embedded systems wonder: motor control, digital signal processing, LEDs, connectivity, all sorts of fun!

So after writing this article I still haven’t decided if I’ll turn my guitar into a freak…any opinions?

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?