Embedded in Cork

It’s been a might long time since I last created an EmbeddedSphere post. Here’s some web items that have caught my eye:

A ‘C’ Test: The 0×10 Best Questions for Would-be Embedded Programmers – An excellent example of sane C interview questions. Well worth a read.

Netrino – The tag line for the site is “The Embedded Systems Experts”. Well worth checking out as they kindly make a large number of embedded software articles available for reading.

Embedded Group on LinkedIn – There’s a group for embedded engineers available at LinkedIn. I can’t really comment on how useful it is as I haven’t had a chance to browse through it any detail yet.

Making C behave like C++ – Ah yes, the great C versus C++ debate for embedded systems. Miro Samek has a good article on how to add object based programming concepts to C. The comments on the post are well worth reading as well.

Before examining the different key design areas relating to the PowerPC kernel implementation it’s worth taking a look at the overall system. The purpose of the kernel is to support a GSM radio platform capable of supporting two carriers of GSM, GPRS or EDGE. At the heart of the digital part of the radio is a PowerPC based communications processor (PowerQUICC 2). The other main digital components on the radio are illustrated in the diagram below and include digital signal processors (DSP), an ASIC, PCI bridge and memory.

The PowerPC based processor on the board is responsible for radio application software associated with initialization and control of the radio transceiver. This includes responsibility for configuring, monitoring and communicating with the DSP block. A number of software processes run on the processor to take care of the radio subsystem (needed for channel configuration, handover, power control etc.) a data link service provider for controlling a HDLC link off board and other maintenance applications for TTY debug and alarm monitoring.

The real time response of the platform comes from the timing demands of GSM. The PowerPC based kernel must provide real time response to multiple interrupt sources, including DSP interrupts at a frequency of 577 microseconds, GSM frame interrupts, sourced from the ASIC every 4.615 milliseconds, GSM Superframe interrupts every 6.12 seconds, HDLC interrupts and TTY interrupts.

With the above processing and interrupt handling requirements it’s clear that a real time operating system is needed. So why persist in porting or developing an in-house solution instead of going with an off the shelf option such as Linux or VxWorks? That’s a question I hope to tackle in the next article. Stay tuned….

PowerPC Kernel Implementation for GSM Radio Platform – Previous Posts

• PowerPC Kernel Implementation – Introduction

As part of my work with Motorola I had the opportunity to be part of a team that ported an RTOS (Real Time Operating System). The original RTOS ran on a Motorola/Freescale 68K (68000) series of processors and we moved it to a PowerPC based communications processor.

During the summer of 2007 I was able to co-present a paper about the work we did at the Embedded Systems and Applications conference of Worldcomp ‘07. The title of the paper is “PowerPC Kernel Implementation for GSM Radio Platform” and as it was published and presented in a public forum it gives me the liberty to openly discuss the contents of the paper on this blog.

My hope is that this will be the first of a series of posts that delves into the key areas involved in implementing a PowerPC kernel. The kernel is at the heart of the RTOS, managing context switching, memory, stack switching, interrupts and system calls. I hope to touch on all of those areas, with a focus on the optimisations introduced to minimise the impact of running with a fully enabled memory management unit and unique user/supervisor/interrupt stacks.

I’ve recently started a new position with Silicon & Software Systems (S3) in Cork. The new role is with the consumer home product division as a senior software engineer and moves me away from telecoms and towards digital set top boxes. The good news is that it is still very much within the embedded sphere and keeps me in Cork.

First of all I must apologies for the lack of activity on this blog. My intention was to keep it current and flowing with embedded software related information. Hopefully I will be more diligent going forward in publishing fresh content.

On a personal note I’m currently looking for a new position in embedded software. My LinkedIn profile has a summary of my professional and education experience www.linkedin.com/in/ralphdepping and I am happy to email my resume to any interested parties.

EuropeanIrish.com have an ‘inside view’ article on the shutting down of Motorola Cork. Here are my own brief thoughts as I look back on my time there.

As a 2001 graduate I started my working career in Motorola Cork. 2001 was just about the worst year to look for a job as a graduate with an electrical/electronic degree. I almost didn’t take the initial offer from Motorola. At the time I had two concrete job offers, including Motorola, and I was waiting to hear back from a number of other companies. I told one recruiter from Alcatel that I might turn down all the current offers, take the summer off and re-apply in the Autumn. Thankfully she told me to take one of the two current offers as the scene was changing fast and there would be few companies recruiting within a couple of months. So taking on board her advice and wanting to stay in Cork I ended up in the GSM Base Station Systems software group.

