I just finished two videos on assembling the Crib for Arduino Case. The two-part videos cover:

Part 1) Crib for Arduino Case with the Arduino Duemilanove
Part 2) Crib for Arduino Case with Arduino Mega and an Arduino with Ethernet Shield faceplate

Part 1:


Part 2:

I hope those help everyone to see not only how the enclosure goes together but also give you a closer look at the Crib for Arduino Case itself from more angles. Sometimes it’s hard to get a tangible feeling for a product by static pictures alone.

If you have any questions or comments about the video instruction or on the Crib for Arduino Case, please let me know.

Landon Cox
www.ESawdust.com

We’re happy to announce the introduction of a new ESawdust enclosure design, Crib for Arduino. Crib for Arduino is a tough metal (aluminum) case for Arduino and Arduino Mega and is tall enough for shields, Arduino daughter cards, as well.

Until now, we’ve accommodated Arduino projects with the Chameleon 1 enclosure combined with an Arduino faceplate. That was great, had lots of room for other electronics, but was not tall enough for a shield. It is larger, which for some Arduino projects might be required, but if you want a more compact Arduino case, Crib for Arduino is it.

We designed Crib for Arduino to be easy to install an Arduino board. This is the first enclosure system we’ve built which comes with snap-in standoffs. You can see the snap-in standoffs in action in this next picture:

The snap-in standoffs are great because you can press them into the pre-drilled holes, or if you make your own holes, make them with a 1/8” drill bit and the snap-in standoffs will fit to a T. Press them into the base plate, then lay your Arduino over the standoffs and press it down one corner at a time. They make a nice, secure fit and they are easier than the typical two-screws and a standoff per corner method.

We are also offering an optional faceplate to help those who have the Ethernet Shield for Arduino.

If you have ever tried to cut a square hole into metal, you know it can be very difficult. This faceplate alleviates that pain and gives you a nice clean front panel for your Arduino with Ethernet shield.

The finish throughout is powder-coated black texture which won’t show fingerprints and is tough like our Chameleon and Dog House for BeagleBoard. (Update 6/24/10: Watch for a new Dog House for BeagleBoard xM coming in mid-July 2010.)

So, check out the Crib for Arduino and give your Arduino the home it deserves.

Tags: Arduino, Enclosure, Case

Just posted an article on porting my Ragel-based NMEA GPS parser to an AVR ATMega128.

See “Porting a Ragel GPS NMEA Parser to AVR ATMega128”

Tags: Ragel

Synopsis: Alright, “pimped out” might be a little bold...lets say we “spruced up” an AVR-P28 dev board. A few weekends ago I built about 8 ATMega8 proto-boards to go into the hand sensors of the speed timing system. In the process, I spruced up a little Olimex AVR-P28 board so I could flash the chips and also to test the code on the dev board and use the dev board to test the protoboards as well. Here’s a video of how that looks if you’re new to AVRs or the Olimex AVR-P28 dev board.

Pimping out an Olimex AVR-P28 Dev Board from Landon Cox on Vimeo.

In order to get serial data in and out of the board you need to tie a couple pins together. At first it may seem like an oversight that Olimex didn’t just have the serial port hooked to the serial pins of the ATMega socket, but like most things on an AVR, these serial pins can be used for other purposes, so it’s not a given that all people will use them for serial. For that reason, you need to connect it yourself. Here’s a shot of the underside of the board with a couple of wire-wrap size wires soldered to connect serial input and output to the ATMega:




Here are some pictures the pimped out Olimex AVR-P28 board: mounted in a Chameleon 1 enclosure:

Tags: AVR, ATMega

Synopsis: This tutorial demonstrates how to connect the bulky Atmel JTAGICE mkII connector to a Futurlec ETT ET-AVR Stamp development board’s JTAG IDE socket. Since the standard connector on the JTAGICE will cover up the pins needed to interface any SPI-based peripherals on the board, using a squid adapter leaves them free of obstruction so you can use them again and source level debug SPI protocols at the same time.

