Spinneret, Built-In RTC and I2C question

xanatos

The Spinneret has the DS1307 I2C RTC built in. The I2C "RTC" routine in HTTPServer.spin puts the default pins 28 & 29 into play.

I'm planning to use I2C Driver.spin for my external EEPROM functions, but - here's my questions.

1. Can/Should I use the calls defined in S35390A_RTCEngine.spin somehow to call my external EEPROM and NOT need to use I2C Driver.spin? I'm very shaky with this stuff, but it looks like the answer is probably no...

2: If I use I2C Driver.spin, and I use it on pins 28 & 29, would I be correct that the external EEPROM should NOT be configured to $A0, but should be on $A1 or above to prevent conflict with the DS1307?

3: Does the Propeller have any restrictions on what pins CAN be I2C? For example, with the BS2px, it can only be pins 0 & 1, or pins 8 & 9. No other pins will work with the I2CIN/OUT commands. In other words, can I use, say, p24 and p25 for my I2C line with the Propeller? Or can it only be 28 & 29?

4. I cannot see anywhere in HTTPServer.spin or the other support files where the RTC clock is called (and therefore using the I2C lines on pins 28 & 29). There seems to be some calls during the initialization method, but not during the ongoing regular operation of the server - that I can see. Just want to be sure I don't create any I2C buss conflicts.

Thanks!

Dave

Mike G

1. Can/Should I use the calls defined in S35390A_RTCEngine.spin somehow to call my external EEPROM and NOT need to use I2C Driver.spin? I'm very shaky with this stuff, but it looks like the answer is probably no...

No S35390A_RTCEngine.spin is a RTC driver not an EEPROM driver.

2: If I use I2C Driver.spin, and I use it on pins 28 & 29, would I be correct that the external EEPROM should NOT be configured to $A0, but should be on $A1 or above to prevent conflict with the DS1307?

Please read the published DS1307 datasheet for address ID of the DS1307. If I recall, the RTC address is not $A0 or $A1 - that's the EEPROM. By the way, a 1 is a write and 0 is a read. You might want to read up on the I2C protocol.

3: Does the Propeller have any restrictions on what pins CAN be I2C? For example, with the BS2px, it can only be pins 0 & 1, or pins 8 & 9. No other pins will work with the I2CIN/OUT commands. In other words, can I use, say, p24 and p25 for my I2C line with the Propeller? Or can it only be 28 & 29?

There is no restriction. Pin 28 and 29 are used to talk to the existing 64k EEPROM on the Spinneret board. Please see the datasheet/schematic.

4. I cannot see anywhere in HTTPServer.spin or the other support files where the RTC clock is called (and therefore using the I2C lines on pins 28 & 29). There seems to be some calls during the initialization method, but not during the ongoing regular operation of the server - that I can see. Just want to be sure I don't create any I2C buss conflicts.

There are code examples that utilize the RTC. The existing code base, S35390A_RTCEngine.spin, explains how to initialize and assign a lock if sharing the I2C bus.

PUB RTCEngineStart(dataPinNumber, clockPinNumber, lockNumberToUse) '' 9 Stack Longs

'' ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
'' // Changes the I2C Circuit pins.
'' //
'' // Returns true on success and false on failure.
'' //
'' // DataPinNumber - Pin to use to drive the SDA data line circuit. Between 0 and 31.
'' // ClockPinNumber - Pin to use to drive the SCL clock line circuit. Between 0 and 31.
'' // LockNumberToUse - Lock number to use if sharing the I2C bus (0 - 7). -1 to disable.
'' ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

I'm confused... Why can't ya just use the upper 32k of the existing 64k EEPROM? Everything is hooked up and ready to go...

xanatos

Mike G wrote: »

I'm confused... Why can't ya just use the upper 32k of the existing 64k EEPROM? Everything is hooked up and ready to go...

