Archive for the ‘Avr Development’ Category

A good stubby phillips.

Wednesday, April 20th, 2011

Whenever I look at integrating avrdude into a software solution I find myself thingking about how useless the “Phillip”s bit on a Leatherman(tm) tool is and how many times I have hurt myself using it when it was the tool on hand.

Benito 2010 (e) Parts List.

Monday, August 23rd, 2010

h

Qty Description Digikey # Price @ ~ 25
1 IC MCU 8BIT 32KB FLASH 32TQFP ATMEGA32U2-AU-ND 2.76360
2 CAP CERAMIC 1.0UF 10V X5R 0603 399-3118-1-ND 0.03600
2 RES 22 OHM 1/10W 5% 0603 SMD 311-22GRCT-ND 0.03480
4 RES 220 OHM 1/10W 5% 0603 SMD RHM220GDKR-ND 0.10820
1 LED 5MM BI-COLOR RED/YLW DIFF 754-1472-ND 0.18840
1 LED 5MM BI-COLOR RED/GRN DIFF 754-1471-ND 0.18840
1 CRYSTAL 16.000 MHZ 18PF 535-10226-1-ND 0.31360
2 CAP CER 22PF 50V C0G 5% 0603
445-1273-1-ND
0.01950
2 RES 10.0K OHM 1/10W 1% 0603 SMD RHM10.0KHCT-ND 0.02385
1 CAP .10UF 25V CERAMIC Y5V 0603 399-1100-1-ND 0.01620
2 SWITCH TACT 6MM BLACK 160GF 450-1650-ND 0.10100
1 CONN HEADR 2.54MM 10POS GOLD R/A S9177-ND 0.43200
1 CONN HEADR 2.54MM 10POS GOLD S9169-ND 0.43200
1 CONN RECEPT MINIUSB R/A 5POS SMD WM5461CT-ND 1.16700

..

Benito changes.

Monday, August 23rd, 2010

One of the benefits of having laens pcb order available is that I can test design changes iteratively and explore other possibilities. The benitos i am using in the induction this month are the result of three iterative changes based on the original Benito and a redesign done by Monty Goodson a few years back. They (the benito2010d) will be the last of the design to use the pinouts of the origional benito. Fot the end users the biggest change will be that the cable will be a mini-b like the one used on the teensy.

I am not entirely convinced that the mini-b is the right decision but the full sized b uses a lot of board real estate. The other changes on the board come from things that I did and did not like in the previous iterations.This board uses a few through hole parts where the previous versions used surface mount most noticeably for the leds and the switches. I also find that solder mask is not something to be left off of a board.

The next iteration will abandon the original benito pin-out in favor of the stk500 style pin-outs.

There will be two versions of this board available.

The e1 which will be primarily for the inductions and the e2 which will replace the benito pcb on the tempus dictum site.  I will update the parts list shortly along with the other parts of the site with the new design once the next board order goes through.

98-all-your-atmel-belong-to-us

Wednesday, July 14th, 2010

Foobarred is Normal

Recently I started using my linux laptop as my primary avr-usb development environment. When I upgraded the laptop to the current Ubuntu-LTS release (10.4 aka Lucid lynx) a bunch of stuff was broken including all of the wonderful udev rules provided by my linux savvy friends at dorkbotpdx.

I mean jeesh even lsusb was broken.

$ lsusb -vd "03eb:"|grep iM
cannot read device status, Operation not permitted (1)
iManufacturer           1

When I started looking at what changed and how to adjust, the web dead ended to a lot of threads like the one at http://ubuntuforums.org/showthread.php?t=1360412 ; where two people declared that having to escalate privileges to root in order to talk to a user device was “normal”. Even when the developer said it wasn’t normal the ubuntu folk redeclared it normal (apparently after Bush you just have to repeat something blatantly stupid for it to be true). As an administrator the last thing you want is everything and its dog requiring root privileges.

Hanging around the #ubuntu channel was a lot like having people repeat the searches on the web that provided me with the same dead ends that I joined the channel trying to resolve.

Cherchez la femme (look at the squeeze)

