I was never really thrilled with the WordPress plugins that use <pre>…</pre> for delimiting code, because of bad mojo between the WordPress editor and <pre>, specifically when the two meet the lowly < character. (Specifically, code can disappear without warning.) I detest having to tip-toe around software; humans shouldn’t have to bend to the code.
I’ve installed SyntaxHighlighter Evolved, which uses the  notation, and doesn’t care how < is encoded.
Quick documentation can be found on WordPress’ Posting Source Code.
The kit was easy to assembly following the instructions on the ladyada.net site. I recommend heeding the advice to use the 16-pin IC sockets and not soldering the L293D motor drivers to the board unless you’re experienced driving motors.
Instructions for servos is sketchy. There are two servo connectors SER1 and SERVO2. According to the schematic, SER1 is connected to Arduino pin D10, and SERVO2 is connected to Arduino pin D9.
As the kit is, there is no way to stack a shield on top of the motor shield, or make easy connections for proofing. For my purposes, I added female headers to the shield using the holes parallel to the male headers. An alternative would be to use stacking headers instead of the provided male headers.
This is a small Arduino project our family did for Hallowe’en.
In the old cartoons, dark forests were shown as black backgrounds with mysterious eyes that would glow in the dark, often blinking or opening and closing.
The electronic hardware is very simple: multiple Arduino digital outputs sporting 330Ω resistors and an LED.
Each LED is mounted in a cardboard toilet paper tube with eyes cut out.
Run pairs of copper wire from where the eyes will hide in the bushes to the Arduino. (Ensure the Arduino is protected from the weather. I put mine in a small cooler.) Check all connections and connect the battery to the Arduino.
Be sure to use a battery that has enough capacity to run all the lights and the Arduino for several hours. I used a small hobby 6V lead-acid battery.
This is a glorified “blink” program; nothing amazing going on here.
The software consists of a simple coöperative multitasking core that runs simple processes in a round-robin fashion.
Each process has a references to a master array oftapes, or eye programs.
As you can see, there’s nothing terribly complicated about any of this. The software may be found on GitHub here.
There’s an annoying subtlety in the Arduino IDE when using tabs (multiple files in the sketch), that was kindly explained by PaulS on the Arduino forums.
Any Arduino libraries that are needed by the files outside of the sketch (.ino) file must also be listed in the sketch file itself.
You cannot simply do this:
example.h: #include <Servo.h>
When you attempt to compile, you’ll get an error like,
In file included from test_junk_02.cpp:1: test.h:7: error: 'Servo' does not name a type
You must also include the library in the sketch:
test.ino: #include <Servo.h> #incude "example.h"
The explanation that PaulS gave was the following:
The sketch is parsed for include files. The sketch, all included header files, and the corresponding source files, are copied to another directory for compiling. From that directory, library-based include files are NOT available unless they are included in the sketch and copied to the build directory.
Granted, the Arduino IDE isn’t conducive to heavy-duty projects, but it’s useful for quick and dirty programs.
Once you outgrow a single file and wish to break the project up into multiple files, you can do so in the Arduino IDE with multiple tabs. Each tab represents a single file stored in the same directory as the sketch file (.ino).
You create new tabs using the drop-down menu that appears by clicking on the inverted triangle above the upper right-hand corner of the editor.
Note that unlike the sketch’s main .ino file, you will not have automatic access to the Arduino basic definitions. That is easily remedied by including
Please note that there is a quirk in the Arduino IDE that can prevent libraries from being included in the compile. The IDE requires all libraries to be #include’d in the main (.ino) file. If you do not do this, the library will not be included, and you’ll get errors during compile.
When compiling, the IDE copies all the files to a temporary directory. It scans the .ino file for libraries, and copies the library files to the temporary directory. Finally, it does the actual compile. If you #include a library in any of the tabbed files, but not in the .ino file, the library will not be available to the parser. The IDE only scans the .ino file for libraries.
I’ve been working on a small robot on occasion to exercise some professional skills and simple personal enjoyment. The robot’s purpose is simple — point the sensor board toward the strongest light source.
I’ll post more information when I haven’t more pressing things. These are just pictures for “show and tell”.
The hardware is pretty much complete at this point. The mechanical portion consists of four light sensors and two servos.
The control board consists of a power regulator, ATmega328P microcontroller, and voltage dividers for the sensors to turn resistance into voltage. There is an optional connector for serial diagnostics. There is a connector in the far right corner for in-system programming (ISP). I’ve been doing some tutoring, and have a number of microcontrollers with stickers that document the pins names that correspond to the Arduino Uno platform.
The wiring is done by hand. I use a wirewrap tool to make the initial mechanical connection for soldering. Leads for ICs &c. are typically far to short to use plain wirewrap.
I’ve done proof-of-concept and diagnostic software up to this point. I’ll do testing to ensure the basic functionality is working correctly still, and work on the firmware in earnest.
Internationalization and localization have been long-time interests of mine, and I’ve had the privilege to delve deep into it with a large project for the last year. I submitted the following comment on the Real-World Haskell site in hopes that it would be of value for future readers.
In response to Phil’s question, and for general information for those not familiar with Unicode:
Unicode consists of “code points”; numeric values that represents a character or meta-character. This is purely an abstraction that dictates no specific digital representation.
How those numeric values are encoded and stored digitally is a separate issue. The main three encoding systems follow.
UTF-32 uses 32 bit “characters” to store each code point. A pro is that each “character” corresponds exactly to a code point. A con is that for English text, this quadruples the amount of storage space required, filling memory with a lot of zeroes.
UTF-16 uses 16-bit “characters” to encode code points. It requires either one or two “characters” to represent the entire Unicode set, with the most common values requiring a single “character”. A pro is that it’s more space-efficient than UTF-32. A con is that it’s a variable-length encoding system.
UTF-8 uses 8-bit “characters” to encode code points. It’s designed to be a superset of ASCII. It requires between one and four bytes to encode the entire Unicode set. A pro is that plain ASCII is UTF-8; no conversion is required. A con is that it’s a variable-length encoding, and is inefficient for Asian languages compared to UTF-16 (requiring 3 bytes rather than two for most Asian text).
In my internationalization and localization work, I have to ensure that UTF-8 is being correctly generated and stored.
The hixie.ch UTF-8 decoder is very flexible on the input it accepts and shows the internals of the decoding.
The rishida.net conversion tool is useful for converting formats.