 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Rohit de Sa
Joined: 09 Nov 2007
Posts: 282
Location: India
|
|
 Posted: Thu Nov 12, 2009 12:18 pm |
 |
|
Darko: | Quote: | | i need to use one pin for writing SDA line and another pin for reading SDA |
I don't know why you'd want to do this, since the whole point of using 'serial' comms is to reduce the number of pins used  , and since CCS already has pre-made I2C functions ready for your use.
All the same, there are two ways you could go about this.
First:
You could bit-bang an I2C-like routine in firmware that uses one pin for SDAin and another for SDAout. SDAin can be permanently set as input, and SDAout can permanently be set as output. I say 'I2C-like' because this sort of bit-banging no longer confirms to I2C specs. Its more like 'three-wire-serial' (*not* SPI, mind you!). The SDAin and SDAout pins need to be shorted. Please keep in mind that there are 'ACK's and 'nACK's in I2C communications. You need to keep track of this.
Second:
Using this method you may be able to use the built-in functions (which was not possible in the previous implementation). Create two I2C streams: | Code: | #use I2C(master, sda=PIN_B0, scl=PIN_B1, stream=I2C_1)
#use I2C(master, sda=PIN_B2, scl=PIN_B1, stream=I2C_2)
|
I think the streams can share the same clock line (*please verify this!!*). Short B2 and B0.
I have *NOT* tested this code, but I think it'll work. I will put it into my compiler and try it out when I get the time.
In both cases, make sure you put pull ups on the pins and allow the pins to float high.
Rohit |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Nov 12, 2009 12:31 pm |
|
|
I2C master and slave are reading and writing within a single byte frame, so the suggestion surely can't work. Using your own software I2C code ist definitely the way to go.
There are of course several possible reasons, why you may want to split the SDA in- and output function, e.g. inplementing optical isolation or protected driver hardware. |
|
|
Rohit de Sa
Joined: 09 Nov 2007
Posts: 282
Location: India
|
|
| Posted: Thu Nov 12, 2009 7:26 pm |
|
|
| Quote: | | I2C master and slave are reading and writing within a single byte frame, so the suggestion surely can't work. |
With the sharp eyes and brains on this forum, I should probably have tested the code, or put much deeper thought into it, before suggesting it  | Quote: | | Please keep in mind that there are 'ACK's and 'nACK's in I2C communications. You need to keep track of this. |
Guess I should have added this disclaimer in the second suggestion as well. Anyway, thanks to FvM & Darko for pointing this out. 
| Quote: | | Or maybe there's an hardware solution for merging the 2 lines (read: open collector output from a comparator --- write: ttl input) into one pin of the pic... :/ |
I like the direction this is headed - personally, I'm more a 'hardware' than a 'software' guy. Tell me if you get this solution to work.
Rohit |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Fri Nov 13, 2009 1:24 am |
|
|
| Quote: | | I like the direction this is headed - personally, I'm more a 'hardware' than a 'software' guy. Tell me if you get this solution to work. |
As an inveterate hardware guy, I can tell you this: A hardware solution for demultiplexing a bidirectional
wired or signal can't work without a current sense or a similar means, e.g. utilizing different low levels.
Philips/NXP bidirectional bus buffer P82B96 is an example how it can work.
http://www.standardics.nxp.com/products/p82b/datasheet/p82b96.pdf
The part can be a hardware solution in the questioned application. |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Nov 14, 2009 3:16 am |
|
|
I think though, a crude solution, probably does exist, since in this case the signalling is single directional to/from the wireless modules.
The wireless 'receive' module, doesn't need to have the I2C bus come 'to' it. All it potentially does, is pull the I2C lines 'low', when it is receiving data. Hence, if it's output was a genuine I2C 'open collector' drive, it could be wire or'ed with the PIC's I2C pin. If it's output is push/pull, this could be simulated by adding an open-collector buffer, or even (but be careful about the levels involved), by putting a low drop diode in line.
The transmit module, would presumably need 'disable' connections, so it is not driven by data coming from the receive module, but with this present, can then just be driven from the PIC's I2C lines.
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
