Post by thread:[PIC] CC5X errors

It does exist at the location where the -I flag points to, and is readable. I have programed PICs (only F84 and F628) only in assembler before. I have already written a version of working program in assembler. Now I want to write the same logic in C. I want to see how the two compare. I am not new to C but I am new to programming microcontrollers in C. --- Jan-Erik Soderholm <spam_OUTjan-erik.soderholmTakeThisOuTtelia.com> wrote: {Quote hidden}> Hasan A. Khan wrote : > > > Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" > > SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program > > Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc > > Error : Unable to open file 'reloc.inc' > > > > why can't the compiler find it? > > Does it exist at all ? > > Jan-Erik. > > PS: > You also wrote : > " One thing I learned was that I didn't have to use > assembler..." > > No, but why not ? > You are using a 16F628. Not that much memory. And > you'll > probaby learn the chip faster with assembler then > with C. > Have you written anything in (PIC) assembler ? > > > > --

I did not have a problem like that installing into mplab 6.60 and building sample1. I did not see reloc.lnk in the default command string, though. Why do you need the options in a file? Go into project/build options and uncheck "options on file". Include any options from the file in the "additional command line options" box. However, I get an error based on the hex format I select: the default, INHX8M, generates a hex file but mplab says: the hex file not written because the format extension is not recognized (but the hex file was actually generated). All 3 other hex formats cause cc5x to fail to build. Since I currently don't use an mplab compatible programmer, its sort of ok (for free) but I can't use the simulator and may get a compatible programmer some day. I don't think I'd pay money for it unless I can resolve this error. Anyone got any ideas? --- "Hasan A. Khan" <.....hasanKILLspam@spam@khansden.com> wrote: {Quote hidden}> Hi, > As a new comer to this list, I have been read this > list for a while now and its been a great help. One > thing I learned was that I didn't have to use > assembler and there is a free C compiler CC5X. I > immediately installed in MPLAB and tried the > samples. > All my excitement vanished when it failed the first > time and it still failing. When I compile the file > sample1.c I get the following error > > Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" > SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program > Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc > Error : Unable to open file 'reloc.inc' > > Error options: -ew: no warning details -ed: no > error > details -eL: list details > > I have set up the incpath correctly in mplab, I > think. > I have not turned on the + flag in 'build options' > so > why is +reloc.inc showing up in the compile line and > why can't the compiler find it? > > Thanks for any help. > > > > -Hasan > --

While I prefer to understand the chip to a depth that only asm allows, it is completely valid that some one whould prefer to code in C. The benefits of C are very real. As part of evaluating cc5x, I rewrote my driveway sensor logger code in C (ds1302-SPI, relay, serial I/O). It took all of about 3 hours vs the 2 days to do the asm version (and I borrowed a lot of asm code from previous projects). Granted, some time was saved because I was writing the program the second time but not having to worry about details like the screwy conditional instructions of the PIC is a big benefit. Phil --- Jan-Erik Soderholm <jan-erik.soderholmKILLspamtelia.com> wrote: {Quote hidden}> Hasan A. Khan wrote : > > > Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" > > SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program > > Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc > > Error : Unable to open file 'reloc.inc' > > > > why can't the compiler find it? > > Does it exist at all ? > > Jan-Erik. > > PS: > You also wrote : > " One thing I learned was that I didn't have to use > assembler..." > > No, but why not ? > You are using a 16F628. Not that much memory. And > you'll > probaby learn the chip faster with assembler then > with C. > Have you written anything in (PIC) assembler ? > > > > --

I didn't put the +reloc.inc file on the command line! That was my original question. Why is this option showing up at all? In build options, 'options on file' is unchecked but it is still showing up. It is driving me nuts. --- phil B <.....philpiclistKILLspam.....yahoo.com> wrote: {Quote hidden}> I did not have a problem like that installing into > mplab 6.60 and building sample1. I did not see > reloc.lnk in the default command string, though. > Why > do you need the options in a file? Go into > project/build options and uncheck "options on file". > > Include any options from the file in the "additional > command line options" box. > > However, I get an error based on the hex format I > select: the default, INHX8M, generates a hex file > but > mplab says: the hex file not written because the > format extension is not recognized (but the hex file > was actually generated). All 3 other hex formats > cause cc5x to fail to build. Since I currently > don't > use an mplab compatible programmer, its sort of ok > (for free) but I can't use the simulator and may get > a > compatible programmer some day. I don't think I'd > pay > money for it unless I can resolve this error. > Anyone > got any ideas? > > --- "Hasan A. Khan" <EraseMEhasanspam_OUTTakeThisOuTkhansden.com> wrote: > > Hi, > > As a new comer to this list, I have been read this > > list for a while now and its been a great help. > One > > thing I learned was that I didn't have to use > > assembler and there is a free C compiler CC5X. I > > immediately installed in MPLAB and tried the > > samples. > > All my excitement vanished when it failed the > first > > time and it still failing. When I compile the > file > > sample1.c I get the following error > > > > Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" > > SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program > > Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc > > Error : Unable to open file 'reloc.inc' > > > > Error options: -ew: no warning details -ed: no > > error > > details -eL: list details > > > > I have set up the incpath correctly in mplab, I > > think. > > I have not turned on the + flag in 'build > options' > > so > > why is +reloc.inc showing up in the compile line > and > > why can't the compiler find it? > > > > Thanks for any help. > > > > > > > > -Hasan > > --