Looking back I didn’t realise at the time that the variety of projects I got to work on was somewhat priviliged. A lot of engineers end up getting stuck in one area, often gaining some domain knowledge by fixing bugs before going on to work on features in that domain. At almost the start of my time there I got to work on a critical software element of a massive project to introduce new radio hardware into one of Motorolas base stations. Not only that but I got to work with a very dedicated and skilled group of engineers to make it happen.
A lot of the good memories are not the result of the big corporate system that was at play in Motorla, but rather down to a handful of dedicated and helpful engineers who really cared about the work they produced. Working in the BSS group was a great fit. I worked at the level of assembly programming an MMU on a PowerPC based network communication processor right up to writing application code for implementing 3GPP spec defined call processing features.

Alas the BSS group in Cork was closed down in 2005 and the work shipped to China. The writing had been on the wall for that move way back when I had joined in 2001. At that point the BSS group were training up 5 Chinese engineers on site in Cork. Concerns about training up people to take our jobs were allayed with the assurances that there was plenty of work to go around and we need a development presence in China close to our customers.

As a result of the loss of the BSS group my last few months before quitting Motorola in the summer of 2006 were served out working as a Systems Engineer. I got to work on a high-tier element management system for WiMAX. Although it was nice to explore the land of UML, requirements and architecture it made me long to get back into the embedded realm.

So I finished in the summer of 2006 and took away the great memories and immense amount of engineering skill and knowledge I managed to glean over my 5 years in Motorola Cork. Now I’m working for a small company just down the road and back working on embedded software. Hopefully the engineers pouring out from Motorola over the next months will find suitable work. I wish them all well. Bye, bye Moto.

A large amount of the hits on this site are for a previous previous list of C technical interview questions. As a follow on here are my top tips for technical interviews along with some additional technical interview links. Nothing here is revolutionary, rather it’s some advice based on my own experience of attending a number of technical interviews for embedded jobs.

1. Be on Time

Although this is one of the more obvious points regarding interviews it is still worth re-stating. Allow plenty of time to find the correct location, taking into account possible traffic delays. Also make sure you know where the interview is actually taking place. One recruitment company sent me to the offices of the company instead of the hotel where the interview was being held. Fortunately the hotel was near the office and I had enough time to make the short trip and still be on time. On a related note don’t show up too early. It may make people uncomfortable to have you sitting around for a long time at reception.

2. Make a Good Last Impression

The old saying regarding the importance of “making a good first impression” also applies to “making a good last impression”. I’ll always remember a test the BBC carried out. They showed two different versions of the same interview. In the first instance the interviewee started well but finished poorly. In the second instance the interviewee started poorly but finished well. One half of the viewing public saw the first version and the other half saw the second version. The public were then asked if the interview went well for the interviewee. It turned out based on the public votes that leaving a good last impression is more important than making a good first impression.

3. Avoid Technical Jargon

Although it’s a technical interview avoid using too much jargon. The person will be more impressed with your ability to describe the work you’ve done in a clear and concise way than trying to dominate the conversation with obscure technical waffle. Remember that you may know more than the person interviewing you in a particular area but you won’t score many points by trying to show off.

4. Can I Work With This Person?

One of the key questions that both sides to an interview should be asking is “Can I work with this person?”. Ticking all of the experience and educational boxes is rarely enough to ensure a successful working environment. An interviewer will be wondering what it will be like to work with you on a daily basis. Ensure that during the interview you don’t loose sight of what the day to day working conditions will be like. Think of a couple of questions in advance that will highlight a typical working day. Is it high pressured or relaxed? Do people tend to spend lunch together or do most people just grab a sandwich and eat it at their desk? Try to relate to the people at the interview as they may end up being co-workers in the near future.

5. Do Your Homework

The most obvious aspect to this is to research the company you are applying for. However if you can find out the name of the interviewer(s) better again. It’s amazing the amount of detail that can be found these days on the Internet. Google is a great starting point, but consider searching more specialized sites such as linkedin or zoominfo If they have a relatively common name that throws up numerous results trying narrowing the search based on the company name or the geographical area the company is located in.