Keywords: Atmel JTAGICE mkII, JTAG squid, JTAG pinout, IDE pinout, Futurlec ETT ET-AVR Stamp, AVR ATMega128, AVR Stamp

I’ve been working with the Futurlec ET-AVR Stamp which is a fantastic $20 ATMega128 based board you can buy with an adjunct ET-AVR Stamp development board. With these components, you can easily have a $50 AVR development system (if you don’t count the JTAGICE.) If you want source level debugging, you need a JTAG programmer and that’s where things got interesting with the Futurlec dev board. The AVR stamp does not have a JTAG connector on the module, so JTAG debugging is done only through the dev board.

This is the Atmel JTAGICE mkII with the bulky, problem connector highlighted:




If you’re not using certain pins on the ATMega128 module, a direct connection of the JTAG connector to the JTAG IDE socket will work just fine. Here’s a shot of how the Atmel JTAGICE mkII connects to the AVR dev board when the SPI pins on the micro are not being used:


No problem. However, once you want to connect a SPI device such as an SD/MMC device, the JTAG connector will no longer physically fit:


Regardless of whether you use the male or female headers on the dev board, the JTAG socket will not fit due to the overlap of the circuit board with the dev board headers as shown above.

The solution: a JTAG squid cable. You can either make one [update 2/17/09 - use this technique] or scrounge one up like I did from my STK500 dev kit from Atmel. Then you have to physically map the squid to the IDE socket on the dev board. The JTAG IDE socket on the dev board looks like this:



Identify Pin 1 on the IDE socket which is on the top right if the socket key is on the top:



The pinout goes 1,3,5,7,9 right to left along the keyed top of the IDE connector and 2,4,6,8,10 right to left along the bottom row opposite the key.

The squid cable header will connect to the JTAGICE mkII. The two pieces are the JTAGICE bulky connector:


Pin 1 is identified:



and the squid socket. You can see the key on both the male and female components.



The pin mapping to the ribbon cable is Pin 1 - black and it goes in sequence to pin 10 which is brown on the ribbon above.

Pin 1 is identified on the JTAG squid IDE connector:



After attaching the squid IDE to the JTAGICE mkII bulky JTAG connector, it’s just a matter of mapping the ribbon leads on the squid to the IDE socket on the dev board. You can use this color coding as a guide to see how they map to the IDE socket in the pictures below:

Pin 1 - black - TCK - output
Pin 2 - white - GND
Pin 3 - gray - TDO - input
Pin 4 - purple - VTref - input
Pin 5 - blue - TMS -output
Pin 6 - green - nSRST - out or in
Pin 7 - yellow - n/a
Pin 8 - orange - nTRST - not connected
Pin 9 - red - TDI - output
Pin 10 - brown - GND



The back of the JTAGICE connector has the pin definitions if you need but not the mapping to the IDE ribbon colors:



Here’s how the squid looks from the JTAGICE mkII as it’s mapped into the IDE connector on the dev board:



Summary: The solution to the bulky connector on the JTAGICE mkII is the JTAG squid cable directly mapped to the dev board JTAG IDE socket. With this solution in place, you can debug SPI protocols on the Futurlec AVR stamp board with JTAG and source level debugging.

Tags: Futurlec, ET-AVR, AVR JTAGICE

These are notes on how I was able to successfully reflash my NGW100 using the most recent factory images at Atmel AVR32 beta-ware site.

The reflash takes place in two stages. The first stage is done from uBoot to reflash the root file system. The second stage takes place from the NGW100 BusyBox command prompt, so you have to have a good bootable root file system in order to proceed to the second stage. The second stage is a reflash of the /usr file system.

In order to do this, you need both a working TFTP server and NFS server or you need to be able to create the /usr/ file system on a Compact Flash so that in the second stage it can pull the image from the CF instead of NFS. I went for the first method, TFTP and NFS as the source.

I should also mention that if you have issues in the second stage with updating the /usr/ flash, and you reboot, your eth0 interface will come up static and you won't be able to talk to your NFS server from the NGW100. In that case, you should still be able to manually give it an IP address like this: Read More...

