Searching \ for '[PIC] Problems with Hi-Tech C in Linux .hex output' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=output
Search entire site for: 'Problems with Hi-Tech C in Linux .hex output'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Problems with Hi-Tech C in Linux .hex output'
2004\10\02@141650 by Adam Woodworth

flavicon
face
Hello,

I am having trouble getting any .hex files generated by Hi-Tech C in Linux
to actually do anything on my PIC16F84A. I can compile programs cleanly
and get the program onto my PIC, but when I put the PIC into my simple
circuit it doesn't do anything.

For example, the following simple program doesn't do anything when loaded
onto my PIC and put into a circuit with an LED attached to pin 1 of PORTB.

#include <pic.h>
__CONFIG(WDTEN & XT & UNPROTECT & PWRTEN);
void main(void)
{
       TRISB = 0;
       PORTB = 255;
}

I compile it like this:
picl -O -Ot.hex t.c -16F84A

Am I missing some special flags to the picl compiler, or any special
config/pragmas in my code? I've made sure that it's not my programming
software in Linux -- any .hex file I have generated from Basic on Windows
and copied to my Linux box will load onto the PIC fine with the
programming software I use in Linux and operate the circuit as expected.

The same program written in Proton+ Lite Basic on Windows will work in the
PIC and the LED will turn on.

Any help would be appreciated!

Thanks,
Adam

_______________________________________________________________________
 Adam Woodworth
 SMTP : spam_OUTadamTakeThisOuTspammirkwood.com
 HTTP : http://www.mirkwood.com
 HAM  : N1ZNN
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@170034 by Brent Brown

picon face
Adam Woodworth wrote:
> For example, the following simple program doesn't do anything when
> loaded onto my PIC and put into a circuit with an LED attached to pin
> 1 of PORTB.
>
> #include <pic.h>
> __CONFIG(WDTEN & XT & UNPROTECT & PWRTEN);
> void main(void)
> {
>  TRISB = 0;
>  PORTB = 255;
> }

I think this is a fairly common hurdle for people to overcome when first
learning C. Your two lines of code will get executed and then the processor
will wander off into never never land because you haven't told it what to do
next. You could add the following:-

while(1)
       ;

The above is a never ending loop.

Or you could re-structure your program so all of function main gets repeated:

void main(void){
       while(1){
               TRISB = 0;
               PORTB = 255;
               }
       }

Hope this helps somewhat.

--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/txt: 025 334 069
eMail:  .....brent.brownKILLspamspam@spam@clear.net.nz


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@174644 by Adam Woodworth

flavicon
face
Hi Brent,

Thanks for your response!  Actually, I've been programming in C for years,
and I tried putting the code in a loop earlier and still nothing happens
to the LED.  So I'm still clueless as to what the problem is.

I even tried setting PORTB = 0 instead of 255 in case 0 meant high and 1
meant low (which seems to be the case with gpasm).

But would this program really require an endless loop?  I'm still not too
familiar with PICs, but I would assume that the compiler would generate
code that would have an instruction to terminate the program, so that the
PIC wouldn't go off into never never land.  I was expecting the code to
run, change the state of PORTB, and exit cleanly and the PIC would be
sitting "idle".  Am I wrong?

Thanks!
Adam


On Sun, 3 Oct 2004, Brent Brown wrote:

{Quote hidden}

_______________________________________________________________________
 Adam Woodworth
 SMTP : .....adamKILLspamspam.....mirkwood.com
 HTTP : http://www.mirkwood.com
 HAM  : N1ZNN
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@175204 by piclist

flavicon
face
On Sun, 3 Oct 2004, Brent Brown wrote:

> > void main(void)
> > {
> >  TRISB = 0;
> >  PORTB = 255;
> > }
>
> I think this is a fairly common hurdle for people to overcome when first
> learning C. Your two lines of code will get executed and then the processor
> will wander off into never never land because you haven't told it what to do
> next.

I agree that falling off the end of main() is not a good idea, but the
code won't wander off into uninitialzed code space.  Code generated by
the Hi-Tech compilers jumps back to the beginning after the closing
brace of main().

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@175909 by piclist

flavicon
face
On Sat, 2 Oct 2004, Adam Woodworth wrote:

> I am having trouble getting any .hex files generated by Hi-Tech C in Linux
> to actually do anything on my PIC16F84A.

There's nothing obviously wrong with your code.

> any .hex file I have generated from Basic on Windows
> and copied to my Linux box will load onto the PIC fine with the
> programming software I use in Linux and operate the circuit as expected.

Hex files generated with PICC on Linux will be in UNIX text format (LF
delimited), while hex files generated under Windows will be in DOS
format (CRLF delimited).  Since your Linux programmer seems happy with
DOS-formatted hex files, perhaps it doesn't correctly support hex
files in UNIX format?

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@180210 by Dave VanHorn

flavicon
face
At 04:52 PM 10/2/2004, EraseMEpiclistspam_OUTspamTakeThisOuTxargs.com wrote:

>On Sun, 3 Oct 2004, Brent Brown wrote:
>
>> > void main(void)
>> > {
>> >  TRISB = 0;
>> >  PORTB = 255;
>> > }
>>
>> I think this is a fairly common hurdle for people to overcome when first
>> learning C. Your two lines of code will get executed and then the processor
>> will wander off into never never land because you haven't told it what to do
>> next.
>
>I agree that falling off the end of main() is not a good idea, but the
>code won't wander off into uninitialzed code space.  Code generated by
>the Hi-Tech compilers jumps back to the beginning after the closing
>brace of main().

In general, all uC programs are infinite loops.

I have seen a few cases where they run, then kill their own power until something external brings them back up again, but these are exceptions.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@180538 by Herbert Graf

flavicon
face
On Sat, 2004-10-02 at 17:46, Adam Woodworth wrote:
> Hi Brent,
>
> Thanks for your response!  Actually, I've been programming in C for years,
> and I tried putting the code in a loop earlier and still nothing happens
> to the LED.  So I'm still clueless as to what the problem is.

Then you've either got a wiring mistake, a power problem, a programming
problem, a reset problem or a config fuse problem.

Which PIC are you using? Which programmer? What are your fuse settings?

> I even tried setting PORTB = 0 instead of 255 in case 0 meant high and 1
> meant low (which seems to be the case with gpasm).

Huh? "high" and "low" aren't defined in gpasm AFAIK, a 0 is a 0, a 1 is
a 1, a 1 on a port pin will cause it to go to Vh, what did you observe
to make you think differently??

> But would this program really require an endless loop?  

If you want it to behave in an expected way... yes.

> I'm still not too
> familiar with PICs, but I would assume that the compiler would generate
> code that would have an instruction to terminate the program, so that the
> PIC wouldn't go off into never never land.  

Nope, the compiler won't do anything more then you ask it to.

> I was expecting the code to
> run, change the state of PORTB, and exit cleanly and the PIC would be
> sitting "idle".  

Define "exit cleanly" in the context of a PIC?

I think you are confusing things here with a PC. When a program "ends"
on a PC control returns to that which called the program, which is your
OS. But even when control is with the OS, there is still an infinite
loop running, your CPU never actually stops doing things (except when
going into suspend and things like that).

On a PIC you have NO OS, there is no such thing as your program
"exiting", your program is the only thing the PIC knows, it is the PIC's
universe.

> Am I wrong?

Unfortunately yes, although wrong is a little harsh. I just think you
haven't completely wrapped your head around what a PIC is. This is why I
NEVER recommend people start out with a PIC using C, it ends up
confusing people more then if they just went ASM first and then moved to
C.

Just wait until you hit your first compiler bug, if you know nothing of
PIC ASM and it's "interesting" architecture you WILL be lost.

> Thanks!
> Adam

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@180837 by piclist

flavicon
face
On Sat, 2 Oct 2004, Adam Woodworth wrote:

> I even tried setting PORTB = 0 instead of 255 in case 0 meant high and 1
> meant low (which seems to be the case with gpasm).

Hi-Tech doesn't do any strange translations; a 0 is a 0.

