using BREAK in 'C'

[Peter Restall]

On Mon, 29 Jun 2009 15:41:16 +0100 (BST), sergio masci wrote:

> Actually if you really want to see some F.*D UP S.*T - try this:
>
>         switch (x)
>         {
>         case 1:
>                
>                 if (x == a)
>                 {
>                         x++;
>                 }  
>                 else
>                 {
>         case 2:
>                         x = 0;
>                 }
>         }

Wow, that's fantastic !  It certainly does compile under GCC - without any
warning or anything too :)  To be honest, I've never felt the urge to try
and get away with such crazy antics - that could easily have been a copy-and-
paste error.  It hurts readability and introduces bugs.  Speaking of which,
is there still an annual obfuscated C contest - do they still do that ?  I
think it may eventually have been outdone by the obfuscated Perl contest...:)

Regards,

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

[Peter Restall]

On Mon, 29 Jun 2009 15:11:41 +0100, Tamas Rudnai wrote:

> I think many people does not like C (well, those who knows Pascal). But
> nowadays you "have to" use C as you have everything in C, like Microchip's
> libraries, but here we can talk about Bytecraft, HiTech, CCS or FED. The
> route is quite long and steep till you reach the point what Olin has now --
> his own libraries and macros and compiler infractructure. Most comanies
> choose the "easier way" using an existing package which is mostly in C, so
> you "have to" use C.

I personally like C; it was Pascal I couldn't get away with.  I don't get to
use C much in my line of work though; it's all C# now (used to be VB...gah !)
I get the occasional C or C++ or assembler jobbie, but that's few and far
between - business systems tend to be higher level; C is mainly reserved for
the stuff I write for myself, presuming there isn't a scripting language
better suited to the task at hand.

Regards,

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

[Gerhard Fiedler]

Luis Moreira wrote:

> You are right, this is probably what I need.
>
> I never realised how difficult it was to get a relationship diagram
> in C that gives you all the information about the function
> interaction. But maybe is the way I am writing my programs.
>
> I started out by having a separate file for each function that I
> deemed it was large enough or had some possibility of reuse, but then
> it seem to make more sense to have library C file that had all the
> functions in it. Like this I just include one file and all the
> functions are there. At this point it doesn't seem like a good idea
> anymore.

In C, you typically create files in pairs (.c and .h, with same file
name). The .h file is called a "header" file, the .c file is called a
"source" file. The .h file contains the declarations that other files
need to see in order to use the contents of the .c file. The .h file is
included in the .c file, to make sure that the declarations in the .h
file match the definitions in the .c file.

How to decide how to group your code into different files is not a very
clear thing. It is affected by a number of considerations, some of which
are conflicting.

If you use a librarian, it can decide whether or not to link something
in, but only in chunks of whole files. That is, you translate your .c
files into relocatable object files (typically .o or .obj), then bind
these into libraries (typically .lib). When linking a new project, you
bind in your library, and the librarian decides which object files are
needed. This is not that important in our small micro world, but it
shows that you only can link in code based on files; that's the smallest
unit for linking. (You can see how this may be done by looking at the
standard library sources of your compiler, and check out how they
grouped things into source files. This is done mostly following this
consideration.) If you need one function in a file that has 15, the
linker will link in all. Some linkers are smart enough to later optimize
out functions that are never called, but this is only possible if the
compiler doesn't allow function pointers (or maybe if you don't use them
even though they are allowed).

Another consideration is that some compiler optimizations only work on
the file level. It's this consideration that created the "one source
file" style. Basically, you have everything in one big .c file. You
still can create a certain modularity, by using the include directive to
include different source files (not only header files). Every .c file
"sees" all the innards of every other .c file (it's a bit more complex,
but that's the basic idea), but also the compiler "sees" all the code
when compiling and can optimize it better. (Hi-Tech's PRO compilers have
a feature where the compiler looks at the whole code, not only at a
single translation unit, when compiling. The objective is to make the
compiler work with traditional, separate translation units as if it were
translating such a single-source project.)

Other than that, the "normal" thing to do is to group related
functionality together in a file. The objective is what Vitaliy calls
"tight cohesion and loose coupling": you pack stuff together that needs
to see each others' details, and together present an API (as declared in
the header file) that is as compact and loosely coupled as possible.

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

[Herbert Graf-5]

On Mon, 2009-06-29 at 10:40 -0400, Olin Lathrop wrote:

> David Harris wrote:
> > Times were very different when K&R were constructing a programming
> > language and operating system from scratch.  If one doesn't like C,
> > then don't use it.
>
> And I don't when I can help it.  Of course that is orthogonal the argument
> that C is a very badly designed language.
>
> Times were different when Algol and Pascal were invented too, so that's no
> excuse.

