Low Country Software Ramblings

In your new project, you need a processing core to control your fancy new whizbang device, which can reside on a main board.  The question is: Are you better off buying a commercial processor board or designing your own module?

Just from a dollars and cents perspective, a commercial board will typically cost you a minimum of 3 times the Bill-of-material cost.  For example, if the module you are considering costs $60, you can figure that the manufacturer’s cost is about $20.  Thus, if you were to roll your own module with similar features, you can estimate a similar cost for your own production.

Does saving $40 per module worth the trouble to design your own?  As with every other engineering questions, the answer is “It depends“.

If your plans are to ship 100 devices per year, a $4000 savings per year is chump change and the engineering effort will end up costing you way more than $4000.

If you ship 10,000 per year,  then the savings are more than enough to recoup your development cost.

What about 1000 units per year?  On the face of it, you would save $40,000 per year, but keep in mind that you need to design your board, debug it and also potentially write quite a bit of code to provide the drivers (which would typically be available from a commercial board vendor).

The other big factor in all this is time.  You save a large amount of time if you buy off the shelf.  And occasionally, that trumps everyhing…

No Comments »

Your company has been using an 8-bit processor for years, and you have a new project coming up.  The question comes up: What processor should we use?
In this day and age, some would say that there is no reason to do an embedded design with anything less than a 32-bit machine.
These days, you can get full fledge 32-bit processors for less than $10 in single quantity!  In fact, you can get an ARM based processor for less than $3 in quantities!
Some 8-bit processors go for $14!  So why would you not move to a 32-bit processor?

As with most things, it depends on your application!
If you have a low cost application that does not require fast processing or I/O, not much RAM, etc… then a single chip 8-bit processor that costs pennies is clearly the way to go.
If you have a high-end data crunching router, anything less than a power packed 32-bit processor is foolhardy!
But what about the grey zone in-between?
Let’s say you have these requirements:
- 10/100 Base-T Connectivity
- Support for 2 serial ports
- Support for storing configuration items in non-volatile memory
- Support for storing Data on a removable media (SD/MMC card or such)
- $30 Processing Block budget (e.g. Pocessor, RAM, Flash, EEPROM, etc…)

There are a number of processors out there, both 8-bit and 32-bit which would meet these requirements

What should you base your decision on? A host of factors.  Here are two areas to look at.

Generally speaking, 32-bit processors will require more memory.
A number of 8-bit micro-controllers come with built-in memory (PIC, Atmel) up to 128 or even 256Kb.
For many applications, this is all the memory that would be needed.
Contrast this with a 32-bit processor, which will usually require external memory.  In addition, this memory will generally need to be 32-bit wide.  That’s 4 times the bus width of an 8-bit processor.  Also, mahcine instructions tend to be 32-bit wide, such that the memory requirements of a 32-bit processor are simply larger.

8-bit processor toolchains come with more for less.
In most cases, an 8-bit processor toolchain will cost significantly less for an 8-bit processor than a 32-bit processor.
You need a way to connect to the processor, to program the flash/eeprom and debug the software.
8-bit processor debugging devices range from $50 to $300.  This will often include the debugger.
In fact, 8-bit processor vendors will often provide a development environment for free.  This includes a debugger and an assembler (C compilers are usually extra, or 3rd-party provided).

Contrast this with a 32-bit processor, where a JTAG probe can range from $400 for a very basic serial port based probe,  $8000 for an Ethernet based JTAG device, to $12,000 for a processor trace module (a way cool and worthwhile addition if your budget permits).  Rarely will development tools from the vendor be free, but most processors have a GCC compiler port available.

No Comments »

Steve Eichert’s recent blog entry about consulting (and DomXml’s article on consulting rates) got me thinking about my experience (or lack thereof) regarding consultants.  Working for a small company where the management team is very fiscally responsible represents some challenges.  It would be nigh impossible for management to bring on a consultant with a rate of $90/hour.

If you take the $90 figure at face value, you might think that it is equivalent to a salary of  $187,200 (at 2080 hours = 52 weeks @ 40 hours).  Quite a gap from the $77,000 average electronics engineer’s salary (a close enough comparison to software in my book).  However, here are some points to keep in mind:

