Is there an industry standard style guide that I should be following when coding in C for embedded applications or should I just make up my own and stick with it. I don't want to start any flame wars about which style is better than which, but if there is one that is generally accepted as a de facto standard I would like to get in the habit of using it.

Also, I'm finding it difficult to avoid using global variables in C. I've often heard that they should be avoided, but the only way I can think to avoid them is to make getters and setters. But then don't the getter and setter functions have to be global scope -- how is that better than just using globals to begin with?

Thanks for helping out a newbie.

John





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

It generally depends on the requirements imposed on you by the customer.

If the req'ts say you SHALL use MISRA-C then you MUST use it.

Same with the global variables.

It ALL depends on what is imposed on you by the req'ts.

If it's not a req't then you can impose it on yourself to d what you
deem is best, and make your own DERIVED req't out of it.

From: m... [mailto:m...] On Behalf
Of johnevanbaxter
Sent: Tuesday, July 10, 2012 7:29 PM
To: m...
Subject: [msp430] A couple of question from a new embedded developer

Is there an industry standard style guide that I should be following
when coding in C for embedded applications or should I just make up my
own and stick with it. I don't want to start any flame wars about which
style is better than which, but if there is one that is generally
accepted as a de facto standard I would like to get in the habit of
using it.

Also, I'm finding it difficult to avoid using global variables in C.
I've often heard that they should be avoided, but the only way I can
think to avoid them is to make getters and setters. But then don't the
getter and setter functions have to be global scope -- how is that
better than just using globals to begin with?

Thanks for helping out a newbie.

John







