C Sharp Development 101 – A Tutorial Series

Posted on 3 September 2010 | 3:00 pm

The Spindicator

[Harvey] wrote in to share the Spindicator with us. The spindicator is a hard drive activity activity indicator built in a ring to resemble a dekatron. Using the pulses from the hard drive activity LED, [Harvey] tested several different methods of interpreting that data for display. The final version, negative edge triggered with a lowpass filter can be seen after the break.  It is nice and smooth and vaguely reminiscent of many programs’ loading screens.

He has pictures and tons of detail on the project including videos of previous versions that acted quite erratically.

Posted on 3 September 2010 | 2:00 pm

EEVblog dissects a kindle 3

[Dave] over at the EEVblog did a review of the kindle 3 recently, but never got to the good stuff, the guts.  He is now rectifying this with a full video dissection of the eReader. Full of details on how to open it up as well as specifics on the internals, this is a fun video to watch. One thing that caught our attention was the RFID tag on the inside of the case.  It is probably for inventory tracking, but we can’t help but have a few tinfoil hat type thoughts. You can watch the video after the break.

[thanks Julius]

Posted on 3 September 2010 | 12:51 pm

Controlling the power of a flash with a tv remote

For those who do fancy photography, setting up the lighting ends up being one of the larger tasks of each session. There are flashes out there that can be controlled via a remote control to help ease the process, but they can cost a considerable amount more. [Dsvilko] shares with us a fairly simple circuit that allows you to use a tv remote to control your flash. He’s using a picaxe 08m and he states that before this project, he had never messed with microcontrollers. We say great job on your first microcontroller project. You can catch a video of it in action after the break.

[via Makezine]

Posted on 3 September 2010 | 8:50 am

Trossen Robotics holding another contest

You have until December 1st to get your entry into the Trossen DIY robotics contest. Unlike the last Trossen contest we told you about, this one has no clear theme. The goal is simply to make an awesome robot. Registration is free, and entries will be judged on Ingenuity, Originality, and presentation/documentation. There are prizes for 1st, 2nd, and 3rd places, with the 1st place prize being the Interbotix Hexapod. If you haven’t seen it yet, it is a kit of a hexapod that is pretty quick on its feet. You can catch a video of it after the break.

[via botjunkie]

Posted on 2 September 2010 | 5:00 pm

Using an NES controller on an Android phone

[Sk3tch] rigged up a way to use an original NES controller with Android. He bought the controller and a breakout board for it at DEFCON. By combining the controller, an Arduino, and a blueSMIRF BlueTooth module the controller can be used as a keyboard on his Android device. In the video after the break he demonstrates pairing the devices and playing Super Mario Bros. 3 in an emulator.

He calls this Alpha quality but it certainly looks like it works well. In the beta version we’d love to see all of the extra electronics inside the controller case like those USB mods.

Posted on 2 September 2010 | 4:00 pm

Car computer requires PIN for ignition

[Ben's] added some nice goodies to his Volvo in the form of an in-dash computer. The system monitors two pressure sensors for boost and vacuum, as well as reading RPM, O2, and exhaust directly. All of this is tied into the touch interface running on an eeePC 900A. But our favorite feature is that the system requires you to enter a PIN to start the ignition. The forum post linked above is short on details so we asked [Ben] if he could tell us more. Join us after the break for a demonstration video as well as [Ben's] rundown on the system.

Ben writes:

Hi, great, glad you like it. The EEE 900A has a 2GB ram upgrade and a 16GB SSD upgrade, running windows 7. I modified the computer so it could fit directly behind the screen, which involved relocating the USB ports, and also using a HP webcam from a broken laptop as a back up camera.

The black box has three circuit boards. I’ll send you some pictures of the most current version later. The first board is for power, It has a 3.3v and 5v regulators to provide the two voltage rails, and the three relays. One relay controls the power supply to the netbook, the second controls the car’s actual starter, and the third controls the auxiliary power and lighting system.

The second board uses two freescale semiconductor pressure sensors, one to read boost and the other to read vacuum. It also has a secondary microcontroller (A PIC18F2550) to read a direct RPM input as well as a wideband o2 sensor in the exhaust. This uC is running in i2c slave mode.