You have seen the light... ;-) Cheers /Ake phil B wrote: {Quote hidden}>While I prefer to understand the chip to a depth that >only asm allows, it is completely valid that some one >whould prefer to code in C. The benefits of C are >very real. > >As part of evaluating cc5x, I rewrote my driveway >sensor logger code in C (ds1302-SPI, relay, serial >I/O). It took all of about 3 hours vs the 2 days to >do the asm version (and I borrowed a lot of asm code >from previous projects). Granted, some time was saved >because I was writing the program the second time but >not having to worry about details like the screwy >conditional instructions of the PIC is a big benefit. > >Phil > >--- Jan-Erik Soderholm <jan-erik.soderholmspam_OUTtelia.com> >wrote: > > >>Hasan A. Khan wrote : >> >> >> >>>Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" >>>SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program >>>Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc >>>Error : Unable to open file 'reloc.inc' >>> >>>why can't the compiler find it? >>> >>> >>Does it exist at all ? >> >>Jan-Erik. >> >>PS: >>You also wrote : >>" One thing I learned was that I didn't have to use >>assembler..." >> >>No, but why not ? >>You are using a 16F628. Not that much memory. And >>you'll >>probaby learn the chip faster with assembler then >>with C. >>Have you written anything in (PIC) assembler ? >> >> >> >>-

I am sure this topic has been discussed to death before but here are my two cents. Coming with a background in CS and higher level languages like C++/Java, I would always choose a high level language over assembler if given a choice, simply because people are much more productive in these languages. After understanding the chip, I can think of two reasons for using assemblers, higher speed and smaller code size...but then my experience with uCs is limited. --- phil B <@spam@philpiclistKILLspamyahoo.com> wrote: {Quote hidden}> While I prefer to understand the chip to a depth > that > only asm allows, it is completely valid that some > one > whould prefer to code in C. The benefits of C are > very real. > > As part of evaluating cc5x, I rewrote my driveway > sensor logger code in C (ds1302-SPI, relay, serial > I/O). It took all of about 3 hours vs the 2 days to > do the asm version (and I borrowed a lot of asm code > from previous projects). Granted, some time was > saved > because I was writing the program the second time > but > not having to worry about details like the screwy > conditional instructions of the PIC is a big > benefit. > > Phil > > --- Jan-Erik Soderholm > <KILLspamjan-erik.soderholmKILLspamtelia.com> > wrote: > > Hasan A. Khan wrote : > > > > > Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" > > > SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program > > > Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc > > > Error : Unable to open file 'reloc.inc' > > > > > > why can't the compiler find it? > > > > Does it exist at all ? > > > > Jan-Erik. > > > > PS: > > You also wrote : > > " One thing I learned was that I didn't have to > use > > assembler..." > > > > No, but why not ? > > You are using a 16F628. Not that much memory. And > > you'll > > probaby learn the chip faster with assembler then > > with C. > > Have you written anything in (PIC) assembler ? > > > > > > > > --