> I would assume that the compiler would generate
> code that would have an instruction to terminate the program, so that the
> PIC wouldn't go off into never never land.  I was expecting the code to
> run, change the state of PORTB, and exit cleanly and the PIC would be
> sitting "idle".  Am I wrong?

The only thing approaching an "idle" state with a PIC is the sleep
instruction.

Also note that you had the watchdog timer enabled, which will cause
the PIC to periodically reset.  This, along with the powerup timer,
means PORTB will return to hi-z state for ~72 ms after a reset.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@180940 by Herbert Graf

flavicon
face
On Sat, 2004-10-02 at 17:52, piclistspamspam_OUTxargs.com wrote:
> On Sun, 3 Oct 2004, Brent Brown wrote:
>
> > > void main(void)
> > > {
> > >  TRISB = 0;
> > >  PORTB = 255;
> > > }
> >
> > I think this is a fairly common hurdle for people to overcome when first
> > learning C. Your two lines of code will get executed and then the processor
> > will wander off into never never land because you haven't told it what to do
> > next.
>
> I agree that falling off the end of main() is not a good idea, but the
> code won't wander off into uninitialzed code space.  Code generated by
> the Hi-Tech compilers jumps back to the beginning after the closing
> brace of main().

Are you absolutely certain of that? Does HiTech put a "goto" at the end
brace? I would be very surprised and disturbed if they did.

Remember, that if execution DOES go into "never never" land, and all of
that place is uninitialized, the PIC will simply see 3ff as the op code.
Since that is an invalid op code it will treat it as a NOP and increment
the PC. Eventually the PC will wrap and hit address 0, which of course
is the first instruction of your program, which will "rerun" your
program, giving the ILLUSION that the program "restarted".

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@181546 by Ivan Kocher

flavicon
face
Have you tried your .hex in a simulator?
picsim works for me quite good... or just disasseble the .hex and see
what might be wrong ...


Ivan Kocher
---------------

Adam Woodworth wrote:
{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@181816 by Adam Woodworth

flavicon
face
> Hex files generated with PICC on Linux will be in UNIX text format (LF
> delimited), while hex files generated under Windows will be in DOS
> format (CRLF delimited).  Since your Linux programmer seems happy with
> DOS-formatted hex files, perhaps it doesn't correctly support hex
> files in UNIX format?

Actually I'm using Odyssey, programming software written for Linux, and it
happily works with DOS formatted HEX files and UNIX formatted HEX files.
I can use Odyssey to load hex files generated by Proton Basic on Windows
and hex files generated by gpasm on Linux.

_______________________________________________________________________
 Adam Woodworth
 SMTP : RemoveMEadamTakeThisOuTspammirkwood.com
 HTTP : http://www.mirkwood.com
 HAM  : N1ZNN
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@183655 by Adam Woodworth

flavicon
face
> Which PIC are you using? Which programmer? What are your fuse settings?

PIC16F84A.  EPIC programmer.  I'm setting XT, watchdog enable, unprotect,
and power up enable in the C source file.  I'm using the Odyssey
programming software in Linux.  If I pull the .hex file generated by
Hi-Tech C over to my Windows box and use the EPIC programming software on
it, there's no difference.

> Huh? "high" and "low" aren't defined in gpasm AFAIK, a 0 is a 0, a 1 is
> a 1, a 1 on a port pin will cause it to go to Vh, what did you observe
> to make you think differently??

In gpasm, the following turns a pin high (at least for me):

       movlw        0
       tris        PORTB
       movlw        0x00
       movwf        PORTB

> On a PIC you have NO OS, there is no such thing as your program
> "exiting", your program is the only thing the PIC knows, it is the PIC's
> universe.

I understand how a PC works.  I guess I was just figuring that there would
exist some "exit" instruction on the PIC and when it reached that
instruction it would set a bit somewhere in the PIC that would inform the
PIC to just do nop's forever.  But now I know I'm completely wrong. :)
Thanks for the information!

At any rate, even with a while(1); at the end of main(), the PIC still
doesn't light up the LED.

> Just wait until you hit your first compiler bug, if you know nothing of
> PIC ASM and it's "interesting" architecture you WILL be lost.

Fortunately I know enough about assembly to have a vague idea of what's
going on in a PIC assembly file. :)

Adam

_______________________________________________________________________
 Adam Woodworth
 SMTP : spamBeGoneadamspamBeGonespammirkwood.com
 HTTP : http://www.mirkwood.com
 HAM  : N1ZNN
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@183931 by Adam Woodworth

flavicon
face
> > I agree that falling off the end of main() is not a good idea, but the
> > code won't wander off into uninitialzed code space.  Code generated by
> > the Hi-Tech compilers jumps back to the beginning after the closing
> > brace of main().
>
> Are you absolutely certain of that? Does HiTech put a "goto" at the end
> brace? I would be very surprised and disturbed if they did.

After inspecting the assembler generated by HiTech, I can tell you that
HiTech defines "global start" at the head of the assembler file, and at
the end of the program instructions it does an "ljmp start".


>
> Remember, that if execution DOES go into "never never" land, and all of
> that place is uninitialized, the PIC will simply see 3ff as the op code.
> Since that is an invalid op code it will treat it as a NOP and increment
> the PC. Eventually the PC will wrap and hit address 0, which of course
> is the first instruction of your program, which will "rerun" your
> program, giving the ILLUSION that the program "restarted".

_______________________________________________________________________
 Adam Woodworth
 SMTP : TakeThisOuTadamEraseMEspamspam_OUTmirkwood.com
 HTTP : http://www.mirkwood.com
 HAM  : N1ZNN
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@185329 by Wouter van Ooijen

face picon face
> I was expecting the code to
> > run, change the state of PORTB, and exit cleanly

Exit to what, PIC-DOS? Unless you have an OS, executive or something
like that there is nothing to return to, your progeam is all alone.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@185513 by piclist

flavicon
face
On Sat, 2 Oct 2004, Herbert Graf wrote:

> > Code generated by
> > the Hi-Tech compilers jumps back to the beginning after the closing
> > brace of main().
>
> Are you absolutely certain of that?

Yes.

> Does HiTech put a "goto" at the end brace?

Yes.  Here is the assembly listing of the OP's code:

   25  03FA  1683                  bsf 3,5
   26  03FB  0186                  clrf    6   ;volatile
   27                           ;t.c: 13: PORTB = 0xFF;
   28  03FC  30FF                  movlw   -1
   29  03FD  1283                  bcf 3,5
   30  03FE  0086                  movwf   6   ;volatile
   31                           ;t.c: 14: }
   32  03FF  2804                  ljmp    start

"start" being the C startup code which I haven't included here.

> I would be very surprised and disturbed if they did.

Why?  The standard specifically states that this behavior is
implementation-defined.  I don't see how having random code executed
would be preferrable.

> Remember, that if execution DOES go into "never never" land, and all of
> that place is uninitialized

The latter condition is certainly not likely to be true when
discussing what follows the closing brace of main(), except in the
most trivial of programs.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@191001 by Peter Johansson

flavicon
face
Dave VanHorn writes:

> In general, all uC programs are infinite loops.

Unless you are using a uC with sleep and interrupts.  That's one of
the really nice things about the SX.  ;-)

> I have seen a few cases where they run, then kill their own power
> until something external brings them back up again, but these are
> exceptions.

I can see where this would certainly be an exception on a uC where you
don't have sleep and interrupts, but when you've got that I'm not sure
why you wouldn't want to make use of it.

So far, my only uC development platform is the SX, and all of my
programs have been interrupt driven.  Well, all but the first one to
flash the LED.  The second one flashed the LED using interrupts.

I haven't yet made the jump from SX over to PIC, so I have only the
most basic idea of the differences between the two.  I get the
impression that the older PICs did not support interrupts, but surely
the whole lot of the low power chips (at least the nano-watt ones)
must have some sort of sleep/interrupt capabilities.

-p.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@192235 by Dave VanHorn

