The AVR Dragon is nice because you can use it as a small developpement device without any other requirement: Simply drop the needed ATMega on the board, some little wrapping for : Jtag + power supply.

As you can see, this is compact and nothing else is needed. The power supply come from the USB port, and I soldered a DIP on the board.. and that’s it.

I use the Jtag connector, so now I can use a real debugger instead of playing with the UART. Simply put a breakpoint, and enjoy :) By this way, I figure out that most of the time I simply push some stuff in arrays, and inspect them with debugger. This is really efficient. For example, last week I need to fix a timing issue with a IR sensor, simply wrap the little board, and push all interrupts in a array with the related timing. Of course, this can be done with a serial connection too, but it will take more time, and even worst if you encounter a bug, you will have to find where is it (the UART printf, or the code itself) ..

So, how to use this with a Linux OS ?

First you need to use AVaRICE to program the ATMega with a command like this :

avarice -g -j usb --erase --program --file main.hex :4242

Here the result:

AVaRICE flash the hex file to the ATMega, and wait for a GDB connection on port 4242. GDB is fine, but not really visual ;)

Let’s take a look at DDD

To use DDD with avr-gdb (the gdb for AVR), you need to edit a config file, for example gdb.conf and put this in :

file main.out
target remote localhost:4242

And the final command, just launch DDD like this :

ddd --debugger "avr-gdb -x gdb.conf"

Next step: Simply place some breakpoint, and the press “Cont” inue button in DDD. Et voilà :

I hope this little tuto will help people looking for a nice AVR debuger for the AVR on Linux (or any OSS system). The AVR Dragon is definitively a must have for low budget user in AVR scene.

Enjoy bug ? :)

After a couple of month, I decided it was enough, I was sick of this dirty stripes on screen. I tested every ATI driver one after one … (ATI opensource drivers have too bad performances to be used on a every days desktop, could you live without google-earth ? ) .. so I decided to go to other side, and bought a Nvidia 8600GT from ASUS. This card perform quite as the ATI in 3D, and have a affordable price. So I switched from ATI to Nvidia.

ATI offers better opensource support, but Nvidia binary driver is really nice to use and have better support today from stuffs like Compiz and Co.. and NO MORE STRIPES !! :)

A couple of weeks ago, I upgraded my Ubuntu Gusty to Hardy. Everything was Ok, since I played with firefox. Some heavy loaded pages (like Amazon, or Gmail) was damn sloowwwww ! Playing with scroll was a source …… grrrrrr ….Firefox on Hardy is 3.0b5. This version has a major “feature” the use a Xrender for the page display. And this looks like Xrender is dawn slow on Nvidia cards .. In fact, Nvidia has already work on this kind of issue before. Without looking forward I decided to run a little benchmark, with the help of friends with Xrenderbenchmark. So here the results.

Benchmarks

Benchmarks was done by me and 2 firends, on Q6600 or E6600 Intel CPU running at 2.4Gh, with kernel 2.6.24.1. The graphs only show the Plain results (not Plains + Alpha, or Transformation) but the results are quite the same anyways.

Legend:

• 8600GT/nv : Nividia 8600GT / Xorg 1.4.1git 32 bits / Nvidia GPL driver
• 8600GT/nvidia : Nividia 8600GT / Xorg 1.4.1git 32 bits / Nvidia binary driver ver: 169.12
• 8600GT/nividia-64 : Nvidia 8600GT / Xorg 1.4.1git 64 bits / Nvidia binary driver ver: 169.12
• Intel GMA X300 : Intel GMA 3000 / Xorg 1.4.0.9 64 bits / Intel GPL driver
• ATI HD2600PRO : ATI HD 2600 Pro / Xorg 1.4.1git 64 bits / ATI GPL driver

I split the results into two graphs for convenience.

As you can see on this first part, numbers are really small, the Nvidia GPL driver is the worst : 5 times slower than any other one. Not a good news, and the binary one have some bad results on 2 tests. ATI HD and Nvidia drivers offer quite the same results, but remenber this is the GPL ATI driver ! … The Intel doesn’t have a lot of linearity on this part.