I probably saw the light before you were programming! I got hooked on C in 1976 on a PDP-11/45 running Unix V6. (it had 256K of RAM and supported 16 concurrent users. those were the days. sigh...). But there is no substitute for understanding the machine architecture. I still write lots of code in ASM. Sorry for helping the thread to veer OT... Phil --- Ake Hedman <RemoveMEakheTakeThisOuTeurosource.se> wrote: {Quote hidden}> > You have seen the light... ;-) > > Cheers > /Ake > > phil B wrote: > > >While I prefer to understand the chip to a depth > that > >only asm allows, it is completely valid that some > one > >whould prefer to code in C. The benefits of C are > >very real. > > > >As part of evaluating cc5x, I rewrote my driveway > >sensor logger code in C (ds1302-SPI, relay, serial > >I/O). It took all of about 3 hours vs the 2 days > to > >do the asm version (and I borrowed a lot of asm > code > >from previous projects). Granted, some time was > saved > >because I was writing the program the second time > but > >not having to worry about details like the screwy > >conditional instructions of the PIC is a big > benefit. > > > >Phil > > > >--- Jan-Erik Soderholm > <spamBeGonejan-erik.soderholmspamBeGonetelia.com> > >wrote: > > > > > >>Hasan A. Khan wrote : > >> > >> > >> > >>>Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" > >>>SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program > >>>Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc > >>>Error : Unable to open file 'reloc.inc' > >>> > >>>why can't the compiler find it? > >>> > >>> > >>Does it exist at all ? > >> > >>Jan-Erik. > >> > >>PS: > >>You also wrote : > >>" One thing I learned was that I didn't have to > use > >>assembler..." > >> > >>No, but why not ? > >>You are using a 16F628. Not that much memory. And > >>you'll > >>probaby learn the chip faster with assembler then > >>with C. > >>Have you written anything in (PIC) assembler ? > >> > >> > >> > >>--

Phil, You are right. I wrote my first code early 1980 so you beat me with four years. ;-) I also still write a lot of assembler still but not for any religious reasons. I just try to use the tool I think is best for the job at hand. For me it would be stupid to write all the code for a 18F258 in assembler. I can understand if one or maybe two K of it was in assembler because of some special needs. But as always this is up to the person doing the job. I can't see that one way or the other should be wrong even if I'm convinced that 32K C is easier to maintain and debug then 32K assembler. Sorry if I upset you in any way. It was not my intent! /Ake phil B wrote: {Quote hidden}>I probably saw the light before you were programming! >I got hooked on C in 1976 on a PDP-11/45 running Unix >V6. (it had 256K of RAM and supported 16 concurrent >users. those were the days. sigh...). > >But there is no substitute for understanding the >machine architecture. I still write lots of code in >ASM. > >Sorry for helping the thread to veer OT... > >Phil > >--- Ake Hedman <TakeThisOuTakheEraseMEspam_OUTeurosource.se> wrote: > > >>You have seen the light... ;-) >> >>Cheers >>/Ake >> >>phil B wrote: >> >> >> >>>While I prefer to understand the chip to a depth >>> >>> >>that >> >> >>>only asm allows, it is completely valid that some >>> >>> >>one >> >> >>>whould prefer to code in C. The benefits of C are >>>very real. >>> >>>As part of evaluating cc5x, I rewrote my driveway >>>sensor logger code in C (ds1302-SPI, relay, serial >>>I/O). It took all of about 3 hours vs the 2 days >>> >>> >>to >> >> >>>do the asm version (and I borrowed a lot of asm >>> >>> >>code >>>from previous projects). Granted, some time was >>saved >> >> >>>because I was writing the program the second time >>> >>> >>but >> >> >>>not having to worry about details like the screwy >>>conditional instructions of the PIC is a big >>> >>> >>benefit. >> >> >>>Phil >>> >>>--- Jan-Erik Soderholm >>> >>> >><RemoveMEjan-erik.soderholmTakeThisOuTtelia.com> >> >> >>>wrote: >>> >>> >>> >>> >>>>Hasan A. Khan wrote : >>>> >>>> >>>> >>>> >>>> >>>>>Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" >>>>>SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program >>>>>Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc >>>>>Error : Unable to open file 'reloc.inc' >>>>> >>>>>why can't the compiler find it? >>>>> >>>>> >>>>> >>>>> >>>>Does it exist at all ? >>>> >>>>Jan-Erik. >>>> >>>>PS: >>>>You also wrote : >>>>" One thing I learned was that I didn't have to >>>> >>>> >>use >> >> >>>>assembler..." >>>> >>>>No, but why not ? >>>>You are using a 16F628. Not that much memory. And >>>>you'll >>>>probaby learn the chip faster with assembler then >>>>with C. >>>>Have you written anything in (PIC) assembler ? >>>> >>>> >>>> >>>>--