The final board in the back is a PIC18F4550, which has direct control over the relays, the secondary controller, and also directly reads the two pressure sensors. Both controllers run software written in PICBASIC.

Now the part that I like about the interface box, is in order to talk to the computer, it uses only the PIC18F4550′s USB port. one usb connection is all that the computer talks to the car with.

The software running on the netbook is an application that provides a front end to the control box, A PIN is required to be entered, and once the PIN is correct, you are then able to start the car via the
button on the screen. The normal key method of starting no longer works. For security, The interface ONLY sends the PIN number to the control box, the control box has a PIN number saved and encrypted on the PIC’s internal eeprom. The entire application was written in VC++, .net, and provide me with accurate boost, vacuum, RPM, and AFR on screen. Touching a gauge on the screen enlarges it, and minimizes the other two gauges for enhance readability.

It’s all cleanly installed in my 1998 S70 T5, which was an automatic from the factory and that I swapped to manual in January this year. To power the entire system on, you only need to press the unlock button on the keyfob. by time you get to the car, the computer is running, and the control box is connected to my software and waiting. Locking the doors via key fob (using the key on the door also works just as well) tells the contol box to use a transistor to electrical press the EEE’s power button and put it into sleep mode. Once the EEE is off, it cuts power to the EEE, and then both controllers go into sleep mode, drawing minimal current. I’ve left the car for a couple weeks with the entire thing hooked up, got home, and started it right up and drove away. I designed the entire system like any company would, to ensure reliability. There are safety measures that only I know about, that allow me to re-enable the standard key ignition in case of an emergency.

Posted on 2 September 2010 | 3:00 pm

Meter clock using the TI Launchpad

Here’s an analog meter clock using an MSP430G2211 microcontroller. [Doug Paradis] chose this processor because it is the lesser of the two that come with the TI Launchpad. The parts count is fairly low too; a clock crystal, two analog meters, a few buttons, and a voltage regulator.

He’s done a nice job putting this together. We challenge you to give this a try yourself and build on [Doug's] features. We really liked the calibration subroutine in [Alan's] multi meter clock. It would be fun to implement that functionality and store the calibration code in the MSP’s flash memory. You can use our ported garage door opener code if you need an example of how to store data in flash.

Posted on 2 September 2010 | 1:48 pm

Firmware hacking on Behringer midi devices

A new project called the Unofficial Behringer Control Development Kit lets you tweak or completely replace the firmware on the popular devices. The proof of concept demo shows a custom message scrolling on the 4-character 7-segment display but you can do with the device is only limited by how well you can code for the ARM processor inside. Development takes place using the GNU ARM toolchain but don’t worry, you don’t have to crack the case open to program the chip. The BCR2000 and BCF2000 models supported by the project both run bootloaders that allow firmware updates via midi commands. There’s even a recovery mode if you screw something up. Just make sure you have a direct midi connection for recovery, the USB port won’t work for that purpose. If you need a shove to get you started there’s a nice little example file in the repository.

[Thanks Bjonnh]

Posted on 2 September 2010 | 1:00 pm

Meat smoker texts you when it is done

[Peter Rauch] has built this meat smoker that has a touch screen control interface. His system is capable of controlling the cooking by monitoring the internal temperature of the smoker as well as the temperature of the meat itself. His touch screen interface allows him to enter his desired parameters and it basically just takes over from that point and texts him when it is done.  You’ll have to download the pdf to get to the juicy details of his build, but it is an interesting read.

It looks like he’s using a 4-loop Gefran GFX4 temp controller in conjunction with a Modbus remote terminul interface and a TS8010 HMI touchscreen for the bulk of the electronics. It even has protection limits he can set to keep his family from bumping it up to 1200 degrees.

[via Makezine]

Posted on 2 September 2010 | 11:30 am

Barcode Infiltrator

