Basic I2c Driver and DS1307 Coexist?

william chan

Hi, I am having problems using both the Basic I2C Driver and Kye's DS1307 RTC driver on the same pins P28 and P29.

The DS1307 object requires that both SDA and SCL pins are pulled up by 10k resistors, whereas the Basic I2C Driver assumes both pins are not pulled up at all.

My circuit has both pins pulled up by 10k resistors.

Before I initialized the Basic I2C Driver, the DS1307 RTC object works well.
As soon I i initialized the Basic I2C Driver to allow access to the 64k eeprom, the DS1307 access functions fail.

How do I modify the Basic I2C driver to coexist with the DS1307 RTC object?

Kye,

FYI, Your code works well at 40Mhz and 20Mhz clock speeds.
Great object!.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Rayman

pull-ups are required for all i2c busses...

Sounds like your just having the problem that one cog is trying to set a pin low while another cog is forcing it high...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

Mike Green

Basic_I2C_Driver leaves the I/O pins in input mode between calls, so it will work with other drivers. It makes no assumptions about whether pullup resistors are present. It will work if you have them. It will work if you only have a pullup on SDA (a minimum requirement for I2C).

Note that James Burrows' i2cObjectv2 from the Object Exchange uses the same I2C I/O as Basic_I2C_Driver and includes objects for both the DS1307 and standard EEPROMs.

As far as I can tell, Kye's DS1307 driver also leaves the I/O pins in input mode between accesses to the DS1307 (as they should be).

If you call the Initialize routine in Basic_I2C_Driver, this assumes that some other Basic_I2C_Driver routine will be called next. The Initialize routine does not leave the SCL I/O pin in input mode. This is deliberate. The Initialize routine is only intended to be called once during program initialization and may not need to be called at all. Some I2C devices may be left in an undefined state, particularly if you use the Propeller's reset button and the reset occurs in the middle of an I2C access. The Initialize routine is intended to get you out of that situation without cycling power.

Basic_I2C_Driver and Kye's DS1307 driver should co-exist. There must be something else going on. Please list your code.

william chan

I use the same main cog to access either Basic I2c Driver or the DS1307 object, so it is impossible that both objects are accessed simultaneously at any one time.

After I initialized the Basic I2c Driver, all accesses to the DS1307 clock like clock.getSeconds returns a zero value every time.

I think it might be because the Basic I2C driver leaves the SCL pin in output mode which the DS1307 object finds unacceptable.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Kye

Mmm, I wouldn't have a clue why there is a problem. My driver leaves the pins in input mode after it finish a transaction regardless of failure.

As far as I can tell the read and write page functionality of the Basic_I2C driver also leave the pins in input mode.

Try using the ROMEngine online. (Its the generic EEPROM driver in the data storage section in the obex.) It does everything using open drain mode just like my RTC driver.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Beau Schwabe

william chan,

If you are just using the RAW 'Read' and 'Write' commands from the 'Basic_I2C_Driver' make sure that you issue a 'Stop' command when you are done. Otherwise the lines won't be released and you WILL have conflicts with another I2C driver using the same SDA and SCL lines.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

william chan

I now found that if I add two lines to DS1307 StartDataTransfer method, everything works.

PRI startDataTransfer ' 3 Stack Longs

outa[noparse][[/noparse]Data_Pin]~ ' Added 2 lines to set the initial conditions
outa[noparse][[/noparse]Clock_Pin]~
dira[noparse][[/noparse]constant(((Data_Pin <# 31) #> 0))] := true
dira[noparse][[/noparse]constant(((Clock_Pin <# 31) #> 0))] := true

Seems like the DS1307 driver expects both the outa[noparse][[/noparse]SDA] and outa[noparse][[/noparse]SCL] to be low before a transaction can work correctly.

Unfortunately, calling either eeprom.initalize(28) or eeprom.stop(28) leaves either the outa[noparse][[/noparse]SDA] or outa[noparse][[/noparse]SCL] in a high state, even though they are input,
causing the clock.getSeconds to return zero value everytime.
Unless outa[noparse][[/noparse]sda] and outa[noparse][[/noparse]scl] are set to low (it does not matter that the pins are in input state)
before clock.getSeconds is called, it will fail.

This is the conclusion of my tests.
Can anyone confirm this?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Post Edited (william chan) : 6/8/2010 12:27:30 AM GMT

Mike Green

All of the Basic_I2C_Driver routines meant to be called directly by the user (except for "initialize") leave SDA and SCL in input mode. They don't care what state the OUTA bits are left in since those are always initialized to whatever state is needed.

I believe the I2C start sequence is supposed to begin with both lines pulled up, so I'm not sure why you had to add those lines to the DS1307 driver. I'll have to look at Kye's code more carefully when I have time.

kuroneko

dira[noparse][[/noparse]constant(((Data_Pin <# 31) #> 0))] := true

Slightly OT but can some kind soul explain to me what the point of constant clipping is (for pin numbers)? I mean if I - by mistake - specify my pin as 42 I don't want it silently clipped to 31 (which is dangerous given the special function of said pin). I'd rather prefer compilation to fail (which is easy to do, non-constant parameters could obviously be checked at runtime).

Mike Green

Unfortunately, the Propeller Tool doesn't have a way for a conditional error to occur. For a lot of hardware configuations, there's no way to provide a meaningful error indication on a run-time check. For library objects, there's also the question of how to provide a useful indication of an illegal parameter. In most situations, there will be some kind of default behavior. In the case of a pin number, there will be silent clipping of the 5 bit value whether it's written explicitly in the code or not. That's just the nature of the hardware (and the Spin interpreter).

Dave Hein

William,

It looks like you found the solution by clearing outa[noparse][[/noparse]Data_Pin] and outa[noparse][[/noparse]Clock_Pin].· Kye's driver seems to only toggle the dira pins.· I couldn't find any code that explicitly clears the outa pins.· Maybe it is done in another object.· The basic I2C driver will toggle the outa pins and the dira pins, so you will have to clear the outa pins before you can run Kye's driver again.

Dave

william chan

Can you get Kye to update the DS1307 code in the OBEX for the benefit of future users?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

JonnyMac

It seems odd to have an I2C component include I2C driver code (this assumes there will be nothing else on the buss). You may want to write a generic DS1307 driver that assumes the I2C protocol is handled elsewhere; this would allow it to play nicely with other I2C components. I've done DS1307 experiments with my own I2C driver, but don't have them wrapped into an object that's ready to post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Kye

Sure, I'll fix that. The one online is an old version anyway.

If you plan on using the FATEngine however you're gonna want to use my I2C driver. Its be designed to have locking support and such for multiple copies of the FATEngine open at once using·multiple copies of the DS1307 driver.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,