Joe Wronski wrote:
>=20
> On 4/2/2012 7:08 PM, Sergey Dryga wrote:
> > eMyListsDDg<emylistsddg<at>  gmail.com>  writes:
> >
> >>
> >> new to using hi-tech c and would like to know which is preferred way
> >> to define
> > a pin for use.
> >>
> >> one can use TRIS, PORT or LAT bits to define a pin to put a LED on,
> yes?
> >>
> >> does one use one of the above or is it as simple as this?
> >>
> >>     #define LED1 RA0
> >>
> >> i'm a bit unsure which of the SFRs such as listed above that one
> would use.
> > i'm using 16f88
> >>
> > Yes, it is that simple.
> > Make sure that you set corresponding TRIS bit to output, in your
> case:
> > TRISA =3D 0bxxxxxxx0;
> >
> > where x - 0 or 1
> >
> > for simple use no need to do anything else.  You should
> > #include<htc.h>  file, it defines all different SFRs for the
> processor you use.
> >
> > Sergey Dryga
> > http://beaglerobotics.com
>=20
> So, it's not that simple, since you also need to set the tris bit to
> the right state.  Which could involve another macro statement, like:
> #define LED1_TRIS_BIT SomeTrisBitUnion.SomeTrisBit  And maybe another
> level of macro like #define ENABLE_LED (some code)
>=20
> It is good to know that rather than set the whole tris reg, in the case
> where some other code has already set it up, you can just (re)set the
> individual bit with a bit instruction or a bitwise AND or OR.

Yes, this is something I've struggled with when writing my tutorials -
deciding what the best advice to give is.  There's certainly a need to teac=
h
good practices, such as defining pins using macros, whether at the start of
the program or in a header, making the code far more maintainable - I make
the point that pin assignments can and do change, and you don't want to be
ferreting around trying to find everywhere you've referred to each LED.  On
the other hand, you can end up with so many macros that the code becomes
lost and so does the point I'm trying to explain.

So I've ended up with a compromise.  I define macros for individual pins
like this, and/or for the shadow equivalents of them, but not TRIS - or
others such as enabling pull-ups or interrupt on change (it can go on and
on).  Instead I keep all port configuration in a single initialisation
routine.  So, if a pin assignment changes later, I only need to make two
changes - a macro at the start of the program, and in the initialisation
code - which could be much more than changing one TRIS expression.  Maybe
the new pin has an analog input that has to be disabled, while the old one
didn't.

But of course there are always exceptions.  If you have some code that
flipping a pin between input and output (say multiplexing a switch with an
output), then sure it's best practice to define macros for the TRIS bits an=
d
changing them one at a time to avoid affecting anything else, as you say.

At the end of the day, some level of judgement has to apply.  There can't b=
e
one rule fits all.

Regards,

David Meiklejohn
www.gooligum.com.au


--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.