(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I would stay away from MISRA unless you have a real reason for it. Michael Barr (Netrino) has a great coding standard specifically for embedded C. We have adopted it as our own with just a few tweaks.
http://www.barrgroup.com/Coding-Standard-Muse

If you're looking for some justification as to WHY variable names should be what they are, function lengths, etc., I highly recommend "Code Complete" (McConnell). It's language agnostic, so it really helps you draw your own conclusions about how to craft code which is best for your own projects, company, etc.

As for global variables... if you have lots of them or you have created lots of getters/setters to deal with them, then perhaps the real problem is with the architecture. If lots of modules need to get to lots of variables in other modules, it may be time to refactor. I suspect (since this is an MSP430 group) that you have lots of application code banging away at hardware. Abstracting this into higher-level application code isolated from the hardware may obviate the need for the globals. Decouple your modules.

This is not a criticism of your code; I have no idea what the particulars are, but universally accessible getters/setters don't actually solve the problems of global variables; they just mask them and give the code author the ability to say he doesn't have global variables.

Good luck.

Stuart
--- In m..., "johnevanbaxter" wrote:
>
> Is there an industry standard style guide that I should be following when coding in C for embedded applications or should I just make up my own and stick with it. I don't want to start any flame wars about which style is better than which, but if there is one that is generally accepted as a de facto standard I would like to get in the habit of using it.
>
> Also, I'm finding it difficult to avoid using global variables in C. I've often heard that they should be avoided, but the only way I can think to avoid them is to make getters and setters. But then don't the getter and setter functions have to be global scope -- how is that better than just using globals to begin with?
>
> Thanks for helping out a newbie.
>
> John
>





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 11 Jul 2012 14:25:08 -0000, you wrote:

> I would stay away from MISRA unless you have a real reason
> for it. Michael Barr (Netrino) has a great coding standard
> specifically for embedded C. We have adopted it as our own
> with just a few tweaks.
> http://www.barrgroup.com/Coding-Standard-Muse

I agree about staying away from MISRA, not so much because I
don't like it but because I don't like the idea of any
ideology taking over one's ability to think and process.

The above statement does NOT imply that you don't develop a
consistent style of coding. You must do that because anyone
else reading your inconsistently written code will be put to
some serious strains. So developing your style is important
and applying it consistently for any specific project at the
moment is important.

Having a personal consistency is NOT the same thing as
imposing (someone else's) blindly accepted standards. Blind
acceptance of anything is wrong-minded.

I would passionately avoid some of Barr's standard. But as
this is a style issue I will avoid starting another debate by
listing some of the ones I feel more strongly opposed to.

My advice is to THINK, not just blindly following anyone
else's exposition. Ideological sycophants deserve no respect.
Think and then do what works better (when you have the room
to make such choices.) And be open to changing what you do
when you find you've grown and learned something new that
impacts your earlier decisions. (But not in the MIDDLE of a
project!!)

Get better over time. But do NOT become a stick in the mud
with no brain. Learn from standards others have composed and
think about what they say and why, but never treat them as
gospel.

...

One does have to follow imposed standards, such as they may
be; imposed by those paying for the work when doing something
or by the needs of a team effort where shared approaches
become increasingly important. But I've had as many as three
customers (money passing through each of them to get to me,
so I really did have three completely different and
independent customers with their own different goals and
interests and team coding standards) and that can really
complicate your life if you try and please everyone at once.

So sometimes you do have to express an opinion and, if
possible, be prepared to make it stick.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On 07/11/2012 10:24 PM, Jon Kirwan wrote:
> On Wed, 11 Jul 2012 14:25:08 -0000, you wrote:
>
> > I would stay away from MISRA unless you have a real reason
> > for it. Michael Barr (Netrino) has a great coding standard
> > specifically for embedded C. We have adopted it as our own
> > with just a few tweaks.
> > http://www.barrgroup.com/Coding-Standard-Muse
>
> I agree about staying away from MISRA, not so much because I
> don't like it but because I don't like the idea of any
> ideology taking over one's ability to think and process.
>
> The above statement does NOT imply that you don't develop a
> consistent style of coding. You must do that because anyone
> else reading your inconsistently written code will be put to
> some serious strains. So developing your style is important
> and applying it consistently for any specific project at the
> moment is important.
>
> Having a personal consistency is NOT the same thing as
> imposing (someone else's) blindly accepted standards. Blind
> acceptance of anything is wrong-minded.
>
> I would passionately avoid some of Barr's standard. But as
> this is a style issue I will avoid starting another debate by
> listing some of the ones I feel more strongly opposed to.
>
> My advice is to THINK, not just blindly following anyone
> else's exposition. Ideological sycophants deserve no respect.
> Think and then do what works better (when you have the room
> to make such choices.) And be open to changing what you do
> when you find you've grown and learned something new that
> impacts your earlier decisions. (But not in the MIDDLE of a
> project!!)
>
> Get better over time. But do NOT become a stick in the mud
> with no brain. Learn from standards others have composed and
> think about what they say and why, but never treat them as
> gospel.
>
> ...
>
> One does have to follow imposed standards, such as they may
> be; imposed by those paying for the work when doing something
> or by the needs of a team effort where shared approaches
> become increasingly important. But I've had as many as three
> customers (money passing through each of them to get to me,
> so I really did have three completely different and
> independent customers with their own different goals and
> interests and team coding standards) and that can really
> complicate your life if you try and please everyone at once.
>
> So sometimes you do have to express an opinion and, if
> possible, be prepared to make it stick.
>
> Jon
>

I agree with this - and in keeping with Jon's post, I will not go into
detail about what I don't like about Misra or Barr's standards. It is
certainly clear to me that no one standard suits every use - the best
advice is to study standards such as these two, and use them to help
formulate a rule set that suits /your/ use.

Another two standards that are worth studying are Google's C++ standard
and the Joint Strike Fighter C++ standards - both are easy found with
google. (The JSF is a an astoundingly badly managed software project -
but their standards document is not bad.) These are both C++ standards
rather than C, but many of the ideas apply.

Also when looking at standards, remember that you don't necessarily have
to have a large set of rules. You can start with just a few lines,
emphasising the need for clarity and readability in the code - or you
can write hundreds of pages detailing exact naming conventions and the
precise spacing used in comments. Obviously, I recommend starting
small, and don't go for more detail than you need.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Why the big taboo on global variables? Like any other aspect of
programming they are simply a tool that, if used carefully, is no
different to any other tool. Although I fully appreciate the need for a
decent coding standard I think that sometimes it is taken too far.
Eliminating global variables for the sake of it (and I know that isn't
what you're suggesting, this is just my general commentary to the thread
with no personal criticisms of anybody intended) is an inane excercise
that probably leads to slower, larger and unnecessarily complex code.

The argument against globals seems to mostly boil down to issues
regarding cross contamination between functions, but this issue has been
there since the dawn of programming, and has been handled by programmers
without issue long before the advent of high level programs that hid
such things from view. I see the bigger problem as being anything that
detracts from code efficiency. If it is more efficient to use a global
then do it.

Al
On 11/07/2012 11:55 PM, Stuart_Rubin wrote:
> I would stay away from MISRA unless you have a real reason for it. Michael Barr (Netrino) has a great coding standard specifically for embedded C. We have adopted it as our own with just a few tweaks.
> http://www.barrgroup.com/Coding-Standard-Muse
>
> If you're looking for some justification as to WHY variable names should be what they are, function lengths, etc., I highly recommend "Code Complete" (McConnell). It's language agnostic, so it really helps you draw your own conclusions about how to craft code which is best for your own projects, company, etc.
>
> As for global variables... if you have lots of them or you have created lots of getters/setters to deal with them, then perhaps the real problem is with the architecture. If lots of modules need to get to lots of variables in other modules, it may be time to refactor. I suspect (since this is an MSP430 group) that you have lots of application code banging away at hardware. Abstracting this into higher-level application code isolated from the hardware may obviate the need for the globals. Decouple your modules.
>
> This is not a criticism of your code; I have no idea what the particulars are, but universally accessible getters/setters don't actually solve the problems of global variables; they just mask them and give the code author the ability to say he doesn't have global variables.
>
> Good luck.
>
> Stuart
> --- In m..., "johnevanbaxter" wrote:
>> Is there an industry standard style guide that I should be following when coding in C for embedded applications or should I just make up my own and stick with it. I don't want to start any flame wars about which style is better than which, but if there is one that is generally accepted as a de facto standard I would like to get in the habit of using it.
>>
>> Also, I'm finding it difficult to avoid using global variables in C. I've often heard that they should be avoided, but the only way I can think to avoid them is to make getters and setters. But then don't the getter and setter functions have to be global scope -- how is that better than just using globals to begin with?
>>
>> Thanks for helping out a newbie.
>>
>> John
>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I once wrote a program that had a large "if else if" section so that it could take appropriate action if any of the functions called in the conditional returned an error.

There were about a dozen conditionals all of which took exactly the same arguments except for two. After looking at this, I made the 4 arguments that were passed to all the functions globals with file scope. This made the two functions which had 5 arguments more obvious.

In programming the most important thing is readability. If a program is hard to read and understand it is either wrong or will be when someone tries to change it.

Programming rules exist for a reason. What matters is the reason, not the rule.

Have Fun!
Reg





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Thu, 12 Jul 2012 14:52:41 -0700 (PDT), Reginald Beardsley
wrote:

>
> In programming the most important thing is readability. If
> a program is hard to read and understand it is either wrong
> or will be when someone tries to change it.
>
> Programming rules exist for a reason. What matters is the
> reason, not the rule.

Yes. I use a close analogy to this.

Goals are things you cannot ever achieve -- but they are
directions you hope you move towards. One then sets specific
"objectives," which if achieved one believes are indications
that the right direction is still in hand. But sometimes the
objectives (or rules) that are set down to be completed
actually turn out to move you in the wrong direction in
achieving your goals. So you always have to be aware that
your real purpose isn't this or that objective, but the
goals.

When Lee Iococca said that wanted Chrysler to be "the best
car company" he wasn't talking about achieving that, but that
it was a path they wanted to walk. You cannot ever say,
"Well, there. We've done it. We are now the best car
company." It's not a destination. It's a guiding principle
and you can't achieve those and then walk away. You aren't
ever done, you never "get there." It's your goal, not a spot
you reach.

The goal of readability is an example. You cannot ever say
you've achieved it and then walk away from it and put no more
work into it. But you can say that specific rules you try and
apply regularly help move you closer towards your actual
goals. But you also must always keep in mind that you need to
look and see if your concrete, specific rules or objectives
you've set earlier really do move you in the right
directions.

In other words, your brain is always engaged and examining
and weighing the results of your objectives and rules. If you
can see that they are moving you away from your actual goals,
then you need to change them. Because it is the goal, not the
objectives you've set in the belief they will help you get
there, that really counts.

Don't get confused and ever allow your rules to become your
goals.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Thanks for the good advice, everyone.






(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Giving a mathematician�s answer,�



Your goals are reached asymptotically like a hyperbola, meaning you�re always getting closer, but you�ll never get there.







From: m... [mailto:m...] On Behalf Of John Evan Baxter

Sent: Thursday, July 12, 2012 7:05 PM

To: m...

Subject: Re: [msp430] A couple of question from a new embedded developer











Thanks for the good advice, everyone.

















(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Regarding the global variable issue, it's not a taboo. The original poster implied that he had LOTS of them, for which in turn he decided to use accessor functions. (I may be paraphrasing here...)

Sometimes a global variable is the right thing. Often, and in my experience, usually, it is not.

In my experience, having more than one or two absolutely time-critical variables (usually intimate with hardware) which require true global visibility, is a red flag, or at least an arrow pointing an a potential area for improvement. The problem is likely not the variables, but the correct partitioning of the modules.

Every variable, including its type, name (yes, its name), scope, decorators, location in code, is a series of design decisions, not unlike a Mechanical Engineers decision on what size, shape, location, material a bolt should be. If he's struggling with the number, size, shape, etc of the bolts, then maybe there is an underlying design problem, or at least an area for improvement.

Stuart

--- In m..., Onestone wrote:
>
> Why the big taboo on global variables? Like any other aspect of
> programming they are simply a tool that, if used carefully, is no
> different to any other tool. Although I fully appreciate the need for a
> decent coding standard I think that sometimes it is taken too far.
> Eliminating global variables for the sake of it (and I know that isn't
> what you're suggesting, this is just my general commentary to the thread
> with no personal criticisms of anybody intended) is an inane excercise
> that probably leads to slower, larger and unnecessarily complex code.
>
> The argument against globals seems to mostly boil down to issues
> regarding cross contamination between functions, but this issue has been
> there since the dawn of programming, and has been handled by programmers
> without issue long before the advent of high level programs that hid
> such things from view. I see the bigger problem as being anything that
> detracts from code efficiency. If it is more efficient to use a global
> then do it.
>
> Al
> On 11/07/2012 11:55 PM, Stuart_Rubin wrote:
> > I would stay away from MISRA unless you have a real reason for it. Michael Barr (Netrino) has a great coding standard specifically for embedded C. We have adopted it as our own with just a few tweaks.
> > http://www.barrgroup.com/Coding-Standard-Muse
> >
> > If you're looking for some justification as to WHY variable names should be what they are, function lengths, etc., I highly recommend "Code Complete" (McConnell). It's language agnostic, so it really helps you draw your own conclusions about how to craft code which is best for your own projects, company, etc.
> >
> > As for global variables... if you have lots of them or you have created lots of getters/setters to deal with them, then perhaps the real problem is with the architecture. If lots of modules need to get to lots of variables in other modules, it may be time to refactor. I suspect (since this is an MSP430 group) that you have lots of application code banging away at hardware. Abstracting this into higher-level application code isolated from the hardware may obviate the need for the globals. Decouple your modules.
> >
> > This is not a criticism of your code; I have no idea what the particulars are, but universally accessible getters/setters don't actually solve the problems of global variables; they just mask them and give the code author the ability to say he doesn't have global variables.
> >
> > Good luck.
> >
> > Stuart
> > --- In m..., "johnevanbaxter" wrote:
> >> Is there an industry standard style guide that I should be following when coding in C for embedded applications or should I just make up my own and stick with it. I don't want to start any flame wars about which style is better than which, but if there is one that is generally accepted as a de facto standard I would like to get in the habit of using it.
> >>
> >> Also, I'm finding it difficult to avoid using global variables in C. I've often heard that they should be avoided, but the only way I can think to avoid them is to make getters and setters. But then don't the getter and setter functions have to be global scope -- how is that better than just using globals to begin with?
> >>
> >> Thanks for helping out a newbie.
> >>
> >> John
> >>
> >
> >
> >
> >
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Stuart, the reason I referred to this as a taboo stems from the OPs
original post:-

"Also, I'm finding it difficult to avoid using global variables in C. I've often heard that they should be avoided, but the only way I can think to avoid them is to make getters and setters. But then don't the getter and setter functions have to be global scope -- how is that better than just using globals to begin with?"

To me this states that he has heard they should be avoided, with no explanation given,not that he has made a design decision to avoid them, rather the opposite, he is trying, for programming doctrine reasons alone, to avoid them, but can't find a way to.

As a newbie I'd guess that he has underlying design problems, and certainly in C and many other high level languages the use of local variables helps to clarify the code, but I don't think he should blindly avoid them for the sake of it. At least until he has a better understanding of why they are deemed

Al
On 13/07/2012 11:19 PM, Stuart_Rubin wrote:
> Regarding the global variable issue, it's not a taboo. The original poster implied that he had LOTS of them, for which in turn he decided to use accessor functions. (I may be paraphrasing here...)
>
> Sometimes a global variable is the right thing. Often, and in my experience, usually, it is not.
>
> In my experience, having more than one or two absolutely time-critical variables (usually intimate with hardware) which require true global visibility, is a red flag, or at least an arrow pointing an a potential area for improvement. The problem is likely not the variables, but the correct partitioning of the modules.
>
> Every variable, including its type, name (yes, its name), scope, decorators, location in code, is a series of design decisions, not unlike a Mechanical Engineers decision on what size, shape, location, material a bolt should be. If he's struggling with the number, size, shape, etc of the bolts, then maybe there is an underlying design problem, or at least an area for improvement.
>
> Stuart
>
> --- In m..., Onestone wrote:
>> Why the big taboo on global variables? Like any other aspect of
>> programming they are simply a tool that, if used carefully, is no
>> different to any other tool. Although I fully appreciate the need for a
>> decent coding standard I think that sometimes it is taken too far.
>> Eliminating global variables for the sake of it (and I know that isn't
>> what you're suggesting, this is just my general commentary to the thread
>> with no personal criticisms of anybody intended) is an inane excercise
>> that probably leads to slower, larger and unnecessarily complex code.
>>
>> The argument against globals seems to mostly boil down to issues
>> regarding cross contamination between functions, but this issue has been
>> there since the dawn of programming, and has been handled by programmers
>> without issue long before the advent of high level programs that hid
>> such things from view. I see the bigger problem as being anything that
>> detracts from code efficiency. If it is more efficient to use a global
>> then do it.
>>
>> Al
>> On 11/07/2012 11:55 PM, Stuart_Rubin wrote:
>>> I would stay away from MISRA unless you have a real reason for it. Michael Barr (Netrino) has a great coding standard specifically for embedded C. We have adopted it as our own with just a few tweaks.
>>> http://www.barrgroup.com/Coding-Standard-Muse
>>>
>>> If you're looking for some justification as to WHY variable names should be what they are, function lengths, etc., I highly recommend "Code Complete" (McConnell). It's language agnostic, so it really helps you draw your own conclusions about how to craft code which is best for your own projects, company, etc.
>>>
>>> As for global variables... if you have lots of them or you have created lots of getters/setters to deal with them, then perhaps the real problem is with the architecture. If lots of modules need to get to lots of variables in other modules, it may be time to refactor. I suspect (since this is an MSP430 group) that you have lots of application code banging away at hardware. Abstracting this into higher-level application code isolated from the hardware may obviate the need for the globals. Decouple your modules.
>>>
>>> This is not a criticism of your code; I have no idea what the particulars are, but universally accessible getters/setters don't actually solve the problems of global variables; they just mask them and give the code author the ability to say he doesn't have global variables.
>>>
>>> Good luck.
>>>
>>> Stuart
>>> --- In m..., "johnevanbaxter" wrote:
>>>> Is there an industry standard style guide that I should be following when coding in C for embedded applications or should I just make up my own and stick with it. I don't want to start any flame wars about which style is better than which, but if there is one that is generally accepted as a de facto standard I would like to get in the habit of using it.
>>>>
>>>> Also, I'm finding it difficult to avoid using global variables in C. I've often heard that they should be avoided, but the only way I can think to avoid them is to make getters and setters. But then don't the getter and setter functions have to be global scope -- how is that better than just using globals to begin with?
>>>>
>>>> Thanks for helping out a newbie.
>>>>
>>>> John
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

David beckham eat your heart out.

Al

On 13/07/2012 9:32 PM, Hugo Brunert wrote:
> Giving a mathematician�s answer,�
>
> Your goals are reached asymptotically like a hyperbola, meaning you�re always getting closer, but you�ll never get there.
>
>
>
> From: m... [mailto:m...] On Behalf Of John Evan Baxter
>
> Sent: Thursday, July 12, 2012 7:05 PM
>
> To: m...
>
> Subject: Re: [msp430] A couple of question from a new embedded developer
>
>
>
>
>
> Thanks for the good advice, everyone.
>
>
>
>
>
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

GOOOOOOOoooooooooooooooooooooooooooooooolllllllllllllllllllllllll !!!!!!!!!!!!!!!!!!



THAT is reaching your goal!!:)







From: m... [mailto:m...] On Behalf Of Onestone

Sent: Friday, July 13, 2012 11:37 AM

To: m...

Subject: Re: [msp430] A couple of question from a new embedded developer











David beckham eat your heart out.



Al



On 13/07/2012 9:32 PM, Hugo Brunert wrote:

> Giving a mathematician�s answer,�

>

>

>

> Your goals are reached asymptotically like a hyperbola, meaning you�re always getting closer, but you�ll never get there.

>

>

>

>

>

>

>

> From: m... [mailto:ms... ] On Behalf Of John Evan Baxter

>

> Sent: Thursday, July 12, 2012 7:05 PM

>

> To: m...

>

> Subject: Re: [msp430] A couple of question from a new embedded developer

>

>

>

>

>

>

>

>

>

>

>

> Thanks for the good advice, everyone.

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

>
> GOOOOOOOoooooooooooooooooooooooooooooooolllllllllllllllllllllllll
> !!!!!!!!!!!!!!!!!!
>
> THAT is reaching your goal!!:)

I'm sorry--there are always blind referees and assistant referees in football and, hence, your goal will be disallowed, not seen, disputed, whatever.

Of course, the Premier League may now introduce goal line tech, much like Hawkeye has for tennis. Personally, I do not like Blatter's attitude, but there you go...

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I feel 50%-50% about adding �technology� to ANY sport.



Yes human eyes do make errors, humans make wrong decisions, and humans can be bought too.



So�. Should we add technology to a sport??? It does take away from what IT USED TO BE, but it does correct for HUMAN ERROR. Hence my 50-50 standings. I see both sides benefiting, and not.







From: m... [mailto:m...] On Behalf Of Paul Curtis

Sent: Friday, July 13, 2012 11:49 AM

To: m...

Subject: RE: [msp430] A couple of question from a new embedded developer











>

> GOOOOOOOoooooooooooooooooooooooooooooooolllllllllllllllllllllllll

> !!!!!!!!!!!!!!!!!!

>

> THAT is reaching your goal!!:)



I'm sorry--there are always blind referees and assistant referees in football and, hence, your goal will be disallowed, not seen, disputed, whatever.



Of course, the Premier League may now introduce goal line tech, much like Hawkeye has for tennis. Personally, I do not like Blatter's attitude, but there you go...



--

Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk

SolderCore Development Platform http://www.soldercore.com













(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

i DON'T THINK YOU CAN GO BACKWARDS. the olympics started out as a
strictly amateur event, but even in its earliest days there were often
under the table payments, and the concept of amateurism varied from
country to country. In England we used to expect our athletes to fund
them selves almost entirely. In my long lost youth I was chosen to train
with the swim team, but my parents simply couldn't afford it. Whereas
the eastern europeans and the Us had massive 'college' programs that
effectively paid and supported their athletes.

Sport has come a long way since then. And technology has crept in at
every level. I have worked in the development of sports performance
monitoring since 1992, when I knew of nobody else in the field using
motion sensors, GPS and the like. Now it is rife in every aspect, so why
not goal line monitoring and instant replay for football? The olympics
does this for most sports, you wouldn't imagine being able to hand start
or hand time a sprint event, let alone judge by eye who broke first,
and, with the millions of dollars involved a mistake can mean a very
expensive lawsuit, so I don't think we really have any option but to
adopt it.

Al

On 14/07/2012 2:57 AM, Hugo Brunert wrote:
> I feel 50%-50% about adding �technology� to ANY sport.
>
> Yes human eyes do make errors, humans make wrong decisions, and humans can be bought too.
>
> So�. Should we add technology to a sport??? It does take away from what IT USED TO BE, but it does correct for HUMAN ERROR. Hence my 50-50 standings. I see both sides benefiting, and not.
>
>
>
> From: m... [mailto:m...] On Behalf Of Paul Curtis
>
> Sent: Friday, July 13, 2012 11:49 AM
>
> To: m...
>
> Subject: RE: [msp430] A couple of question from a new embedded developer
>
>
>
>
>
>> GOOOOOOOoooooooooooooooooooooooooooooooolllllllllllllllllllllllll
>> !!!!!!!!!!!!!!!!!!
>> THAT is reaching your goal!!:)
> I'm sorry--there are always blind referees and assistant referees in football and, hence, your goal will be disallowed, not seen, disputed, whatever.
>
> Of course, the Premier League may now introduce goal line tech, much like Hawkeye has for tennis. Personally, I do not like Blatter's attitude, but there you go...
>
> --
>
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> SolderCore Development Platform http://www.soldercore.com
>
>
>
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I agree with Al in certain points, I strongly disliked the US DREAM TEAM (basketball) made up of Jordan, et al where they were the highest paid athletes in the world, competing with amateurs. Amateurs had no chance.



The olympic committee should have banned the US dream team from it







From: m... [mailto:m...] On Behalf Of Onestone

Sent: Friday, July 13, 2012 1:46 PM

To: m...

Subject: OT:Re: [msp430] A couple of question from a new embedded developer











i DON'T THINK YOU CAN GO BACKWARDS. the olympics started out as a

strictly amateur event, but even in its earliest days there were often

under the table payments, and the concept of amateurism varied from

country to country. In England we used to expect our athletes to fund

them selves almost entirely. In my long lost youth I was chosen to train

with the swim team, but my parents simply couldn't afford it. Whereas

the eastern europeans and the Us had massive 'college' programs that

effectively paid and supported their athletes.



Sport has come a long way since then. And technology has crept in at

every level. I have worked in the development of sports performance

monitoring since 1992, when I knew of nobody else in the field using

motion sensors, GPS and the like. Now it is rife in every aspect, so why

not goal line monitoring and instant replay for football? The olympics

does this for most sports, you wouldn't imagine being able to hand start

or hand time a sprint event, let alone judge by eye who broke first,

and, with the millions of dollars involved a mistake can mean a very

expensive lawsuit, so I don't think we really have any option but to

adopt it.



Al



On 14/07/2012 2:57 AM, Hugo Brunert wrote:

> I feel 50%-50% about adding �technology� to ANY sport.

>

>

>

> Yes human eyes do make errors, humans make wrong decisions, and humans can be bought too.

>

>

>

> So�. Should we add technology to a sport??? It does take away from what IT USED TO BE, but it does correct for HUMAN ERROR. Hence my 50-50 standings. I see both sides benefiting, and not.

>

>

>

>

>

>

>

> From: m... [mailto:ms... ] On Behalf Of Paul Curtis

>

> Sent: Friday, July 13, 2012 11:49 AM

>

> To: m...

>

> Subject: RE: [msp430] A couple of question from a new embedded developer

>

>

>

>

>

>

>

>

>

>

>

>> GOOOOOOOoooooooooooooooooooooooooooooooolllllllllllllllllllllllll

>> !!!!!!!!!!!!!!!!!!

>> THAT is reaching your goal!!:)

>

>

> I'm sorry--there are always blind referees and assistant referees in football and, hence, your goal will be disallowed, not seen, disputed, whatever.

>

>

>

> Of course, the Premier League may now introduce goal line tech, much like Hawkeye has for tennis. Personally, I do not like Blatter's attitude, but there you go...

>

>

>

> --

>

> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk

>

> SolderCore Development Platform http://www.soldercore.com

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>

>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

going a bit off topic
definition of amateur
am·a·teur
   
noun
1. a person who engages in a study, sport, or other activity for pleasure rather than for financial benefit or professional reasons. Compare professional.
2. an athlete who has never competed for payment or for a monetary prize.
3. a person inexperienced or unskilled in a particular activity: Hunting lions is not for amateurs.
4. a person who admires something; devotee; fan: an amateur of the cinema.

Guess the Olympic committee doesn't have a dictionary

Plus when the Athletes do come home with a Gold, they are heavily indorsed to sell their product, even though they themselves don't use them.
As for me, If anyone of importance endorses a product, I tend to stay away, for a number of reasons.

Been watching the Olympics since I was a kid, it was less technical and more practiced skill, and down to earth training

just my 2 cents

--- In m..., Hugo Brunert wrote:
>
> I agree with Al in certain points, I strongly disliked the US DREAM TEAM (basketball) made up of Jordan, et al where they were the highest paid athletes in the world, competing with amateurs. Amateurs had no chance.
>
> The olympic committee should have banned the US dream team from it
>
>
>
> From: m... [mailto:m...] On Behalf Of Onestone
> Sent: Friday, July 13, 2012 1:46 PM
> To: m...
> Subject: OT:Re: [msp430] A couple of question from a new embedded developer
>
>
>
>
>
> i DON'T THINK YOU CAN GO BACKWARDS. the olympics started out as a
> strictly amateur event, but even in its earliest days there were often
> under the table payments, and the concept of amateurism varied from
> country to country. In England we used to expect our athletes to fund
> them selves almost entirely. In my long lost youth I was chosen to train
> with the swim team, but my parents simply couldn't afford it. Whereas
> the eastern europeans and the Us had massive 'college' programs that
> effectively paid and supported their athletes.
>
> Sport has come a long way since then. And technology has crept in at
> every level. I have worked in the development of sports performance
> monitoring since 1992, when I knew of nobody else in the field using
> motion sensors, GPS and the like. Now it is rife in every aspect, so why
> not goal line monitoring and instant replay for football? The olympics
> does this for most sports, you wouldn't imagine being able to hand start
> or hand time a sprint event, let alone judge by eye who broke first,
> and, with the millions of dollars involved a mistake can mean a very
> expensive lawsuit, so I don't think we really have any option but to
> adopt it.
>
> Al
>
> On 14/07/2012 2:57 AM, Hugo Brunert wrote:
> > I feel 50%-50% about adding �technology� to ANY sport.
> >
> >
> >
> > Yes human eyes do make errors, humans make wrong decisions, and humans can be bought too.
> >
> >
> >
> > So�. Should we add technology to a sport??? It does take away from what IT USED TO BE, but it does correct for HUMAN ERROR. Hence my 50-50 standings. I see both sides benefiting, and not.
> >
> >
> >
> >
> >
> >
> >
> > From: m... [mailto:m... ] On Behalf Of Paul Curtis
> >
> > Sent: Friday, July 13, 2012 11:49 AM
> >
> > To: m...
> >
> > Subject: RE: [msp430] A couple of question from a new embedded developer
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> GOOOOOOOoooooooooooooooooooooooooooooooolllllllllllllllllllllllll
> >> !!!!!!!!!!!!!!!!!!
> >> THAT is reaching your goal!!:)
> >
> >
> > I'm sorry--there are always blind referees and assistant referees in football and, hence, your goal will be disallowed, not seen, disputed, whatever.
> >
> >
> >
> > Of course, the Premier League may now introduce goal line tech, much like Hawkeye has for tennis. Personally, I do not like Blatter's attitude, but there you go...
> >
> >
> >
> > --
> >
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> >
> > SolderCore Development Platform http://www.soldercore.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I just think that the Olympics is no place for highly commercialised
professional team sports, such as football, baseball, basketball, and
tiddly winks