6. Be Prepared to Address Salary

One of the hardest questions to address in an interview can be that of salary. This is especially the case for new graduates, for whom this is probably their first experience of interviewing for a job. Make sure you’ve done your salary research. If your using a recruitment company they are often in a position to negotiate on your behalf and should have a good idea of how far a potential employer is willing to go in terms of salary.
One way of shifting the discussion and giving a potential employer more scope is to discuss the overall renumeration package. Salary is one aspect (and of course the major one) but things like pension, health insurance, gym membership and even additional holiday entitlements all add up. Recognize that taking on a new employee is a risk for the company and they want to make sure they don’t start you off on a bloated salary as it is hard to roll back from that point. If salary is becoming a major sticking point consider offering to prove your worth over a 6-12 month period. At the end of an agreed period if you’ve lived up to your own hype then the company should be willing to reward you appropriately. If not then do you really want to work there anywhere?

Tech Interview Links

• An great article from the other side of the fence, how to recognise a good programmer during an interview.
• Although some of the suggestions are, in my opinion, a little over the top i (I can’t see a HireMe book taking off in Ireland) Nailing Your Technical Interview does have some great advice on areas most of us wouldn’t naturally consider.
• Finally for those just looking for more C programming related interview questions then apparently these are some of the interview questions that Microsoft ask.

The Register reports from the CanSecWest security conference in Vancouver on the threat to embedded devices from hacking. However the specific threat to a router requires direct hardware access. More worrying are the threats that are going to emerge as more and more embedded devices acquire IP addresses and are exposed to remote access. EmbeddedSphere #3 contains some more links on the topic.

Doug Gaff, an embedded enginer with Rind River speaks highly of his time at Virginia Techn University. Sadly the University, especially internationally, will be mainly known for the terrible killings that took place there this past week. Doug’s post helpfully points to the positive aspects of the University and town of Blacksburg, in particular it’s contribution to engineering.

Damien Mulley is looking for your old mobile phones. Although not strictly related to embedded software the request is curious enough to make me wonder what he is up to, especially as the phones need to be in working order and you won’t get them back.

Finally Clare Dillon from Microsoft Ireland highlights a free one day introduction to developing software for Windows Mobile. It’s been run by Microsoft in Dublin on May 14th.

It’s been a while since the last post. There’s a few in the pipeline but in the mean time here’s another quick dip into the EmbeddedSphere.

Zfone from Phil Zimmerman is continuing to take some massive strides towards acceptance by the IETF according to the VOIPSA. So as VOIPSA asks why doesn’t Skype embrace a protocol like ZRTP to deflect the criticism and suspicion surrounding it’s VoIP encryption?

Doug Gaff gives embedded engineers a scare by asking is the embedded industry dead? Embedded Processors from ExtremeTech is a great introduction to the embedded processor market (although the article is now 5 years old). Making the Pentium processor’s market share equate to practically 0% should come as some comfort to embedded engineers that are worried about the death of their industry

The Embedded Components blog allows active contribution as means of increasing your influence in the embedded market place. The blog seems to have quite a low rate of posting, but it’s still great to keep coming across embedded focused blogs.

China Daily reports that tickets for the 2008 Olympics will have embedded RFID chips in order to prevent counterfeiting. This was also done for the last football world cup.

The Register reports on plans to test programmers ability to program securely as a help to software buyers. If like me you assume that embedded devices are hard to attack then this article on embedded security will give you pause for thought. Of course once you add one of those fancy IP addresses to your device you open up a whole world of security pains for your embedded device. Just look for embedded security on Google and examine how many of the top results relate to IP.

We write code for humans, not computers. That may seem a strange statement, but when you consider that machines don’t care about the number of source files you have, the use of nice variable names, comments, white space, new lines, functions etc. then it’s clear that the main audience for the code you write is the human reader. So if you’re going to bother to write code that can be read by a human then it better be easy to understand, preferably first time. Scott Belware uses the term Soluble Code for code that can be understood first time and his short summary on the topic is excellent.
(By the way one possible exception to soluble code may be when writing assembly, but even then clear comments, spacing, multiple files etc. should still be present).

Quickly, pick a number between 1 and 20? So how “Random” was your guess? Turns out humans aren’t great at doing random and 17 is the most random number we come up with between 1 and 20.