Often times I’ve been faced with boards that have come back with issues. Doesn’t matter what it is. Usually, a sticker or some other indicator is used to remind me what the issue was so I can address it. As long as I have the board, it’s all good and I can keep track. But what happens when I ship it back to assembly or to the client? Stickers peel off. I have also written on the boards themselves. But these solutions are not ideal. A unique serial ID accessible by firmware is necessary. It allows me to track the board throughout its lifetime. Whenever possible, I’ve added such an identifier to a nonvolatile storage. But this requires programmings and other modifications. Another solution I’ve adopted for some boards I develop myself is to use one of Maxim’s 1-Wire Serial Number ICs. These little devices come in SOT23 and require VCC, GND and one data line. The DS2411, for example, has a 64-bit ROM with a unique 48-bit serial number, an 8-bit CRC, and an 8-bit family code. It’s hard not to justify 50 cents and a bit of programming (which is usually reusable).
Another major benefit of such devices is that board revisions can be be linked with software revisions, so that the right firmware is used for a board.
Many engineers know the feeling. A lost battle with a circuit where everything goes wrong not because it was badly engineered, but because the silicone has bugs in it that were only discovered after the board has been prototyped and failed to work as expected. It ends up wasting time and money, causes delays in time to market and might make a client doubt whether you didn’t put the bugs in that silicon yourself. Even though there might be silicon bugs that could have escaped testing, many would be documented by the manufacturer (and hopefully fixed or include a workaround) in the Errata. The Errata seems for many engineers to be an elusive animal, a document no one reads until after something has gone wrong(some of them do after all seem to be as long as the datasheet itself). That should not be so! Make sure you read the errata and ensure that nothing you’re trying to achieve with the device is affected by bugs (or that the workaround is acceptable). Moreover, make sure that the silicon version of the devices you obtain from your supplier are either the latest or don’t contain the bugs in early revisions. When in doubt, contact the manufacturer.
When you think of Sensor Networks, 2.4GHz transceivers likely come to mind. The CC2420 is one of the most popular transceivers for sensor networks and other applications and it uses 2.4GHz as per Zigbee. Of course, Zigbee does allow Sub-1GHz frequencies, but I’ve yet to see many of those made. Undoubtedly this is due (among other reasons) to the smaller antenna which results in a smaller PCB. However, there are several issues with these transceivers, among them:
- Operating sensor networks and other devices at 2.4GHz can be a coexistance nightmare. Consider that most deployments will be done in urban environments where the 2.4GHz band is saturated with Microwave Ovens, Baby Monitors, Bluetooth, WiFi, etc. A node needing to survive in this environment will experience frequent collisions. There have been several papers analyzing the performance of devices in these conditions and needless to say the results were far from acceptable.
- Decreased range is to be expected from higher frequencies as per the Friis transmission equation.
2.4GHz devices do have some advantages such as popularity, small size, and ease of interoperability. However, next time you consider a transceiver, don’t disregard the sub-1GHz options which might be better.
Some useful transceivers:
TI CC1101 – sub-1GHz transceiver with multiple bands, 10dBm output power, flexible modulation formats and 500kbps
TI CC2520 – 2.4GHz Zigbee compliant transceiver
There are many other manufacturers of RF Transceivers (especially Zigbee/ 802.15.4) such as Microchip, but I listed TI transceivers because they seem to be quite predominant in the market and I’ve personally used them in several projects. The CC2520 is an update to the CC2420.
Some of you might have heard about the new Cortex-M4 ARM Processor.
It’s a superset of the Cortex-M3, meaning it can run Cortex-M3 instructions while adding new ones. The processor is primarily targeted at DSP applications (which seems to be everywhere these days) but I suspect will be good for almost any application. Texas Instruments, NXP and Freescale have licensed the core, which promises an ample supply of choices for your next project. Another huge advantage of the Cortex-M4 is the addition of SIMD. If your data is 8 or 16-bit, you’ll be able to perform multiple operations in one clock cycle, giving a huge boost to many algorithms. The following table shows the difference in cycles for the several of the instructions:
||Long signed multiply
||3 to 5
||Long unsigned multiply
||3 to 5
||Long signed accumulate
||4 to 7
||Long unsigned accumulate
||4 to 7
Many algorithms will benefit from the single cycle instructions and even more from the SIMD instructions. There will probably be a lot of demand for those of us who still use Assembly.
For more information:
Cortex-M3 Technical Reference Manual
Cortex-M4 Technical Reference Manual
Let’s face it, many (if not most) engineering software is made to run on Windows. There are, however, many open source options that are worth while. I find gEDA to be one of these rough gems. gEDA is a Schematic capture, PCB layout, and simulation package. Although it’s missing features and is lacking on integration, it is close to Eagle CAD in its performance (and in some cases outperforms it). Many projects have used it successfully. I myself am working on some improvements I hope will be accepted upstream.
gEDA Home Page
If you’re looking to build from source (I highly recommend doing so, even if only to try), follow the instructions on this page. The only difficult part is to get all the dependencies, which is not that bad if you use apt-get or some other package manager.
I’ve been delighted to see the addition of price sorting at Digikey. It’s a long overdue feature that really helps speed up the component procurement process. I find many of the more expensive components are usually specialty components that I won’t need to purchase unless I search for them specifically.
Electrical Engineering is usually divided into many specialties – Power, Control, Microelectronics, Signal processing, Telecommunications, etc. and it’s rare for engineers to move away from their specialty. I’ve found that Embedded Engineers are sometimes required to work in many of these areas at once – to be able to get an application off the ground, you need to be able to understand many of the issues surrounding the system. Imagine how a microcontroller would perform if its supply rails were full of noise due to a bad power supply design or trying to perform an FFT on an 8-bit microcontroller? This clearly calls for knowledge in many disciplines.
My MSP430 has apparently been used by quite a few people (It shows up as #2 in Google if you look up MSP430 Tutorial). Does it need work? Yes. I’m currently working on adding many new sections, updating old ones and giving it a better look. However, for those who need some starting point, here it is:
This is my blog about engineering and my work. Stay tuned for some interesting tidbits I’ll publish soon.