On Sat, Apr 05, 2014 at 05:50:46PM -0400, Josh Koffman wrote:
> Hi all,
>=20
> Ok, as I continue to ply the waters of embedded C, I have a few more
> questions. I realize I should have saved the header file question I
> had last night and just made a list.
>=20
> First off, I wish I hadn't waited so long to give this a try. I am
> having a great time with this, it's quite a bit of fun!
>=20
> 1. Are variables usually declared as global or in the correct scope? I
> am struggling with what's the best practice here. For example, say I
> have a variable that I increment only in the ISR, so technically I
> should probably declare it in the ISR. I don't know exactly how the
> compiler allocates memory, is it even possible that it could allocate
> and free memory when entering or exiting a function?

This is a question of visibility. For the example you gave above, it should
probably be declared as a static local variable. This gives it the lifetime
of a global variable (the entire execution of the program) but the
visibility of a local variable. So it'll be visible during ISR calls, but
will retain its contents between ISR calls.

While it's a feel thing, the general best practice is to give each variable
the minimum lifetime and targeted scope to get its job done.

>=20
> 3. In regular C, the goto keyword is frowned on as it makes program
> execution hard to follow. Is this the case in embedded C as well?

I think that's a bit of a broad generalization. As a higher level language
C has abstracted control constructs (if, while, for, switch) that generally=
=20
abstract out the goto statements. Gotos/branches are still used underneath.
But the compiler handles them so that you don't have to.

> I
> haven't found much info with the searches I've been doing. Most of my
> current code in assembly uses gotos all over the place, but I
> understand that C removes the restrictions imposed by things like a
> decfsz, in that I can execute more than a single line after, or make
> these into function calls.

Exactly. The rule of thumb is to use the highest level abstraction that's
appropriate when available. You didn't have any of these higher level
contructs in assembly, so gotos/branches were appropriate. In C if a if or
while statement does the job you need to get done, then use it. Only if the
abstration creates more of a convoluted mess than the underlaying
construct, do you drop down.

In short, only use a goto if you have to, and if it makes your code cleaner
than not using it. Also document why. You'll find that it won't be very
often.

That's my take on the general language issues. I'll leave the specifics to
the group.

BAJ

--=20
Byron A. Jeff
Chair: Department of Computer Science and Information Technology
College of Information and Mathematical Sciences
Clayton State University
http://faculty.clayton.edu/bjeff
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.