SHIn and SHOut

[streborc]

Is there any reason why SHIn and SHOut cannot occupy the same data pin such that the instructions below would not work?  My understanding is that the commands set the data direction of the port used.

SHIn Dat_Pin, Clk_Pin, Mode, [Var_In]

SHOut Dat_Pin, Clk_Pin, Mode, [Var_Out]

[top204]

Technically, the MISO and MOSI pins can be shared. However, it must be remembered that while data is being clocked into a slave unit, the slave unit is also outputting data, so it will meet a pin that is output low, then output high many times over, and this may cause problems. It all depends on the slave device.

If sharing the MISO and MOSI pins, it would be wise to place series resistors in them, so current overloads should not harm the slave chip. Or Schottky diodes, so one pin does not see the output of another.

[streborc]

Les,

Thanks for your reply.  I think I need to provide a bit more information about my question and issue.

As you are aware I'm sure, in the world of serial peripheral devices, there are a handful of non-conformists that are almost, but not quite I2C.  I guess that in order to avoid paying licensing fees, the designers of these device deviate just enough to make their lives less expensive and our lives more complicated.  One example that you and others are likely familiar with is the TM1637 that's used in 4-digit/7-segment LED displays.  It's quite I2C except for its lacking of an I2C bus address, so interfacing it usually becomes a bit-bashing event.

I am currently working with an Everset ES100 timecode receiver.  This device receives broadcasts from the WWVB transmitter in the US\NA, which is similar to the UK's NPL/MSF transmitter.  The ES100 is another "almost I2C" interface that has a 2-wire SDA and SCL interface with 8-bit address and data, but has some goofy preamble/postamble chatter, that has to be coded for.  It's just different enough to rule out use of Positron's I2C command set.  And even if it was I2C compatible, the ES100's manufacturer recommends isolating it on its own bus so that its RF functions are not adversely affected by digital noise with other serial bus shared devices.

I wrote code in PBP a couple years ago that has been working effectively in receiving broadcasts and keeping my clock synchronized with WWVB's atomic clock.  My PBP code talks to the ES100 using the SHIFTIN/SHIFTOUT commands and uses some short bit-bashed preamble/postamble segments.  I'm now transposing the PBP code to Positron, and everything (the LCD uses I2COut and the RTC uses BusIn/BusOut) is working just fine, except for the ES100 interface.  I've transposed PBP's SHIFTIN/SHIFTOUT instructions to Positron's SHIn and SHOut instructions, but the SHIn variable always comes up empty.

The SHOut commands work exactly as required to configure a couple ES100 registers, set the receiver into reception mode, and then read the time/date data from the ES100 registers, except the ES100 register output data that is clearly present on the SDA line is never captured by the SHIn instruction.  It's as if the SDA port pin has a one-way valve on it that allows address and data to be issued to the ES100, but the byte that is returned is blocked.

I'm using a single hardware platform for testing.  I can install the PBP code and the clock works correctly.  When I install the Positron code, it never reads the ES100 registers.  I've tried every gymnastic I can think of with timing manipulations, including "Declare Shift_DelayUs", every mode and every port pin manipulation that's available (TRIS, WPU, ODCON, etc.), but nothing has worked.  In this regard, and perhaps a clue, I did have to ODCON the SDA pin in Positron to get SHOut to work, whereas this is not required in the PBP version.  I've compared the SCL/SDA waveforms on my oscilloscope, and there is no difference between the PBP and Positron bus activity.  The register byte that the ES100 outputs is present in both cases, but SHIFTIN reads it and SHIn does not.

At this point I'm completely perplexed. I asked my original question thinking that perhaps there is something is Positron's SHIn instruction that precludes it from accessing the same SDA pin assignment used by SHOut, inasmuch as the intended use of these instructions is with SPI's separate MISO/MOSI data pins.

I have an extra uC port pin available, so I'm going to use some resistors to divide the SHOut pin from the SHIn pin at the ES100's SDA pin and see if that remedies the problem.  I'll let your know the results.

[trastikata]

Hello streborc,

out of interest what is the uC device you are using.

Best regards.

[streborc]

I'm using a PIC16F18346.

[Fanie]

Is there any reason why SHIn and SHOut cannot occupy the same data pin such that the instructions below would not work?  My understanding is that the commands set the data direction of the port used.

SHIn Dat_Pin, Clk_Pin, Mode, [Var_In]

SHOut Dat_Pin, Clk_Pin, Mode, [Var_Out]

You will have to set conditions so the pic and the peripheral knows when to send and when to read.
(Assuming you have a peripheral device  )