But the next graph give us absolutely different picture !

For every graph, Nvidia drivers (GPL, or binary, 32 or 64 bits) are at least 6 time slower. Intel perform very well, no surprise, this card are damn cool, perfect driver for linux.. but to slow in 3D to really rock. And ATI GPL driver is the clear winner of this benchmarks tests.

As my issue is the Nvidia one, I can comment the results, the GPL driver performs better than the binary one. This is not a big surprise cause, I can see it in Firefox, even it’s slow. There is difference between 64 bits and 32, but I guess this is more kernel related than the driver itself.

I’m not a video guru and only do that figure out what’s going on my computer. I publish in the hope it might help somebody else, and to find help.

Update : The numbers can be found here

Thanks to Ludo and Christian for their help !

Important update : Check the new driver results !!

This is an old trick, but udev added a little complexity, so let’s give it a try. First boot on a Ubunty CD, open a console and run:

(here my linux partition is sda2, second partition on a sata disk)

mkdir /media/mnt
mount /dev/sda2 /media/mnt/
mount -o bind /dev/ /media/mnt/dev
chroot /media/mnt

=> now you are on the destination disk, so you can install grub.
grub-install /dev/sda

Of course you can do a lot more stuff, like changing fstab etc etc .. but the trick is to mount + mount bind + chroot

I decided to look at this a little deeply, and decided to use /dev/rtc to do the trick. Here a little example of the stuff.

from  fcntl import ioctl
import os, time

# some linux kernel header
RTC_IRQP_SET = 1074032652
RTC_PIE_ON =  28677
RTC_PIE_OFF = 28678

# open the realtime clock
f = open ("/dev/rtc", "r")
fd = f.fileno()

# 2048 freq
ioctl(fd,RTC_IRQP_SET,2048)
ioctl(fd,RTC_PIE_ON,0)

t0 = time.time()
interupt = 0

# the read will block until the next interrupt.
while interupt < 1000 :
os.read(fd,4)  # 4 = size of double
interupt = interupt + 1

delta = time.time() - t0
print interupt / delta

# drop the scheduler
ioctl(fd,RTC_PIE_OFF,0)

This is quite accurate enought, the only issue is that I’m unable to call the sched_setscheduler() from Python right now. So, if the host isn’t loaded I get the 2048 interrupts.. but it can be less :(

Update:
The sched_setscheduler can be done w/ a simple pyrex extension:

cdef extern from "sched.h":
struct sched_param:
int sched_priority
int sched_setscheduler(int pid, int policy,sched_param  *p)

SCHED_FIFO = 1

def switchRTCPriority(nb):
cdef sched_param sp
sp.sched_priority = nb
sched_setscheduler (0,SCHED_FIFO , &sp);

After this quick Pyrex hack, I now have a accurate realtime interrupt in Python ;)

Here on my shuttle .. not working

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: IXP [ATI IXP], device 0: ATI IXP AC97 [ATI IXP AC97]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: IXP [ATI IXP], device 1: ATI IXP IEC958 [ATI IXP IEC958 (AC97)]
Subdevices: 1/1
Subdevice #0: subdevice #0

Here on another box (VIA C3 based)

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: V8235 [VIA 8235], device 0: VIA 8235 [VIA 8235]
Subdevices: 4/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
card 0: V8235 [VIA 8235], device 1: VIA 8235 [VIA 8235]
Subdevices: 1/1
Subdevice #0: subdevice #0

So yes the C3 can play 4 stream at the same time, while the AC97 doesn’t.

Another way to do this is to use software mixing

Update:

To use the software mix in Alsa: simply change the pcm.default to pcm.dmix

#pcm.default cards.pcm.default
pcm.default pcm.dmix

I have tested several way to fix this issue. The only that’s working fine right now, is to use swsup. So to make it work:

• install the latest 2.6.9 kernel (the 2.6.8 has a issue w/ agpart and drm)
• in kernel select ‘ACPI -> sleep state’
• and ‘ACPI -> swsup’
• build the kernel
• create a swap partition if you don’t have one (i resized a ntfs w/ qparted)
• mkswap /dev/hda4 (for example)
• add ‘resume=/dev/hda4′ in your boot prompt (in grub for example)