Al

On 14/07/2012 5:05 AM, Hugo Brunert wrote:
> I agree with Al in certain points, I strongly disliked the US DREAM TEAM (basketball) made up of Jordan, et al where they were the highest paid athletes in the world, competing with amateurs. Amateurs had no chance.
>
> The olympic committee should have banned the US dream team from it
>
>
>
> From: m... [mailto:m...] On Behalf Of Onestone
>
> Sent: Friday, July 13, 2012 1:46 PM
>
> To: m...
>
> Subject: OT:Re: [msp430] A couple of question from a new embedded developer
>
>
>
>
>
> i DON'T THINK YOU CAN GO BACKWARDS. the olympics started out as a
>
> strictly amateur event, but even in its earliest days there were often
>
> under the table payments, and the concept of amateurism varied from
>
> country to country. In England we used to expect our athletes to fund
>
> them selves almost entirely. In my long lost youth I was chosen to train
>
> with the swim team, but my parents simply couldn't afford it. Whereas
>
> the eastern europeans and the Us had massive 'college' programs that
>
> effectively paid and supported their athletes.
>
> Sport has come a long way since then. And technology has crept in at
>
> every level. I have worked in the development of sports performance
>
> monitoring since 1992, when I knew of nobody else in the field using
>
> motion sensors, GPS and the like. Now it is rife in every aspect, so why
>
> not goal line monitoring and instant replay for football? The olympics
>
> does this for most sports, you wouldn't imagine being able to hand start
>
> or hand time a sprint event, let alone judge by eye who broke first,
>
> and, with the millions of dollars involved a mistake can mean a very
>
> expensive lawsuit, so I don't think we really have any option but to
>
> adopt it.
>
> Al
>
> On 14/07/2012 2:57 AM, Hugo Brunert wrote:
>
>> I feel 50%-50% about adding �technology� to ANY sport.
>> Yes human eyes do make errors, humans make wrong decisions, and humans can be bought too.
>> So�. Should we add technology to a sport??? It does take away from what IT USED TO BE, but it does correct for HUMAN ERROR. Hence my 50-50 standings. I see both sides benefiting, and not.
>> From: m... [mailto:m... ] On Behalf Of Paul Curtis
>> Sent: Friday, July 13, 2012 11:49 AM
>> To: m...
>> Subject: RE: [msp430] A couple of question from a new embedded developer
>>> GOOOOOOOoooooooooooooooooooooooooooooooolllllllllllllllllllllllll
>>> !!!!!!!!!!!!!!!!!!
>>> THAT is reaching your goal!!:)
>> I'm sorry--there are always blind referees and assistant referees in football and, hence, your goal will be disallowed, not seen, disputed, whatever.
>> Of course, the Premier League may now introduce goal line tech, much like Hawkeye has for tennis. Personally, I do not like Blatter's attitude, but there you go...
>> --
>> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>> SolderCore Development Platform http://www.soldercore.com
>>
>>
>>
>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I don't think amateurs are able to compete in the olympics any more, it
is far too expensive. to be competitive they have to train extremely
hard, to the point where holding a job is difficult. They also need a
team of support personnel, like sports scientists, masseurs, physios,
feng shui artists and the like.