Whenever someone manages to expose vulnerabilities in everyday devices, we love to root for them. [Adrian] over at Irongeek has been inspired to exploit barcodes as a means to attack a POS database. Based on an idea from a Pauldotcom episode, he set out to make a rapid attack device, using an LED to spoof the signals that would be received by scanning a barcode. By exposing the POS to a set of generic database attacks, including XSS, SQL Injection, and other errors easily solved by input sanitation, he has created the first version of an automated system penetration device. In this case the hardware is simple, but the concept is impressive.

With the hardware explained and the source code provided, as well as a basic un-sanitized input cheat sheet, the would-be barcode hackers have a great place to start if they feel compelled to provide a revision two.

[Thanks Robert W.]

Posted on 2 September 2010 | 10:12 am

Spy Video TRAKR: software and first hack

Our initial view of the Spy Video TRAKR “App BUILDR” site had us believing this would be an internet-based code editor and compiler, similar to the mbed microcontroller development tools. Delving deeper into the available resources, we’re not entirely sure that’s an accurate assessment — TRAKR may well permit or even require offline development after all. Regardless of the final plan, in the interim we have sniffed out the early documentation, libraries and standalone C compiler and have beaten it into submission for your entertainment, in order to produce our first TRAKR hack!

TRAKR software development at the moment, to phrase it just as politely as we can, has a Wild West flavor to it. The finished tools and reference materials aren’t expected until October. Early documentation is rough — entire sections still missing — so it’s frequently necessary to rummage through their example code to learn how things operate. And the compiler is exceedingly rough right now…it requires a minor patch just to get started, and works only within Cygwin, a UNIX-like command shell for Windows systems. So tonight we’re gonna program like it’s 1999! To continue, we’ll have to assume you’re at least vaguely familiar with command-line development tools, as explaining the entire process from scratch is more than we can fit here.

It probably goes without saying, but for posterity: these are beta tools and the entire process will almost certainly change as the TRAKR HAKR site nears release, rendering these directions obsolete. Until then, for those wanting to get an early start, here’s how we began building our own TRAKR hacks…

Getting the compiler

The C compiler and documentation are presently located on the Apps Help page of the TRAKR web site. Just follow the directions there to download the App Primer (containing the compiler and demo source code), the TRAKR Codebook PDF (an introduction to TRAKR programming), and the Function Reference and code snippets for lighter-weight reference once you’re familiar with the concepts.

The Apps Help page states that the tools work with Linux, but this isn’t entirely true. The App Primer ZIP file contains only the Cygwin (Windows) toolchain, along with the TRAKR libraries and sample code. The C compiler is based on arm-elf-gcc 3.4.6 — Linux users might stand a chance with the pre-built 3.4.3 package from the GNU ARM web site. You’ll still need to download the App Primer for the libraries. With Mac OS X, things get ugly…we’ve yet to locate a viable package for Intel Macs. Building the 3.4.6 toolchain from source (or via MacPorts) has brought only frustration, and the TRAKR makefiles don’t play nice with later (but working) arm-elf-gcc editions. Joy. Eager to move ahead, and not wanting to invest a lot of time on beta tools that are certain to change, some of us are simply using the Windows package in VirtualBox for now.

Getting the compiler to actually work

After unpacking the App Primer ZIP file, copy the TRAKR.1 folder inside to a suitable working location within your Cygwin directory. The _MACOSX folder can be deleted — this is just an artifact of the files having passed through a Mac at one point; there are no OS X build tools here.

Just unpacking the Primer and trying to compile the examples, you’ll encounter a slew of “undefined reference” error messages and a failed build. There’s a problem with the TRAKR library — some test data that’s not properly archived — but it’s a straightforward fix. Go into the Internals directory and edit the Makefile using vi (or another editor of choice if you have one installed). Line 22 looks like this:

OBJECTS = $(S_OBJECTS) $(O_OBJECTS)

It should be changed to this:

OBJECTS = $(S_OBJECTS) $(O_OBJECTS) $(O_IMAGES)

Save the changes and exit the editor, then (still in the Internals directory) type:

make trakr.a

Now you can go back to any of the examples and successfully compile by typing “make”. For example:

cd ../EX06_Sound
make

