I'm going to be interfacing with several Devantech SRV-02 sonar sensors, that communicate over the i2c bus. I know that the EFIKA has an i2s bus on it, but am still unclear on what electrical and software changes need to happen to use i2c clients on the i2s bus.

I'd like to know if anyone is doing this, and could point me to some resources. I'll be doing this under QNX, but stuff in any OS would be great!

_________________
Kevin Nickels, Assoc. Prof, Trinity University, San Antonio, TX, USA

Kevin, check here:

http://www.powerdeveloper.org/platforms ... ifications

R&B :)

_________________
http://bbrv.blogspot.com

Yes, this points me to the 5200 manual with specs on it. Good to know, but not as useful as an actual success story. :)

_________________
Kevin Nickels, Assoc. Prof, Trinity University, San Antonio, TX, USA

OK, then the best thing to do is send a detailed email to support@efika.de and we will do our best to assist you!

Just think of it as another meeting like this:


Left to right: Bill, Gerald, Open Client with webcam and Kevin Nickels - Professor, Engineering Science, Trinity University

R&B :)

_________________
http://bbrv.blogspot.com

Since the 5 pin port (for i2c) has multiple functionality (irda,second serial port, i2c and gpio) it would be nice if we could get some input on how to use/switch each different function, as there are many applications that could be served by it

It doesn't do I2C, it does I2S which is a little different. I2S is meant for PCM data transfer for audio codecs. AC97 is very similar to I2S.

However at the very core it's a clock line and a data line (I2S has another data line too, which may mean only getting data from the sensor, rather than sending any..)