They also need to compete against the best, and in most sports this
means international travel, so true amateurism just doesn't seem viable
anymore. that being said many, if not most, world class athletes (in the
broad term of sportsmen and women) don't make the mega bucks that a
fortunate few do. Either their sport is just not commercially
attractive, or they are not communicative, or attractive from a sponsors
perspective. Look at Mark Spitz for example, by far the best swimmer of
his day, but never made much from it until later in life, compare him to
the likes of Thorpe and Phelps.

I don't think the world has many millionaire shot putters, or hammer
throwers, or canadian canoeists, or archers or even long jumpers, yet
they still have to put in the same amount of training as the glamour
events, like the 100mtr, 1500mtr, cycling and swimming. They still need
access to the same high tech medical monitoring, dietary customisation,
and performance monitoring as the higher profile sports to be able to
perform to the expectations of their home audiences. I've never heard
anyone getting excited about their athlete who came 17th, but that was
brilliant because he had to live on mars bars and french fries and
trained in his garage.

The Olympic games is worth millions of dollars, the global audience is
billions and their expectations are that they will see new records,
amazing performances and be thrilled by the whole spectacle. That is why
the nations that do best are those that have formalised across the board
support for their elite, and up and coming athletes. Australia, for
example, performs out of all proportion to its small population, because
for many years we have had state, local and national institutes of sport
that provide the necessary support.