Now your system is ready. Reboot :) ..To put the the system in standby and dump the current state in the swap: echo 4 > /proc/acpi/sleep.

Next step simply bind the power button on this action. This is done w/ the acpid.

#!/bin/sh
# /etc/acpi/powerbtn.sh

# put the box in swsup mode
echo 4 > /proc/acpi/sleep

Beside the S2/S3 ACPI doesn’t work right now, swsup permit to have suspend to disk without too much trouble.

This is really a bad news to all webcam users: USB kernel hackers decide to patch PWC kernel driver to avoid the use of the extended kernel module which is binary only. Check out this for more infos.

update: read this thread. Why Philips doesn’t provide spec ?

Hardware

The Shuttle STK62K is a small XPC that use:

• ATI IGP9100 video board
• ATI IXP150 AC’97 Audio Controller
• OHCI based USB 2
• Realtek network card

As i run into different issue with that box, i decided to write a little howto. Look here for more infos

0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5833 (rev 02)
0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5838
0000:00:13.0 USB Controller: ATI Technologies Inc: Unknown device 4347 (rev 01)
0000:00:13.1 USB Controller: ATI Technologies Inc: Unknown device 4348 (rev 01)
0000:00:13.2 USB Controller: ATI Technologies Inc: Unknown device 4345 (rev 01)
0000:00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 17)
0000:00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4349
0000:00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 434c
0000:00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4342
0000:00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC'97 Audio Controller
0000:01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5834
0000:02:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:02:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)

[*]   Symmetric multi-processing support
[*]   SMT (Hyperthreading) scheduler support

[*] ACPI Support
[*]   Sleep States (EXPERIMENTAL)
<M>   AC Adapter
<M>   Battery
<M>   Button
<M>   Fan
<M>   Processor
<M>   Thermal Zone

Device Driver > ATA/ATAPI/MFM/RLL support
<*>       Generic PCI IDE Chipset Support
[*]       Generic PCI bus-master DMA support
[*]         Use PCI DMA by default when available
<*>        ATI IXP chipset IDE support

Devices Drivers > Graphics support
<*>   ATI Radeon display support

Section "Device"
#Driver      "ati"
Driver       "radeon"
VendorName  "ATI Technologies Inc"
BoardName   "Unknown Board"
BusID       "PCI:1:5:0"
EndSection

Device Drivers> Sound > Alsa PCI devices
<M> ATI IXP 150/200/250/300

I2C > Hardware Sensors Chip support
<M> ITE IT87xx and compatibles

it87-isa-0228
Adapter: ISA adapter
VCore 1:   +1.45 V  (min =  +1.42 V, max =  +1.56 V)
VCore 2:   +1.53 V  (min =  +2.40 V, max =  +2.60 V)   ALARM
+3.3V:     +6.40 V  (min =  +3.12 V, max =  +3.44 V)   ALARM
+5V:       +4.97 V  (min =  +4.72 V, max =  +5.24 V)
+12V:     +11.68 V  (min = +11.36 V, max = +12.60 V)
-12V:     -19.77 V  (min = -12.63 V, max = -11.41 V)   ALARM
-5V:       -2.38 V  (min =  -5.28 V, max =  -4.81 V)   ALARM
Stdby:     +5.02 V  (min =  +4.72 V, max =  +5.24 V)
VBat:      +3.16 V
fan1:     1795 RPM  (min =    0 RPM, div = 16)
fan2:        0 RPM  (min =  332 RPM, div = 16)
fan3:        0 RPM  (min =  664 RPM, div = 8)
M/B Temp:    +60°C  (low  =   +15°C, high =   +40°C)   sensor = diode
CPU Temp:    +44°C  (low  =   +15°C, high =   +45°C)   sensor = diode
Temp3:       +41°C  (low  =   +15°C, high =   +45°C)   sensor = thermistor

Contents

• Introduction
  • Latitude D400
• Base Installation
• Finishing the install
• X / Sound / PCMCIA / ACPI
  • XFree
  • Sound
  • PCMCIA
  • ACPI
• About