This was getting stupid. All I wanted to do was to have devices that I could plug in and program and then communicate with them using ruby or perl or some other haphazzardly thrown together scripts without having to be root. Then I realized once again that ubuntu is really focused on making the users life easier and that this leads to a lot of non technical help. So I asked my friends what the nick name was for the Debian release that was the basis for the Ubuntu release nick named “Lucid” and then re did all of my dead ended web queries replacing “Ubuntu Lucid” with “Debian Squeeze”.

The results were heavy on the technical detail and light on social skills.

More importantly I quickly found the solution that I needed in the middle of this link (http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=blob_plain&f=README&hb=HEAD) what I was missing was the difference between the new and the old udev rules.

“If you are running a newer version of udev (as in Debian Squeeze and
Ubuntu 9.10), you need to adapt the rules-file to the new udev-version:
sed -i -e ‘s/TEMPNODE/tempnode/’ -e ‘s/SYSFS/ATTRS/g’ -e ‘s/BUS/SUBSYSTEMS/’ \
/etc/udev/rules.d/xusbdfwu.rules”

One line of sed was all I needed and it had taken me a week of asking about lucid when i should have been asking about squeeze. With this I also was able to find the changes to the lay out of the /dev and /proc trees and the new tools to monitor udev and diagnose issues.

All-Your-Atmel-Belong to Us

I really just wanted to change the permissions so I could use my devices. Adding the following udev rule to your system will do just that.  You will also need to restart the udev service. Both of these will require you to be root.

# cat >/etc/udev/rules.d/98-all-your-atmel-belong-to-us.rules<<EOF
#------------------------/etc/udev/rules.d/98-all-your-atmel-belong-to-us.rules
#
# Make atmel devices (dfu, LUFA, obdev) accessible in userland
# 
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", MODE="0666"
EOF
# service udev restart

To actually own all my atmel I could have also added ‘ ,USER=”don” ‘ after the mode part but I just wanted to talk my Atmel usb-avr devices and the open source firmware I was developing. And the above rule made things “just work”.

$ lsusb -vd "03eb:"|grep iM
iManufacturer           1 mycompany.com
$

This rule fixed all of my LUFA based devices including the my open source arduino programmer as well as the dfu programmer.used to code them. Hopefully it will be a while before I have to go through this again.

There’s trunk and then there’s whatever-ax-was-using

Tuesday, July 6th, 2010

feurig: ax have you gotten anything to work with deans post feburary lufa?
[1:29pm] ax: post feb. hmm, i’d have to look into my project files to remember which version i was usting
[1:29pm] ax: just a sec
[1:29pm] feurig: I was pulling my hair out with the may release and then I went back to the standard “what ever ax was using” and things started working
[1:30pm] feurig: you used the feb19 release on the midimonster stuff
[1:30pm] feurig: where is that (explicitive deleted) tourist????
[1:34pm] ax: yeah, /lufa_100219/
[1:35pm] ax: i like this ‘whatever ax was using’ standard
[1:35pm] ax:
[1:48pm] bzztbomb: That should be a source control tag

Avr C programming references (linux-osx biased)

Thursday, June 3rd, 2010

Making Pigs Fly — Object Space, Spokane 07-11 June 2010 ($105)

Sunday, May 16th, 2010

An introduction to physical computing for artists and musicians.

What:

This workshop is an opportunity for 15 to 25 people to spend a week working on the fundamentals of integrating micro-controllers into the arts. At the end of the week participants should be able to build and program their own Arduino compatible micro-controller system and use it to interact with the physical world using motors servos lights relays and switches.

The workshop will be structured with a hands on approach. The theory being that we learn best by doing. The first two days will be devoted to building and programming the base platform and using it to control various devices. The remaining 3 days will be a lab devoted to incorporating the new tools into actual pieces. The cost of the course is $105 and includes the materials listed below as well as 5 days of hands on instruction.

What you will get.

  • A Benito usb to serial programmer
  • A Dorkboard! (an Arduino clone) Kit
  • An introduction to the Arduino and microcontrollers in an artists setting
  • A servo and a geared motor with paper feed.
  • A motor driver board.
  • Misc parts.
  • Help when you need it
  • To know that what you built worked at least once
  • Ideas

