Archive for September, 2006

Martin Fowler started it with his assertion that entreprise development is where it’s at, and those who find it boring simply lack Customer Affinity.

Ravi Mohan countered with his observation that entreprise developers just wanna have fun by working on the infrastructure, but no plumber wants to cross that Berlin Wall! Edward G Niles points out that entreprise development can sometimes be fun, but coding in your typical entreprise (e.g. Health Care industry) is a soul sucking endeavor. He also has a follow-up post.
As for me, I just don’t know which side of the fence I’m on. My experience is different than most. I’ve never worked on entreprise software, although I have worked for a largish multi-national company, on a software team consisting of over 70 software designers. Did that inherently make me an entreprise developer, or does writing embedded systems automatically make me fall in the infrastructure category?

What about now? I work for a small company which produces both “shrink-wrap”ish software and hardware devices and associated firmware. In the end, just like Charlie Brown, I end up fitting nowhere.

Dynamic C : $200
Dynamic C is Z-World’s compiler for the Rabbit series of micro-controllers. The Rabbits are based on the venerable Z-80 architecture, and Z-world (soon to be renamed Rabbit Semiconductors) has managed to make a series of very affordable and versatile processing modules, including Ethernet Connectivity. The compiler includes an IDE used to perform the compilation, loading and debugging of the program.

The biggest issue you will face when using Dynamic C is the non-standard mechanism used by the compiler. Dynamic C does not have the normal concept of source files compiled to an object module, and the various objects linked together to produce the final image. Instead, it uses one .C file to hold the main program, and in essence, it includes a bunch of .lib files (really source files) which it compiles together to produce the firmware image.

Dynamic C does not have a normal #include directive. Instead it has a #use directive, which imports the above mentioned .LIB files. Since it does not have header files, functions are declared using a special type of comment:

/*** BeginHeader SerInitialize */
void SerInitialize(void);
/*** EndHeader */
void SerInitialize()
{ ... }

Dynamic C also extends the standard C language with the concept of CoState and CoFunctions. It is a way to perform multi-tasking, but much of the multi-tasking guts are hidden from the user. One the surface, this is appealing, but one quickly runs into limitations imposed by this particular approach.
The problem with this approach is that the code you write can’t easily be used as-is in a standard compiler. This makes it difficult to retarget some of the code, to run unit tests for example. If you have an extensive code base making use of the Dynamic C extensions, it would be nigh imposible to move to a different compiler, or easily reuse that code.

The libraries that come with Dynamic C are extensive and provide an good amount of functionality. The whole TCP/IP stack is present, including DHCP, an HTTP server and other functionality. Standard functions are also available to access the Rabbit’s 6 serial ports.

Z-world rolls out new versions of the compilers fairly regularly. As a result of the compiler architecture, whenever a new processor module comes out, a new version of Dynamic C must also be released. Unfortunately, there has been a few instances where upgrading the compiler has proved problematic. Some of it has been related to major changes performed to the TCP/IP stack between release 8 and 9 of the compiler.

At heart, Z-World is a hardware company. Their bread and butter is selling their processors and processor modules. Their compiler is only an enabler; after all, if there was no compiler, nobody would choose their processors. Ultimately, the historical decision to have their own dialect of “C” does developers a disservice.

Unless you absolutely need the support for the latest & greatest Rabbit processor (the R4000), or you already have a significant investment in Dynamic C code, there is at least one other alternative compiler out there you should seriously consider.

Lee Holmes is a PowerShell god! He’s also a nice guy…he posted a comment on my Monad Rocks! entry. In this blog, he shows how to add instant scripting to a .NET application using 6 lines of code and PowerShell. How crazy is that?!

Once again, the implication are staggering! Since PowerShell understands .NET objects directly, you simply create an object representing the scripting API to your application, host a shell instance and voila! Granted, PowerShell is for serious power users and you might not want to expose those capabilities by default, but when you need power that a GUI can’t provide, PowerShell is where it’s at!

On most large embedded devices (routers, telecom switches, etc…) you often have a management interface you can plug into. This interface allows you to do things a normal user doesn’t care about. Things like display a list of significant events, an audit trail for user transactions, display the live connections, etc…

Those capabilities help tremendously when the customer (AT&T, MCI, …) calls the telephone switch Manufacturer (Lucent, Alcatel, Nortel) at 3AM and is screaming that his phone switch is not putting calls through. If you think the Internet service providers and related agencies (CERT, etc…) respond quickly to an outage/virus, you clearly have not been around a “Fast Response Team” from the major telephony players. Those guys are awesome, but they have the (hidden) tools to diagnose and fix the problem, thanks to these administrative consoles.

A PowerShell interface could be one of those secret tools – for your own application. Awesome!

Ask any good mechanic, and they will tell you that a well stocked toolbox is essential. The same holds true when doing embedded system design.

There are three categories of tools on needs to be familiar with in order to succeed in this challenging world: Knowledge, Software tools and Hardware tools. Anyone who has programmed is familiar with the first two categories. However, rare is the individual who requires a hardware tool when programming an enterprise class, web enabled, business intelligence gathering Oracle masterpiece.

Knowledge

These should be amongst your most precious tools. You might have the best stocked software & hardware toolbox, if you don’t have the knowledge to apply those tools, you are doomed! Note that I didn’t say your most expensive tools; in general, those would be in the hardware toolbox. In fact, knowledge is the cheapest tool to acquire! Case in point: The incredible amount I charge for these words of wisdom. You want to learn to program in language XYZ…visit amazon.com, download an open source compiler and you’re there! The problem with knowledge, is that while it is relatively cheap to acquire, it can be difficult to find!

Here are some of the basic tools which fall under the knowledge category:

  • Programming Language
  • Basic understanding of electronics and the ability to read a schematic
  • General Data Structure & Algorithms (Linked Lists, hash Tables, Binary Trees)
  • Specialized Algorithms (Goertzel, Hartley Transform, Kalman Filters)

One of the fist place to start looking at is the Embedded Systems Design web site. It is a treasure trove of information on all things embedded. If you can get on the magazine’s subscription list, it is well worth it.
Software Tools

These tools allow you to translate your knowledge into something that will be useful.

  • Compiler & Linker
  • Algorithm Development tools (MathLab, Mathematica, etc…)
  • Debugger

One of the phenomenon you will sometimes see is that since each processor familly is so different, you end up with a collection of compilers. Each of them with their quirks.

Hardware Tools

This is where the embedded engineer blazes a different path from his desktop/web brethren. These are tools that while not always essential, will make your life a whole lot easier and more productive. If you always have to bug a hardware engineer to analyze something, that won’t make you win any popularity contests…

  • Oscilloscope – THE essential tool.
  • Digital Multi-Meter – for quick and dirty checks
  • Logic Analyzer – very handy to see what is really happening
  • Programming & Debugging Cable – How else do you transfer your program?
  • Emulators – If you want to know exactly what is going on inside

This list is by no means exhaustive, but it should give you an idea of what you need to get going with embedded systems.

Don’t you hate it when you open your mouth to pontificate and realize someone smarter than you has already done it better? There is a fantastic podcast with Nancy Van Schooenderwoert where she talks about introducing Extreme Programming to a new embedded project. Actually, the entire Agile Toolkit podcast series is fantastic.  It is “Inside the Actor’s Studio” of the agile world.

Getting back to Nancy V, some of the papers she wrote about XP and embedded development are available at Agile Rules. Highly recommended reading!