> 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.brownKILLspamclear.net.nz
>
>
> _______________________________________________
> http://www.piclist.com
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

> 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:
>
>
>>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:  @spam@brent.brownKILLspamclear.net.nz
>>
>>
>>_______________________________________________
>>http://www.piclist.com
>>View/change your membership options at
>>mailman.mit.edu/mailman/listinfo/piclist
>>
>
>
> _______________________________________________________________________
>   Adam Woodworth
>   SMTP : KILLspamadamKILLspammirkwood.com
>   HTTP : http://www.mirkwood.com
>   HAM  : N1ZNN
> _______________________________________________
> http://www.piclist.com
> View/change your membership options at
> mailman.mit.edu/mailman/listinfo/piclist
>

> 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:
> > 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:
> >
> >
> >>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:  RemoveMEbrent.brownEraseMEEraseMEclear.net.nz
> >>
> >>
> >>_______________________________________________
> >>http://www.piclist.com
> >>View/change your membership options at
> >>mailman.mit.edu/mailman/listinfo/piclist
> >>
> >
> >
> > _______________________________________________________________________
> >   Adam Woodworth
> >   SMTP : RemoveMEadamspam_OUTKILLspammirkwood.com
> >   HTTP : http://www.mirkwood.com
> >   HAM  : N1ZNN
> > _______________________________________________
> > http://www.piclist.com
> > View/change your membership options at
> > mailman.mit.edu/mailman/listinfo/piclist
> >
>
> _______________________________________________
> http://www.piclist.com
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

>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:
>
>  
>
>>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:
>>    
>>
>>>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:
>>>
>>>
>>>      
>>>
>>>>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:  EraseMEbrent.brownspamspamBeGoneclear.net.nz
>>>>
>>>>
>>>>_______________________________________________
>>>>http://www.piclist.com
>>>>View/change your membership options at
>>>>mailman.mit.edu/mailman/listinfo/piclist
>>>>
>>>>        
>>>>
>>>_______________________________________________________________________
>>>  Adam Woodworth
>>>  SMTP : RemoveMEadamKILLspammirkwood.com
>>>  HTTP : http://www.mirkwood.com
>>>  HAM  : N1ZNN
>>>_______________________________________________
>>>http://www.piclist.com
>>>View/change your membership options at
>>>mailman.mit.edu/mailman/listinfo/piclist
>>>
>>>      
>>>
>>_______________________________________________
>>http://www.piclist.com
>>View/change your membership options at
>>mailman.mit.edu/mailman/listinfo/piclist
>>
>>    
>>
>
>_______________________________________________________________________
>  Adam Woodworth
>  SMTP : adamSTOPspamspam_OUTmirkwood.com
>  HTTP : http://www.mirkwood.com
>  HAM  : N1ZNN
>_______________________________________________
>http://www.piclist.com
>View/change your membership options at
>mailman.mit.edu/mailman/listinfo/piclist
>  
>

> 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:
>
>
>>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
>>---------------
>>

> 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
> mailman.mit.edu/mailman/listinfo/piclist
>

> > 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

>
> ...Just an observation.
>
> -Shawn
>
>
>
> Adam Woodworth wrote:
>
> >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:
> >
> >
> >
> >>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:
> >>
> >>
> >>>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:
> >>>
> >>>
> >>>
> >>>
> >>>>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:  spamBeGonebrent.brownSTOPspamEraseMEclear.net.nz
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>http://www.piclist.com
> >>>>View/change your membership options at
> >>>>mailman.mit.edu/mailman/listinfo/piclist
> >>>>
> >>>>
> >>>>
> >>>_______________________________________________________________________
> >>>  Adam Woodworth
> >>>  SMTP : KILLspamadamspamBeGonemirkwood.com
> >>>  HTTP : http://www.mirkwood.com
> >>>  HAM  : N1ZNN
> >>>_______________________________________________
> >>>http://www.piclist.com
> >>>View/change your membership options at
> >>>mailman.mit.edu/mailman/listinfo/piclist
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>http://www.piclist.com
> >>View/change your membership options at
> >>mailman.mit.edu/mailman/listinfo/piclist
> >>
> >>
> >>
> >
> >_______________________________________________________________________
> >  Adam Woodworth
> >  SMTP : EraseMEadamEraseMEmirkwood.com
> >  HTTP : http://www.mirkwood.com
> >  HAM  : N1ZNN
> >_______________________________________________
> >http://www.piclist.com
> >View/change your membership options at
> >mailman.mit.edu/mailman/listinfo/piclist
> >
> >
>
> _______________________________________________
> http://www.piclist.com
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

>>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 : TakeThisOuTadamKILLspamspammirkwood.com
>   HTTP : http://www.mirkwood.com
>   HAM  : N1ZNN
> _______________________________________________
> http://www.piclist.com
> View/change your membership options at
> mailman.mit.edu/mailman/listinfo/piclist
>

> 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 ?