embedded
Archived Posts from this Category
Archived Posts from this Category
Posted by benoit on 26 Feb 2007 | Tagged as: embedded, ramblings
Today has decidedly been an interesting day…one where no matter how much I wanted it, a device simulator was simply not going to do…real hardware reared it’s ugly head and I had to break-out the oscilloscope.
You would think that a small PIC processor running at 8MHz would be able to handle the requirements for the Dallas 1-wire bus. It worked just fine with the serial-to-1-wire converter we use. Unfortunately, hooking it up to our embedded controller caused the integration blues to burst on the scene.
Our controller uses a Dallas (now part of Maxim) DS2482 to do the interfacing from the processor to the 1-wire bus. That device definitely has its quirks! The trouble we ran into: the DS2482 has much faster transitions than the converter we were using for design. Turns out it was too fast for our 8-bit processor!
5 different permutations of assembler instructions later, the problem was fixed. And you think software is a handful! Hah! But this is what makes embedded a challenge! Do you have what it takes?
Posted by benoit on 20 Feb 2007 | Tagged as: embedded, ramblings
Jack Gansle has updated his salary survey for 2006. The original embedded engineer 2004 salary survey is still available. Go have a look and see how you stack up to the rest of the world.
Posted by benoit on 18 Feb 2007 | Tagged as: embedded, 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…
Posted by benoit on 15 Feb 2007 | Tagged as: embedded, ramblings
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!
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…
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…
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.
Posted by benoit on 12 Feb 2007 | Tagged as: embedded, ramblings, review
We have been using PIC based micro-controllers for the last year, and generally been satisfied. One of the annoying thing we ran across is that the smaller controllers (with only 8 pins) don’t support debugging. To develop (and debug) your code, you need to use a special ICD version of the chip which only comes on an adapter board. Honestly, that is just a minor annoyance.
The real problem we ran into is the eternal nemesis of embedded development: firmware upgrades. In order to upgrade the firmware on a PIC based device, you have to connect the programmer to the processor (often using some kind of clip), fire up the firmware upgrade program and download the new firmware image. No big deal, except when you’re in the field, must unmount the unit from the wall, open up the case, connect everything to your laptop, perform the update, close the case and remount the unit. Now multiply this by a few units scattered around campus, and you’ve eaten up a day…
Enter Atmel’s AVR family of processors. The primary reason we’re looking at them? The ability to perform a firmware update under software control. They call this self-programming flash. Essentially, with the AVR processors, you can partition your flash into a small bootloader section and an application section. When running under bootloader control, you can program the application into flash.
This my friends is a huge advantage when upgrading units in the field.