flavicon
face
At 06:10 PM 10/2/2004, Peter Johansson wrote:

>Dave VanHorn writes:
>
>> In general, all uC programs are infinite loops.
>
>Unless you are using a uC with sleep and interrupts.  That's one of
>the really nice things about the SX.  ;-)


Even so.
The int is merely a diversion, and sleep just a pause.



>I haven't yet made the jump from SX over to PIC, so I have only the
>most basic idea of the differences between the two.  I get the
>impression that the older PICs did not support interrupts, but surely
>the whole lot of the low power chips (at least the nano-watt ones)
>must have some sort of sleep/interrupt capabilities.

We may not be speaking quite the same language.
AFAIK, all the pics had some sort of int support, though the early ones weren't vectored.
Sleep is probably relatively new.

Some of the AVRs can also divide their clock way down, up to /128 for a major power reduction.  I haven't thought of anything clever yet to do with the ability to set CLK/7 or CLK/121 yet.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@201428 by Herbert Graf

flavicon
face
On Sat, 2004-10-02 at 18:39, Adam Woodworth wrote:
> > > I agree that falling off the end of main() is not a good idea, but the
> > > code won't wander off into uninitialzed code space.  Code generated by
> > > the Hi-Tech compilers jumps back to the beginning after the closing
> > > brace of main().
> >
> > Are you absolutely certain of that? Does HiTech put a "goto" at the end
> > brace? I would be very surprised and disturbed if they did.
>
> After inspecting the assembler generated by HiTech, I can tell you that
> HiTech defines "global start" at the head of the assembler file, and at
> the end of the program instructions it does an "ljmp start".

Wow, that is surprising, why they would so something so silly is beyond
me, I'd class junk like that as a bug.

For the record I HATE compilers that do things that weren't asked of
them, most of the compiler bugs I've hit in the PIC world have revolved
around the writers of the compiler ASSUMING something they clearly
shouldn't have, this sounds like one of those things.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@201557 by Herbert Graf

flavicon
face
On Sat, 2004-10-02 at 18:55, RemoveMEpiclistspamTakeThisOuTxargs.com wrote:
> > Remember, that if execution DOES go into "never never" land, and all of
> > that place is uninitialized
>
> The latter condition is certainly not likely to be true when
> discussing what follows the closing brace of main(), except in the
> most trivial of programs.

True, but this IS the most "trivial" of programs, hence my statement.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@214533 by piclist

flavicon
face
On Sat, 2 Oct 2004, Herbert Graf wrote:

> > After inspecting the assembler generated by HiTech, I can tell you that
> > HiTech defines "global start" at the head of the assembler file, and at
> > the end of the program instructions it does an "ljmp start".
>
> Wow, that is surprising, why they would so something so silly is beyond
> me, I'd class junk like that as a bug.

The standard requires that some behavior be defined for returning from
main().  If the behavior that was implemented didn't make sense, I
could see classifying that as a bug, but I don't see anything strange
about this behavior.  What behavior would you suggest instead?

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@220901 by steve

flavicon
face
> Are you absolutely certain of that? Does HiTech put a "goto" at the
> end brace? I would be very surprised and disturbed if they did.

What would you say is the correct thing to do in this situation ?

> Remember, that if execution DOES go into "never never" land, and all
> of that place is uninitialized, the PIC will simply see 3ff as the op
> code. Since that is an invalid op code it will treat it as a NOP and
> increment the PC. Eventually the PC will wrap and hit address 0, which
> of course is the first instruction of your program, which will "rerun"
> your program, giving the ILLUSION that the program "restarted".

ILLUSION ?
Is that a newly defined C keyword ?

You have assumed that the locater has put main() at the highest
address in memory. What happens (according to you scheme) if
main() is located immediately before detonate() ?

You have also assumed PIC architecture, operation based on an
undefined opcode and that the instruction returned from all
addressable memory between the top of rom and PC rollover be
executed as a NOP.

My personal preference would be a jmp $ after the closing brace,
but I think I'd take Hi-Tech's approach over a mixture of undefined
assumptions producing an illusion.

Steve.


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@000328 by Herbert Graf

flavicon
face
On Sat, 2004-10-02 at 22:08, steveEraseMEspam.....tla.co.nz wrote:
> > Are you absolutely certain of that? Does HiTech put a "goto" at the
> > end brace? I would be very surprised and disturbed if they did.
>
> What would you say is the correct thing to do in this situation ?

Nothing, since proper code would NEVER have the situation.

> > Remember, that if execution DOES go into "never never" land, and all
> > of that place is uninitialized, the PIC will simply see 3ff as the op
> > code. Since that is an invalid op code it will treat it as a NOP and
> > increment the PC. Eventually the PC will wrap and hit address 0, which
> > of course is the first instruction of your program, which will "rerun"
> > your program, giving the ILLUSION that the program "restarted".
>
> ILLUSION ?
> Is that a newly defined C keyword ?

No, why do you think I think that?

> You have assumed that the locater has put main() at the highest
> address in memory. What happens (according to you scheme) if
> main() is located immediately before detonate() ?

The reason I gave WAS SPECIFIC TO THE EXAMPLE, in which case there WAS
ONLY MAIN, NOTHING ELSE, I also specified that ALL OTHER LOCATIONS WERE
UNDEFINED.

> You have also assumed PIC architecture, operation based on an
> undefined opcode and that the instruction returned from all
> addressable memory between the top of rom and PC rollover be
> executed as a NOP.

Read the datasheet and show me where an undefined op code in the PIC
architecture IS NOT TREATED AS A NOP?

> My personal preference would be a jmp $ after the closing brace,
> but I think I'd take Hi-Tech's approach over a mixture of undefined
> assumptions producing an illusion.

My personal preference is that the compiler didn't do more then it was
asked of. There is no such this as "exiting main" on the PIC, to define
a behaviour is simply silly since it SHOULD NEVER HAPPEN.

Sloppy coding is the ONLY reason something like this would happen, and
the compiler "fixing" sloppy coding is what I'm really against.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@000425 by Herbert Graf

flavicon
face
On Sat, 2004-10-02 at 21:45, EraseMEpiclistspamxargs.com wrote:
> On Sat, 2 Oct 2004, Herbert Graf wrote:
>
> > > After inspecting the assembler generated by HiTech, I can tell you that
> > > HiTech defines "global start" at the head of the assembler file, and at
> > > the end of the program instructions it does an "ljmp start".
> >
> > Wow, that is surprising, why they would so something so silly is beyond
> > me, I'd class junk like that as a bug.
>
> The standard requires that some behavior be defined for returning from
> main().  If the behavior that was implemented didn't make sense, I
> could see classifying that as a bug, but I don't see anything strange
> about this behavior.  What behavior would you suggest instead?

None, or at least throw a clear warning, this situation should never
happen, and the compiler shouldn't have a behaviour to define something
that shouldn't be.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@003820 by Adam Woodworth

flavicon
face
Thanks for the idea!  Disassembling the .hex file showed me what was
wrong, although I don't know why it's wrong...  It turns out HiTech C was
splitting the code into a couple sections and putting them in different
places in the memory space for some reason.

Here's the disassembled .hex file:

000000:  0183  clrf     0x3
000001:  3000  movlw    0
000002:  008a  movwf    0xa
000003:  2804  goto     0x4
000004:  0183  clrf     0x3
000005:  2bfa  goto     0x3fa
0003fa:  1683  bsf      0x3, 0x5
0003fb:  0186  clrf     0x6
0003fc:  30ff  movlw    0xff
0003fd:  1283  bcf      0x3, 0x5
0003fe:  0086  movwf    0x6
0003ff:  2bff  goto     0x3ff
002007:  3ff5  addlw    0xf5

As you can see, there's 2 extraneous goto statements, one at 0003 and one
at 0005.  And the one at 0005 jumps to a completely different area in
memory.  So for some reason after 0005 the compiler moved the code up to
03fa.  Now if I take this assembly code and remove the gotos at 0003 and
0005 and compile it into .hex with gpasm, it works fine.  I can load it
onto my PIC and the LED lights up.