gee, didn't mean to come across as upset - far from it! I got a chuckle out of it. I've written a ton of PIC assembler and am getting tired of getting the btfsx sense wrong or being in the wrong bank. That's why I use the simulator on little snippets of code - too make sure I got it right. PICs are amazing but the instruction set basically sucks. A C compiler really does make it a lot easier for the average programmer. btw, my first code was Basic on an RCA Spectra 70 in 1971 but I really dont count that as programming. --- Ake Hedman <akheEraseME.....eurosource.se> wrote: {Quote hidden}> Phil, > > You are right. I wrote my first code early 1980 so > you beat me with four > years. ;-) > > I also still write a lot of assembler still but not > for any religious > reasons. I just try to use the tool I think is best > for the job at > hand. For me it would be stupid to write all the > code for a 18F258 in > assembler. I can understand if one or maybe two K > of it was in > assembler because of some special needs. But as > always this is up to the > person doing the job. I can't see that one way or > the other should be > wrong even if I'm convinced that 32K C is easier to > maintain and debug > then 32K assembler. > > Sorry if I upset you in any way. It was not my > intent! > > /Ake > > phil B wrote: > > >I probably saw the light before you were > programming! > >I got hooked on C in 1976 on a PDP-11/45 running > Unix > >V6. (it had 256K of RAM and supported 16 > concurrent > >users. those were the days. sigh...). > > > >But there is no substitute for understanding the > >machine architecture. I still write lots of code > in > >ASM. > > > >Sorry for helping the thread to veer OT... > > > >Phil > > > >--- Ake Hedman <EraseMEakheeurosource.se> wrote: > > > > > >>You have seen the light... ;-) > >> > >>Cheers > >>/Ake > >> > >>phil B wrote: > >> > >> > >> > >>>While I prefer to understand the chip to a depth > >>> > >>> > >>that > >> > >> > >>>only asm allows, it is completely valid that some > >>> > >>> > >>one > >> > >> > >>>whould prefer to code in C. The benefits of C > are > >>>very real. > >>> > >>>As part of evaluating cc5x, I rewrote my driveway > >>>sensor logger code in C (ds1302-SPI, relay, > serial > >>>I/O). It took all of about 3 hours vs the 2 days > >>> > >>> > >>to > >> > >> > >>>do the asm version (and I borrowed a lot of asm > >>> > >>> > >>code > >>>from previous projects). Granted, some time was > >>saved > >> > >> > >>>because I was writing the program the second time > >>> > >>> > >>but > >> > >> > >>>not having to worry about details like the screwy > >>>conditional instructions of the PIC is a big > >>> > >>> > >>benefit. > >> > >> > >>>Phil > >>> > >>>--- Jan-Erik Soderholm > >>> > >>> > >><RemoveMEjan-erik.soderholmEraseMEEraseMEtelia.com> > >> > >> > >>>wrote: > >>> > >>> > >>> > >>> > >>>>Hasan A. Khan wrote : > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Executing: "C:\Program > Files\bknd\CC5X\CC5X.EXE" > >>>>>SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program > >>>>>Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc > >>>>>Error : Unable to open file 'reloc.inc' > >>>>> > >>>>>why can't the compiler find it? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Does it exist at all ? > >>>> > >>>>Jan-Erik. > >>>> > >>>>PS: > >>>>You also wrote : > >>>>" One thing I learned was that I didn't have to > >>>> > >>>> > >>use > >> > >> > >>>>assembler..." > >>>> > >>>>No, but why not ? > >>>>You are using a 16F628. Not that much memory. > And > >>>>you'll > >>>>probaby learn the chip faster with assembler > then > >>>>with C. > >>>>Have you written anything in (PIC) assembler ? > >>>> > >>>> > >>>> > >>>>-- >

