FreePCB Arduino Shield Template

Having been too busy / lazy to sit down and learn Eagle CAD or another “real” PCB program, I’ve been using FreePCB to make all kinds of PC boards on the LPKF board plotter at work.

With our increasing use of Arduinos (we’ve been using them in Senior Design projects for several years now, and are starting to teach introductory programming with them), we will almost certainly need to design Arduino shields in the near future.

Having looked online and not found an Arduino shield template for FreePCB, I decided to make one.

(Screenshot of template in FreePCB)

The template, rendered in FreePCB. (Click for larger.)

Here is the FreePCB template file. Remember to save a copy before you modify it with the components and traces for your design.

“Share and enjoy!” (CC:BY-SA)


Posted in Arduino, Design, Digital, Electronics, Resources | Tagged , , , , , , , | Comments Off

User Interface Done Right

Advances in technology often make possible new, more efficient ways of doing things. This can certainly make our lives easier and more enjoyable. As with any change, however, there can be drawbacks. The operation of new devices is not always intuitive to users who have never seen it before. Novel devices should be designed with a naive user in mind: the device should teach the user how to use it — ideally, with little or no effort on the part of the user. This advice is especially relevant in situations when the use of new technology is forced upon users, such as in public restrooms. Infrared towel dispensers, which require the user to perform a kind of modern-day rain dance in order to obtain a towel, are increasingly prevalent. The benefit is that you don’t have to touch the dispenser to get your towel — but for someone who has never seen one before, they can be confusing at first. Sometimes, however, a small change in operation can make a device a lot more intuitive to use. A local community college recently installed touchless towel dispensers in its restrooms. These dispensers, however, extend a towel right away, replacing it immediately when it is taken. Even if a user hasn’t seen one of these before, they will probably understand that they are supposed to take the towel.  When they do so, the dispenser replaces it. Now the user knows how the process works, without ever having to figure anything out! 2014-08-07 17.32.55_sm

Posted in Design, Digital Citizenship, User Interface Design | Comments Off

How Not To Code

Recently, my friend Dan shared a thought-provoking picture of a quote by Martin Golding:


"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." --Martin Golding

Words to live by.

When I first started writing programs back in the Dark Ages (1980s), I wasn’t even aware that coding styles existed. Not only did I probably break every applicable rule in the Embedded C Coding Standard — my code was usually cryptic, terse, and would have been very very difficult to scale.

Nowadays, looking through my code library, I can almost tell when I wrote a piece of code, based on how it looks. Here’s an example of some of my oldest BASIC code that I could find: (The file, helpfully, was called “T.BAS”)

10 FOR X = 1 TO 1000000
20 P = 1 / X

This is Dark Ages code for sure. No comments or other documentation whatsoever, single-letter variable names (the only reason TIME$ is there is that it’s built-in), and LINE NUMBERS. Fortunately, this program is very simple, so it’s an easy enough task to figure out what it does. (It’s a very simple benchmark for a division loop.)

Here’s how I might write it these days:

‘Division loop benchmark test program (FreeBASIC)
‘Notes time to execute one million divisions of size double
‘M. Eric Carr / eric(at)(email address)

‘Variable declarations
dim as double quotient
dim as ulongint curNum

‘Note the start time
print “Doing 1,000,000 divisions…”
print “Started at: “;time$

‘Run a loop of 1,000,000 divisions
for curNum = 1 to 1000000
quotient = 1/x
next curNum

‘Note the end time
print “Ended at: “;time$


This is a little better. It’s still flat code (no subroutines or other hierarchical structure), but it’s simple enough that such structure isn’t really needed. The documentation and intuitive variable names make it much easier to maintain, the output now tells the poor clueless user what is going on, and the global variables are at least declared.

Here are some other helpful tips to make your code more maintainable:

  • Use comments liberally. If it isn’t immediately obvious what a line of code does, document it inline with comments. In fact, it can be helpful to write the entire program in pseudocode, as comments, and then go back and fill in the mechanics.
  • Use intuitive, descriptive variable names. A variable named “x” can mean many things, but one named “currentOutdoorTemp” is a bit more descriptive. When using a compiler, this has zero runtime cost — the compiler will translate the variable names into memory locations automagically, anyway.
  • Use structured programming. If you have several pieces of information that belong together, consider using custom data types. If you have a program that is more than a dozen lines of code or so, it has probably become large enough to be split into subroutines. Doing so modularizes the task of programming, making the program easier to understand and far easier to maintain, modify, and scale.
  • Along with the “structured programming” theme, use as few global variables as possible. They can be modified by not only the main code, but by subroutines, making it potentially very difficult to diagnose what is happening. For multithreaded applications, this becomes crucial; any global or shared variables will require good, solid mutexes.
  • Don’t use GOTO statements unless absolutely necessary. These can often be avoided even when programming in assembly. (My own goal is to never use GOTOs, with the exception of a single GOTO at the end of the main loop, when coding in assembly.) GOTO statements can make code execution very difficult to trace.

…because all too often, the violent psychopath who will have to maintain your code — is YOU!

Posted in BASIC, Coding | Comments Off

Resistive Security Loops

Perhaps the most basic form of electronic security system involves a buzzer or bell set to go off if a loop of wire is cut. Sensors, such as door position switches and sliding window contacts, can be inserted into this loop, breaking the circuit if a window or door is opened. When the loop is cut (say, by a window switch opening), an alarm bell can be made to ring.


A simple, naive security system. (Click for larger.)

This simple approach, though effective, has a weakness. If a nefarious individual wished to circumvent this protection, he or she need only expose a section of cable, short it in two places (who knows which side of the wire goes to the alarm), and then cut it between the two shorts. Whether the security system was on the right or left side of the cut, the loop would still be complete, and current would still flow. Make these shorts on either side of a door or window sensor, and you can then open the door or window without triggering the alarm. In addition, all of the sensors “downstream” of the cut are now taken out of action.


First, the thief shorts the wire on both sides of the switch (he doesn’t know which end goes to the alarm system)…


…then, the wires are cut, and the window is opened. (Click for larger.)

What can be done to detect such dastardly meddling? Plenty. Rather than making a simple current loop, an end-of-loop resistor can be incorporated, and the system set to monitor the loop for a specific expected resistance. Any would-be burglar would then have to not just short the cable, but provide the appropriate resistance. Without prior knowledge of the system, this would be essentially impossible; it would be quite tricky even if given a schematic, wiring layout diagrams, and a good portable electronics lab. Even if the correct resistance (and direction to the control box) were known, inserting a fake end-of-loop resistor while maintaining a constant line resistance would be very difficult.


This one is harder to defeat. (Click for larger.)


Here, a thief has tried to defeat the added-resistor system, but the electronics sense a dead short and trigger a tamper alarm. ARF ARF — GOTCHA! (Click for larger.)

However, a security system is only as good as its weakest link –including the installer. Loop resistors do not, by themselves, somehow imbue the wire with magical properties which make it immune to tampering. If placed at the near end of the loop (I.E. in the box), the loop resistors add nothing to the system security. Whether the wire is shorted or not, the resistance will always be there.


Even with the resistor in the loop, the thief can safely disable this system with the simple shorting technique. Moral of the story: don’t put your loop resistances right at the box. (Click for larger.)

In other words, this is how it’s not done:

Loop resistances done wrong. Those 2.2k resistors (red/red/red) should be at the far end of the loop. (Click for larger.)

Note to self: Re-wire security system the right way.


Posted in Electronics | Comments Off