In this era, being a world class sportsperson is a career like any
other, but I still feel that sports in the Olympic games should reflect
a more global participation. Personally I could take no pride in winning
a gold medal if i were a member of the US basketball team, or baseball
team, or a national football team (except England of course, who would
be gobsmacked to win anything).

Al
On 14/07/2012 5:25 AM, spacejuggernaut wrote:
> going a bit off topic
> definition of amateur
> am·a·teur
>    
> noun
> 1. a person who engages in a study, sport, or other activity for pleasure rather than for financial benefit or professional reasons. Compare professional.
> 2. an athlete who has never competed for payment or for a monetary prize.
> 3. a person inexperienced or unskilled in a particular activity: Hunting lions is not for amateurs.
> 4. a person who admires something; devotee; fan: an amateur of the cinema.
>
> Guess the Olympic committee doesn't have a dictionary
>
> Plus when the Athletes do come home with a Gold, they are heavily indorsed to sell their product, even though they themselves don't use them.
> As for me, If anyone of importance endorses a product, I tend to stay away, for a number of reasons.
>
> Been watching the Olympics since I was a kid, it was less technical and more practiced skill, and down to earth training
>
> just my 2 cents
>
> --- In m..., Hugo Brunert wrote:
>> I agree with Al in certain points, I strongly disliked the US DREAM TEAM (basketball) made up of Jordan, et al where they were the highest paid athletes in the world, competing with amateurs. Amateurs had no chance.
>>
>> The olympic committee should have banned the US dream team from it
>>
>>
>>
>> From: m... [mailto:m...] On Behalf Of Onestone
>> Sent: Friday, July 13, 2012 1:46 PM
>> To: m...
>> Subject: OT:Re: [msp430] A couple of question from a new embedded developer
>>
>>
>>
>>
>>
>> i DON'T THINK YOU CAN GO BACKWARDS. the olympics started out as a
>> strictly amateur event, but even in its earliest days there were often
>> under the table payments, and the concept of amateurism varied from
>> country to country. In England we used to expect our athletes to fund
>> them selves almost entirely. In my long lost youth I was chosen to train
>> with the swim team, but my parents simply couldn't afford it. Whereas
>> the eastern europeans and the Us had massive 'college' programs that
>> effectively paid and supported their athletes.
>>
>> Sport has come a long way since then. And technology has crept in at
>> every level. I have worked in the development of sports performance
>> monitoring since 1992, when I knew of nobody else in the field using
>> motion sensors, GPS and the like. Now it is rife in every aspect, so why
>> not goal line monitoring and instant replay for football? The olympics
>> does this for most sports, you wouldn't imagine being able to hand start
>> or hand time a sprint event, let alone judge by eye who broke first,
>> and, with the millions of dollars involved a mistake can mean a very
>> expensive lawsuit, so I don't think we really have any option but to
>> adopt it.
>>
>> Al
>>
>> On 14/07/2012 2:57 AM, Hugo Brunert wrote:
>>> I feel 50%-50% about adding �technology� to ANY sport.
>>>
>>>
>>>
>>> Yes human eyes do make errors, humans make wrong decisions, and humans can be bought too.
>>>
>>>
>>>
>>> So�. Should we add technology to a sport??? It does take away from what IT USED TO BE, but it does correct for HUMAN ERROR. Hence my 50-50 standings. I see both sides benefiting, and not.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: m... [mailto:m... ] On Behalf Of Paul Curtis
>>>
>>> Sent: Friday, July 13, 2012 11:49 AM
>>>
>>> To: m...
>>>
>>> Subject: RE: [msp430] A couple of question from a new embedded developer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> GOOOOOOOoooooooooooooooooooooooooooooooolllllllllllllllllllllllll
>>>> !!!!!!!!!!!!!!!!!!
>>>> THAT is reaching your goal!!:)
>>>
>>> I'm sorry--there are always blind referees and assistant referees in football and, hence, your goal will be disallowed, not seen, disputed, whatever.
>>>
>>>
>>>
>>> Of course, the Premier League may now introduce goal line tech, much like Hawkeye has for tennis. Personally, I do not like Blatter's attitude, but there you go...
>>>
>>>
>>>
>>> --
>>>
>>> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>>>
>>> SolderCore Development Platform http://www.soldercore.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