• Employer provide roughly 10 days of statutory holidays.
• Employees have a minimum of 10 days vacation
• Let’s throw in 5 sick days.

These are days that your employees have 0 productivity yet still draw a salary. That means the total annual hours of work from your employees are now 1880.   This still gives our consultant $169,200.

Your employee typically gets some benefits that the consultant does not get:  Health & Dental Insurance, retirement benefits, etc… Let’s round that to $10,000 (on average).  The gap narrows: $87K to $169K

On the number of hours worked per week:  A good consultant will only charge you for time spent on your project. To stay relevant to the industry, the consultant has to spend time looking at new technologies and experimenting.  Let’s give them 1 week for training (which your employees should also get!).  Let’s also give them 5 hours per week for them to keep their skills up to date.  Our consultant now can only work  1610 hours per year.  Their salary is reduced to $144,900.

If we were to leave it at that, this still looks like a huge compensation (although I hear in NYC, a new employee at FogCreek could make 6 figures with great benefits - but Joel goes for the Cream of the Crop).  The one factor implied in the 1610 hours per year is 100% employment.  Chances are, some of your time as a consultant will be spent “marketing” yourself and finding jobs.  If you’re good, and live in a metro area (or are willing to relocate to the job), this might be a fair assumption but then again, you’ll probably be charging more than $90/hour…  For most consultant, some time will be spent hunting for work.  Let’s call it 20%.  Our highly paid consultant is now only going to work 1288 hours in a given year.  At $90/hour he is now paid $115,920.

Not cheap, but lets face it, top notch employees can earn that much…And if you’re looking for a consultant, they have skills that you need and don’t possess.  That’s worth something.

No Comments »

Since I’m an embedded engineer, I deal with hardware devices…Serial based devices, ethernet devices, wireless devices, if just never ends…

Did I mention I also have to write the PC drivers that talk to those devices? Here is a dirty little secret: Dealing with real hardware is a royal pain!

• You have to find one

Early prototypes can be difficult to come by. It might be an expensive piece of equipment that belongs to a different department or partner. It might be something from long ago which got put in “storage”.  There goes an hour or two…

• You have to hook it up

Sometimes, it’s easy…Plug in the ethernet cable, and you’re done.  Other times, it is a nightmare… Solder a couple of wires from the board to the RJ-11 jack, hook that up to the data converter, which is connected on an RS-485 daisy chain which hooks to the RS-485 to RS-232  converter, hooked to the PC.  For some strange reason, we can’t seem to communicate.  See more hours fly by…

• You have to configure it

Sometimes you are lucky, and the equipment does not require configuration, but more often than not, you need to configure it.  This might mean finding the configuration software, reading the manual, figuring things out.  Where did my day go?

Since I have personally experienced all of these things (occasionally all at the same time), I have come to the conclusion that if I don’t have to deal with real hardware, I should avoid it.

Of course,  I still need to work on those PC drivers.  What is my secret you ask?  I write a hardware device simulator!  I will invest one or two days to do a quick and dirty simulator.  Just a console application with a text configuration file and no UI.  Then it’s done and I know I will save time down the road.
Don’t get me wrong, sometimes you just plain need the real hardware, especially when you want to test that your system works correctly.  But often, if you have a simulator that behaves 80% like the real hardware, it will be good enough for your purpose.

Case in point:  We have to reproduce a customer’s setup, which has 20 devices in it.  It would be a huge time sink for us to set up the real hardware, not to mention the cost involved.  Using a device simulator on the other hand,  makes it quick and easy.

No Comments »

Long time readers might remember that our company decided to run an experiment to see if scrum-like principles could be applied to areas other than software engineering. The results are in, and while the experiment would not be deemed a success, I sure did learn a few things.

• Team members should have clear focus.
• Upper Management must buy into the concept with more than words.
• The team members need to see the benefits.
• A single blade of grass a grassroots movement does not make
• The facilitator should not go on vacation during the 1st month
• Going from nobody being in charge to no one being in charge is not progress!
• Teams should have a clear mandate and have a critical mass (more than 3 people!)
• A small company, where everyone has 5 roles is not the best place for agile processes.

We ended up hiring someone to oversee the operational aspects of the business, more in line with traditional project management. I believe this was the right decision for us. Your mileage may vary.

No Comments »