Phil, For me it was only machine code for the first years. We used Fortran and some people used C on the Nord 100 at our physics department but I stick to the hex entry display on my self built 6800 system. I had some friends that had an Apple but I couldn't afford one but when the Commodore VIC-20 came I bought one and then Basic and Assembler for the wonderful 6502 was possible. I have never been that interested in the big systems and have done very little on them. The AVR is the best uP I ever worked with. The company is not. *Very* bad and *very* bad reps at least here in Sweden. The PIC is second best, the company is great, sample service is great. With the 18F and dsPIC C and other HLL works fine on them and for most people there is no need for anything else then the HLL. You still have to understand the details of the uP but the HLL also takes care of a lot of stuff for you. Just as it should. If you want complete understanding you should write machine code but I seldom here anyone suggestion that to someone new to the uP.... ;-) /Ake phil B wrote: {Quote hidden}>gee, didn't mean to come across as upset - far from >it! I got a chuckle out of it. I've written a ton of >PIC assembler and am getting tired of getting the >btfsx sense wrong or being in the wrong bank. That's >why I use the simulator on little snippets of code - >too make sure I got it right. PICs are amazing but >the instruction set basically sucks. A C compiler >really does make it a lot easier for the average >programmer. > >btw, my first code was Basic on an RCA Spectra 70 in >1971 but I really dont count that as programming. > >--- Ake Hedman <RemoveMEakhespam_OUTKILLspameurosource.se> wrote: > > > >>Phil, >> >>You are right. I wrote my first code early 1980 so >>you beat me with four >>years. ;-) >> >>I also still write a lot of assembler still but not >>for any religious >>reasons. I just try to use the tool I think is best >>for the job at >>hand. For me it would be stupid to write all the >>code for a 18F258 in >>assembler. I can understand if one or maybe two K >>of it was in >>assembler because of some special needs. But as >>always this is up to the >>person doing the job. I can't see that one way or >>the other should be >>wrong even if I'm convinced that 32K C is easier to >>maintain and debug >>then 32K assembler. >> >>Sorry if I upset you in any way. It was not my >>intent! >> >>/Ake >> >>phil B wrote: >> >> >> >>>I probably saw the light before you were >>> >>> >>programming! >> >> >>>I got hooked on C in 1976 on a PDP-11/45 running >>> >>> >>Unix >> >> >>>V6. (it had 256K of RAM and supported 16 >>> >>> >>concurrent >> >> >>>users. those were the days. sigh...). >>> >>>But there is no substitute for understanding the >>>machine architecture. I still write lots of code >>> >>> >>in >> >> >>>ASM. >>> >>>Sorry for helping the thread to veer OT... >>> >>>Phil >>> >>>--- Ake Hedman <RemoveMEakheTakeThisOuTspameurosource.se> wrote: >>> >>> >>> >>> >>>>You have seen the light... ;-) >>>> >>>>Cheers >>>>/Ake >>>> >>>>phil B wrote: >>>> >>>> >>>> >>>> >>>> >>>>>While I prefer to understand the chip to a depth >>>>> >>>>> >>>>> >>>>> >>>>that >>>> >>>> >>>> >>>> >>>>>only asm allows, it is completely valid that some >>>>> >>>>> >>>>> >>>>> >>>>one >>>> >>>> >>>> >>>> >>>>>whould prefer to code in C. The benefits of C >>>>> >>>>> >>are >> >> >>>>>very real. >>>>> >>>>>As part of evaluating cc5x, I rewrote my driveway >>>>>sensor logger code in C (ds1302-SPI, relay, >>>>> >>>>> >>serial >> >> >>>>>I/O). It took all of about 3 hours vs the 2 days >>>>> >>>>> >>>>> >>>>> >>>>to >>>> >>>> >>>> >>>> >>>>>do the asm version (and I borrowed a lot of asm >>>>> >>>>> >>>>> >>>>> >>>>code >>>>>from previous projects). Granted, some time was >>>>saved >>>> >>>> >>>> >>>> >>>>>because I was writing the program the second time >>>>> >>>>> >>>>> >>>>> >>>>but >>>> >>>> >>>> >>>> >>>>>not having to worry about details like the screwy >>>>>conditional instructions of the PIC is a big >>>>> >>>>> >>>>> >>>>> >>>>benefit. >>>> >>>> >>>> >>>> >>>>>Phil >>>>> >>>>>--- Jan-Erik Soderholm >>>>> >>>>> >>>>> >>>>> >>>><EraseMEjan-erik.soderholmspamspamBeGonetelia.com> >>>> >>>> >>>> >>>> >>>>>wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hasan A. Khan wrote : >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Executing: "C:\Program >>>>>>> >>>>>>> >>Files\bknd\CC5X\CC5X.EXE" >> >> >>>>>>>SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program >>>>>>>Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc >>>>>>>Error : Unable to open file 'reloc.inc' >>>>>>> >>>>>>>why can't the compiler find it? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Does it exist at all ? >>>>>> >>>>>>Jan-Erik. >>>>>> >>>>>>PS: >>>>>>You also wrote : >>>>>>" One thing I learned was that I didn't have to >>>>>> >>>>>> >>>>>> >>>>>> >>>>use >>>> >>>> >>>> >>>> >>>>>>assembler..." >>>>>> >>>>>>No, but why not ? >>>>>>You are using a 16F628. Not that much memory. >>>>>> >>>>>> >>And >> >> >>>>>>you'll >>>>>>probaby learn the chip faster with assembler >>>>>> >>>>>> >>then >> >> >>>>>>with C. >>>>>>Have you written anything in (PIC) assembler ? >>>>>> >>>>>> >>>>>> >>>>>>-- >