johnevanbaxter wrote:
> Is there an industry standard style guide that I should be following
> when coding in C for embedded applications or should I just make up
> my own and stick with it. I don't want to start any flame wars about
> which style is better than which, but if there is one that is
> generally accepted as a de facto standard I would like to get in the
> habit of using it.
>
> Also, I'm finding it difficult to avoid using global variables in C.
> I've often heard that they should be avoided, but the only way I can
> think to avoid them is to make getters and setters. But then don't
> the getter and setter functions have to be global scope -- how is
> that better than just using globals to begin with?
>
> Thanks for helping out a newbie.
>

Just a word from a non-programmer but someone who has to regulary find
bugs in HW and SW, and has to guide systems through agency approvals: No
matter what you decide to do: Document, document, document.

When I start to work the first thing that happens is that a Word
document gets opened. There, the required specs and all this are
entered, then my ideas, then the reasons for design strategies, and then
the design starts. Not the other way around. While designing, this
document starts to grow immediately.

All too often have I tried to obtain SW or uC code documentation and was
given ... the source code. "But there's comments in there". Then I sent
off a list of detailed questions ... "Oh, Leroy programmed this. He'd
know but he's on vacation right now".

--
Regards, Joerg

http://www.analogconsultants.com/





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

That bloody Leroy, he stuffs everything up and the buggers always on
holiday!

