1 24LC256, 2 controllers w/r from/to it, hardware?

xanatos

I have a 24LC256 that gets ~ 1300 bytes written to it by a BS2px. I want, every so often, to switch the connections over to my Spinneret and have that read those bytes into an array. I'm all set with the code, but I'm thinking that the wiring between them might get interesting. First, the BS2 and the '256 are all on 5v; second, I'm not sure that even with level shifting that both the prop and the bs can be on the same i2c bus together... can they? Looking for thoughts about the simple way to do this. Also - timing of reads & writes between the bs2 and the prop is not an issue, only at issue is the physical level of what can be on the same i2c bus when one writes, and then the other reads.

Thanks for any help/schematics/links!

Dave

kwinn

Don't see where doing this would be a problem if level shifting is done for the prop and the BS2/prop are not stepping on each others reads/writes.

Mike Green

There's a nice application note on mixed voltage I2C busses. There's also a sticky thread in the Prop-1 forum that has a section on the use of 5V devices with the Propeller (here). As kwinn noted, the Stamp and the Prop-1 have to negotiate about access to the EEPROM.

xanatos

Thanks for the link - that level shifter is elegant. I'm sold on that one! Much simpler than what I was thinking about.

I can also set the I/O lines on the Prop and the BS2 to inputs when that unit is not actively doing any I2C'ing.

The Prop on the Spinneret acts really as a slave in its reading role. The BS2 sends a LOW to one of the IOs on the prop to initiate it's various functions of reading from the EEPROM and sending email. That function occurs in just over 3 seconds... then the Prop doesn't do much except serve HTTP requests on occasion with no access to the externals of the shared circuitry until the next LOW comes from the Stamp. And the Stamp doesn't write to the EEProm again until 10 minutes later, so there should be no issues with contention. Unless I screw up, not that that's ever happened! :-)

Thanks again,

Dave

Mike Green

If you're really brave, you could connect it all together with the 24LC256 and any I2C pullups all running at 3.3V. If, for some strange reason, either Stamp signal (SCK or SDA) gets accidentally set to high, even for a short time, you'll destroy the 24LC256 and the Propeller's substrate protection diodes and possibly the chip itself. You can't use a large enough series resistor in the line to the Stamp because the signal is open-drain with both the Stamp and Prop-1 serving as bus masters and you have to have pullups. Best is to use a proper voltage translator.

xanatos

Mike Green wrote: »

If you're really brave, ....

Nah. I'm paranoid with this stuff. You should see the input protection and rail clamping I have on the sensor data acquisition circuitry! It might survive multiple lightenting strikes! :-) It will at least remain completely unaffected by a 24VDC direct short to a 6.5A capable power supply! (Thanks to Tracey Allen for telling me how to use a transistor biased with a Zener to have the transistor do the heavy lifting with current shunting).

I'm going with those BSN10 N-Channel MOSFETS for my level shifters. Simple, cheap, easy. And this system really can't fail for something design related - bad juju. :-)

Dave

Peter Jakacki

xanatos wrote: »

I have a 24LC256 that gets ~ 1300 bytes written to it by a BS2px. I want, every so often, to switch the connections over to my Spinneret and have that read those bytes into an array. I'm all set with the code, but I'm thinking that the wiring between them might get interesting. First, the BS2 and the '256 are all on 5v; second, I'm not sure that even with level shifting that both the prop and the bs can be on the same i2c bus together... can they? Looking for thoughts about the simple way to do this. Also - timing of reads & writes between the bs2 and the prop is not an issue, only at issue is the physical level of what can be on the same i2c bus when one writes, and then the other reads.

Thanks for any help/schematics/links!

Dave

You can always force a Prop pin to "open-drain" mode. How do you do that you say? Just put a diode (cathode to port) in the line and a 10K resistor in parallel (just for SDA), now you are driving the I2C bus as it was meant to be driven and the 10K resistor allows the SDA to read the state of the line. If your EEPROM was on 3.3V then pull-ups to 3.3V would be all that would be required. Could you still do that? A little trick I use for 5V I2C devices to get them to recognize 3.3V pull-up as a high is to add a diode into their supply line.
If your EEPROM runs on a full 5V supply then alternatively you could connect your pull-ups to 5V through two diodes. The pull-up voltage will then be 3.8V max and the Prop pin will see 0.6V less than that, so 3.2V although the voltage will be higher than that on the SDA but current limited through the 10K.

Too easy? Your right, just use a more complicated solution.

EDIT: just included a schematic, 6 diodes and 2 resistors extra, works for all 5V and 3.3V devices. Assumes there are no other pull-ups.

Phil Pilgrim (PhiPi)

Is the 24LC256 really necessary? IOW, why not just stream the data directly to the Prop from the BS2SX? If the volume of data is an issue, the Prop could simply save it to its own dedicated EEPROM or SD card. In either case, the mess of a multi-master system is eliminated.

-Phil

xanatos

Nice circuit Peter, thanks. I did already buy the equivalents to the BSN10 (2N7000 and another number I forget now), so I'll probably stick with that - two transistors seems easy enough.

Phil... honest answer: I'm learning as I go and I have a time/deadline factor to consider and this is the route I felt most comfortable implementing given my limited Spin/Propeller knowledge! :-) Currently I'm collecting 100+ sensor outputs, sequentially selecting each one for A/D conversion, and then storing it's value, along with time/date and sensor ID info in the EEPROM. When they're all collected, I then read this data with the Propeller in the Spinneret into an array, and then write the elements of that array into specific order to create an email on-the-fly that is effectively a csv file, which is going to a third-party web-hosted monitoring system that ties into a bunch of other stuff.

Part of the reason I chose the EEPROM method is 1. the write cycle of the sensor values only needs to happen once every 10 minutes; 2. the data acquisition of all 100+ sensors takes a finite time to complete - I have set a rate for stable data that takes roughly 8 seconds to acquire all the sensor data WITHOUT writing to the EEPROM. I am concerned that if I establish a connection to the server for email and iterate the datalines after my SMTP DATA statement, and read in the sensor data at that point, it will take too long to send the email. 3. Between all the stuff I have going on that I've added into the Spinneret's programming to watch for various external signals and to handle certain requests in through the HTTP side of things, I have a total of about 80 longs left of the Propeller's memory, and I still have a few more things to add in.

I considered doing direct serial to Propeller with the data, but I'm not sure I will have the room for the FullDuplexSerial.spin object, and I still have questions about the timing to create the email.

HOWEVER... Since so far I've only made PC Boards for the input data selector boards ( lots of schottky diodes, resistors, 74HC4514s and CD4066 analog switches... all on 8 PC Boards) and the rest is still on my PPDB and the Spinneret is just hanging on some wires - I'm open to changing my course of action... I like the idea of writing direct to the Spinneret's Propeller's EEPROM and then reading from that at email time... the less unnecessary hardware - and code - to contend with, the better...

Probably more than you wanted to know... :-)

Dave