Still can't figure out the problem. I stoped compiling my C in mplab and I am using it only as an editor. I have fallen back to the good old days of batch/make files to build projects, for the time being. --- "Hasan A. Khan" <RemoveMEhasanKILLspamkhansden.com> wrote: {Quote hidden}> I didn't put the +reloc.inc file on the command > line! > That was my original question. Why is this option > showing up at all? In build options, 'options on > file' is unchecked but it is still showing up. It > is > driving me nuts. > > --- phil B <philpiclistSTOPspamspam_OUTyahoo.com> wrote: > > I did not have a problem like that installing into > > mplab 6.60 and building sample1. I did not see > > reloc.lnk in the default command string, though. > > Why > > do you need the options in a file? Go into > > project/build options and uncheck "options on > file". > > > > Include any options from the file in the > "additional > > command line options" box. > > > > However, I get an error based on the hex format I > > select: the default, INHX8M, generates a hex file > > but > > mplab says: the hex file not written because the > > format extension is not recognized (but the hex > file > > was actually generated). All 3 other hex formats > > cause cc5x to fail to build. Since I currently > > don't > > use an mplab compatible programmer, its sort of ok > > (for free) but I can't use the simulator and may > get > > a > > compatible programmer some day. I don't think I'd > > pay > > money for it unless I can resolve this error. > > Anyone > > got any ideas? > > > > --- "Hasan A. Khan" <spamBeGonehasanSTOPspamEraseMEkhansden.com> wrote: > > > Hi, > > > As a new comer to this list, I have been read > this > > > list for a while now and its been a great help. > > One > > > thing I learned was that I didn't have to use > > > assembler and there is a free C compiler CC5X. > I > > > immediately installed in MPLAB and tried the > > > samples. > > > All my excitement vanished when it failed the > > first > > > time and it still failing. When I compile the > > file > > > sample1.c I get the following error > > > > > > Executing: "C:\Program Files\bknd\CC5X\CC5X.EXE" > > > SAMPLE1.C -CC -fINHX8M -p16F628 -I"C:\Program > > > Files\bknd\CC5X" -a -L -Q -V -FM +reloc.inc > > > Error : Unable to open file 'reloc.inc' > > > > > > Error options: -ew: no warning details -ed: no > > > error > > > details -eL: list details > > > > > > I have set up the incpath correctly in mplab, I > > > think. > > > I have not turned on the + flag in 'build > > options' > > > so > > > why is +reloc.inc showing up in the compile line > > and > > > why can't the compiler find it? > > > > > > Thanks for any help. > > > > > > > > > > > > -Hasan > > > -- >

Alan B. Pearce <KILLspamA.B.PearcespamBeGonerl.ac.uk> wrote: > > I've written a ton of PIC assembler and am getting tired > > of getting the btfsx sense wrong or being in the wrong bank. > > This is why I use Olins macros. The conditional macros seem to make more > sense, and the banking macros produce code only if they need to (although > there are still occasions where you can get caught out). Yes. To prevent that, I went one step further and wrote a simple preprocessor (a Perl script, see below) that allows me to "declare" the banked symbols. Whenever an instruction makes a reference to such a symbol, this preprocessor inserts Olin's macro call ahead of it. Even this isn't foolproof -- for example, if you reference one of those symbols immediately after a skip instruction and the macro inserts something there. The workaround for that is to explicitly put a dbankif *ahead* of the skip to insure that the macro inserted by my script won't generate any code. At some point, it just becomes simpler to write a compiler. Currently, I'm running two different Perl scripts over the code (hence the reference to "2nd pass" below), then Olin's "prepic" preprocessor, then all of the macros get expanded before the actual assembly happens. Fortunately, this is all managed by a Makefile, so my workflow is actually fairly simple. -- Dave Tweed ========================================================================= #!perl -w use strict; use vars qw/%bankmap/; # preprocessor 2nd pass for PIC assembly language # keeps track of symbols and what bank they're in, inserting bank-switching # directives where needed # If a line contains the pattern "banksym <bank> <symbol>", it is deleted # from the source code and the relationship is memorized. # If any subsequent line contains <symbol>, a "dbankif <bank>" line is # inserted ahead of it. while (<>) { if (/^\s*banksym\s+(\w+)\s+(\w+)\s*$/) { $bankmap{$2} = $1; } else { (my $temp = $_) =~ s/;.*//; for my $sym (keys %bankmap) { if ($temp =~ /\b$sym\b/) { print " dbankif $bankmap{$sym}\n"; last; } } print; } } =========================================================================