What I don't understand is 1) why HiTech is putting in these extra gotos,
and 2) why the extra gotos and splitting of code is causing the PIC not to
work as expected.

Anyone have any ideas?

Adam

On Sat, 2 Oct 2004, Ivan Kocher wrote:

{Quote hidden}

_______________________________________________________________________
 Adam Woodworth
 SMTP : RemoveMEadamTakeThisOuTspamspammirkwood.com
 HTTP : http://www.mirkwood.com
 HAM  : N1ZNN
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@010123 by Shawn Wilton

flavicon
face
It sounds as though it's possibly compiling for a different model
uController.  My guess as to why it's not working is that it's placing
the code somewhere it can't actually get to.

Just a guess.

I don't have the datasheet for your micro to look at to verify it.  It's
good that you've solved the problem, but bad that you wasted all that
time when you could have written the program in ASM in no more than 10
minutes...

...Just an observation.

-Shawn



Adam Woodworth wrote:

{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@011039 by Ken Pergola

flavicon
face

Hi Adam,

1) Could you post the newly edited source code you are using after following
the suggestions given to you in this thread?

2) Have you verified that your LED is not connected backwards?

3) How have you connected the PIC's /MCLR pin?

4) I see that your OSC configuration is 'XT'. What frequency quartz crystal
or ceramic resonator are you using? Or, are you using an external clock
oscillator? If you are using appropriate loading capacitors? Could you tell
us more details about this.

If you could answer these questions and provide any other hardware details
they may give us more clues so that we can get your back on track.

Best regards,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@012724 by Ken Pergola

flavicon
face

I wrote:

> "...so that we can get your back on track."

Hi Adam,

Freudian slip -- I did not mean that we were chiropractors. :)

I obviously meant: "...so that we can get you back on track."

Best regards,

Ken Pergola

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@020722 by Wouter van Ooijen

face picon face
> We may not be speaking quite the same language.
> AFAIK, all the pics had some sort of int support, though the
> early ones weren't vectored.
> Sleep is probably relatively new.

The 12-bit core PICs (of which the SX is a clone with additions) don't
have an interrupt. But IIRC they do have sleep.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@021912 by Dave VanHorn

flavicon
face
At 01:07 AM 10/3/2004, Wouter van Ooijen wrote:

>> We may not be speaking quite the same language.
>> AFAIK, all the pics had some sort of int support, though the
>> early ones weren't vectored.
>> Sleep is probably relatively new.
>
>The 12-bit core PICs (of which the SX is a clone with additions) don't
>have an interrupt. But IIRC they do have sleep.


Wasn't the C84/F84 a 12 bitter? That had ints.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@023653 by Ivan Kocher

flavicon
face
weird ... :(

About the C compiler, nothing strange, compiler compile and some of them
"leave" certain zones of memory for "their" use, sort of a prereseve of
that memory, that should be corrected in the optimization stage of the
compile... this is not optimized, did you have some flag for
optimization? maybe that will "correct" this strage memory usage.

About the two gotos not working... that really scares me, freezes me....
too spooky!!!

Or the pic has a bug, one that has not been detected, or we are not seen
something... I am checking the datasheet (PIC 16F84A, right?) but I
don't see anything strage on those two gotos ... auch!!!!!!

Any body else who can try this source with and without gotos?  I would,
but my programer is at the office, not with me at home, and I know I
have 16F84, not sure where... never used it.


If you can check this, and have something on it, it would be
interesting.  Bug???  or me not reading or forgeting something... ;)



Ivan Kocher
---------------


Adam Woodworth wrote:
{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@024755 by piclist

flavicon
face
On Sun, 3 Oct 2004, Adam Woodworth wrote:

> As you can see, there's 2 extraneous goto statements, one at 0003 and one
> at 0005.

They're not extraneous; it's just startup code.  They won't cause any
problems.

> And the one at 0005 jumps to a completely different area in
> memory.  So for some reason after 0005 the compiler moved the code up to
> 03fa.

That's what the compiler chose to do.  It doesn't cause a problem.

> Now if I take this assembly code and remove the gotos at 0003 and
> 0005 and compile it into .hex with gpasm, it works fine.  I can load it
> onto my PIC and the LED lights up.

I don't think that proves anything.  Did you try the same test without
modifying the assembly code?

The output you're getting matches what I get from the commercial
version of PICC on Linux.  I can import the hex file into MPLAB,
unmodified; simulating it leaves me with TRISB at 0x00 and PORTB at
0xFF, just as you'd expect.  The GOTOs don't do anything strange.
Have you tried simulating it yourself?

I can state pretty confidently that there is essentially zero
probability that your two-line program is getting compiled
incorrectly, and that trying to figure out what is "wrong" with the
output of the compiler is going to lead you nowhere.  I still say the
most likely problem is some incompatibility between the hex file and
your programming software.

Try importing the hex file into MPLAB on a Windows machine, then
exporting it, and see if the resulting DOS-formatted hex file makes
your programmer happy.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@025146 by Ivan Kocher

flavicon
face
Already check the datasheet, it is a 14 bit one ...
ie: goto 0x3ff  is a valid instruction, no 12 bit ones as in the 16C5x

Still I can't find anything in the datasheet that says there are some
problems with gotos... still checking.



Ivan Kocher
---------------


Dave VanHorn wrote:
{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@032601 by Wouter van Ooijen

face picon face
> Wasn't the C84/F84 a 12 bitter?

nope, 14 bit

> That had ints.

true, like all 14-bit cores AFAIK. Note that it is not dead yet, the
F84A is still produced.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@101536 by Herbert Graf

flavicon
face
On Sat, 2004-10-02 at 18:36, Adam Woodworth wrote:
> > Which PIC are you using? Which programmer? What are your fuse settings?
>
> PIC16F84A.  EPIC programmer.  I'm setting XT, watchdog enable, unprotect,
> and power up enable in the C source file.  I'm using the Odyssey
> programming software in Linux.  If I pull the .hex file generated by
> Hi-Tech C over to my Windows box and use the EPIC programming software on
> it, there's no difference.

Hmm, sounds like then you've got a wiring mistake, power issue, reset
issue or your oscillator isn't good (bad crystal, wrong caps).

{Quote hidden}

That simply isn't possible, how do you know the pin is "high"? Are you
sure it's high and not "tristate"? Try putting a 10k resistor to ground
on the pin and see if it still reads high.

> At any rate, even with a while(1); at the end of main(), the PIC still
> doesn't light up the LED.

Which sounds to me like the PIC either isn't being programmed (does the
could verify correctly?) or the PIC isn't running to code.

Try changing to RC mode, right now you don't care about timing accuracy,
RC mode will almost certainly get the PIC going.

What do you have attached to MCLR?


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@111819 by Adam Woodworth

flavicon
face
> I don't have the datasheet for your micro to look at to verify it.  It's
> good that you've solved the problem, but bad that you wasted all that
> time when you could have written the program in ASM in no more than 10
> minutes...

Well sure, but I don't intend to use C just to write 2 line programs.  My
goal was to see if I could get the C compiler to work.  I intend to learn
PIC assembly as well, but I like to have options.




{Quote hidden}

_______________________________________________________________________
 Adam Woodworth
 SMTP : @spam@adam@spam@spamspam_OUTmirkwood.com
 HTTP : http://www.mirkwood.com
 HAM  : N1ZNN
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@121301 by Adam Woodworth

flavicon
face
> I don't think that proves anything.  Did you try the same test without
> modifying the assembly code?

Yes.  No go.  But I found out that it seems to be a problem with the
programming software I'm using in Linux.  If I pull the HiTech generated
hex file over to Windows and use EPICs programming software the program
works as expected.

Which is odd because the hex file generated by HiTech C uses 0x0a for line
breaks, and so does gpasm, and the programming software I use in Linux
works with gpasm generated hex files.  (So apparently the EPIC Windows
software is capable of handling 0x0d0a and 0x0a terminated lines, since
I just straight copied the hex file over to Windows from Linux.)

Anyways, it looks like the Odyssey programming software I'm using in Linux
is pretty buggy.  I'm now seeing that sometimes it works with HiTech hex
files and sometimes it doesn't.  So finally we have our answer.

Thanks for everyone for their help!

Adam

_______________________________________________________________________
 Adam Woodworth
 SMTP : spamBeGoneadamspamKILLspammirkwood.com
 HTTP : http://www.mirkwood.com
 HAM  : N1ZNN
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@042155 by Alan B. Pearce

face picon face
>You have assumed that the locater has put main()
>at the highest address in memory. What happens
>(according to you scheme) if main() is located
>immediately before detonate() ?

You have an extremely hard to find bug ???? <VBG>
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@043051 by Alan B. Pearce

face picon face
>My personal preference is that the compiler didn't do
>more then it was asked of. There is no such this as
>"exiting main" on the PIC, to define a behaviour is
>simply silly since it SHOULD NEVER HAPPEN.

True, but only in that using C on a PIC (or any other microcontroller) is a
hack, in that the C standard allows main() to return, and so some provision
needs to be made to allow for things to not blow up.

>Sloppy coding is the ONLY reason something like this
>would happen, and the compiler "fixing" sloppy coding
>is what I'm really against.

This sounds like someone who never makes errors in their code talking.

Personally I find the "fix" for falling out of main() reasonable, in that in
most circumstances it causes the PIC code to do a failsafe operation instead
of (possibly) falling through to code that could damage hardware (think in
terms of turning on all arms of an H-bridge). Agreed you were talking in
terms of this particular minimalist program, but it does show that the
compiler designer has done something to "fail safe" in the event of a
mistype in the source code. That would surely make me add some brownie
points for that compiler if looking at compiler options.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@060836 by Russell McMahon

face
flavicon
face
> Personally I find the "fix" for falling out of main() reasonable, in that
> in
> most circumstances it causes the PIC code to do a failsafe operation
> instead
> of (possibly) falling through to code that could damage hardware (think in
> terms of turning on all arms of an H-bridge). Agreed you were talking in
> terms of this particular minimalist program, but it does show that the
> compiler designer has done something to "fail safe" in the event of a
> mistype in the source code. That would surely make me add some brownie
> points for that compiler if looking at compiler options.

While the material below is FAR from PIC's or C per se it is very much on
topic.

I hate "cottonwool" that can't be removed that isolates you from reality or
corrects your mistakes - even "bad" ones - or that stops you doing
"dangerous" things. If there are safety protections that can be
enabled/disabled that's fine. You can decide whether to use them or not. My
word processor runs with as much cotton wool turned off as possible, as it
seems in my case to add more errors than it removes. Spelling checkers I
approve of, but not if they change things automatically and/or unbeknown to
me.

One of the first Airbus A-320 airliners was doing a low pass at the Paris
(Habsheim) airshow in June 1988. The vastly experienced pilot brought the
plane down in a breathtakingly low wheels-down pass to strut his stuff for
the assembled masses. Much lower than he should have, 'but he knew what he
was doing and what the plane was capable of'. At the end of the pass he
commanded * it to climb out.  The rate required for safety was rather high.
But the aircraft was capable of it. But the computers had other ideas.
Cottonwool dictated that they must not fly the wings off the aircraft - or
come anywhere near doing so*** . So they gave him as much thrust as they
deemed him to be allowed. The plane flew magnificently into the adjacent
forest just above tree top level, slowly settling so that it scythed through
the tress, tearing the wings off and gleefully destroying itself. If you
view the video referenced below you will be utterly astounded that only 3**
of 136 people on board died. [[And never want C to stop you falling out of
main() ever again :-) ]]

