First step: Simply use the Arduino IDE and the Wire lib. I use an Seeeduino because I need an Arduino that works at 3.3v level. Here the code :

#include <Wire.h>
void setup()
{
  Wire.begin(4);                // join i2c bus with address #4
  Wire.onReceive(receiveEvent); // register event
  Wire.onRequest(requestEvent); // register event
  Serial.begin(38400);           // start serial for output
  Serial.println("Boot Ok");
}

void loop()
{ delay(100); }

void receiveEvent(int howMany)
{
  char c = NULL;
  while(Wire.available()) // loop through all
  {
    c = Wire.receive(); // receive byte as a character
    Serial.print(c);         // print the character
  }
  Serial.println();
  Serial.println("===");
}

void requestEvent()
{
  Serial.println("read");
  Wire.send("Hello world from Arduino");
}

To test the Arduino I used a Bus Pirate, this is quite simple and fun, here a little snipset of my initial test with the BP (note the string are different). The I2C slave is at the 0×4 address (check the setup()).

Searching I2C address space. Found devices at:
0x08(0x04 W) 0x09(0x04 R) 

Read content from the device, 'ABCD'
I2C>[0x09 rrrrrr]
I2C START BIT
WRITE: 0x09 ACK
READ: 0x41
READ:  ACK 0x42
READ:  ACK 0x43
READ:  ACK 0x44
READ:  ACK 0xFF
READ:  ACK 0xFF
NACK
I2C STOP BIT
I2C>

send content to the device 'ABC'
I2C>[0x08 0x41 0x42 0x43]
I2C START BIT
WRITE: 0x08 ACK
WRITE: 0x41 ACK
WRITE: 0x42 ACK
WRITE: 0x43 ACK
I2C STOP BIT

Second step: Plug the Arduino to the NGW100. I used the wrapping technique. Simply connect SDA, SCL, and GND. (NGW100 pinouts : SDA=>9, SCL=>10, GND=>2)

On Linux, load the I2C-GPIO kernel module. On OpenWRT (used on the NGW100), simply load the kmod-i2c-gpio package.

Final step: If everything is Ok, we can now test the communication. I used a small piece of C code to deal with I2C on Linux.

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <linux/i2c-dev.h>
#include <sys/ioctl.h>
#include <fcntl.h>

void i2c_run(void) {
    int file;
    char filename[40];
    int addr = 0x4;
    char buf[32] = {0};
    int i;

    sprintf(filename,"/dev/i2c-0");
    if ((file = open(filename,O_RDWR)) < 0) {
        printf("Failed to open the bus.");
        exit(1);
    }

    if (ioctl(file,I2C_SLAVE,addr) < 0) {
        printf("Failed to acquire bus access and/or talk to slave.\n");
        exit(1);
    }

    i = 24;
    // read I2C
    if (read(file,buf,i) != i) {
      printf("Failed to read from the i2c bus.\n");
    } else {
      printf("Read %d bytes from I2C: [%s]\n",i,buf);
    }

    sprintf(buf,"IC2 from Linux to Arduino");
    i = strlen(buf);
    if (write(file,buf,i) != i) {
        printf("Failed to write to the i2c bus.\n");
    } else {
      printf("Sent %d bytes to I2C: [%s]\n",i,buf);
    }
}

int main()
{
  i2c_run();
  return 0;
}

As you can see this code is a bit rude, but works really well : Read the I2C bus, and send a sample string, a proof ? :)

Of course, I used string values but in real life a small protocol shoud be used. Another important thing: I used a NGW100 but you can use the same idea on all Linux embedded board like the Fonera, or anything else.

Update: Of course you can use the i2c-tools on Linux to detect your own device. To do that : Grab the i2c-tools source, and cross compile it for the AVR32. (You only have to change the CC path in the Makefile).

/Enjoy small Linux

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