CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

TRIS register calls.

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
beaker404



Joined: 24 Jul 2012
Posts: 163

View user's profile Send private message

TRIS register calls.
PostPosted: Wed Feb 27, 2019 2:04 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Feb 27, 2019 2:10 pm     Reply with quote

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



Joined: 24 Jul 2012
Posts: 163

View user's profile Send private message

PostPosted: Wed Feb 27, 2019 2:21 pm     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Wed Feb 27, 2019 2:24 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Feb 27, 2019 2:31 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Feb 27, 2019 2:31 pm     Reply with quote

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



Joined: 24 Jul 2012
Posts: 163

View user's profile Send private message

PostPosted: Wed Feb 27, 2019 3:42 pm     Reply with quote

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



Joined: 24 Jul 2012
Posts: 163

View user's profile Send private message

PostPosted: Wed Feb 27, 2019 3:50 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Feb 28, 2019 12:03 am     Reply with quote

_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



Joined: 24 Jul 2012
Posts: 163

View user's profile Send private message

PostPosted: Thu Feb 28, 2019 7:11 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Feb 28, 2019 9:00 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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