TRIS register calls.

[beaker404]

Starting a project that will be heavy on I/O needs. I am kicking around the idea of doing TRIS register calls throughout the code to use the 8 pins of a port as both inputs and outputs depending on what part of the code is running. Specifically using using say Port B for both address and data lines by setting the TRIS register and using octal latches.
Any pitfalls or reason this would not work? Typically I set the TRIS once in my INIT routine and not change it later in the code. Is there a problem with timing for changing a port mode? Comments welcome.

No code yet, still in the hardware design stage, and this question/concern came up.

Windows 10
PIC18F452 @10MHz
CCS PCB,PCM,PCH,PCD V5.064

[temtronic]

some ideas...

If you use standard_IO() the compiler will automatically change the tris as required.....

Speed, generally isn't an issue for 99.9999% of the programs posted here..

Could you use another PIC (bigger)...? I tend to design with a 46k22 (40 pins) then MAYBE reduce down to 26K22 (28 pins)...

Oops, I just dld the datasheet...it's a 40 pinner...

Maybe instead of a latch, use an 'I/O expander' ?
Maybe offload some functions to a smaller PIC ?

[beaker404]

Good ideas Temtronic.
was considering using the 18F65K40 for the extra I/O. It would simplify the design and make my PCB smaller as size is a concern here too.
Have not used the 18F65K40 before, so a bit out of my comfort zone but the thought of a simplified design is attractive. Not really needing the 64MHz speed of the chip either, looking at running around 20MHz.

[newguy]

You've probably already done this, but always consult a processor's errata before committing to using it in a design. ...Just me being paranoid.

[Ttelmah]

Using TRIS like this is perfectly sensible.

You have two choices to access the register:

1) #USE FAST_IO
This then means you can do a port wide output or input on the port
and TRIS will not be changed by the compiler.

Or

2)
#byte LATx=getenv("SFR:LATx")
#byte PORTx=getenv("SFR:PORTx")

Then do outputs to LATx (where 'x' is the port involved), and inputs from
PORTx.

The only 'issue' is if you forget and get the TRIS wrong. Particularly
remember that you have to set things like peripherals with the correct
TRIS if you are operating it totally yourself.

[temtronic]

Might lose less hair if you use what you KNOW, maybe add expanders as needed.
While there's 'better PICs' coming to market everyday...you can kill as LOT of valuable time due to 'bugs'....

[beaker404]

I think I will go with the FAST_IO option if that means I can drive the port pins with either the PIC port write or have them driven my device data lines without any need to change the TRIS or otherwise. Not sure about setting a port output byte then turning around and having the port pins driven to a state by another device data lines.

[beaker404]

Getting beyond the CCS discussion I know but I think what i am going to do, is use Port B as address and two latches to get my 16 address lines, then use Port D as data and two latches to get my 16 data lines in.

That way I set each port up as either input or output and do not change it, and get 32 lines for the price of 16. I may dig up schematics from last job 20 years ago when I did this there, hard to remember now.

[Ttelmah]

_You_ are always going to have to set TRIS, if you don't use standard_io.

With standard_io, the compiler automatically sets TRIS for every I/O
operation. Do an 'out', it sets a pin/port to drive. Do an 'in', and it sets
this to input. Use a peripheral, and it automaticllly sets it up for this.
Your TRIS at the start of the code, will be being overridden every time
you perform an I/O operation.
Use any other method of working, and _you_ become responsible for
doing this for every operation.

[beaker404]

Thanks for the clarification Ttelmah.

My only concern is how the PIC port hardware hands me writing OUT on a port then switching my hardware with incoming data to the port and then doing a IN on the port.
for that short time where the port is still an OUT and I am driving the pins externally as though they were inputs before I do the IN call.
granted, it is a small time, (uS) but still would happen allot, not wanting to damage port pins.

[Ttelmah]

Surely the external drive does not change till _you_ tell it?.
The normal proceedure would be to tri-state the pins (float), that are going
to have data fed in on them, _before_ you enable the external drive.
Not doing so, is unlikely to harm the PIC (though it will result in heating),
but will give massive 'noise' problems as spikes are introduced to the
supply rails and anything else round your circuit.
Switching must always be 'off before on'. Turning off what is already driving
a signal, before turning another source on.