Dave Tweed wrote: > Alan B. Pearce wrote: > > > I've written a ton of PIC assembler and am getting tired > > > of getting the btfsx sense wrong or being in the wrong bank. > > > > This is why I use Olins macros. The conditional macros seem to make more > > sense, and the banking macros produce code only if they need to (although > > there are still occasions where you can get caught out). > > Yes. To prevent that, I went one step further and wrote a simple > preprocessor (a Perl script, see below) that allows me to "declare" the > banked symbols. Whenever an instruction makes a reference to such a symbol, > this preprocessor inserts Olin's macro call ahead of it. The XCASM assembler tracks bank useage and inserts bank select instructions automatically for you (if you let it). With this assembler there is no need to declare special banked symbols, all RAM accesses are tracked. > > Even this isn't foolproof -- for example, if you reference one of those > symbols immediately after a skip instruction and the macro inserts > something there. The workaround for that is to explicitly put a dbankif > *ahead* of the skip to insure that the macro inserted by my script won't > generate any code. The XCASM assembler knows how to deal with bank switching through skip instructions and inserts the instructions in the right place. It tracks multiple execution paths through each instruction (including subroutine calls) and only inserts bank select instructions which are absolutely necessary. If you manually insert bank select instructions elsewhere (maybe further up in the execution path) it will compensate and not insert the now redundent bank select instructions. > > At some point, it just becomes simpler to write a compiler. The bank and page management of the XCASM assembler works great, there really is no need for a compiler to do all the hard work. The XCSB compiler uses XCASM as the backend assembler so programmers get the full benefit when embedding inline assembler (there is no need to hack about in assembler trying to maintain consistancy between the programmer supplied inline assembler and the compiler generated assembler). > Currently, I'm > running two different Perl scripts over the code (hence the reference to > "2nd pass" below), then Olin's "prepic" preprocessor, then all of the > macros get expanded before the actual assembly happens. Fortunately, this > is all managed by a Makefile, so my workflow is actually fairly simple. A further advantage of doing this in the assembler is that XCASM can generate a profile of the executable which shows all the execution paths through an instruction. With this you can easily work backwards and identify paths through an instruction that you had not anticipated or simple forgotten about. This greatly helps locate an execution path where a variable (or SFR) is undefined. This is the kind of error you normally use a simulator and trace buffer to find, but with this kind of debugging you might need to spend hours homing in on the problem path. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use

----- Original Message ----- From: Alan B. Pearce <EraseMEA.B.PearceEraseMErl.ac.uk> To: Microcontroller discussion list - Public. <@spam@piclist@spam@spam_OUTmit.edu> Sent: Tuesday, May 17, 2005 5:06 PM Subject: Re: [PIC] CC5X errors - help {Quote hidden}> >A further advantage of doing this in the assembler is that XCASM > >can generate a profile of the executable which shows all the > >execution paths through an instruction. With this you can easily > >work backwards and identify paths through an instruction that you > >had not anticipated or simple forgotten about. This greatly helps > >locate an execution path where a variable (or SFR) is undefined. > >This is the kind of error you normally use a simulator and trace > >buffer to find, but with this kind of debugging you might need to > >spend hours homing in on the problem path. > > Whew, with all this, will it also act as a disassembler ? Yes but only of the executable it generates. If you add a buch of data statements and your execution path goes through these then the profile will show the actual code (the data disassembled). Of course if the program is self modifying then your profile will only be valid until the self mod :-) Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use

Olin Lathrop wrote: > Sergio Masci wrote: > > A further advantage of doing this in the assembler is that XCASM can > > generate a profile of the executable which shows all the execution > > paths through an instruction. With this you can easily work backwards > > and identify paths through an instruction that you had not anticipated > > or simple forgotten about. > > How does it deal with data-dependent modification of the PC? It depends on the data. It knows about XCSB longcalls so if it encounters a sequence of instructions that corresponds to a longcall it associates the RAM locations with a return address. If the PC is modified from such a return address the execution path remains valid and is tracked, (loading a constant into the PC via PCLATH and PCL will also result in a valid tracked path). If the PC is modified using undefined data (e.g. from an untracked RAM location) then the execution thread for the undefined PC ends and the PC is undefined at that point. You could argue that this will be invalid because there is no way of tracking all possible execution paths. However since the purpose of the program is to execute a well defined sequence of instructions it is possible to ignore undefined jumps and assume that they will be valid if they are based on valid data. Most of the time (almost always), a computed jump will start from an otherwise unreachable instruction. Such start points allow the assembler to identify execution paths where the bank and page may be undefined. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use