[** Figures vary with report. 3 seems most likely].

       * In an Airbus you command it using an electronically linked
fly-by-wire
       side-stick, none of this brute force pulleys and wires stuff)

*** Good arguments could be advanced for setting limits to the flight
envelope that did not damage or stress the air-frame or shorten the airframe
lifetime by improper use. Even better arguments can be advanced for giving
the pilot the ability to fly the wings off if he really really really wants
to.

____________________________________

Video. Well worth watching.
Failure to pullup was painfully obvious long before the event. Hard to
believe that the plane was not capable of doing so.
Utterly unbelievable. Anyone watching the slow plow in, subsequent
invisibility amongst the trees and then subsequent fireball would have
believed that most or all aboard had died.

       http://www.airdisaster.com/download/af320.shtml

Coverup? Officially blamed on pilot error.  Switzerland's Institute of
Police Forensic Evidence and Criminology subsequently stated that the flight
data recorder had been substituted after the crash.

       http://www.wordiq.com/definition/Airbus_A320

This gives several versions of what "really" happened

       http://www.cs.berkeley.edu/~szewczyk/cs294-8/hw1.html

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@083740 by Gerhard Fiedler

picon face
> [[And never want C to stop you falling out of  main() ever again :-) ]]

While I agree with all you wrote about the flight incident, I pretty much
doubt it happened because a C compiler stopped a program from falling out
of main :)

Seriously, I don't think anyone here advocates falling out of main in an
embedded C program as a programming technique. This already shows that
whatever the compiler does in such a situation shouldn't affect a properly
written program. (Which means that all who only write properly written
programs really don't have to bother about this. :)

Consequently, the only programs that are affected by this compiler behavior
are programs that don't behave as designed. One could advocate for an
endless loop, as some did, as it makes the error more obvious during
testing. OTOH, coming back to the Airbus incident, I'd rather be in a plane
where the relevant control program runs through a series of resets and
moves the actuator in slow steps than in one where it just stops working --
or blows the drivers.

Again you could say the program should never get there... but 1) if it
never gets there, why does it bother you? and 2) most of us have written
programs that did something they never should have done :)

Actually, the larger part of a typical program (and I include compilers
here, even though I never really wrote one) is to deal with things that
never should happen...