This will create a “.bin” file that can be loaded onto the TRAKR. Attach a USB cable between your computer and the TRAKR vehicle (the power switch can be on or off, it doesn’t matter). In a moment, the TRAKR’s internal storage will show up as a small removable drive. Then just copy the .bin file to the APPs folder on this drive, e.g.:

cp EX\ Sound.bin E:APPs

Disconnect the USB cable, power up the TRAKR and remote, press the remote’s Home button and use either stick to navigate to the “EX Sound” menu item, then press the “Go” button. The app should prompt you to record 10 seconds of audio from the TRAKR’s microphone, then plays this back. Cool stuff!

Writing your own apps

Each TRAKR app is required to have three functions: Start(), Run() and End(). Your Start() function contains one-time initialization code, such as opening the motors to software control; End() is the complimentary function for when your program finishes, restoring control to normal TRAKR operation. Run() contains the meat of your application…this function is expected to return either “true” or “false” to indicate whether it should run again iteratively, or is ready to exit.

The header file svt.h contains constants and prototypes for the functions described in the Codebook and reference documents. This includes high-level functions for producing graphics and sound, turning the infrared LED on or off, reading the controls, driving the motors and accessing the SD card. This is all the Official Documented Stuff thatApp BUILDR will encourage us to use.

But there’s a second header, JAPI.h, revealing much of the underlying functionality on which the TRAKR library is built. And for the time being, this is the only way to access the really interesting stuff like digital I/O, video processing and USB host. This is most definitely not the Official Documented Stuff, and relying on it now means your code will probably require some changes to work with the Official Stuff later.

There’s something conspicuously absent from both libraries: higher-level digital I/O such as serial UART or precise PWM control. We’re not even certain yet whether any the accessible breakout lines correspond to these hardware functions. Maybe it’s something forthcoming, or maybe this will require the chip datasheet, with code talking to the registers directly. Worst case, such I/O will just have to be done with slower bit-banged methods. Which is exactly what we do with…

Our first hack

We really wanted to showcase both the software and hardware hackability of the TRAKR. There isn’t the space for an overly-technical writeup, but neither do we want to send you off with a trivial modification. Hopefully we’ve found a good balance here…mildly esoteric, but most readers with modest prior soldering and programming experience should be able to follow along and create something similar.

Our inspiration came from an earlier Hack a Day article about the txtBomber, a handheld dot-matrix graffiti printer:

The width of the TRAKR is about the same as a sheet of paper. With a row of solenoids and some paint markers, we could make a fantastic mess with this…or even simpler, skip the markers and head to the beach, having the TRAKR “comb” messages in the sand.

Problem is, we didn’t have a stack of solenoids on hand, and we wanted to get right into this rather than wait around for parts to arrive. Rooting among the detritus of our secret underground vault, we found a great substitute from a prior project: a row of 48 addressable LEDs driven by shift registers, the board on which they’re mounted perfectly matching the TRAKR’s 10 inch width! So our aim now was to achieve the same effect in light. The TRAKR moves too slowly for retinal persistence of vision to occur, but we could use long exposure photography to capture the results.

Anyone can buy a TRAKR off the shelf now, but the light bar was something custom-made for a POV project. The good news is that it’s a very common circuit, something we’ve linked to before, and a slightly scaled-back version can be built on a breadboard. Ours has a set of six 75HC595 shift registers with decoupling caps, each driving eight LEDs with associated current-limiting resistors. Very similar to what’s shown in that article, but cascaded out to six chips. You could also do something similar (and way more colorful) using ShiftBrite LEDs.

The LED board is held to the ’bot with masking tape. Spared no expense!

As pointed out in our teardown, the all-important JACK3, containing the GPIO lines, is smack dab in the middle of the TRAKR main board. The unpopulated header USB2, which we’ll use as a power tap, is closer to the outside edge.

In our haste to create a presentable demo, we just soldered wires directly to the TRAKR’s circuit board, but at some point intend to dismantle the thing again and solder on a proper header for inserting wires. For +5VDC and ground, the VDD5V and VGND pads of the idle USB connector are used. The shift registers require three data lines (as we’ll explain in a moment), and we opted to use the first GPIO lines on the board, labeled GPC0, GPC1 and GPC2.