Any discussion on "what language is best" quickly devolves into a almost
religious argument, so to all, please stop this part of the discussion
here.

Thanks, TTYL

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

[Herbert Graf-5]

On Wed, 2009-07-01 at 10:23 -0400, Herbert Graf wrote:

> On Mon, 2009-06-29 at 10:40 -0400, Olin Lathrop wrote:
> > David Harris wrote:
> > > Times were very different when K&R were constructing a programming
> > > language and operating system from scratch.  If one doesn't like C,
> > > then don't use it.
> >
> > And I don't when I can help it.  Of course that is orthogonal the argument
> > that C is a very badly designed language.
> >
> > Times were different when Algol and Pascal were invented too, so that's no
> > excuse.
>
> Any discussion on "what language is best" quickly devolves into a almost
> religious argument, so to all, please stop this part of the discussion
> here.
>
> Thanks, TTYL

Dammit, see what happens when you're on vacation, you forget what day it
is, I could have sworn it was Monday.

So, my statement above still stands, albeit 2 whole days late, grr... :)

TTYL

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

[Vitaliy-14]

Luis Moreira wrote:
> You are right, this is probably what I need.
> I never realised how difficult it was to get a relationship diagram in C
> that gives you all the information about the function interaction. But
> maybe is the way I am writing my programs.
> I started out by having a separate file for each function that I deemed
> it was large enough or had some possibility of reuse, but then it seem
> to make more sense to have library C file that had all the functions in
> it. Like this I just include one file and all the functions are there.
> At this point it doesn't seem like a good idea anymore.

Luis, I think it's great that you recognize that there is a problem and that
you are looking for a better way.

I think that any serious procedural programmer sooner or later gets to a
point where his program get so complex that it's impossible to grasp in its
entirety. The natural reaction is to try to rein in this complexity with
documentation in the form of flowcharts, interface specifications, and
comments inside the code. I know because I've been there. It is frustrating.

About a year and a half ago, I got really tired of using the brute force
method of learning from my mistakes, and started researching better ways of
writing and managing code.  I read books on OOP, design patterns and
refactoring, came across a great article on the internet written by someone
who explained how to use C++ concepts in plain C, and bounced ideas off the
PICList. If you were bored enough, you could follow my posts starting around
that time, and see how the method gradually took shape.

My biggest realization was that in order to effectively manage complexity,
one has to start thinking in terms of objects. An object is "something with
responsibilities". It takes some practice, but eventually the answer to the
question "where do I put this function?" becomes self-evident. Perhaps even
more important, this works in reverse as well: you know which object a
function resides in.

Thinking in objects has other positive side effects, for instance you get
code that is more cohesive and loosely coupled, which in turn makes it
reusable. If you want to give it a shot, I can describe the specifics in
more detail.

You don't have to spend a lot of time to change over to this system, either.
You can do it in small steps, refactoring your existing code little by
little. So the risk is minimal, and the benefits are great.

Vitaliy


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

[Luis Moreira-2]

Hi Vitaliy,
The OOP approach was the one I took in the beginning, but as I tried to
make may program more and more universal, similar to a class, it started
not working very well. The main problems were how to deal with the
interrupt routines and the order of the include files. As some of my
"class like functions" had links with the interrupt routines, they
seemed not to make sense on there own, also the order of the include
files on the main "class" was not always the same depending how the
program was used.
On this particular program I am using the USART to transmit and receive
a packet of information, I have several functions that dealt with packet
reception, packet processing once received, packet validation and
checksum calculation. I also have similar functions for packet
transmission. The intension was to use this program as an ancillary
program to transmit/receive data from another device like a PC, whenever
I need that facility. So when I need communications I just include the
packet transmission functions and on the main program pass it or get the
data I need to transmit or receive. In OOP this structure is trivial but
in C it is difficult to make it that simple.
I will be interested to look at your method.
Thanks.
Best Regards
                Luis      


-----Original Message-----
From: piclist-bounces@... [mailto:piclist-bounces@...] On Behalf
Of Vitaliy
Sent: 02 July 2009 06:37
To: Microcontroller discussion list - Public.
Subject: Re: [EE] C programs representation

Luis Moreira wrote:
> You are right, this is probably what I need.
> I never realised how difficult it was to get a relationship diagram in
C
> that gives you all the information about the function interaction. But
> maybe is the way I am writing my programs.
> I started out by having a separate file for each function that I
deemed
> it was large enough or had some possibility of reuse, but then it seem
> to make more sense to have library C file that had all the functions
in
> it. Like this I just include one file and all the functions are there.
> At this point it doesn't seem like a good idea anymore.

