Small Device C Compiler suite

Your logic for requesting this is flawed.  It has been my experance that each IIC implementation for a new project is diffrent.  For instance On one project I had to implement two diffrent IIC modules to talk on two seperate port pins.  On another project I had to share IIC and SPI on the same port pins because the hardware guys stuffed up and did on supply IIC to a seperate PCB that required it.  On other implamantations I've had to use IIC hardware.  Every project I've done has required a slight modification to the driver in some way.

You also say that you are cutting and pasting you IIC code into each diffrent project.  I would suggest that if you are doing this then you figure out how to use makefiles is you can save yourself a lot of work by creating a seperate .C file for each module in your code and just linking it in when you need it.
I have used Borland make when I was using windows as a development platform but I've moved on since then.  I also have been using GNU make with SDCC I could provide example file of both if anybody is interested.

Using the seperate .C file approach then you and create a speperate .H file for project wide configurations like which pins your IIC is connect to, what baud rate your project is going to use and what speed the timmer runs at.

Makefiles are your friends you should get to know them well.  It makes compiling a project of any size easy it would also cut down on globals except of #defines which can only increase teh quality of the code you are writting.

Regards,
Rod Boyce.

On Sat, 25 Jan 2003 14:16:01 +0530
"Royce & Sharal Pereira" <bethell@...> wrote:

> 
> 
> > > data at 8 char valu0;
> > > bit at 0x20 flg_one;
> > >
> > > both refer to absolutely placed variables.
> > > In the asm file, I get
> > >
> > > .global  _valu0
> > > .....
> > > _valu0 = 0x08         ------------> this is ok!
> > >
> > > but in case of my bit variable, I get:
> > >
> > > _flg_one = 0x20        ------------> Why no global for bits?
> > >
> Maybe I did confuse the terms declaration & definition , but I beg you to
> look at the spirit of my query.
> All I need is a ".global  _flg_one"  & ".global _SDA" etc. in the .asm file.
> Is this such a problem?
> Why this discrimination towards bit variables whose addresses are declared
> explicitly? Why are similarly declared byte variables only (like valu0
> above) given the luxury of being global?
> 
> Don't you agree that it would be really simple for an outside(like a
> library) module to use these bits if they were global? Of course I would
> declare them as extern bits in the lib module. The problem is that the
> assignment of port lines for _SDA & _SCL etc. change with every project.
> using "#define  _SDA  P3_6" does not make _SDA global, so my lib module
> (if it uses a bit defined in "main.c" )becomes useless.
> 
> >Same procedure as last year?
> >http://www.geocrawler.com/archives/3/3278/2002/4/50/8337589/
> 
> Yes, I did post a similar mail when I tried to create a lib file for a ser.
> ADC.
> Unfortunately the attempt failed for the above reason & I have had to
> cut-paste my adc code in every project since then, when I could have just
> linked my ADC code to my new projects.
> 
> I did think that 2.3.3 would correct this, so I tried to link a recent iic
> module,
> but found the same situation. Thats the reason for raking up the issue
> again.
> 
> Again I humbly ask, is there a real issue in fixing a declaration in the
> .asm to make these bit variables global?
> 
> Thanks,
> --Royce.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Hi,
----- Original Message -----
> Your logic for requesting this is flawed.  It has been my experance that
each IIC implementation for a new project is diffrent.  For instance On one
---------------------------------------------------------------
Let me simplify things a bit.
My request has nothing to do with IIC implementation...it was just an
example.
My point was about C language convention.

All  variables declared outside a function are to be made global, if i'm not
mistaken. This is not followed by SDCC in some cases.

if I say:  " bit flg_one ;" outside a function
I get: " .globl flg_one"   which is correct.

but if I say "bit at 0x20 flg_one;"
I    do  not   get   ".global flg_one"
while there is basically no difference between the two.
flg_one is not declared global in the second case, while it should be. Can
someone explain why ? I believe that it's just something that's been
overlooked.

Whereas, If I say: "char value;" or " data at 0x21 char value;"  outside a
function, both are interpreted correctly & I get " .global _value;" in both
cases which is what is expected.

Thats the point I was trying to make :-). Not about a particular function or
anything.

PS: I found a workaround:
    void globals()    _naked
        {
            _asm
                .globl   _flg_one
                .globl    _SDA  // for example
               .globl    _SCL
            _endasm;
        }
This gives me the global attribute for explicitly located bit & sbit
variables.

Thanks,
--Royce.

> but if I say "bit at 0x20 flg_one;"
> I    do  not   get   ".global flg_one"
This is simply not true. 2.3.2 and later emit this line.