In any case, you can switch the mode by using the GPS register (MBAR + 0xB00) as described in the manual. We also have a Forth script for nvramrc which will swap the mode to IrDA before the OS boots if you need it (it doesn't present it in the device tree, however)

The chip is VERY well documented. You don't need any 'input' if you can read a PDF. Pay very close attention to the ports though, as you must not tamper with the USB, audio or ethernet configuration, and a lot of the ports on the board are actually multiplexed with each other so cannot be used.

The cheapest and easiest way of getting I2C (and SPI and a bunch more GPIO) on the Efika without messing with anything is this;

http://www.dimax.com.ua/i2c_usb/u2c12.shtml

I might have some more information on how (and why..) you can configure the board a little more flexibly for such device/project configurations, just be warned that the Efika has been designed to be functional from the start, and not just a bed of nails development system, so a lot of the resources are tied down.

_________________
Matt Sealey

I have just been learning about this - it's a lot different. I2C is more like SPI than like I2S - they're electrically different, and as far as I can tell incompatible.
Sure, I see how this helps me if I'm doing assembly on a bare 5200B. But if I'm reading the EFIKA docs correctly, the I2C pins are not brought out, correct?
The 5200B supports I2C as well as I2S, though not on this port.

(Really, I'm not yelling, I'm trying to figure out a new board, a new CPU, and a new OS while redesigning the project)
OK, I see how that would work. I see two other options for my situation.

• First, I've already got an I/O slave that understands I2C (an OOPIC) communicating with the EFIKA via serial, so I can just tunnel the data through the OOPIC. This is functionally what Matt suggested, just a different slave.
• Second, the SPI mode of the 5200B's PSC6 may work with some restrictions on what else you connect to it and some software - see, e.g. http://www.i2cchip.com/mix_spi_i2c.html)

My inclination is to do the latter, if QNX lets me set up PSC6 in this flexible a manner. I suspect it will.

BTW, whoever is responsible for the EFIKA specs sheet should take I2C out of the line about the "I2S/I2C 'codec' mode", which is what led me to believe that the PSC supported I2C. I could have sworn that Gerald told me that was the case as well, but once I started digging into the docs it doesn't look like it.

_________________
Kevin Nickels, Assoc. Prof, Trinity University, San Antonio, TX, USA

Pretty much.
Yes, there are two I2C controllers on the board, but as a side-effect of the board design, there is most definitely the RTC/NVRAM/power management chip sitting on one I2C bus, and the other one may be multiplexed into the CAN bus. I'm not sure as I can't work out what of the myriad options Gerald actually designed in, but with a little paper and a lot of thought I might even work it out before he gives the definitive answer.
You can set PSC6 up however you like, however ONE of the PSC6 pins is missing from the board (it wasn't required to support IrDA.. probably a silly idea in hindsight). This actually means that SPI configurations won't work (missing a data pin), you can't use serial handshakes (CTS is there but RTS is missing) and one of the codec modes won't work.
Hang on while I bite my foot off, then I'll remove the I2C bit.

I'm 100% sure Gerald told you it will do I2C too, because I'm 100% sure he told me too, but it's not true - that port just doesn't operate as an I2C port.

However the CAN bus pins on the bottom MAY (or may just be useless timer pins). It's probably just some confusion.. it's not hard to get confused looking at the signal descriptions in the manual (it's many, many pages of tables, and no bookmarks..) and I don't envy anyone who has it committed to memory.

Either way the USB or Serial interface is the best way right now. I'll find out for ya..

_________________
Matt Sealey

Is this paper that I have access to? Much as I try to treat these things as modules, I sometimes have to get down to this level to understand things - I'm an engineer, after all :)
Well, darn.
OK. I just had a thought - these sonars also have a UART mode that might work out. I had focussed on the I2C mode as the "easy" one. I'll check it out tomorrow. Thanks for the help, I think that I'm beginning to understand this now! Bill makes it sound so easy :)

_________________
Kevin Nickels, Assoc. Prof, Trinity University, San Antonio, TX, USA

As an exercise to rattle your mind, check out Chapter 2 of the MPC5200B manual. Embedded in this nightmare is the data required to derive the pin muxing on the Efika :D

I just can't do this stuff staring at a screen and a PDF.. I need to copy diagrams and things. I'm only doing THAT because I can't get the printer to work :D
I would think the advantage of having I2C sonars over UART sonars is that you can chain I2C and have them all at different slave addresses...

_________________
Matt Sealey

I'm currently working on a similar project. I plugged a TFT screen on the EFIKA and I need at least 1 gpio from the 5200B to manage the backlight module.

Since you can get up to 3 GPIOs on the IRDA connector I've begun to work on a "driver".

GPIO can be interested for you knickels because if you need a basic Master (EFIKA) / slave communication, I2C is very easy to emulate by software with GPIOs (I've done that many times and you will find many examples on the web).

As a basis you can look at this very interesting e-mail from the Linuxppc-embedded mailing list.

Going back to the EFIKA I've quickly tested this piece of code:
#include <asm-ppc/mpc52xx.h> have to be used instead of #include <asm/mpc52xx.h> because (at least for me...) asm/mpc52xx.h refers to asm-powerpc/mpc52xx.h which is not relevant here (strange, isn't it ?).

If you have built and installed the 2.6_rc6 kernel & modules (make && make modules && make modules_install) you can compile this module by doing this.

Makefile (assuming the name of the module src is testmod.c)
and to build it
insmod returns the correct GPIO base address...
So I'm pretty sure that each member of the "mpc52xx_gpio struct" will access the needed gpio registers (the datasheet gives all the details in chapter 7).

Perhaps you are familiar with modules on the 2.6 kernel but I'm pretty sure it can be usefull for other people.

Last thing, on the datasheet I saw that these 3 PINS are DRV4 and it seems that the max current you can get from them is 4mA. So I strongly suggest that you put a serial resistor of 1~10k to protect the 5200B in case of IO conflict.

(Please Neko correct me if I'm wrong.)

I'm too busy to work more on it this week but if you have some success using PSC6 it would be very nice to share this experience. ;-)

Stellae

Sure, but how do you generate the I2C clock using a GPIO pin? Surely it needs to be a constant tick and not just a "I will flick this when I am sending data and just leave it when I am not".

http://lwn.net/Articles/230571/

This is probably THE best route for writing an I2C driver over GPIO. The last Linux kernel release included a hardware-independant GPIO API, which I have been looking into getting support for..
Ugh. What's missing? We should make a patch..

_________________
Matt Sealey

I2C is a synchronous protocol and thus SCL can be generated by an IO even if the program is sometimes stopped by the OS scheduler. If you use the 5200B as a master, the clock is generated by an (output only) PIN.

SDA have to be bidir.

This method is called "bit-banging" and there is many examples on the web and even in the linux kernel (I've already driven many I2C devices with a program under linux (and from the user space ;-) as root) through a parallel port).

Stellae

Sure this method does not respect 100% of the protocol but it works very well. The I2C protocol define a max speed (100Khz or 400kHz) not a minimum speed (this is simple logic which act as a slave, so all operations are linked to SCL, this is the basic behaviour of synchronous digital logic...). I've driven DVB demodulators (hundreds of registers to handle) and tuners with this method... even a SAF7113 (a philips component which needs restart condition).

The patch you linked in your post is not also 100% clean but it (do) works:
Sensors are simple devices and this approach should work. This kind of driver requires less that 100~200 lines of code. If you dislike this method, do not use it. I just want to help, and share my experience, nothing else. ;-)

Nevertheless, I give information on how to use GPIO, this can be useful (I2C was not my primary goal...).
In the linux-2.6.19-rc6_efika you find code related to the mpc52xx in the include/asm-powerpc (freescale) folder and also in include/asm-ppc (efika). mpc52xx.h is in both folder but are not the same... And the default one when you include <asm/mpc52xx.h> is include/asm-powerpc which is incomplete.

Perhaps I've made a mistake, if you want to check. ;-)

Stellae

Okay I understand that you would generate the clock by just toggling the pin on and off, but you can't just stop the clock, right? Or doesn't it matter? The slave devices will simply not transfer data if the clock is not being used?
Well that's easy, just turn the GPIO from input to output mode.

What I'm worried about is this becomes a really CPU-intensive process, and if you want to sample input you would have to poll it incessantly..

Anyway, the only real problem I see is that as far as I can tell, the PSC6 controller is completely misnamed IRDA in the documentation, at least in parts. This is a giddy holdover from the original MPC5200 where there was no PSC6, only a dedicated IRDA controller.

So, you basically access the GPS port configuration register, which as previously mentioned as MBAR + 0xb00, and set the IRDA bits to 0 (the firmware does this anyway, but it may not in the future..)

Then you can use the GPS Simple GPIO Enables (MBAR + 0xb04) register to enable the TX pin on the IrDA connector. This is bit 28. Just toggle it on.

The same bit in the GPS Simple GPIO Data Direction register (MBAR + 0xb0c) sets input or output. Input is 0, output is 1.

The very same bit on the GPS Simple Data Output Values register (MBAR + 0xb10) drives the pin high (1) or low (0). This is your "write port". The GPS Simple Data Input Values register (MBAR + 0xb14) is your read port. Same bit.

...

The other two pins are wakeup-enabled so they are controlled by the wakeup set. The enables register is MBAR + 0xc00 and onwards and upwards.

It's all in chapter 7-3 (around page ~196) of the manual, just read through.

Something to note, the actual pinout of the IrDA connector (from the back of the board, nearest the USB ports) is

[ POWER PSC6_1 PSC6_0 GROUND PSC6_2 ]

PSC6_2 is otherwise known as IRDA_TX. PSC6_3 - otherwise known as IR_USB_CLK - is not connected. This is described in Chapter 2-78 (page ~104).

1 and 0 are wakeup and 2 is simple.

_________________
Matt Sealey