Category Archives: Hardware

Hardware centric

The MSP430 FET will never be the same

Hardware, MSP430

43oh just came with a post showing the new MSP430 Wolverine that is coming out really soon. This is an expanded version of the MSP430 using FRAM instead of Flash.

Wolverine

Source – 43oh.com

TI Has done some pretty interesting things on the board. An e-ink display with capacitive touch.  E-ink is a very good pairing with the MSP430 because they’re both targeted towards low power. E-ink displays can hold on to the last data displayed for extended periods of time without the need for power, and this works great for a lot of applications. Although the board is greenish, the actual board released will most likely have a different color scheme.

Despite all this I want to discuss something that we don’t see anymore. Take a look at the back of the board. This is the area usually reserved by TI for the on-board FET debugger.
I’ve been using the MSP430 for over 5 years and for all that time the FET has been built around an MSP430 paired with a TUSB3410 USB to UART, as well as EEPROM and a few external elements. On the Wolverine board, this isn’t there. The markings are not clear, but I believe TI has finally integrated the FET. The main chip that is at an angle is likely an MSP430 with integrated USB capabilities. There’s no longer a need to use an external TUSB3410 device, so the BOM is lower. It makes supporting the platform better. You can use DFU or other mechanisms and its a nice way to display the MSP430 USB capabilities.
The F5529 Launchpad board changed things a bit. The TUSB3410 was replaced by a TUSB2046.
Soon we’ll know.

Designing a System? Consider NRE vs. COGS

Electrical Engineering, Embedded Systems, Hardware, Software

There are always tradeoffs between Non Recurring Engineering (NRE, or product development costs) and Costs of Goods Sold (COGS, or the cost of the final product). The balance between the two depends on the project. Simple products will require lower COGS. However, never forget about NRE costs. It is possible for you to increase COGS slightly and save a lot of money on NRE. One example of this is an embedded project requiring UART. Assuming your microcontroller or design has no UART capability, you can go either the software or the hardware route. Most will go the software route. Why? obviously because software is cheap (the most erroneous assumption by some).

When you look at software, development is very expensive. Sure, you can bit bang UART and it will work, but to get it to work reliably will require code design, development and debugging. For just a little added cost to COGS (the price of the final product), you can save yourself major headaches, not to mention that you won’t be burdening your microcontroller with handling UART itself.

If you don’t believe it, consider that IBM’s own analysis of hundreds of software projects finds that software development does not scale linearly with complexity. Simpler software costs less.

Nonetheless, there are cases where hardware won’t do. This is especially true when upgrades will be required. UART is standard and won’t require upgrades, but a proprietary algorithm that’s in flux will change.

Unique Serial – Total Board Lifecycle Management

Hardware, , ,

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.

Electrical Engineering on Linux – gEDA

Electrical Engineering, Hardware

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.