Sergio Masci <spamBeGonesmplxKILLspamxcprod.com> wrote: > The XCASM assembler tracks bank useage and inserts bank select > instructions automatically for you (if you let it). With this assembler > there is no need to declare special banked symbols, all RAM accesses are > tracked. > The XCASM assembler knows how to deal with bank switching through skip > instructions and inserts the instructions in the right place. It tracks > multiple execution paths through each instruction (including subroutine > calls) and only inserts bank select instructions which are absolutely > necessary. If you manually insert bank select instructions elsewhere > (maybe further up in the execution path) it will compensate and not > insert the now redundent bank select instructions. Sounds interesting. But the documentation on your website leaves a lot to be desired. I remember looking at it once before and basically giving up. I can't tell what the output format of your assembler is. Is it compatible with the MPLAB linker? Can it accept MPASM/gpasm source code? Except for the global flow analysis you do to "optimize" the bank switching and ignoring the "expression compiler", I can do pretty much everything that XCASM does with a few lines of Perl code. Why would I spend GBP100 or GBP1250 to switch to a tool I have no control over? I'm not even sure that the "Enterprise Edition" supports the processors I'm interested in. -- Dave Tweed

Dave Tweed wrote: > Sergio Masci wrote: > > The XCASM assembler tracks bank useage and inserts bank select > > instructions automatically for you (if you let it). With this assembler > > there is no need to declare special banked symbols, all RAM accesses are > > tracked. > > > The XCASM assembler knows how to deal with bank switching through skip > > instructions and inserts the instructions in the right place. It tracks > > multiple execution paths through each instruction (including subroutine > > calls) and only inserts bank select instructions which are absolutely > > necessary. If you manually insert bank select instructions elsewhere > > (maybe further up in the execution path) it will compensate and not > > insert the now redundent bank select instructions. > > Sounds interesting. But the documentation on your website leaves a lot > to be desired. I remember looking at it once before and basically giving > up. Ok, regardless of my feelings about the documentation, it is obviously not upto your requirements and I will need to address this. > I can't tell what the output format of your assembler is. Is it > compatible with the MPLAB linker? No. XCASM produces far more information about an executable than the MPLAB linker can deal with e.g. XCASM handles floating point directly, produces RAM bank and code page diagnostic information which the XCSIM simiulator can use to track incorrect bank and page setting during program simulation. > Can it accept MPASM/gpasm source code? assembler source yes, assembler directives no. > > Except for the global flow analysis you do to "optimize" the bank > switching and ignoring the "expression compiler", I can do pretty much > everything that XCASM does with a few lines of Perl code. Reading other posts regarding your Perl code I must conclude you are mistaken. Your Perl script requires that you define symbols as paged, XCASM decides itself which symbols need to be paged based on the address of the symbol computed during the assembly of the source. As variables are added or removed to/from the program during program development or the program grows or shrinks, the assembler does all the work without the need for the programmer to maintain a seperate list of banked symbols. This goes to the heart of good software development practices i.e. keeping all information about an object within the object. There is a divide between your preprocessor and the MPASM assembler which cannot be bridged even though it may apear that the information is available within the source code. It has as much meaning to MPASM as any other comment. By maintaining seperate information about the object there is great scope for error which will require subsequent debugging. Besides all of this, XCASM also performs code page management not just RAM bank management. > Why would I > spend GBP100 or GBP1250 to switch to a tool I have no control over? GPB 100 does not buy you a MPASM clone. It buys you a sophisticated professional assembler. If you can get by with MPASM or gpasm then you can use these free of charge. If you need something that improves your productivity (amongst other things greatly helps eliminate bank and page issuses which so many people find anonying) then XCASM is available. Regardless which route you take you are still paying unless your time is worth nothing that is. I assume that by "control over" you mean "one that you have the source code for and can fix yourself". Yes I know that many people think like this but even so these people are in the minority. Most people do not want to fix a program they find bugs in, they either want it fixed for them or they look for a workaround. People that dig their heals in and reject non-open source software are cutting their noses off to spite their face. Fact of life: their competion will use the software and will have an advantage. > I'm not even sure that the "Enterprise Edition" supports the processors > I'm interested in. XCASM is a mata assembler, the enterprise edition gives full access to the configuration components. In other words you can define your own opcode syntax and the way it generates machine code. It comes with several processor definitions (e.g. Z80, 6502, 68HC11, PIC16 etc) which you can easily extend or change to suit your own requirements. You also get access to the intermediate high level opcodes of the "expression compiler" which you refer to above. This allows you to hack the expression compiler for other processors. XCASM enterprise edition is intended for people / companies who wish to develope their own CPU cores using FPGAs. You should also keep in mind that XCASM is the back end of the XCSB compiler and some of the other CASE tools that I provide so it is not a dead end product. As a company's needs evolve it can build on its XCASM based source code without the need to re-write everything. This is what the enterprise edition is all about. It is not simply an unlimted site license for the standard product. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use