Luis, I think it's great that you recognize that there is a problem and
that
you are looking for a better way.

I think that any serious procedural programmer sooner or later gets to a

point where his program get so complex that it's impossible to grasp in
its
entirety. The natural reaction is to try to rein in this complexity with

documentation in the form of flowcharts, interface specifications, and
comments inside the code. I know because I've been there. It is
frustrating.

About a year and a half ago, I got really tired of using the brute force

method of learning from my mistakes, and started researching better ways
of
writing and managing code.  I read books on OOP, design patterns and
refactoring, came across a great article on the internet written by
someone
who explained how to use C++ concepts in plain C, and bounced ideas off
the
PICList. If you were bored enough, you could follow my posts starting
around
that time, and see how the method gradually took shape.

My biggest realization was that in order to effectively manage
complexity,
one has to start thinking in terms of objects. An object is "something
with
responsibilities". It takes some practice, but eventually the answer to
the
question "where do I put this function?" becomes self-evident. Perhaps
even
more important, this works in reverse as well: you know which object a
function resides in.

Thinking in objects has other positive side effects, for instance you
get
code that is more cohesive and loosely coupled, which in turn makes it
reusable. If you want to give it a shot, I can describe the specifics in

more detail.

You don't have to spend a lot of time to change over to this system,
either.
You can do it in small steps, refactoring your existing code little by
little. So the risk is minimal, and the benefits are great.

Vitaliy


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

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

[Terry Harris]

On Wed, 1 Jul 2009 22:37:04 -0700, you wrote:

>My biggest realization was that in order to effectively manage complexity,
>one has to start thinking in terms of objects.

Good lord, an embedded engineer who looked at OOP and actually got it
instead of whining about things going on under the hood and how you can't
possibly trust anything which you can't see.

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

[Luis Moreira-2]

Terry,
You know what you just done, you just opened the floodgates for a lot of
flaming :) enjoy.

Best Regards
                Luis


-----Original Message-----
From: piclist-bounces@... [mailto:piclist-bounces@...] On Behalf
Of Terry Harris
Sent: 02 July 2009 13:22
To: Microcontroller discussion list - Public.
Subject: Re: [EE] C programs representation

On Wed, 1 Jul 2009 22:37:04 -0700, you wrote:

>My biggest realization was that in order to effectively manage
complexity,
>one has to start thinking in terms of objects.

Good lord, an embedded engineer who looked at OOP and actually got it
instead of whining about things going on under the hood and how you
can't
possibly trust anything which you can't see.

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

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

[John Gardner-3]

Vitaliy -

Do you happen to have the url of the article you mentioned?
Sounds like food for thought...

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

[Rikard Bosnjakovic-2]

On Thu, Jul 2, 2009 at 17:37, John Gardner<goflo3@...> wrote:

> Do you happen to have the url of the article you mentioned?
> Sounds like food for thought...

Could it be these two, posted by Xiaofan 2008-06-02?

http://www.embedded.com/97/fe29712.htm
http://www.ddj.com/cpp/184406396


--
- Rikard - http://bos.hack.org/cv/
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Luis Moreira-2]

Hi Vitaliy,
I have been looking at the OOP using C for a few days now, and I can
sort of understand the mechanism, but it looks to me that you probably
generate a bigger code overhead. Do you actually use it? Even for PIC
projects?
Best Regards
                Luis



-----Original Message-----
From: piclist-bounces@... [mailto:piclist-bounces@...] On Behalf
Of Vitaliy
Sent: 02 July 2009 06:37
To: Microcontroller discussion list - Public.
Subject: Re: [EE] C programs representation

Luis Moreira wrote:
> You are right, this is probably what I need.
> I never realised how difficult it was to get a relationship diagram in
C
> that gives you all the information about the function interaction. But
> maybe is the way I am writing my programs.
> I started out by having a separate file for each function that I
deemed
> it was large enough or had some possibility of reuse, but then it seem
> to make more sense to have library C file that had all the functions
in
> it. Like this I just include one file and all the functions are there.
> At this point it doesn't seem like a good idea anymore.

Luis, I think it's great that you recognize that there is a problem and
that
you are looking for a better way.

I think that any serious procedural programmer sooner or later gets to a

point where his program get so complex that it's impossible to grasp in
its
entirety. The natural reaction is to try to rein in this complexity with

documentation in the form of flowcharts, interface specifications, and
comments inside the code. I know because I've been there. It is
frustrating.

