Every journey goes more smoothly with a map of some sort. Whether it’s a trip to Antarctica or developing firmware for a new microcontroller-based device, it helps to know where you’re going. Without a clear definition of the destination it’s tough to know when you’ve actually arrived. It is also helpful to know what it is, exactly, you expect to find when you do finally arrive. Continue reading ‘Maps and Plans’
Archive Page 3
Tags: development, Electronics Engineering, Engineering, software engineering, software testing
Tags: Electronics Engineering, Hardware
They are all around us. In our watches, laser pointers, hearing aids, toys, calculators, remote control units, and more. Yet we don’t often notice them or give them much thought until they stop working. And then it’s time to poke through the selection at the local drug store or big box retailer, hoping to find one that has the same cryptic number (or at least something that claims to be compatible).
Originally developed for use in hearing aids, so-called coin and button batteries are, as the names suggest, small disc or button-shaped batteries. They come in a variety of formulations and shapes. They can be stacked in series to produce a higher voltage, or wired in parallel for increased current. If purchased in bulk (such as through vendors on Amazon) they are also surprisingly cheap, and they pack a lot of energy into a very small package.
Continue reading ‘Tiny Power: Coin Batteries’
Tags: Arduino, Hardware
Over the years I have found that, at least for me, there are two major annoyances of working with microcontrollers: Packaging and a user interface. I’ve dealt with the packaging annoyance by resorting to techniques from the past involving wood (see my O’Reilly article here) or employing non-conventional packages (like an electrical junction box from Home Depot or a section of PVC or ABS pipe). When I finally get my CNC router/cutter up and running I will be able to easily make neat square holes in plastic and metal panels, but until then I’m fine with mounting my MSP430, or PIC, or Arduino, or whatever, on a wood base and just rolling with that. Or I can stuff it into a section of 3″ PVC and hang it in the olive tree so it can monitor the number of hummingbirds that visit the feeder each day and the level of the food in the feeder.
But that leaves the other source of sand in my swimsuit: The user interface. A serial interface, either via USB or RS-232, is fine for some things, but it’s not exactly what I would call user-friendly. Cryptic commands to remember (I use a cheatsheet), and sometimes equally cryptic responses to decipher. Sure, a serial interface can be implemented so that it looks like a pared-down terminal of some sort, but that represents a significant amount of code to handle the input/output, parsing, and response generation, and microntrollers don’t usually have a significant amount of memory. If I’m going to put that much effort into the code for the user interface then why not build something really nice? Like, for example, a color TFT display with a touchscreen? It’s actually not that hard to do.
Tags: programming, Python
Python’s import statement is an executable statement like any other. This means it can be used to determine if a particular external module is available. If a module is not available for import, the program can either modify its behavior accordingly, or shut down in a graceful fashion. Continue reading ‘Determining Python program behavior based on available imports’
Tags: development, programming, Software, software engineering
Software matters because without it a computer-controlled instrument, device, or system is just a collection of plastic, metal, and silicon. It does nothing.
Without software an interferometer is just a bunch of mirrors and lenses. Without software a CCD or CMOS image sensor is just a slab of inert silicon. Without software a deep space probe is a piece of very expensive metal sculpture. Without software data collection and analysis becomes an exercise in jotting numbers in a notebook, pushing a slide rule to get approximate numerical results, and dealing with errors. Lots of errors.
Good software is not trivial, nor is it easy. It is not the simple exercises encountered in undergraduate courses, nor is it the hacked logic and unreadable gibberish generated by overcaffeinated graduate students late at night. Good software is the result of applied discipline, resulting in the creation of an abstract logical construct that is coherent, readable, elegant, and reusable. Good software is beautiful.
Tags: Management, programming
I don’t know what it is about programming and software engineering, but these two fields seem to attract a significant number of people with some serious personality issues.
One of the types I’ve encountered on a regular basis is what I call the APAP, or Arrogant Passive-Agressive Programmer. These are the people who will go in and rewrite existing code just to show off how clever they think they are, but can’t be bothered to document what they did or why. Heaven forbid that they should go and actually talk to the original author of the code before making changes to it. Another variation on this is the person who won’t talk directly to the person originally responsible for the design or the initial code, but instead go to the group manager, or someone not even directly associated, and discuss issues and changes with them instead.
Continue reading ‘Dealing With Arrogant Passive-Agressive Programmers’