So, I don't really see how this behavior could affect anybody negatively.
It won't affect what you intend to do, and among the alternatives of how to
handle what you didn't intend to do, the choice it makes is as good (or
better) as any other. Starting all over after returning from main or has at
least a touch of logic and consistency (which continuing to execute the
next function in memory doesn't have). And that's one thing I expect from a
compiler: don't do any funky things I didn't explicitly ask for...

So maybe look at it that way: rather than seeing the starting over as
"cottonwool", you could see the execution of arbitrary code in memory as
the compiler doing things it wasn't asked to do -- which it never should
do. I see the prevention of doing arbitrary things it wasn't asked to do as
a higher priority than the removal of "cottonwool" -- if there is a
conflict between the two.

Gerhard
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@084849 by Herbert Graf

flavicon
face
On Mon, 2004-10-04 at 04:32, Alan B. Pearce wrote:
> >My personal preference is that the compiler didn't do
> >more then it was asked of. There is no such this as
> >"exiting main" on the PIC, to define a behaviour is
> >simply silly since it SHOULD NEVER HAPPEN.
>
> True, but only in that using C on a PIC (or any other microcontroller) is a
> hack, in that the C standard allows main() to return, and so some provision
> needs to be made to allow for things to not blow up.

No, the standard only says the behaviour must be defined. Something like
a compiler time warning would probably be enough, and far more
appropriate.

> >Sloppy coding is the ONLY reason something like this
> >would happen, and the compiler "fixing" sloppy coding
> >is what I'm really against.
>
> This sounds like someone who never makes errors in their code talking.

Nope.

> Personally I find the "fix" for falling out of main() reasonable, in that in
> most circumstances it causes the PIC code to do a failsafe operation instead
> of (possibly) falling through to code that could damage hardware (think in
> terms of turning on all arms of an H-bridge). Agreed you were talking in
> terms of this particular minimalist program, but it does show that the
> compiler designer has done something to "fail safe" in the event of a
> mistype in the source code. That would surely make me add some brownie
> points for that compiler if looking at compiler options.

Failsafe huh? How do you know the init sequence called from main in some
program doesn't do something "dangerous" to external hardware if
repeated? How about something as simple as writing something to EEPROM
during init, this "loop forever" could end up killing the write
endurance of your EEPROM, while if nothing were done the code might hit
a sleep. There is NOTHING fail safe about this silly idea.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@090007 by Herbert Graf

flavicon
face
On Mon, 2004-10-04 at 08:37, Gerhard Fiedler wrote:
> > [[And never want C to stop you falling out of  main() ever again :-) ]]
>
> While I agree with all you wrote about the flight incident, I pretty much
> doubt it happened because a C compiler stopped a program from falling out
> of main :)
>
> Seriously, I don't think anyone here advocates falling out of main in an
> embedded C program as a programming technique. This already shows that
> whatever the compiler does in such a situation shouldn't affect a properly
> written program. (Which means that all who only write properly written
> programs really don't have to bother about this. :)

Fine, consider this: someone designs a program and forgets that main
could "exit". This program uses a watchdog, and during testing the
program APPEARS to reset when things go wrong in simulation although
they forgot to turn on the WDT. Then, in the real chip, boom, the
h-bridge blows.

Or, consider this: someone writes a program with main ending. During
simulation they see their code properly being reset by the process they
expected (a watchdog or something else) when in actuality that's NOT
happening. Then, because of some compiler issue let's say, they change
compilers. Mod the code for the new compiler and go with it. Hitch? The
new compiler doesn't do have this silly "goto after end of main". All of
a sudden the product no longer works. What gets blamed? The new
compiler. What SHOULD have gotten blamed? The old compiler+ the
programmer who didn't program right in the first place.

My "problem" with this sort of "feature" is it tends to HIDE PROBLEMS IN
CODE. Main "ending" is a hard enough bug to find if you're not looking
for it, imagine how much harder it becomes if the compiler hides the
fact from you that there IS a problem??

Go with what you like, but my day job often involves fighting compiler
bugs, and in my hobby time the hitech tool has bit me twice now with
bugs. I HATE wasting my time figuring out that the bug I'm hunting turns
out to be the tool, and not my design.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@092725 by Russell McMahon

face
flavicon
face
>> [[And never want C to stop you falling out of  main() ever again :-) ]]

> While I agree with all you wrote about the flight incident, I pretty much
> doubt it happened because a C compiler stopped a program from falling out
> of main :)

I agree. And it's not what I meant of course :-)

My point was that in the case of the C compiler the makers have identified
STANDARD behaviour which they deem to be undesirable and dangerous and have
implemented a NON STANDARD fix to keep the user safe from themselves. A
compile time warning message would have served much the same job if it was
deemed desirable to protect the user in this way.

In the case of the Airbus (if we are to believe that version of the story)
the program writers (and presumably the system definers & implementers)
deemed it appropriate to hobble the aircraft's capabilities below that which
a competent pilot knew it had, in order, presumably, to protect the aircraft
from damage. No or not enough thought was given to giving the pilot the
ability to override the system in the event that he deemed the computers to
be out to lunch. When he did there was nothing that he could do to terminate
their lunch break.

Both are arguably examples of similar thinking on the part of the system
implementors. In one case it leads to a minor annoyance. In the other to the
loss of an aircraft and 3 lives.



       Russell McMahon


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@101517 by Wouter van Ooijen

face picon face
> My "problem" with this sort of "feature" is it tends to HIDE
> PROBLEMS IN
> CODE. Main "ending" is a hard enough bug to find if you're not looking
> for it, imagine how much harder it becomes if the compiler hides the
> fact from you that there IS a problem??

So what do you propose the compiler to insert after the main? It can't
honk a horn unless you connect one, so I see a few alternatives: 'idle:
goto idle', 'sleep' (maybe even 'idle: sleep; goto sleep'), 'goto 0'.
Doing nothing will in most cases be the same as 'goto 0' because the
all-ones opcode on most PICs will simply execute untill the PC wrapsa
round to 0. As far as I can see each alternative will hide some
problems.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@101518 by Wouter van Ooijen

face picon face
> No, the standard only says the behaviour must be defined.
> Something like
> a compiler time warning would probably be enough, and far more
> appropriate.

Detecting whether a program will return from main is in general a
computationally undecideable problem, so a warning is not a general
solution. I don't say a warning is not a good idea, just that even with
such a warning the compiler writer must still decide what to do after
main. My Jal compiler appends an 'idle: goto idle' after the main code.
Maybe it removes it when the main happens to be a forever loop, I
forgot.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@110446 by Alan B. Pearce

face picon face
>My point was that in the case of the C compiler the
>makers have identified STANDARD behaviour which they
>deem to be undesirable and dangerous and have implemented
>a NON STANDARD fix to keep the user safe from themselves.

Not sure that it is a "non-standard fix". I prefer to think of it as
"defining the behaviour" in the words of Herbert's email a couple back on
this thread.

However I can also see that it would be even nicer to have the ability to
"define the behaviour" yourself, i.e. override the default behaviour, to
something that may be more suited to ones work practices, or to reduce the
possibility of problems like Herbert suggests due to continuous "resetting".

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@112330 by Herbert Graf

flavicon
face
On Mon, 2004-10-04 at 10:15, Wouter van Ooijen wrote:
> > My "problem" with this sort of "feature" is it tends to HIDE
> > PROBLEMS IN
> > CODE. Main "ending" is a hard enough bug to find if you're not looking
> > for it, imagine how much harder it becomes if the compiler hides the
> > fact from you that there IS a problem??
>
> So what do you propose the compiler to insert after the main? It can't
> honk a horn unless you connect one, so I see a few alternatives: 'idle:
> goto idle', 'sleep' (maybe even 'idle: sleep; goto sleep'), 'goto 0'.
> Doing nothing will in most cases be the same as 'goto 0' because the
> all-ones opcode on most PICs will simply execute untill the PC wrapsa
> round to 0. As far as I can see each alternative will hide some
> problems.

As is the case with the simple 2 line program you are right, doing
nothing will have the same effect as looping to the beginning.

But doing nothing is FAR more useful in the case of having more then
just a two line program. Operation will show a huge amount of craziness
going on, and when I see craziness of that proportion happening
(routines being run out of nowhere) I would start to suspect having done
something done like that.

Looping back to start OTOH, if I didn't know the compiler did it, would
instead have me hunting "PIC reboots randomly" issues, which are far
from obvious to hunt down (flaky power supply, noise on reset pin, watch
dog going, etc.), and chances are I would waste many hours hunting down
a problem who's symptoms were changed because some person decided their
compiler did something non obvious.