Update 4/26/07 - rather than keeping two places up to date, I've been working out these issues along with AVR Freaks on this thread.

and one helpful link for reflashing firmware on the NGW100 is at:
http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/Firmware_upgrade

4/26/07

I royally hosed my SuSE 10 environment this morning and needed to start from scratch, so thought I'd document it from a naked install of SuSE 10.0 and see if I can repeat the process only get prerequisites in place first before attempting any builds.

So, this is all with a SuSE 10.0 retail DVD and onward. I did a generic install of the distro with KDE for a desktop.

> supassword:# yast2 &

After that, through yast2, I added these packages or package sets:

Selections = C++ Compiler and Tools - check
Kernel Development - check

Additionally, check these selections if not already selected:
Development/Languages/C and C++ - selected all
Development/Languages/Other - make sure GNU binutils is checked
Development/Libraries/C and C++ - - additionally selected glib2 and glibc all include devel
Development/Libraries/C and C++ -- select e2fsprogs-devel
Sources/Kernel Sources

In Yast2 search, search for "libelf" and select it.

In Yast2 - install the "tftp" package.

Proceed to install all the selected packages from Yast2. Resolve any flex conflicts by choosing not to install the old rev and taking the new rev.
-----

Older notes....
These are notes I'm keeping on my trail to try to create a kernel build environment for the AVR NGW100 on SuSE 10.1 Linux. Note that I do not know if any of this is correct right now because I'm gunning for a working environment. I'll be figuring it out as I go.

1) The first thing I did was copy the AVR32 NGW100 Board Support Package (BSP) contents to my SuSE 10.1 linux box.

2) Knowing that I will need a GNU AVR32 compilation environment, I went into devel/linux/opensuse/10.1 and installed all the RPMs in that directory. There is no information about what depends upon what and therefore there is also no information about what order these RPMs should be installed. So, I had to go for broke. I needed to be root and then issues this command:
Read More...

[Update: 7/14/09 - We now offer a sweet metal enclosure for NGW100, the Chameleon 1. Same enclosure system will accommodate several other popular dev boards. Check it out at Sparkfun.]

Just got my AVR32 NGW100 board and fired it up. The thing that's very interesting about this board is that:
1) It's $69
2) It's running an embedded Linux with BusyBox
3) It's a two-port ethernet board
4) 32 bit RISC processor

Read More...

It didn't exist and I needed something like this for working with the Olimex AVR MT 128, so I made it. I'll take requests for additional pin locations and annotations. These happened to be some of the ones I was using or expected to use.

[Not finished - Draft of proposed article] [Update 5/26/09: See “Pimping out an AVR-P28 Dev Board”]

Synopsis: I wanted to publish a very targeted tutorial on how to bring up an ATMega8 AVR processor on an Olimex AVR-P28 development board. This board has the minimal power circuitry an LED and push button as well as an 8MHz crystal to clock the device and supports the 28 pin packages (ATMega8 and ATMega168).

This article will cover what modifications are necessary to the development board itself to connect the external DB-9 serial connector to the serial pins on the ATMega8. It will then cover a simple serial communication test program, the programming of the ATMega8 device itself and then the testing.

I will also cover how to set the ATMega8 fuses to take advantage of the 8MHz clock (vs the default 1MHz internal clock of the AVR that is configured as the factory default of the device.) Fuse setting can be an intimidating topic for someone new to AVR because if you do it wrong, you can brick your AVR device. It's further made intimidating because of the plethora of confusing articles that give contradictory explanations of what a fuse setting means (aka: programmed/unprogrammed, checked/unchecked, etc.) I will use the fewest words possible to explain fuse settings through PonyProg and attempt in one short paragraph to succinctly clear confusion about how to set up fuses.

After you've finished this tutorial you will have the foundation you need to communicate with numerous serial devices such as GPS, XBee radios, serial-enabled LCD screens using an AVR ATMega8.

In short, this is the process for a complete round trip for starting to develop with the AVR-P28 board.