Al

On 15/07/2012 12:30 AM, Joerg wrote:
> johnevanbaxter wrote:
>> Is there an industry standard style guide that I should be following
>> when coding in C for embedded applications or should I just make up
>> my own and stick with it. I don't want to start any flame wars about
>> which style is better than which, but if there is one that is
>> generally accepted as a de facto standard I would like to get in the
>> habit of using it.
>>
>> Also, I'm finding it difficult to avoid using global variables in C.
>> I've often heard that they should be avoided, but the only way I can
>> think to avoid them is to make getters and setters. But then don't
>> the getter and setter functions have to be global scope -- how is
>> that better than just using globals to begin with?
>>
>> Thanks for helping out a newbie.
>>
> Just a word from a non-programmer but someone who has to regulary find
> bugs in HW and SW, and has to guide systems through agency approvals: No
> matter what you decide to do: Document, document, document.
>
> When I start to work the first thing that happens is that a Word
> document gets opened. There, the required specs and all this are
> entered, then my ideas, then the reasons for design strategies, and then
> the design starts. Not the other way around. While designing, this
> document starts to grow immediately.
>
> All too often have I tried to obtain SW or uC code documentation and was
> given ... the source code. "But there's comments in there". Then I sent
> off a list of detailed questions ... "Oh, Leroy programmed this. He'd
> know but he's on vacation right now".
>





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Sat, 14 Jul 2012 08:00:40 -0700, Jörg wrote:

>Just a word from a non-programmer but someone who has to regulary find
>bugs in HW and SW, and has to guide systems through agency approvals: No
>matter what you decide to do: Document, document, document.
>
>When I start to work the first thing that happens is that a Word
>document gets opened. There, the required specs and all this are
>entered, then my ideas, then the reasons for design strategies, and then
>the design starts. Not the other way around. While designing, this
>document starts to grow immediately.
>
>All too often have I tried to obtain SW or uC code documentation and was
>given ... the source code. "But there's comments in there". Then I sent
>off a list of detailed questions ... "Oh, Leroy programmed this. He'd
>know but he's on vacation right now".

What a great way to raise the level of the discussion, Jörg!
Niggling about code standards is almost nothing by comparison
to this good advice. I keep an engineering notebook that is
written into sequentially and includes what didn't work, as
well as what did (or I perceived at the time that it did.) I
can see the dead ends, wasted time, etc., all nicely laid
out. Kind of humbling. But when a good idea works out the
evolution of it is there, too. Separately, I keep an editable
specification where the actual, cleaned up design is entered,
modified, updated, etc. Plus any of the dead ends I think are
important to document as to why they were not taken.

I also thoroughly test critical algorithms and document the
results. For example, if I write a specialized, high speed
logarithm routine I will test every possible input and verify
every single possible output from it, check it for
monotonicity as well as accuracy, and record the results as
evidence of additional work effort and possibly where not to
waste time when tracking down possible errors in the future.

Anyway, what you added is very important.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On 07/14/2012 02:56 PM, Jon Kirwan wrote:
>
>
> On Sat, 14 Jul 2012 08:00:40 -0700, Jörg wrote:
>
>>Just a word from a non-programmer but someone who has to regulary find
>>bugs in HW and SW, and has to guide systems through agency approvals: No
>>matter what you decide to do: Document, document, document.

> What a great way to raise the level of the discussion, Jörg!
> Niggling about code standards is almost nothing by comparison
> to this good advice. I keep an engineering notebook that is
> written into sequentially and includes what didn't work, as
> well as what did (or I perceived at the time that it did.) I
> can see the dead ends, wasted time, etc., all nicely laid
> out.

I'd extend this a bit further. I fully agree with the documentation issue.
What I'd like to add is that adding a bit of color, pictures and use of
different fonts, indentation and boxes, can not only make the document
easier to read but easier to find more information quickly.

One of the issues I have with modern computers is that we don't make
them as easy to use as a note book. I solve this by scanning in my
notes from books (copier) and white boards (camera).

>>All too often have I tried to obtain SW or uC code documentation and was
>>given ... the source code. "But there's comments in there". Then I sent
>>off a list of detailed questions ... "Oh, Leroy programmed this. He'd
>>know but he's on vacation right now".

Or even worse, you could become especially good at reverse engineering
and then people start to dump stuff on you to decipher because you are
particularly good at it (as I am - Curse you Leroy du LaVacation).

