An Unflagged Redundant Port Pin Assignment

[streborc]

I'm working on a project using a PIC18F47Q10.  Everything is working just an intended, but when I was cleaning up the schematic and the code, I discovered that I had used the port pin RB1 twice -- first as a clock signal for an I2C device and again as a clock signal for an SPI device.  Curiously, both devices work without walking on each other. I have 2 initialization statements as follows:

Dim BPSK_CLK As PORTB.1

and

Declare SCL_Pin = PORTB.1

I'm puzzled about this redundant assignment not having caused an error or warning during compilation.  I plan to re-assign one of the clock signals to another pin, but am wondering if there's an explanation for this.

[trastikata]

There's nothing wrong to assign multiple names for the same physical port. The compiler will simply replace those names with the actual port pin every time the program listing is compiled.

Using the same pin for multiple purposes, especially is bit-banging i.e. software clock routines, is perfectly fine as long as the SPI device's CS pin is set while the I2C is being clocked. Vice versa clocking the software I2C device while the SDA pin is held low or high will not generate valid I2C address and register address to affect the device work. 

[top204]

As Trastikata, correctly, stated, the devices can have multiples of the same pin doing several different things, and some peripherals can also share pins, or be disabled while another peripheral uses the pin, so there is no way for the compilers to know which pins of which devices cannot be used with which peripherals or software interfaces etc...

Regards
Les

[Stephen Moss]

As @trastikata said, you can use the same pin for different functions and if you are limited on pin count that may be necessary, and as the code runs sequentially it should be impossible for you to use the same pin for both the SPI and I2C clock at the same time. However, as that pin is not being used in isolation it may due more to luck than judgement that you were not accidently communicating to both devices at once, so I think it best to avoid deliberate double usage wherever possible.

Also it is not necessarily a redundant assignment, the declare is presumable for use with one of the compilers commands, whereas the Dim is not as there is no SPI command thus although it may work if you were to remove the Dim statement and replace all instances of BPSK_CLK with SCL_Pin (try it and see), it may be better to use a different name for the SPI comms to avoid confusion as to what it is clocking when coding.

[streborc]

Thank you all for your prompt and informative replies.  I had been viewing this more from the perspective of hardware conflict than from the software angle, and I now appreciate that the compiler would not (and should not) attempt to flag this situation.

Assigning multiple aliases to bus pins is a technique I had not previously considered, but I can see how this could be useful.  For example, an I2C bus that uses PortA.1 for data could be aliased as Data_RTC, Data_LCD, Data_Mem, etc. to make the code more readable (perhaps "self-commenting").

My carelessness seems to have created a "Franken-bus" that's half SPI and half I2C in its sharing of the clock line.  Perhaps I got lucky, but I can see how this sharing can be done safely as long as the SPI chip select pin(s) is disabled during I2C reads/writes, and the I2C data bus remains silent during SPI reads/writes (which is the case for me).  And as stated above, this could be useful if the uC's pinouts are in short supply, but caution is advisable.

To be safe, I plan to isolate the SPI and I2C clock lines so that future code revisions don't bite me.  Again, thank you all for your insight.

[RGV250]

Hi,

this could be useful if the uC's pinouts are in short supply, but caution is advisable.

If you do something like this make sure you put loads of detail in the comments or this
 

so that future code revisions don't bite me

will come true.

Don't ask how I know
When doing it everything makes sense, come 6 months or so later when you revisit the project none of it will make sense and you will be cursing yourself for not commenting your thoughts at the time.

It also helps if you ever need to ask for help here.

Regards,
Bob