I've finally sat down and started looking at getting the DAB module I got a while ago to work. I figure I'll write the control code for it on my desktop machine and then think about porting it over to the empeg.

I intend to blow a PIC to do the actual serial->i2c stuff in the finished product, but given my lack of experience in this exact field I thought I should dispense with as many variables as I can. So, the plan is to use a parallel->i2c adaptor and the i2c-parport-light kernel module with a simple PCF8574 to switch some lights on and off first. Then think about attaching my precious DAB module to the adaptor and then finally blow a PIC to control it directly.

Well, I appear to have stumbled at the first hurdle. I've built the adaptor that is shown in the i2c-parport module documentation. It was an ASCII art drawing, this is it after I fed it into Eagle:



According to the documentation it's an ELV adaptor so I modprobe it with type=3. I've connected up the PCF chip to the SCL and SDA lines and given it power and a couple of LEDs, I've also ensured the address lines are connected to GND. The modprobe appears to be sucessfull, I get a new i2c bus in my dev directory (i2c-3). But sadly all attempts to get or set any data (using i2cdump and i2cset) result in a Remote I/O Error after a long pause. Could anyone help me out?

Sorry Andy but I'm a bit thick, whassallthat?

The only thing I understood is DAB

You getting any activity at all on the clock or data lines? Put a scope on it?

The only scope I have access to is at work. I did put a couple of LEDs across the lines and GND. When it's unused, both LEDs illuminate dimly (of course it could be flashing very fast) when I send a request out the LED on the SDA line goes out and flashes briefly. Looking at the datasheet for the PCF8574 the start condition indicates the SDA line goes low to signify the start of the session. The SCL line doesn't change. Once the program has finished the SDA LED lights up again.

hijack-tree/arch/arm/special/empeg_dsp_i2c.[ch]

-ml

I think using the i2c in the empeg will be my last resort.

Thinking back I remember Patrick talking about using his Risc PC to talk i2c because it was really simple to do. Time to consult the oracle.

first of: i don't think i do qualify as i2c guru.
i have however succeded in getting a pic to talk to various i2c peripherals with the help of http://www.piclist.com/techref/microchip/16f877/snipp.htm !
maybe start at "INIT_I2C". i did come to like the in system debugging capabilites of th PIC16F876. you can get (or make) a fairly cheap ISD (In System Debugger) which helps alot, as you can (in system) single step thourg your code, watch variables and set one breakpoint.
hth