What to bring:

  • A laptop (there will be some (not many) loaner systems available)
  • A soldering iron (20-30W Pencil type)
  • A standard usb cable (A->B)
  • Some basic tools (esp wire cutters, x-acto knife)
  • superglue
  • A hot glue gun.
  • foamcore or cardboard.
  • A copy of your rsvp / paypal reciept.
  • Ideas.

When:

June 7th through June 11th from 1-5pm.

Where:

Object Space Gallery:

1818 1/2 E Sprague, Spokane WA

How do I rsvp?

Running Paul Stoffregons’s teensy_serial arduino core on DFU based chips.

Tuesday, April 20th, 2010
das blinkin

das blinkin

With a lot of my projects I have done my prototyping with Paul Stoffregon’s Teensy series of boards before moving them onto their own codebases. On those occasions where the “prototype was all I needed” I would compile the code using the teensyduino and then manually load the .hex file onto the target. As I am looking at using the arduino for more projects I decided to take a look at how paul interacts with the Arduino IDE and see if I could load code directly onto my chips.

boards.txt

The arduino allows for different chips and configurations through the boards.txt and the programmers.txt files. Each configuration usually will also have a “core” which maps the pins and handles the particulars of that chip. When you run paul’s teensyduino installer it adds several entrys to the boards.txt file including the entry below.

teensy_ser.name=Teensy 1.0 (USB Serial)
teensy_ser.upload.protocol=halfkay
teensy_ser.upload.maximum_size=15872
teensy_ser.upload.speed=38400
teensy_ser.upload.disable_flushing=true
teensy_ser.upload.avrdude_wrapper=teensy_reboot
teensy_ser.build.mcu=at90usb162
teensy_ser.build.f_cpu=16000000L
teensy_ser.build.core=teensy_serial
teensy_ser.build.post_compile_script=teensy_post_compile
teensy_ser.name=Teensy 1.0 (USB Serial) teensy_ser.upload.protocol=halfkay teensy_ser.upload.maximum_size=15872 teensy_ser.upload.speed=38400 teensy_ser.upload.disable_flushing=true teensy_ser.upload.avrdude_wrapper=teensy_reboot teensy_ser.build.mcu=at90usb162 teensy_ser.build.f_cpu=16000000L teensy_ser.build.core=teensy_serial ...
Looking at pauls additions to the boards.txt I see that he is using the teensy_serial core  that he has written to create a simple usb to serial interface and to map the usb avr pins and other peripherals to the arduino conventions. He is also adds an entry to the arduino uploader class which lets him use a wrapper for avrdude which lets him use his proprietary bootloader. This wrapper is installed by the Paul’s installer and  lives in the Arduino’s bin directory. After looking to see if this wrapper was a script I replaced the entry in the boards.txt and put a script into the bin directory called “dfume”, after seeing that my replacement wrapper worked I added two new entries for each class of avr that I wanted to use the atmega32u2 and the atmega32u4
#############################################################
fouryou.name = atMega32U4
fouryou.upload.protocol=atmega32u4
fouryou.upload.maximum_size=32256
fouryou.upload.speed=38400
fouryou.upload.disable_flushing=true
fouryou.upload.avrdude_wrapper=dfume
fouryou.build.mcu=atmega32u4
fouryou.build.f_cpu=16000000L
fouryou.build.core=teensy_serial
#############################################################
tooyou.name = atMega32u2
tooyou.upload.protocol=atmega32u2
tooyou.upload.maximum_size=32256
tooyou.upload.speed=38400
tooyou.upload.disable_flushing=true
tooyou.upload.avrdude_wrapper=dfume
tooyou.build.mcu=at90usb162
tooyou.build.f_cpu=16000000L
tooyou.build.core=teensy_serial
############################################################# fouryou.name = atMega32U4 fouryou.upload.protocol=atmega32u4 fouryou.upload.maximum_size=32256 fouryou.upload.speed=38400 fouryou.upload.disable_flushing=true fouryou.upload.avrdude_wrapper=dfume fouryou.build.mcu=atmega32u4 fouryou.build.f_cpu=16000000L fouryou.build.core=teensy_serial ############################################################# tooyou.name = atMega32u2 tooyou.upload.protocol=atmega32u2 tooyou.upload.maximum_size=32256 tooyou.upload.speed=38400 tooyou.upload.disable_flushing=true tooyou.upload.avrdude_wrapper=dfume tooyou.build.mcu=at90usb162 tooyou.build.f_cpu=16000000L tooyou.build.core=teensy_serial

