Making a Javelin behave as an I2C peripheral

Don French

I have a microcontroller circuit that I am doing development work on and the circuit has no display, which can make debugging challenging. But it does have an I2C bus so I am thinking I might be able to send debugging messages to a Javelin I have laying around that has a LCD display, using the I2C bus to communicate between the two. Are there any examples that I can look at that will help me with this?

jmspaggi

Hi,

You have I2C files inside stamp.peripheral.io. I think using this file and 2 pins, you must be able to retreive the informations from you circuit and display them on a screen with the Javelin.

So take a look at the stamp.peripheral.io.I2C class, and also stamp.peripheral.lcd.SerialLCD for the display.

Regards,

JM

Don French

For the Javelin to receive unsolicited data from the other computer on the I2C bus, it must constantly monitor the bus looking for a header with its (the Javelin's) I2C address and then stream in the data that follows. I assume that the address can be anything I want it to be as long as it doesn't collide with the addresses of the other I2C devices on the other computer and as long as there is agreement between the two programs. But I don't see code in the I2C.java class to make the Javelin act as a peripheral that monitors the bus. It appears that the I2C class was designed only to allow you to attach an I2C peripheral to the Javelin, not the other way around.

jmspaggi

Did you take a look there: http://www.parallax.com/tabid/430/Default.aspx#AN003 ?

I think you will find all what you need regarding I2C and the way to handle the address.

Also, stamp.peripheral.memory.eeprom.MC24LC256 is a good example on the way to use it. I'm using it to connect 8 MC24LC256 to my Javelin (a little home-made memory extention [noparse];)[/noparse] )

JM

Don French

I don't see how it helps. Once again, these are all about connecting I2C devices to a Javelin, not the other way around. All those devices have internal processors that perform the necessary I2C functions that a peripheral needs to perform. It is those functions that I need the Javelin to perform. Or am I missing something?

Don French

Here is a direct quote from the tutorial:

Although the I2C protocol has provisions for networks with more than
one microcontroller, the Javelin Stamp’s I2C library is designed to work
in a single-master network. This means that the Javelin Stamp is the
only microcontroller connected to a given bus. The rest of the devices
are called I2C slaves because they take orders from the I2C master (the
Javelin Stamp).

And I have been asking about a circuit that has two microcontrollers and the master is not the Javelin.

Don French

Now that I know the correct terminology, what I need is an example of how to make the Javelin an I2C slave in a single-master network where another microcontroller is the I2C master. I hope that this is now clear.

Peter Verkaik

There is no way to make the javelin behave like an I2C slave.
The only way to let the javelin act as a slave device is via a receive Uart.
So if you have 1 I/O pin on the other mcu that you can use to send serial
commands then you can use the javelin to control a display.
But in that case, why not use a serial LCD directly?

regards peter

Don French

So, Peter, which of your first two sentences is true? If it is the second sentence, can you elaborate on how it would be done?

The other mcu is on a production board and for various reasons attaching anything other than to an existing I2C port is not an option.

Peter Verkaik

You can use the SDA line for serial as well.
I2Cstart is SDA going low while SCL is high.
So, on your mcu, when I2C is idle (SDA high, SCL high)
make SCL low while SDA is high. This is not recognized by I2C devices.
Then serial transmit data using SDA [url=mailto:pin@9600]pin[/url], while keeping SCL low.
After sending all the bytes that make up a command, SDA will be high
(serial idle state) so just make SCL high again, signaling end of command.


On the javelin:

Uart myRx = new Uart(Uart.dirReceive,CPU.pinSDA.Uart.dontInvert,Uart.speed9600,Uart.stop1);

while (true) {
· if (myRx.byteAvailable()) {
····c = Uart.receiveByte();
··· if (CPU.readPin(pinSCL) == false) {
····· //handle valid incoming byte (store in array for postprocessing)
··· }
··· else { //pinSCL input high
······ //discard byte
······ //also·postprocess·command (special value last byte)
··· }
· }
}

While using I2C on the other mcu, pinSCL is not constantly low and
so the javelin will discard received bytes which have meaningless values.
You can add a checksum·to the command stream so any command received
that has a matching checksum is known to be valid.

JavPinSCL (input)

---

[noparse][[/noparse]1k]

---

SCL other mcu
JavPinSDA (input)

---

[noparse][[/noparse]1k]

---

SDA other mcu
JavGND

---

GND other mcu

regards peter

Post Edited (Peter Verkaik) : 4/21/2009 5:49:28 PM GMT

Don French

Thank you. This is very useful.

Actually I know how to use the IC2 bus with the other mcu as I am already using it to read and write to an EEPROM and a RTC on that unit. It looks like I need to filter for only those messages intended for the Javelin by comparing the device address for the message where you say to "postprocess command (special value last byte)", right? I think that I can figure the rest of this out by studying the I2C protocol.

Peter Verkaik

Not quite. The javelin cannot receive I2C bytes and therefore you can
not filter any I2C command. You must send a serial stream of bytes
that make up a command for the javelin, between I2Cstop and I2Cstart
(when I2C bus is idle) while keeping SCL low. That way the javelin
knows when received bytes are valid. So you must implement a uart
on the other mcu that uses its SDA pin to transmit the serial data.
Because the serial data is transmitted between I2Cstop and I2Cstart
the other I2C devices ignore these bytes.

regards peter

Don French

Oh dear. There is precious little program space left on the other mcu, which is one reason I wanted to use the existing code for talking to I2C devices. So, what is it about the Javelin that prevents it from receiving I2C commands? It is a programmable machine with available IO pins, after all.

Peter Verkaik

It is way too slow to detect incoming clockpulses
which are needed to clock in data.

regards peter

Don French

Ah, well now at least I understand the problem. I guess it's back to the drawing board.

Peter Verkaik

If your goal is to add an LCD display to your other mcu,
there are I2C LCD displays. Just google for I2C LCD.

regards peter

Don French

Thanks, I might just do that. I didn't say so in my original post but I also had some other ideas for using the Javelin but the most important thing right now is to display debug information, so that would be a solution for that. I wonder if there is an I2C to UART bridge device that can buffer data received over the I2C and retransmit it over the UART (and vice versa).

Peter Verkaik

Look here:
http://www.i2cchip.com/

Scroll down to BL233 chip.

regards peter

Don French

Thanks. I also found this: http://www.semiconductors.com/acrobat/datasheets/SC16IS740_750_760_5.pdf which looks like it might be an even better fit for my application.