Imagine a doctor trying to diagnose what the problem is when your little
toe hurting is a symptom of a heart attack because the pill the patience
was taking changed the symptom (which the doctor didn't know) from
"chest pain" to "little toe hurting"...

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@120257 by Wouter van Ooijen

face picon face
> However I can also see that it would be even nicer to have
> the ability to
> "define the behaviour" yourself, i.e. override the default
> behaviour,

You can, in your C code. Or rather, you rather: you can prevent that the
behaviour takes effect. It seems a bit silly that you would want to
define behaviour in a non-standard way (pragma?, command line option?,
waving a fish?) that you can control quite well in C by not letting the
main terminate. Or write your 'void my_main( void )', have the real main
call it, and you can insert after that call whatever you find
appropriate.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@164530 by Wouter van Ooijen

face picon face
> Looping back to start OTOH, if I didn't know the compiler did
> it, would
> instead have me hunting "PIC reboots randomly" issues, which are far
> from obvious to hunt down (flaky power supply, noise on reset
> pin, watch
> dog going, etc.), and chances are I would waste many hours
> hunting down
> a problem who's symptoms were changed because some person
> decided their
> compiler did something non obvious.

So I guess you are advising the 'jump to the start' approach because
that is more likely to draw the attention of the programmer? Or are you
arguing for the 'endless loop' (or sleep?) because that is more likely
to result in a safe situation? A compiler writer can't do with just a
bunch of words, he needs a clear choice.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@173040 by Herbert Graf

flavicon
face
On Mon, 2004-10-04 at 16:45, Wouter van Ooijen wrote:
> > Looping back to start OTOH, if I didn't know the compiler did
> > it, would
> > instead have me hunting "PIC reboots randomly" issues, which are far
> > from obvious to hunt down (flaky power supply, noise on reset
> > pin, watch
> > dog going, etc.), and chances are I would waste many hours
> > hunting down
> > a problem who's symptoms were changed because some person
> > decided their
> > compiler did something non obvious.
>
> So I guess you are advising the 'jump to the start' approach because
> that is more likely to draw the attention of the programmer? Or are you
> arguing for the 'endless loop' (or sleep?) because that is more likely
> to result in a safe situation?

Neither. My position is the compiler shouldn't be doing anything that I
don't ask of it. Either of these "solutions" are something I don't ask
the compiler to do.

> A compiler writer can't do with just a
> bunch of words, he needs a clear choice.

Exactly, and IMHO the only choice he should make is to do NOTHING
special.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@181206 by Wouter van Ooijen

face picon face
> > A compiler writer can't do with just a
> > bunch of words, he needs a clear choice.
>
> Exactly, and IMHO the only choice he should make is to do NOTHING
> special.

You can't sneak out of this. Assuming the main() is at the end of the
code and does not end with a return (both are normal practice) doing
nothing has the same effect as jumping to 0. So like it or not, that is
the effect you are choosing.

Or when the compiler happens to arrange the code in a different way,
your choice is to jump into the function that happens to be after the
main(). Which could be a different function, depending on the version of
the compiler (if you are lucky) or on the phase of the moon and/or
things involving dead fish (if you are less lucky).

IMHO both 'goto $' and 'goto 0' are better choices. I prefer 'goto $',
but 'goto 0' is still much better than completely undefined behaviour.
Which isn't even allowd by the C standard. Luckily I wrote the Jal
'standard' myself so I could make the 'goto $' part of the definition :)
(mental note: did I?)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@193924 by Andrew Warren

flavicon
face
Wouter van Ooijen <.....piclistspam_OUTspammit.edu> wrote:

> IMHO both 'goto $' and 'goto 0' are better choices.

   It's too bad that neither of those choices is guaranteed to work
   in a consistent way across all applications and/or PICs:

   "GOTO $" means "loop here forever"... But only if the watchdog
   timer is disabled.

   "CLRWDT / GOTO $-1" or "CLRWDT / BRA $-1" fixes that problem...
   Except that on PICs with interrupts, the meaning is closer to
   "loop here some of the time, but spend the rest of your time
   executing interrupt-service routines that may or may not be aware
   that the foreground loop is no longer running".

   "GOTO 0" usually means "restart"... But not on any PIC whose
   reset vector is at $1FF, $3FF, or $7FF.

   Even SLEEP behaves inconsistently:  On some PICs, a wakeup event
   makes the PIC jump to the reset vector; on others, the PIC jumps
   to the interrupt vector or, if interrupts are disabled, to the
   address following the SLEEP instruction.

   -Andy

=== Andrew Warren -- TakeThisOuTaiw.....spamTakeThisOuTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@194709 by Herbert Graf

flavicon
face
On Mon, 2004-10-04 at 18:12, Wouter van Ooijen wrote:
> > Exactly, and IMHO the only choice he should make is to do NOTHING
> > special.
>
> You can't sneak out of this.

I'm not "sneaking" out of anything and I resent the suggestion you are
making.

> Assuming the main() is at the end of the
> code and does not end with a return (both are normal practice) doing
> nothing has the same effect as jumping to 0.

That's a pretty BIG assumption.

> So like it or not, that is
> the effect you are choosing.

Sometimes yes, I don't deny that.

> Or when the compiler happens to arrange the code in a different way,
> your choice is to jump into the function that happens to be after the
> main(). Which could be a different function, depending on the version of
> the compiler (if you are lucky) or on the phase of the moon and/or
> things involving dead fish (if you are less lucky).

Exactly, which would be a symptom so obvious that I'd investigate having
done something as blatantly wrong as letting main return.

> IMHO both 'goto $' and 'goto 0' are better choices.

Yes, that's your opinion, which we already were aware of. Do you now
understand that I have a different opinion?

> I prefer 'goto $',
> but 'goto 0' is still much better than completely undefined behaviour.
> Which isn't even allowd by the C standard.

Depends on your definition of "defined" behaviour. I'm not convinced
doing nothing isn't "allowed" by the standard. Of course the point is
moot, there are MANY things in PIC compilers that don't conform to the
standard.


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@212439 by steve

flavicon
face
> > IMHO both 'goto $' and 'goto 0' are better choices.
>     It's too bad that neither of those choices is guaranteed to work
>     in a consistent way across all applications and/or PICs:

The whole discussion is bordering on the insane, IMHO.

The discussion is based on what is the "correct" thing to do after the
user has made an error (ie. provided an execution path past the closing
brace).

To me, an analogy would be driving past the stop sign and off the end of
the pier and considering it a bug if the airbags deployed, rather than the
windows winding up ?

Steve.



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@213945 by Ivan Kocher

flavicon
face
Have you tried to check if it a problem with the "memory break", that
goes from:
       000005:  2bfa  goto     0x3fa
       0003fa:  1683  bsf      0x3, 0x5
maybe the programing software has a bug around here.

Or with this part, at the end of memory
       0003ff:  2bff  goto     0x3ff


Just wondering... it is a bug, but of 0x0d0a stuff or due to the memory
breaks the hex file has?



Ivan Kocher
---------------

Adam Woodworth wrote:
{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\04@214153 by piclist

flavicon
face
On Mon, 4 Oct 2004, Herbert Graf wrote:

> Depends on your definition of "defined" behaviour. I'm not convinced
> doing nothing isn't "allowed" by the standard.

I would agree that an implementation's behavior could be defined as
"execution continues with whatever instructions or data happen to
follow main() in memory, which may cause hardware damage or formatting
of your hard drive if located with 2 meters of the PIC."  But I'd be
surprised to see someone in the business of selling compilers think
such an implementation was appropriate.

In any event, you're generally in control of your startup code and
can do what you like.

> Of course the point is
> moot, there are MANY things in PIC compilers that don't conform to the
> standard.

Can you name more than one regarding the compiler under discussion?

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@000123 by William Chops Westfield

face picon face
On Oct 4, 2004, at 6:00 AM, Herbert Graf wrote:

>> I pretty much doubt it happened because a C compiler stopped
>> a program from falling out of main :)
>>
I dunno what the C compiler ought to do.  Starting over is one
possibility
that makes some sense; as long as its documented pretty clearly, I think
it would be OK.  The other reasonable thing to do is a tight loop
forever.
If watchdog is enabled, that would eventually cause a restart as well.
If not, it'll just sit there.  Just sitting there is more intuitive,
perhaps, but it's not clear that it's a better solution.  You have no
idea whether IO is in a reasonable or safe state at that point.  One
advantage of restarting is that things might have settled into a state
that no longer results in the program running off the end of main.
Sitting in one place is NEVER the right thing; one just hopes it is
more easily noticed during development.

We have this debate internaly rather periodicaly.  If a router exhausts
its memory, should it crash and reload, or sit there spewing error
messages
and diagnostics so someone will notice and figure out WHY its broken?
The answer isn't obvious, and isn't always the same.  If you run out of
memory as part simply because there isn't enough (say, you want to fit
100000 routes in memory that will only hold 80000), restarting is not
very helpful - you just get to the same point again, and crash again.
(OTOH, that would probably be noticed :-)  If instead you run out of
memory because some coding error results in a slow leak that uses up
memory in 2 months, then restarting permits relatively normal operation
for another 2 months...

BillW

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@024145 by Wouter van Ooijen

face picon face
> Exactly, which would be a symptom so obvious that I'd
> investigate having
> done something as blatantly wrong as letting main return.