> I also thoroughly test critical algorithms and document the
> results. For example, if I write a specialized, high speed
> logarithm routine I will test every possible input and verify
> every single possible output from it, check it for
> monotonicity as well as accuracy, and record the results as
> evidence of additional work effort and possibly where not to
> waste time when tracking down possible errors in the future.

My day job is as a systems tester. Every test I do I needs evidence
of that test (Pictures, screen captures, photos, whatever) and
comments. I take my scripts, data and result and tar & compress them
into a file that I include in my documentation. I then back them up
to another medium (2nd hard disk or DVD). We have online storage but
it tends to be good for about 6 months before it's inaccessible.

--
Linux Home Automation Neil Cherry n...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

John,

read Jack Ganssle, he is writing much about good embedded coding and more.
E.g. search google with "coding style ganssle".

For global variables: I think you should distinguish between global and
static variables. Static variables are needed - just to keep track the state
of your process or the system clock or whatever - it is often not possible to
live without them. However you should keep this static variables in the
module you declare them (in plain C this is just the C-file) and avoid to
access them from outside. Use several C-files (modules) for you components
(e.g. one for the keyboard, one for the display). Avoid global variables
means encapsulate your code!
However for plain C module-static and global variables are just the same. It
is in your responsibility - you get no help from the compiler - not to access
them. C++ is much better here.
However there are much more issues for good code. Jack's Word-file is also
just a small part of it, some of my extensions would include:
- think about your algorithm, how to implement it
- write this down as comments (lines)
- fill the code inbetween the comments
after finishing a project step:
- look for similar code and collect this code together in one function
... and much more, it is a philosophy, you can talk weeks about this. :-)

M.

"johnevanbaxter" :

> Is there an industry standard style guide that I should be following
> when coding in C for embedded applications or should I just make up my
> own and stick with it. I don't want to start any flame wars about which
> style is better than which, but if there is one that is generally
> accepted as a de facto standard I would like to get in the habit of
> using it.
>
> Also, I'm finding it difficult to avoid using global variables in C.
> I've often heard that they should be avoided, but the only way I can
> think to avoid them is to make getters and setters. But then don't the
> getter and setter functions have to be global scope -- how is that
> better than just using globals to begin with?
>
> Thanks for helping out a newbie.
>
> John





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m..., Neil Cherry wrote:
>
> On 07/14/2012 02:56 PM, Jon Kirwan wrote:
> >
> >
> > On Sat, 14 Jul 2012 08:00:40 -0700, Jörg wrote:
> >
> >>Just a word from a non-programmer but someone who has to regulary find
> >>bugs in HW and SW, and has to guide systems through agency approvals: No
> >>matter what you decide to do: Document, document, document.
>
> > What a great way to raise the level of the discussion, Jörg!
> > Niggling about code standards is almost nothing by comparison
> > to this good advice. I keep an engineering notebook that is
> > written into sequentially and includes what didn't work, as
> > well as what did (or I perceived at the time that it did.) I
> > can see the dead ends, wasted time, etc., all nicely laid
> > out.
>
> I'd extend this a bit further. I fully agree with the documentation issue.
> What I'd like to add is that adding a bit of color, pictures and use of
> different fonts, indentation and boxes, can not only make the document
> easier to read but easier to find more information quickly.
>
> One of the issues I have with modern computers is that we don't make
> them as easy to use as a note book. I solve this by scanning in my
> notes from books (copier) and white boards (camera).
>
> >>All too often have I tried to obtain SW or uC code documentation and was
> >>given ... the source code. "But there's comments in there". Then I sent
> >>off a list of detailed questions ... "Oh, Leroy programmed this. He'd
> >>know but he's on vacation right now".
>
> Or even worse, you could become especially good at reverse engineering
> and then people start to dump stuff on you to decipher because you are
> particularly good at it (as I am - Curse you Leroy du LaVacation).
>
> > I also thoroughly test critical algorithms and document the
> > results. For example, if I write a specialized, high speed
> > logarithm routine I will test every possible input and verify
> > every single possible output from it, check it for
> > monotonicity as well as accuracy, and record the results as
> > evidence of additional work effort and possibly where not to
> > waste time when tracking down possible errors in the future.
>
> My day job is as a systems tester. Every test I do I needs evidence
> of that test (Pictures, screen captures, photos, whatever) and
> comments. I take my scripts, data and result and tar & compress them
> into a file that I include in my documentation. I then back them up
> to another medium (2nd hard disk or DVD). We have online storage but
> it tends to be good for about 6 months before it's inaccessible.
>
> --
> Linux Home Automation Neil Cherry ncherry@...
> http://www.linuxha.com/ Main site
> http://linuxha.blogspot.com/ My HA Blog
> Author of: Linux Smart Homes For Dummies
>
>>>My advice here is put it in the notebook as if you are sending it to someone and update it weekly with dates (as if for pseudo-transmission).<<< Neil points out a powerful method of documentation not often found in most hoity toity programming books, grab everything and put it in a notebook....neatly and professionally if possible, as if you were actually documenting intellectual property :-) Frequently I end up with five or ten pages of code that represents perhaps a Boolean state chart with maybe 2^8 or 2^9 states scribbled out neatly on yellow notebook paper. "Here is an image of the switch protection mechanism for input 5.3", "the output was set as negative so that power failure wouldn't damage the robot", " big-endian transmission conforms to Company Standard C5.9" Seems tedious but it only takes a few minutes at the end of each week, and come back a year later and try to figure out what happened on November 12th that delayed shipment or why state 139 causes a reboot of some obscure script parsing algorithm. Plus, think of the fun when you fax that 100 pages a week to that evil genius trying to vacation/hide down in Cancun, tehe, what fun :-) In truth I discovered the value of the method in college while doing doctoral research for my major professor who was on sabbatical. It really does rock! And it gives great perspective on wasted time and bottlenecks in need of a good whack!! 40 years later I can give you a day by day, blow by blow description of that diode programmed events driven computer I wire wrapped in back in 1977 (Sadly not a big seller at Best Buy) or the bar chart reader I built in the mid 80's. Note to self: Digital polaroid camera for notebook documentation.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I resent that. I do document - in the code where it won't get lost

LeRoy Baxter
Baxter Codeworks

--- In m..., Onestone wrote:
>
> That bloody Leroy, he stuffs everything up and the buggers always on
> holiday!
>
> Al
>
> On 15/07/2012 12:30 AM, Joerg wrote:
> > johnevanbaxter wrote:
> >> Is there an industry standard style guide that I should be following
> >> when coding in C for embedded applications or should I just make up
> >> my own and stick with it.

> >
> > All too often have I tried to obtain SW or uC code documentation and was
> > given ... the source code. "But there's comments in there". Then I sent
> > off a list of detailed questions ... "Oh, Leroy programmed this. He'd
> > know but he's on vacation right now".
>





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )