Category: Avr Development

Its not very often that you get to go back to old designs and make improvements. Recently I got to rework a design from last year and build on the collective knowlege of 2 design teams and 3 design cycles.

Does practice make perfect? We shall see.

The first run.

Last year I got to build the electronics for a stationary bike racing system. The system had a large ballfield style clock with four hands that were run by these monster stepper motors The initial design was for two bikes done by Percor: a company that makes excercize equipment. Their design used these industrial (expensive and very bulky) cherry hall effect sensors which they loaned us for a race at Lance Armstrong’s bike shop in Austin (http://www.mellowjohnnys.com/). My job for that cycle was to replace Percor’s pic based board with a 4 bike setup.

I broke the stepper driver section into four individual boards. For the processor I built a custom mega128 based board and did the programming in wiring.

Second iteration.

When the Austin race was over Percor needed their parts back so I got to rebuild the sensors. I found some allegra hall effect sensors which were a small fraction of the cost of the cherry’s (like (75c<$25.00)X4). As an attempt to get a zero indicator on the clock I experimented with a triangle based design

While I never did get this particular part of the clock to work correctly the triange stuck as a shape that I liked working with.

I also wanted to replace the cat5 wire used in the Percor design with with less expensive phone cord. (I got a panicked phone call  from Texas and had to remotely direct someone how to get some very expensive ethernet cable on a weekend: it was not cool). To do this I put a non inverting buffer on the sensors and since buffers come in 6s I put an indicator led on the sensors output. In the practice of setting this up for the next race, the blinking lights were invaluable.

Third Time Charm.

A few weeks ago I was asked about another race setup in SanFrancisco. They were going to use a system called open sprints for the display but the open sprints people were out of their hardware for the sensors. So I got a 3 week timeline to put together a sensor and hardware interface that would be compatible with open sprints.

Open sprints (www.opensprints.org) is an open source ruby based software which takes information from an arduino and presents the race data in a way that can be projected instead of having a physical race clock. The only thing that needed to be built was the input side.

So I went back to what I liked and didn’t like about my earlier design and compared and contrasted the opensprints, the percor and my designs to come up with a new system which I could then have fabbed by our local pcb fab (sunstone.com). Looking at the opensprints design I revisited the hall effect sensors and found a set of sensors to experiment with and began to lay out my boards.

I had intended to use the dart design with a through hole led and a throuch hole (sip) sensor and then have some laser cut transparent plastic which could then be “lit” up by the led on the board. A second piece of opaque plastic would be cut to insulate the bottom of the board.

After talking to some of my ee freinds I decided to replace the on board drivers with a single schmidt trigger on the other end of the sensor cable (the percor design used these as well) When selecting the parts I found myself looking at a few options for the rj11 connectors. I ordered a few of each as well as both sip and the origional smt sensor from last year.

Who needs plastic?

When I got the parts I started looking at these rj11 connectors and rethinking things. The connectors were surface mount and shielded. The shielding wasn’t needed but they matched the un-soldermasked boards in texture in color they were about 7 cents more expensive apiece but they looked futuristic.

I went back to surface mount only. If I got rid of the sips and used the surface mount rj11 mounts then the bottom of the board would be shield/ground no insulation needed. The metal from the surface of the board and cable connector would reflect the light from the led and if any attention were payed to the layout of the traces it would look cool!

Even in the hand rolled prototype!

Who needs an Arduino?

At this point given Paul Stoffregon’s (pjrc.com) “teensyduino” software and his 90usb based boards there is no reason to buy any other arduino or arduino clone. ( at least in cases where you need usb to serial solution — in cases where usb-serial is not needed the dorkboard rules :) My first thought was to do a carrier board for on of Paul’s boards and adapt the opensprints code for the inverted inputs. The opensprints code needs to be adapted to invert the input signal and to adjust the registers for the different processor but using the teensyquino codebase that should be simple enough.
In this application however, the board was so simple that it made more sense to just adopt the eagle design for my at90usb162 board (the benito).

Tomorrow I get the boards from sunstone and I should have the hardware built out by late friday. The customer will be in portland saturday.

Does practice make perfect? We will let you know by next week.

While I am wrangling with the appropriate board design, I needed to get started working with the underlying software so I ran up one of the six samples I was able to get from Cascade on a tqfp adapter from measure explorer.

The AtMega32U4 http://www.atmel.com/dyn/products/product_card.asp?part_id=4317 is the midrange model in the atmel usb chipset. It follows a new standard naming convention that atmel is adapting U for Usb 4 is for the 40 pins 32k, there is another 32K part the U6 which has the same pinouts as the 90usb646/647/1286/1287. The U4 does not have a legacy pinout however the q1000 price for this board is around $2 which makes it a very powerful chip for the money.

Dfu-Programmer.

There is a recent release of dfu-programmer (0.4.6) but it seems that they havent read the atmel doc on the signatures for the dfu recently. http://www.atmel.com/dyn/resources/prod_documents/doc7618.pdf recently.

I need to check the memory and eeprom sizes against the datasheets for the parts. However the table in arguments.c should have the following entries; added new parts, corrected 64x and 82 signatures. (I will resubmit this patch).

/* ----- target specific structures ----------------------------------------- */
/*  { "name",         value,            ,device_type, chipID,VID   , MemSize,FPSize,abt,ifclass,eepgsz,eepmemsz} */
static struct target_mapping_structure target_map[] = {
    { "at89c51snd1c", tar_at89c51snd1c, device_8051, 0x2FFF, 0x03eb, 0x10000, 128, false, true,  0,   0      },
    { "at89c5130",    tar_at89c5130,    device_8051, 0x2FFD, 0x03eb, 0x04000, 128, false, true,  128, 0x03FF },
    { "at89c5131",    tar_at89c5131,    device_8051, 0x2FFD, 0x03eb, 0x08000, 128, false, true,  128, 0x03FF },
    { "at89c5132",    tar_at89c5132,    device_8051, 0x2FFF, 0x03eb, 0x10000, 128, false, true,  0,   0      },
    { "at90usb1287",  tar_at90usb1287,  device_AVR,  0x2FFB, 0x03eb, 0x1F000, 128, true,  false, 128, 0x0FFF },
    { "at90usb1286",  tar_at90usb1286,  device_AVR,  0x2FFB, 0x03eb, 0x1F000, 128, true,  false, 128, 0x0FFF },
    { "at90usb647",   tar_at90usb647,   device_AVR,  0x2FF9, 0x03eb, 0x0F000, 128, true,  false, 128, 0x07FF },
    { "at90usb646",   tar_at90usb646,   device_AVR,  0x2FF9, 0x03eb, 0x0F000, 128, true,  false, 128, 0x07FF },
    { "atmega32U6",   tar_atMega32u6,   device_AVR,  0x2FFB, 0x03eb, 0x07000, 128, true,  false, 128, 0x03FF },
    { "atmega32U4",   tar_atMega32u4,   device_AVR,  0x2FF4, 0x03eb, 0x07000, 128, true,  false, 128, 0x03FF },
    { "atmega16U4",   tar_atMega16u4,   device_AVR,  0x2FF3, 0x03eb, 0x03000, 128, true,  false, 128, 0x01FF },
    { "at90usb162",   tar_at90usb162,   device_AVR,  0x2FFA, 0x03eb, 0x03000, 128, true,  false, 128, 0x01FF },
    { "at90usb82",    tar_at90usb82,    device_AVR,  0x2FF7, 0x03eb, 0x01000, 128, true,  false, 128, 0x01FF },
    { NULL }
};

Then we test.

static
dfu-programmer atMega32U4 get bootloader-version --debug 20
     target: atMega32U4
    chip_id: 0x2ff4
  vendor_id: 0x03eb
    command: get
      quiet: false
      debug: 20
device_type: AVR
------ command specific below ------
       name: 0

Bootloader Version: 0x00 (0)

(after reading the datasheets for the 3 classes of avr usb chips and looking at the way that the avr-gcc library calls the cpu names there are some changes to the above that I will post later.)

Next up some code.

Tried running up the midiGate software that I wrote last week and found my first bug for the chip in avr-libc

UBRR1 is redefined in iom32u4.h

#define UBRR1 _SFR_MEM16(0xCC)

#define UBRR1L _SFR_MEM8(0xCC)
#define UBRR0 0
#define UBRR1 1
...

Which results in lvalue errors errors when trying to set the register to a given value. Setting the bit values as in some of the other registers seems to resolve this issue.

#define UBRR1 _SFR_MEM16(0xCC)

#define UBRR1L _SFR_MEM8(0xCC)
#define UBRR_0 0
#define UBRR_1 1
#define UBRR_2 2
#define UBRR_3 3
#define UBRR_4 4
#define UBRR_5 5
#define UBRR_6 6
#define UBRR_7 7

#define UBRR1H _SFR_MEM8(0xCD)
#define UBRR_8 0
#define UBRR_9 1
#define UBRR_10 2
#define UBRR_11 3

This is a pretty braindead error so I am sure that its been resolved by now. I need to see if it is fixed in 1.6.3 or the current release candidate (since AvrMacPack is out of sync and has 1.6.2) And yes this is the case.

We have a device!!!

Fix(ing) it!

Both of these issues were easy enough to fix within the source of the utilities but to make it possible for everyone else to use the new chips some body needs to Fix it! So I went about looking up the chain to get these issues resolved over the long run.

Dfu Programmer.

dfu-programmer is a source forge project so I logged an error through the sourceforge project page. https://sourceforge.net/tracker2/?atid=767783&group_id=147246&func=browse A new release has been made (0.5.0) which resolves the issue above.

Avr-Libc

Since avr-libc is a savanaha project and so making bug requests is a little different. http://savannah.nongnu.org/bugs/?group=avr-libc Fortunately (sort of) I had already been around the buggier parts of the release in question (1.6.2) when I first ran up the at90usb647. When Eric Weddington released the June rev of WinAvr (with avr-libc 1.6.3) I thought I had seen the last of it as obdev released the coresponding AvrMacPack. The bug noted above was fixed in 1.6.3 and I was able to verify that using my windows vmware session. For some reason this was not the case and AvrMacPack went out with the buggy (for this new chip anyway) libc. I filed a bug report with obdev and followed up with Christian from obdev and Eric until the version descrepency was resolved. The new version of WinAvr just came out and I am waiting to verify that the AvrMacPack version matches WinAvr.

If you are running linux plan on building from source and patching as in the script kept current at avrfreaks (you will need to log in) . http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631&start=0&postdays=0&postorder=asc&highlight= This script has not been updated for the latest winavr but it should at least give you a version above 1.6.2.

Ethan and his dad came to the first dorkboard based induction. This is one of his recent projects.

http://etharooni.wordpress.com/2008/09/21/nunchucklogger/

Very cool stuff.

Brian Reilly at Wulfden picked up the dorkboard in his freeduino line of products.

http://wulfden.org/TheShoppe/freeduino/dorkboard.shtml

Yeah!

This has been reposted on dorkbotpdx.org

A few weeks ago I bought the last of the Really Bare Bones Arduino rev A boards from Brian at Wulfden (http://wulfden.org/freeduino/freeduino.shtml) I now have enough boards for one more workshop and then we have to reevaluate the boards which are avaliable. Pictured below is a finished board from the first “Arduino Cult Induction Workshop”

In addition to letting me clean out his new old stock Brian threw in one of the “Rev B” boards so I could check it out. Unfortunately I don’t like it.

The new board is almost 3/4″ of an inch longer than the original. Most of the new space is dedicated to room for a power jack and a regulator. Things that I never use. The design is supposed to allow you to cut the power jack off as well as the regulator. Notice in the finished board above that their is space for a big old reset switch. When the original Arduino came out you had to reset the board to get it into the bootloader. However in the past year or so all the new boards have been using the dtr signal run through a capacitor to pull the reset line so the switch is wasted space. The original board made up for this space by adding ample ground and supply connections. The new board adds another 1/8″ and gets rid of these.

As I was grumbling about this Mark Gross suggested that I just roll my own.

So we are back to the drawing board. Above is my pen markup of the changes that I wanted to see done to the original Really Bare Bones Arduino and below is the draft of the rework to scale with the RBBB rev B.

Now comes the fun part The cost of goods sold and a business case.