I started with a blank script that just printed the arguments passed to the wrapper and then called it by restarting my Arduino (to reload the boards.txt) And then selecting one of the new boards and “Uploading” my code. This gave me a window to interactively work through my script. Since the avrdude_wrapper code just pretends to be an avrdude most of the script is munging the arguments passed to avrdude to get the commands to pass to dfu-programmer.

#!/usr/bin/perl
use Getopt::Std;
print @ARGV;
my %args;
my $hexfile;
my $dfu = "/usr/local/bin/dfu-programmer";
my $cpu;
my $hexfile;

getopt('pUc',\%args);
$hexfile=$args{U};
$hexfile =~ s/flash:w://;
$hexfile =~ s/:i//;
$cpu=$args{c};

print "\n[" . $hexfile . "]";
print "\n[" . $cpu . "]\n";
print "$dfu $cpu erase\n";
system "$dfu $cpu erase";
print "$dfu $cpu flash $hexfile\n";
system"$dfu $cpu flash $hexfile";
print "$dfu $cpu start\n";
system "$dfu $cpu start 1>&2";
print "\n";

There is one tricky bit. The current avr-gcc doesnt support the atmega32u2 correctly but the code for the at90usb162 is binary compatible so the build.mcu is set to the at90usb162. But then dfu-programmer supports the correct chip and wont find the device so we use the fact that the upload.protocol argument is passed directlyalong using the -c argument and everything works fine.

So now we just use the hwb and reset buttons to get the system into dfu mode and upload our code directly from the arduino. Its not as slick as the teensy in “auto” mode but it works.

TestBox

Sunday, March 14th, 2010

The testbox is an LCD/Dorkboard based arduino clone with two buttons and a pair of potentiometers. The switches, power and 4 io pins are made avaliable via screw terminals on the ouside of the testbox.


#include
/*--------------------------------------------------------------
pulse generator for test box

Depending on the setting of left dial send send pulses out on digital ouput pin 2
at between 1 and 122 hz when left button is pressed.
the lcd should show the hz and the number of pulses sent.

*/

//defines for analog "dial" pins.
#define D1PIN 0
#define D2PIN 1
//defines for switches
#define S1PIN 17
#define S2PIN 16
// other pins avaliable for testbox 2, 3, 4, 13
#define PULSEPIN 2

// defines for smooting (nsamples) and debounce (milliseconds)
#define SMOOTHING 16
#define DEBOUNCE 50

//defines to map pins to lcd
#define D4 7
#define D5 8
#define D6 9
#define D7 10
#define RW 11
#define E 6
#define RS 12
#define BL 5

LiquidCrystal lcd(RS, RW, E, D4, D5, D6, D7);

int d1 = 0, d2 = 0, s1=0, s2=0;

/* variables for debouncing switches and knobs */
int s1reading = 0 , s1previous = 0;
long int d1sum = 0, d2sum = 0, s1time=0;
int samples = 0;

volatile int overflowcount;
volatile int pulsecount;
volatile int pinstate=HIGH;

ISR(TIMER2_OVF_vect) {
if (s1) {
if (++overflowcount > d1) {
overflowcount=0;
pinstate=!pinstate;
digitalWrite(PULSEPIN,pinstate);
if ( pinstate ) {
pulsecount++;
}
}
}
}

void setup()
{ overflowcount = 0;
pulsecount = 0;

delay(1000);

lcd.begin(2,16); // Print a message to the LCD.
pinMode(S1PIN, INPUT);
digitalWrite(S1PIN, HIGH);
pinMode(S2PIN, INPUT);
digitalWrite(S2PIN, HIGH);
lcd.setCursor(0,0);
lcd.print(" ");

TCCR2A = 0; //freerunning timer 2
TCCR2B = (CS21|CS22); //divide clock by 256
TIMSK2 = TOIE1; //enable timer2 terrupt

}