Bernhard

For the life of me I cannot understand why you would want to do something that while the language may support it, it is not good programming habits.
If you buy a gun and just because you could shoot your foot off does that mean that you want to shoot your foot off.
Don't get me wrong I'm not trying to put anybodies ideas down.  I have used goto in C code 3 times in about the last 5 years.
I can think up good justifable reasons to break the rules.  BUT I would also say that the example was very thin I've never liked globals it is like adding another parameter to every function you write but that parameter is not included in every prototype for each function.  You can never tell what is happening to a global variable.


Regards,
Rod 

On Sun, 16 Jul 2000 13:20:31 +0530
"Royce & Sharal Pereira" <bethell@...> wrote:

> Hi,
> ----- Original Message -----
> > Your logic for requesting this is flawed.  It has been my experance that
> each IIC implementation for a new project is diffrent.  For instance On one
> ---------------------------------------------------------------
> Let me simplify things a bit.
> My request has nothing to do with IIC implementation...it was just an
> example.
> My point was about C language convention.
> 
> All  variables declared outside a function are to be made global, if i'm not
> mistaken. This is not followed by SDCC in some cases.
> 
> if I say:  " bit flg_one ;" outside a function
> I get: " .globl flg_one"   which is correct.
> 
> but if I say "bit at 0x20 flg_one;"
> I    do  not   get   ".global flg_one"
> while there is basically no difference between the two.
> flg_one is not declared global in the second case, while it should be. Can
> someone explain why ? I believe that it's just something that's been
> overlooked.
> 
> Whereas, If I say: "char value;" or " data at 0x21 char value;"  outside a
> function, both are interpreted correctly & I get " .global _value;" in both
> cases which is what is expected.
> 
> Thats the point I was trying to make :-). Not about a particular function or
> anything.
> 
> PS: I found a workaround:
>     void globals()    _naked
>         {
>             _asm
>                 .globl   _flg_one
>                 .globl    _SDA  // for example
>                .globl    _SCL
>             _endasm;
>         }
> This gives me the global attribute for explicitly located bit & sbit
> variables.
> 
> Thanks,
> --Royce.
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Dear Rod,

I don't agree regarding the use of globals. In embedded code you
frequently have to use globals, for example for communication with ISRs.
Also memory bits representing port pins are global, because the port pin
itself is global and almost never shared in a procedural local sense. If
you cant tell what happens to a port pin in your code, you are most
probably not on a good way to efficient embedded programming. I
generally solve the problem of customizing library modules to an
application using make and the preprocessor, because sometimes a
preprocessor #if is required for customization as well to switch on and
off special features which are sometimes required and sometimes not, but
i don't see why declaring port pins as global variables should be a bad
idea.=20

Just in case you say you don't like #if either: i think in embedded
apllications your code should be as simple as possible to simplify
debugging and testing and to safe memory. I prefer to have code which is
not used in an application to be not compiled at all and the
preprocessor is the best (if not only) way to do this properly.

Concerning gotos: I don't think that the designers of the language put
this in just to have a feature that is never used.

Best regards,

Michael
=20