The shift register interface, referred to as a 3-Wire serial connection or sometimes SPI (Serial Peripheral Interconnect), is a synchronous serial interface, meaning that each bit of data is accompanied by the synchronized tick of a clock bit on another line. A third line, called the latch, signals the end of the data transmission — in the case of an 8-bit shift register, this will output on its 8 parallel data lines the last 8 bits that were “clocked in” over the serial connection.

For our light bar hack, we’ll use GPC0 as the clock line, GPC1 as the data line, and GPC2 as the latch. Most microcontrollers feature some kind of native 3-Wire/SPI support, but as mentioned earlier, with the TRAKR library at present we’ll have to trigger all these bits through software control.

Next thing we need is an image to display on the LEDs, one row at a time. Naturally, we’re going to use the Hack a Day logo:

In the source code archive provided later, the image is present as a 1-bit Windows BMP file, simple to work with because the data is uncompressed. The image is turned sideways as it requires less code for the program to decode each horizontal row of the bitmap than it would for processing vertical columns. It’s 48 pixels wide, corresponding to the 48 pixels in the LED bar, and 60 pixels high, including some blank lines at either end so repeated logos don’t run one into the next.

Our example program is hardcoded for this one demo image, which is embedded in the executable. A more sophisticated program might allow the user to load an image from the SD card, and would properly parse the BMP header to query the actual image dimensions. Again, we’re just looking to keep the code simple and not stretching out to hundreds of lines.

// POV demo for Spy Video TRAKR w/shift register LED bar.

#include "svt.h"  // Official API
#include "JAPI.h" // Secret sauce

#define ROWS  60 // Image height in pixels
#define COLS  6  // Image width in bytes (pixels = 8x this)
#define PAD   (3 - ((COLS - 1) & 3))
extern unsigned char _binary_logo_bmp_start[]; // In logo.o

#define CLOCK (1 << 0)  // GPC0
#define DATA  (1 << 1)  // GPC1
#define LATCH (1 << 2)  // GPC2

void Start()
{
  JAPI_SetIoOutputMode(CLOCK | DATA | LATCH);
}

bool Run()
{
  unsigned char *ptr, byte;
  int r, c, b;

  // 62 byte offset to start of image data within BMP:
  // 14 byte BMP header, 40 byte DIB header, 8 byte palette
  ptr = &_binary_logo_bmp_start[62];

  for(r=0; r<ROWS; r++) {     // Each line in image
    for(c=0; c<COLS; c++) {   // Each byte in line
      byte = *ptr++;
      for(b=128; b; b>>=1) {  // Each bit in byte
        if(byte & b) JAPI_SetIoLow(DATA);
        else         JAPI_SetIoHigh(DATA);
        JAPI_SetIoHigh(CLOCK);
        JAPI_SetIoLow(CLOCK);
      }
    }
    JAPI_SetIoHigh(LATCH);
    JAPI_SetIoLow(LATCH);
    Sleep(20);
    ptr += PAD;  // BMP rows start on 4-byte boundary
  }

  return true;
}

void End()
{
}

The graphics-related #defines should be clear by now, we know this program is set up for this one specific image. The CLOCK, DATA and LATCH #defines correspond to the individual bits passed to GPIO-related functions, making subsequent code easier to read.

In the Start() function, the call to JAPI_SetIoOutputMode() initializes all three lines as outputs.

Because of the way the image is formatted, there’s minimal work now to be done in the Run() function. For each horizontal row of the image, six bytes of image data are output one bit at a time, 48 bits total: the DATA line is set either high or low to indicate the corresponding 1-bit pixel value, and then the CLOCK line is quickly toggled high and then low to “clock out” the data bit. At the end of each row, the LATCH line is similarly toggled to tell the shift registers to display the new data. A 20 millisecond delay holds the image for a moment so it’s not all scrunched together, given the TRAKR’s limited speed.