But you can not rely on that symptom. Murphy rules, so it will probably
not manifest itself during or debugging, to pop up only when 5 y later a
junior programmer changes dome delay from 1 ms to 2 ms.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@024145 by Wouter van Ooijen

face picon face
> The whole discussion is bordering on the insane, IMHO.

Not from the perspective of a compiler writer, who has to choose between
doing nothing or doing one of the alternaives (or come up with a new
variation).

{Quote hidden}

A pier safety engineer would have to choose between a very rigid wall at
the end (will stop the car, possibly killing all accupants) or a weak
wall (will not kill the occupants, but the drop down might).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@034235 by Jan-Erik Soderholm

face picon face
> > > Exactly, and IMHO the only choice he should make is to do NOTHING
> > > special.

Hi.

IMHO, it doesn't realy matters what the compiler designer decides on, as long
as he *does* make an decision and clearly write it down in the docs.
An "undefined" behaviour is, IMHO, the worst solution...

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@080609 by Gerhard Fiedler

picon face
> The answer isn't obvious, and isn't always the same.  If you run out of
> memory as part simply because there isn't enough (say, you want to fit
> 100000 routes in memory that will only hold 80000), restarting is not
> very helpful - you just get to the same point again, and crash again.

Couldn't the router send out an error message before restarting, as the
restart is in this case rather organized? Then it wouldn't remain unnoticed
why there was a restart.

> If instead you run out of memory because some coding error results in a
> slow leak that uses up memory in 2 months, then restarting permits
> relatively normal operation for another 2 months...

And again, an error message could show that event.

In any case I think a helpful error indication when possible and some kind
of defined behavior is usually preferable to just executing random code.
And since most embedded devices have startup code that makes sure they are
in a safe operating state, restarting in case anything odd happens seems to
be the safe thing to do. (That's why it is this what the watchdog timer
usually does... so why not apply the same line of thought for other
irregularities?)

Gerhard
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@084213 by Gerhard Fiedler

picon face
> My point was that in the case of the C compiler the makers have identified
> STANDARD behaviour which they deem to be undesirable and dangerous and have
> implemented a NON STANDARD fix to keep the user safe from themselves.

I'm not really sure myself of what the "STANDARD" says, but it has been
stated here (and not contested) that restarting after main is compliant
with the ANSI C standard if there's nothing main could return to. I don't
think that executing random code is defined as standard behavior.

So I don't really understand where you take your "STANDARD" vs. "NON
STANDARD" from.

To summarize the options:
- Do nothing (which is "doing something", and the "something" in this case
is "execute arbitrary code"). This results either in a similar behavior
(restart from 0) if there's nothing after main in memory, or it results in
random code being executed (whatever the linker placed after main, which is
not defined and could be something different every time you compile --
according to the standard).
- An endless loop. In case you use a WDT, it results in again a similar
behavior (restart from 0). In case you don't, interrupt routines may do
funky things and I'm not sure whether in all cases the real cause would be
that simple to determine from the symptoms.
- Restarting. The Hi-Tech compiler doesn't just jump to 0, it inserts a
"goto start". start is the label of the compiler's startup code; that's
after the user-supplied powerup code. Which makes sense, as this isn't
really a powerup event. In any case, this is the only option that behaves
consistently (independently of the exact location from where to restart).
And that's something I cherish in a compiler, and usually helps debugging
things.

Someone said that this may cost many hours of debugging, because he would
check all kinds of other things. Well, add "check main loop" to your check
list of what to look at when you have repeated apparent resets (it should
be in that list in any case, given the above collection of possible
symptoms), and you're done with it rather quickly.

You called this a "minor annoyance". I call this a "sensible design", given
the alternatives ... :)


> A compile time warning message would have served much the same job if it
> was  deemed desirable to protect the user in this way.

This would definitely be a worthwhile enhancement, IMO, and not cost much
-- the Hi-Tech compiler already "knows" whether it's missing or not,
because it only inserts the "goto start" if an endless loop is missing in
main.

Gerhard
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@091201 by Herbert Graf

flavicon
face
On Tue, 2004-10-05 at 02:41, Wouter van Ooijen wrote:
> > Exactly, which would be a symptom so obvious that I'd
> > investigate having
> > done something as blatantly wrong as letting main return.
>
> But you can not rely on that symptom.

No, but at least I have a chance the compiler isn't going to CHANGE the
symptom on me.

> Murphy rules, so it will probably
> not manifest itself during or debugging, to pop up only when 5 y later a
> junior programmer changes dome delay from 1 ms to 2 ms.

Hehe, at that point I probably won't care anymore....

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@091326 by Herbert Graf

flavicon
face
On Tue, 2004-10-05 at 03:42, Jan-Erik Soderholm wrote:
> > > > Exactly, and IMHO the only choice he should make is to do NOTHING
> > > > special.
>
> Hi.
>
> IMHO, it doesn't realy matters what the compiler designer decides on, as long
> as he *does* make an decision and clearly write it down in the docs.
> An "undefined" behaviour is, IMHO, the worst solution...

Hmm, I agree, and I guess that's what rattles me most, maybe I missed it
in the docs, but I've never seen this behaviour laid out.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@124748 by William Chops Westfield

face picon face
On Oct 5, 2004, at 5:06 AM, Gerhard Fiedler wrote:
>
> Couldn't the router send out an error message before restarting, as the
> restart is in this case rather organized? Then it wouldn't remain
> unnoticed
> why there was a restart.
>
Oh, it tries.  A message probably goes to the console, which is probably
unattended and might not even be connected to anything.  It probably
tries
to send messages via assorted methods to assorted network destinations,
if
they are configured, but those are less likely to succeed if the box has
run out of memory.  Furthermore, "last crash" info is saved and can be
seen via assorted commands after the router has reloaded.  There are
lots of ways to see the bad things that have happened, if you're
watching,
but nothing says "I'm broken" quite like sitting there doing nothing :-)

BillW

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@133020 by Jan-Erik Soderholm

face picon face
William "Chops" Westfield wrote :

> On Oct 5, 2004, at 5:06 AM, Gerhard Fiedler wrote:
> >
> > Couldn't the router send out an error message before
> > restarting...
> >
> Oh, it tries.  A message probably goes to the console, which
> is probably unattended and might not even be connected to
> anything.

So, what you are saying is that the router is well designed, but
it runs in an  unprofessional managed environment. Now,
what could the router software programmer do about that ?

> but nothing says "I'm broken" quite like sitting there doing
> nothing :-)

You could always ask the users sitting at their workstations with
a dead network what they think...

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@152139 by Wouter van Ooijen

face picon face
> No, but at least I have a chance the compiler isn't going to
> CHANGE the symptom on me.

But it will! It will rearrange the code for the various functions in
memory according to either the phase of the moon or the results of the
latest presidential election.

> > Murphy rules, so it will probably
> > not manifest itself during or debugging, to pop up only
> when 5 y later a
> > junior programmer changes dome delay from 1 ms to 2 ms.
>
> Hehe, at that point I probably won't care anymore....

Unless you have been promoted to be the junior's boss.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\05@155834 by Herbert Graf

flavicon
face
On Tue, 2004-10-05 at 15:21, Wouter van Ooijen wrote:
> > No, but at least I have a chance the compiler isn't going to
> > CHANGE the symptom on me.
>
> But it will! It will rearrange the code for the various functions in
> memory according to either the phase of the moon or the results of the
> latest presidential election.

It's not going to change the symptom to something predetermined.

For example, often this sort of problem can be detected by the symptom
changing based on the position of the code. For example, when you have
an errant pointer in C the symptom of the problem will usually change
depending on whether you have a piece of unrelated code above or below a
certain area. Having seen this sort of behaviour I automatically think:
hmm, that sounds like an errant pointer.

In this case, by CHANGING the behaviour to "restart the program every
time" I wouldn't catch on as quickly to that being the problem, I'm much
more likely to investigate "the pic is resetting randomly", which would
cause alot of wasted time.

Again, if there were a CLEAR message that the compiler was doing this I
wouldn't be raising much of a fuss, it's the fact that it's not well
explained that irks me.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...