> -----Urspr=FCngliche Nachricht-----
> Von: sdcc-user-admin@...
> [mailto:sdcc-user-admin@...] Im Auftrag von=20
> Rod Boyce
> Gesendet: Montag, 27. Januar 2003 11:00
> An: Royce & Sharal Pereira
> Cc: sdcc-user@...
> Betreff: Re: Fw: [Sdcc-user] Why not global for explicitly=20
> addressed bits?
>=20
>=20
>=20
>=20
> For the life of me I cannot understand why you would want to=20
> do something that while the language may support it, it is=20
> not good programming habits. If you buy a gun and just=20
> because you could shoot your foot off does that mean that you=20
> want to shoot your foot off. Don't get me wrong I'm not=20
> trying to put anybodies ideas down.  I have used goto in C=20
> code 3 times in about the last 5 years. I can think up good=20
> justifable reasons to break the rules.  BUT I would also say=20
> that the example was very thin I've never liked globals it is=20
> like adding another parameter to every function you write but=20
> that parameter is not included in every prototype for each=20
> function.  You can never tell what is happening to a global variable.
>=20
>=20
> Regards,
> Rod=20
>=20
> On Sun, 16 Jul 2000 13:20:31 +0530
> "Royce & Sharal Pereira" <bethell@...> wrote:
>=20
> > Hi,
> > ----- Original Message -----
> > > Your logic for requesting this is flawed.  It has been my=20
> experance=20
> > > that
> > each IIC implementation for a new project is diffrent.  For=20
> instance=20
> > On one
> > ---------------------------------------------------------------
> > Let me simplify things a bit.
> > My request has nothing to do with IIC implementation...it=20
> was just an
> > example.
> > My point was about C language convention.
> >=20
> > All  variables declared outside a function are to be made=20
> global, if=20
> > i'm not mistaken. This is not followed by SDCC in some cases.
> >=20
> > if I say:  " bit flg_one ;" outside a function
> > I get: " .globl flg_one"   which is correct.
> >=20
> > but if I say "bit at 0x20 flg_one;"
> > I    do  not   get   ".global flg_one"
> > while there is basically no difference between the two.=20
> flg_one is not=20
> > declared global in the second case, while it should be. Can someone=20
> > explain why ? I believe that it's just something that's been=20
> > overlooked.
> >=20
> > Whereas, If I say: "char value;" or " data at 0x21 char value;" =20
> > outside a function, both are interpreted correctly & I get=20
> " .global=20
> > _value;" in both cases which is what is expected.
> >=20
> > Thats the point I was trying to make :-). Not about a particular=20
> > function or anything.
> >=20
> > PS: I found a workaround:
> >     void globals()    _naked
> >         {
> >             _asm
> >                 .globl   _flg_one
> >                 .globl    _SDA  // for example
> >                .globl    _SCL
> >             _endasm;
> >         }
> > This gives me the global attribute for explicitly located=20
> bit & sbit=20
> > variables.
> >=20
> > Thanks,
> > --Royce.
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld =3D=20
> Something 2 See!=20
> > http://www.vasoftware.com=20
> > _______________________________________________
> > Sdcc-user mailing list
> > Sdcc-user@...
> > https://lists.sourceforge.net/lists/listinfo/sdcc-user
> >=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something=20
> 2 See! http://www.vasoftware.com=20
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/s> dcc-user
>=20

Michael & ALl,

I almost agree with everything you say.  It is just for me I'm confortable =
with a file scope globales. =20
But a program wide global in my opinion is a very bad thing.  If you declar=
e a variable static at the top of a file then the scope of this variable is=
 limited to just that file.  This is maybe a global in the strictest sense =
of the word but in every module of your code you could have a static variab=
le declared the same (I feel unconfortable with this to).
In embedded programming #ifdef is your friend for sure but if can have a te=
ndency to make the code look untidy.  I'm much more confortable using #ifde=
f than globals but where possible I try to limit the use of #ifdef to a few=
 header files or the top of the file to make the code more readable.  BUT i=
n quite a few cases you need to conditional compile actual C code and this =
code cannot be split in to product specific and non-product specific code w=
ith making the intention of the code too complex under these circumistances=
 #ifdef is ok.  There are many rules to writting sucessful embedded code I =
try to write my code for maintainability first.

There are many parts of the C language that are not fully understood by man=
y people.
Goto's, some preprocessor macro expansions, even C libries (just look at so=
me of the questions in this list). =20
All these are to be used but in some cases moderation is the watch word.  A=
fter all very few people would consider the following program fragment good=
 code:

#define spit_it_out printf
main( void )
{
label47:
    spit_it_out( "Hello world\n" );
    goto label47;
}

but this is perfictly valid and may even compile and run.

Every part of hte C language has its part some part require more care than =
others this is all I'm saying.


Regards,
Rod=20

On Mon, 27 Jan 2003 11:45:37 +0100
Michael S=F6gtrop <MSoegtrop@...> wrote:

> Dear Rod,
>=20
> I don't agree regarding the use of globals. In embedded code you
> frequently have to use globals, for example for communication with ISRs.
> Also memory bits representing port pins are global, because the port pin
> itself is global and almost never shared in a procedural local sense. If
> you cant tell what happens to a port pin in your code, you are most
> probably not on a good way to efficient embedded programming. I
> generally solve the problem of customizing library modules to an
> application using make and the preprocessor, because sometimes a
> preprocessor #if is required for customization as well to switch on and
> off special features which are sometimes required and sometimes not, but
> i don't see why declaring port pins as global variables should be a bad
> idea.=20
>=20
> Just in case you say you don't like #if either: i think in embedded
> apllications your code should be as simple as possible to simplify
> debugging and testing and to safe memory. I prefer to have code which is
> not used in an application to be not compiled at all and the
> preprocessor is the best (if not only) way to do this properly.
>=20
> Concerning gotos: I don't think that the designers of the language put
> this in just to have a feature that is never used.
>=20
> Best regards,
>=20
> Michael
> =20