void loop()
{

s2 = !digitalRead(S2PIN); //read s2 for grins or DEBOUNCE as below.

//DEBOUNCE s1
s1reading = digitalRead(S1PIN);

// If the switch changed, due to bounce or pressing...
if (s1reading != s1previous) {
// reset the debouncing timer
s1time = millis();
}

if ((millis() - s1time) > DEBOUNCE) {
if (s1 == s1reading) { // if DEBOUNCEd reading is a change
s1=!s1reading;
if (s1) {
pulsecount=0;
}
}
}
s1previous = s1reading;

d1sum += analogRead(D1PIN);
d2sum += analogRead(D2PIN);
if (++samples > SMOOTHING) { //when i have SMOOTHING samples then average them.
d1sum /= SMOOTHING;
d2sum /= SMOOTHING;

d1=map(d1sum,0,1023,0,122); //map dial to what you want values to be
d2=map(d2sum,0,1023,0,300);

samples=0;
d1sum = 0;
d2sum = 0;
}

lcd.setCursor(0,0);
lcd.print("Rate: ");
lcd.setCursor(6,0);
lcd.print(122-d1);
lcd.print("Hz ");

lcd.setCursor(0,1);
if (s1) {
lcd.print("ON ");
} else {
lcd.print("OFF");
}
lcd.setCursor(6,1);
lcd.print("# ");
lcd.setCursor(8,1);
lcd.print(pulsecount);
}

Reprogramming your avr-usb device using atmel’s built in bootloader

Friday, March 5th, 2010

Getting code onto the MidiMonster or Benito device.

Midi Monster Button Locations.

Midi Monster Button Locations.

Benito 7g Switch Positions.

Benito 7g Switch Positions.

Benito 2010 Switch Locations

Benito 2010 Switch Locations

Benito Without Buttons.

Benito Without Buttons.

All of the code on the Benito and MidiMonster devices is open source and references an open source library called the Lightweight Usb For Avr (lufa). Getting the code compiled and onto the device requires a few other open source tools.

AVR-GCC

The most current and stable release of the toochain for the AVR has untill recently been maintained by Eric Wedddington and released as WinAvr (http://sourceforge.net/projects/winavr/) Winaver integrates nicely into atmels avr studio http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=2725 and I reccomend that you get both if you are running windows. Each Winavr Release is closely followed by objective developments CrossPack for avr http://www.obdev.at/products/crosspack/index.html and a script for building the current toolchain on linux which is hosted by AvrFreaks at present there is also a debian package that was put out last month http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=90172

HWB? DFU?

Most Atmel “atmega” devices have a pin dedicated to determining weather or not the device goes into the bootloader depending on the devices flag settings. This pin is labled HWB (for hardware boot) on most of  the datasheets. The usb avr family has this mode set up by default. When you hold the hwb pin low and reset the device it goes into the bootloader. On these devices the built in bootloader uses a usb device class called the Device Firmware Uploader (DFU). Atmel provides a tool called flip for programming DFU devices on  windows and linux. There is an open source programmer called dfu-programmer http://dfu-programmer.sourceforge.net/

That other guys stuff.

Those of you who have worked with the teensy boards from paul stoffregon will notice some subtle differences. Paul wrote his own (closed source) bootloader rather than use the bootloader tha comes installed on the chips. Then he uses a hardware trick similar to the auto reset hack to make a single button manipulate both the reset and the hwb pins to put his boards into the bootloader. I didnt feel that either the two button arrangement or the builtin bootloaders were broken so I like most people working with these chips dont fix them.

Using the dfu-programmer

All of the programs in Dean Cameras Lightweight Usb for Avr have a “dfu” target. Once you have the target into the DFU mode you can simply

$make dfu

This will cause the dfu-programmer to erase the flash reprogramm it with a new hex file and restart the chip. You can also do this manually with the following commands

$dfu-programmer atmega32u2 erase
$dfu-programmer atmega32u2 flash mycode.hex
$dfu-programmer atmega32u2 start

This will cause the dfu-programmer to erase the flash reprogramm it with a new hex file and restart the chip.