By Brian Finkel
I reflect on a recent visit with my 84-year old Aunt Honey. As you might expect, she is not an avid cell phone user. She wanted help entering contacts into her phone. She has a basic phone so we had to enter text using the “9-up” keypad. Her objective is to make phone calls by selecting someone’s name instead of typing the telephone number.
The event had me thinking about the way we used to make telephone calls – using an address book or a phone list and then typing in the number. In my youth, things weren’t so bad – everyone lived in the same town – with the same area code and only a few prefixes. For each friend you only had to remember the 4 digits and perhaps which prefix to use. Fast forward a few years and with the advent of cell phones, IP telephony, new area codes, and geographically-dispersed friends and family – you now need to remember 10 digits. 10 digits is beyond most people’s working memory (which is typically 7 digits). Address books and phone lists were required.[International Readers: The North America phone number is 10 digits. 3-digit Area Code + 3-digit Prefix + 4 digit Number]
Enter the cell phone. And the ability to program phone numbers and contact names into the phone’s memory. That enabled me to Dial-by-Name. Dial-by-Name is intuitive — my Aunt Honey is a person not a 10-digit number. Dial-by-Name is efficient – no more rummaging through the desk drawer for the phone list, no more typing a wrong number, no need to memorize 10 digits. That saves me time! Dial-by-Name is intuitive and efficient compared to the old way.
Before I compare Dial-by-Name to what we do at Wind River, I’d like to take a minute to give kudos to the mobile phone developers for creating this seemingly simple user experience that we now take for granted.
Look at your cell phone. Under the covers things aren’t so simple. Your phone is a complex wonder of miniaturization enabled by numerous technology advances: low-power CPUs and communications chips, small-form factor batteries, cost-effective LCD displays, and thousands of lines of code ranging from device firmware to applications. There are dozens of components that had to be developed, integrated, and finely tuned: the phone dialer application, the contact list application, the CPU, the baseband communications chip, the keypad, speaker, LCD display, headphones, Bluetooth, and more – all working together in harmony. It took 100’s of engineers, project managers, and quality assurance professionals (and a little luck) to deliver Dial-by-Name on your phone. So congratulations to the mobile phone developers out there for making our lives simpler!
So why does this all matter to you, to me, and to Wind River?
I assume if you are reading this blog you are probably closely tied to the embedded developer community. No doubt, you and your colleagues are using or considering multi-core SoCs. These devices are becoming increasingly complex – integrated peripherals, co-processors, 3 levels of cache, and so-on. And to realize the benefits of these devices, you are considering multiple operating systems running on the same CPU potentially in a SMP (Symmetric Multi-Processing) or virtualized system configuration. Your world is complicated. As an example, if you are designing network infrastructure gear, you are probably consolidating data plane and control plane functions onto a single board, blade, or SoC running a combination of Linux, an RTOS, and/or a low-level executive, partitioned across multiple cores or processors.
As an embedded developer, how do you take control of a complex system like this? How do you debug and resolve issues that are prone to arise in this complex multi-core system environment?
As tools developers at Wind River, we strive to deliver solutions that are intuitive and efficient.
Here are some of the challenges we think about on a daily basis:
- How do you simultaneously visualize and interact with the resources for 8 cores in a single IDE?
- How do you provide visibility to multiple operating systems each running its own set of processes, threads, and applications?
- How do you debug guest operating systems running on a hypervisor?
- How do you provide a flexible GUI so that different types of users – hardware engineers, device driver developers, application developers, system integrators – can view and control system elements important to the task at hand?
- What is the best way to represent an embedded system on a 1280 x 1024 display using graphical elements such as colors, fonts, tabular views, scroll bars, icons, expandable lists, progress indicators, windows, and more?
In order to deliver innovation, we embrace a customer-oriented approach in developing our tools. Through our local technical support organizations, we reach out to you to understand the problems you are trying to solve. We implement your usage models and desired “workflows” within our development and quality assurance processes. This approach is yielding innovation.
A recent example is the SMP Debugging capability delivered with our On-Chip Debugging (JTAG) solution. When using Workbench 3.2 and our Wind River ICE 2 JTAG debugger, you can logically represent an OS running on multiple SoC cores as a single system. This enables an intuitive debug experience — operations such as breakpoint management, kernel visibility, and run-control are managed at the system-level. Similar to how Dial-by-Name abstracts the 10-digit phone number, we’ve abstracted the details on each of the cores. It’s intuitive because it’s the way you think about your system.
We look forward to hearing your feedback on how we can make your life easier through an intuitive and efficient development tools experience.
Brian Finkel is a Senior Product Line Manager for Wind River Development Tools and On-Chip Debugging Solutions. One of Brian’s current initiatives is to deliver a world-class debug experience for developers implementing complex multi-core and multi-OS systems. Brian has 15-years experience in product management, technical marketing, program management, and business development roles at Wind River, Marvell Semiconductor, Intel, and IBM. Brian holds a Bachelor of Science Degree in Electrical Engineering from Rutgers University.