If you think YOU'RE confused! :-) I'm quite thoroughly sure that I'm confused, so there may be the answer to your question. I'm learning as I go on a live project, and in order to facilitate a guaranteed function by the delivery date, I'm doing what I can do that I can make reliably work on my bench. And what I can do might not be the best choice given the range of choices available for the hardware and code, but it's what I've been able to learn enough to make work so far. For example, I didn't know (although I'm sure I've probably seen it but it just didn't stick yet) that the Spinneret has a 64k EEPROM, and that I can use the upper 32k to store my stuff. So far, I've been going on the assumption that the Spinneret had just a 32k EEPROM, and with all the code for HTTPServer.spin, the SD Card FAT engines, the RTC Engine, simple numbers, string methods, PST, and I2C Driver, I really don't have a lot of memory left, so I figured out how to use I2C Driver with an external EEPROM that was shared with my BS2px, and voila - it worked. So that means I now have at least that option, even if it's not the best, with which I can satisfy the functional requirements of getting the data into variables that I can drop into iterative loops in my email sending routine and it gets the job done. BUT... I'm never satisfied with just getting the job done, and I'd much rather do it right if I can.

So to that end - I'm still confused on the I2C driving that seems to be already present within the Spinneret - If I want to use the built-in EEPROM's upper 32k, and use the I2C ports that are already broken out on the header on the Spinneret, and interface those two lines to the I2C lines on my BS2px using the level translators (N-Channel Enhancement MOSFET version from another thread) - ... Do I need I2C Driver.spin as an OBJ in my HTTPServer.spin file at all, or is there already an I2C method somewhere in there that I am not seeing? I did look at the code for the RTCEngineStart method and see it bitwise ANDing and comparing things - but I'm still confused as to where the I2C driving is being derived from without something like I2C Driver.spin (confused about most of this actually! :-) )

Also - regarding the write/read on I2C - here's the working code in my BS2px for the write and the read - my test program writes to a bunch of addresses, clears the variables, then reads them back and DEBUGS them. I use $A0 for both, oddly enough:

' Write 

I2Cout  SDA, $A0, wrdAddr.BYTE1\wrdAddr.BYTE0, [testVar]
PAUSE 10

'.... <snip. ----

'Read

I2CIN SDA, $A0, wrdAddr.BYTE1\wrdAddr.BYTE0, [testVar]
DEBUG DEC2 testVar, CR

The addressing in the way that PBASIC does it with the stamps, may be taken care of by the I2CIN/I2COUT commands themselves. I know there's actually data sent and received for both IN or OUT, but IIRC, PBASIC handles that internally, so this is what was in my mind when I asked about A0 above - I was forgetting that PBASIC handled that part.

I apologize for the long winded details here, but I'm hoping to provide you with enough details of what I'm doing so you can get an idea where my thinking is at and what I'm actually doing with this stuff. Also the fact that two weeks ago I wouldn't have understood ANYTHING of what I have written in this post. I have a bad habit of learning things by throwing myself into the deep end with the rocks and the sharks. SO far, it's worked pretty well - thanks to the many helpful people on this forum!!!! :-)

Thanks again for putting up with my questions and helping me figure this amazing thing out!

Dave

Mike G

If I want to use the built-in EEPROM's upper 32k, and use the I2C ports that are already broken out on the header on the Spinneret, and interface those two lines to the I2C lines on my BS2px using the level translators (N-Channel Enhancement MOSFET version from another thread) - ... Do I need I2C Driver.spin as an OBJ in my HTTPServer.spin file at all, or is there already an I2C method somewhere in there that I am not seeing?

Yes, a I2C driver running on the Propeller is required to talk to a I2C EEPROM device. Since there is already resources (PIN IO) allocated and the EEPROM has 64K then I would target the onboard EEPROM.

When I'm faced with unknowns, I'll do a little research and create isolated tests. Start with the EEPROM driver. Get read and write working. Then create a test using the RCT driver. Finally integrate the EEPROM and I2C driver and see what happens.

As for the space concern, the HttpServer is large and encompasses several features which may or may not be useful in the end product. Do you need all the features? Why save data in EEPROM when the data can be persisted on an SD card? Why send email when a simple HTTP GET can return data to a client? Without project requirement it is hard to provide guidance. What are you trying to do? 40,000 foot overview.

On a side note, why the heck is everyone using email to transmit data? That's driving me nuts.

I'll just throw this out there too... There is a newer driver which is a lot smaller and has more features. Plus the featured are layered so they are easier to add and remove.
http://code.google.com/p/propeller-w5200-driver/source/browse/trunk/#trunk%2F%20propeller-w5200-driver%2FSpinneret

xanatos

Lol... sorry to be driving you nuts. Emailing because that's the requirement of the third-party company I am interfacing my device to. They specify an email, since their web-based central monitoring system requires it. Since I code in VBScript/classic ASP, if it were up to me I would write all my server-side stuff to get anything I wanted - but I do not have any authority to place anything on their servers, so I am working within their specified constraints.

As for extra code in HTTPServer.spin, I do see that - actually in several of the object files - there is much that I can pull out, but I want to leave everything intact until I get everything else working, then pull stuff out a little at a time and test to be sure. Plus some of the stuff I have edited to make it do other things instead, such as the handlers for the POST functions - your servebeer website taught me how to respond to posts. Now, it is being used to manually force a data update via email if the company needs to see a level sooner than the 10 minute interval - along with a few other things that I have given them via a web interface.

I did - just as a test - strip down HTTPServer.spin to be free of everything I was certain I didn't need and it saved me 170 longs. A lot of that was also shortening the text in the PST blurbs that just write to the screen. I may pull PST out of there completely when this project gets installed, and that'll save a bunch right there.

So... summarizing so far, I will be using some version of an I2C Driver object to talk to the onboard EEPROM, using the upper 32k to store my data. I will be writing TO that EEPROM from my BS2px using level translating circuitry. And that EEPROM is going to be $A0 and $A1. (Alternately I can write it to/read it from the SD Card. ) My question now refers to that I2C locking function, which I am still very unclear on - where might I find some good reading on that. I looked at the Propeller manual, but the LOCKSET code in there seems to refer to hub/resource access locking - which I'm guessing is a separate function here.

Thanks again,

Dave