About a year and a half ago, I got really tired of using the brute force

method of learning from my mistakes, and started researching better ways
of
writing and managing code.  I read books on OOP, design patterns and
refactoring, came across a great article on the internet written by
someone
who explained how to use C++ concepts in plain C, and bounced ideas off
the
PICList. If you were bored enough, you could follow my posts starting
around
that time, and see how the method gradually took shape.

My biggest realization was that in order to effectively manage
complexity,
one has to start thinking in terms of objects. An object is "something
with
responsibilities". It takes some practice, but eventually the answer to
the
question "where do I put this function?" becomes self-evident. Perhaps
even
more important, this works in reverse as well: you know which object a
function resides in.

Thinking in objects has other positive side effects, for instance you
get
code that is more cohesive and loosely coupled, which in turn makes it
reusable. If you want to give it a shot, I can describe the specifics in

more detail.

You don't have to spend a lot of time to change over to this system,
either.
You can do it in small steps, refactoring your existing code little by
little. So the risk is minimal, and the benefits are great.

Vitaliy


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

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

[Vitaliy-14]

Rikard Bosnjakovic wrote:
>> Do you happen to have the url of the article you mentioned?
>> Sounds like food for thought...
>
> Could it be these two, posted by Xiaofan 2008-06-02?
>
> http://www.embedded.com/97/fe29712.htm
> http://www.ddj.com/cpp/184406396

Yes, these are the ones. However, like I said, we aren't using inheritance,
and every "object" does not necessarily have a Create() or Destroy(), only
the ones that are created dynamically at runtime, and they work differently
from the way you would expect them to work in C++: you can still call the
"methods", even after the object is destroyed.

Vitaliy

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

[Vitaliy-14]

Luis Moreira wrote:
> The OOP approach was the one I took in the beginning, but as I tried to
> make may program more and more universal, similar to a class, it started
> not working very well. The main problems were how to deal with the
> interrupt routines and the order of the include files. As some of my
> "class like functions" had links with the interrupt routines, they
> seemed not to make sense on there own, also the order of the include
> files on the main "class" was not always the same depending how the
> program was used.

This is kind of strange, I don't understand why the order of the include
files would be affected depending on how you use the program. If you design
your objects to be loosely coupled, the order of the includes should never
change.

Can you provide any more information about this?

> On this particular program I am using the USART to transmit and receive
> a packet of information, I have several functions that dealt with packet
> reception, packet processing once received, packet validation and
> checksum calculation. I also have similar functions for packet
> transmission. The intension was to use this program as an ancillary
> program to transmit/receive data from another device like a PC, whenever
> I need that facility. So when I need communications I just include the
> packet transmission functions and on the main program pass it or get the
> data I need to transmit or receive. In OOP this structure is trivial but
> in C it is difficult to make it that simple.
> I will be interested to look at your method.

Put your interrupt routines in your Uart object, either the main Uart.c, or
a helper object -- UartInterrupts.c. Make sure the interrupt's only job is
to grab the bytes out of the FIFO, and put them in a buffer.

Based on your description, this is my stab at how the code should be
organized:

===
main()
    PacketHandler_SendPacket(txPacket)
        txPacket.checksum = PacketHandler_CalculateChecksum(txPacket);
        Uart_SendByte()    // run this in a loop, until the entire packet is
sent

    rxPacket = PacketHandler_GetPacket()
        Uart_GetByte()    // run this in a loop, until you get the entire
packet

    if ( PacketHandler_IsPacketValid(rxPacket) )
        CmdHandler_ProcessPacket(rxPacket);
===

txPacket, rxPacket can be of type TPacket that has members data, dataLen,
and checksum.

CmdHandler should have a more descriptive name that describes its purpose.
For instance, if you have a device that is used to control the sprinklers,
you could call it SprinklerCmdHandler.

The objects that we created so far, proved to be easily portable (literally,
no changes required to the object code itself  -- drop it in, and it just
works). The key was to isolate the stuff that changes b/w projects, into
project-specific files: IoDefs.h, ProjectConfig.h, and Initializer.c.


We actually go a step further, the main() function has only a few lines of
code (usually, three). In the sprinkler example, they would be:

int main()
{
  Initializer_InitializeAll();

  SprinklerController_Run();

  return 0;
}

Now, even the SprinklerController itself is portable/reusable. Or, you could
provide a way to exit out of the SprinklerController, and put it inside an
infinite loop that runs a simple task switcher. So you could now have it
share the chip with GarageDoorOpener and OutsideLightsController
(cooperative multitasking! :)

Vitaliy

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