The next line advances the image pointer to the start of the next row, if required. In BMP files, rows are always a multiple of 4 bytes wide. Our bitmap is only 48 pixels (6 bytes) across, so this skips the two extra bytes at the end of each row. The final “return true;” line tells the TRAKR library to repeat our Run() function again indefinitely.

The End() function is empty for this program, but it still needs to be present to keep the linker happy.

A ZIP file containing the above source code, bitmap image and makefile can be downloaded here. Extract this archive within the Trakr.1 folder, alongside (not within) the Internals directory. “cd” to this directory and type “make”. If all goes as planned, this should produce the file POV.bin, which can be loaded on the TRAKR as described earlier.

Even in this early stage, warts and all, we’re quite excited by the prospects for this toy’s hackability. Wild Planet is to be applauded for their open-minded approach in encouraging software and hardware modifications. A lot of comparisons are already being made to the Roomba and Rovio, both of which have spawned enthusiast sites and even books. Time will tell if the Spy Video TRAKR catches on the same way.

So that’s our TRAKR hack…now let’s see yours! When you’ve got something cool to showcase, don’t forget to tip us off!

Posted on 2 September 2010 | 8:45 am

LED suit lights up the night

When the tipline popped up with this LED suit, part two, by [Marc DeVidts] we were expecing a simple led version of the previously known EL coat.

Well we were right and wrong in the same instance. Correct in that like predictions, the outcome is stonking great. Wrong in that this suit far outpaces EL in abilities we weren’t expecting. Namely to start off, an iPhone app over WiFi dictates to some 200 Arduino multiplexed RGB LED modules to dance randomly or follow patterns; an accelerometer and microphone are also implanted to further some effects. And finally if the suit isn’t enough to make you giddy, his PCB and enclosure milling surely will. Catch a video of the entire setup after the break.

Posted on 1 September 2010 | 6:51 pm

Alarm clock learns new trick, opening doors

Waking up at 5:30 in the morning. [Mark Stead] didn’t like the idea either when his chickens started crying to be let out. One simple solution obviously is to eat the chickens build an automatic door opener. The mechanism starts out with an old style mechanical alarm clock, add a geared motor with some creative switch work to pull open the door, weather proof the entire thing, and done. [Mark] even modified the setup later to work with vertical doors. No MCU required for either.

Pair this with an automated feeder system, egg gathering and cooking setup, and you’re half way to having your breakfast ready for you when you wake up in the morning – around noon like the rest of us.

[Thanks MS3FGX]

Posted on 1 September 2010 | 4:56 pm

How to fix AVR-SIZE on Ubuntu 10.04

The program avr-size is part of the AVR-GCC toolchain used to develop programs for that line of microprocessors. The program tells you how much space the code will take up on the chip, important information if you’re trying to cram a program into a small program memory. Perhaps more importantly, it shows you how much ram is being used. This is the “Data:” portion of the image above and if you overflow the memory this will be the only thing that lets you know that has happened (except for unstable behavior once the program is running).

For quite some time the avr-size package in Ubuntu has been missing a key feature that makes the information more human readable. [Jeff] over at mightyohm tracked down the solution to the problem on the bug tracker and posted the directions on how to bring your copy up to date. Basically, download the package from Debian (an upstream copy that has already been patched) and install it. [Jeff's] guide is based on the AMD64 version so we’ve copied his procedure in a more generalized fashion after the break.

1. First, go here and download the appropriate package for your architecture. The most common is i386 and you should download the most recent revision number (2.20.1-1 at time of writing).

2. Use the Debian package management system to install the package you just downloaded (you will need to change the package name if you didn’t download the i386 version):

sudo dpkg -i binutils-avr_2.20.1-1_i386.deb

3. Place the package on hold to prevent automatic updates that actually downgrade back to the broken version:

echo "binutils-avr hold" | sudo dpkg --set-selections

That’s all there is to it. We like to use a makefile written as a WINAVR example to compile and upload our AVR code. We’ve made the changes necessary to use the fixed avr-size program. Download the makefile here.

Posted on 1 September 2010 | 2:14 pm