From: Stanley L. <sta...@gm...> - 2007-09-29 07:48:57
|
Once again, thanks to Jan and Raphael for their help for getting me started with a template for the C codes on SDCC fusebit syntax. My newest version of the LED blinking code is posted on http://www.dutchforce.com/~eforum/index.php?showtopic=14788. However, I am having a problem of my PIC18F2620 not starting the control execution properly when I use my DC adapter as the power source. Eventually, I will be using the microcontroller on a portable battery, but for now, I'm using a DC adapter for development and testing purposes. I am suspecting that either I'm not setting the fusebits properly or I'm experiencing a problem with my power supply, which might require me to set up brown out reset and power up timer. How can I tell whether I have a fusebit configuration problem or whether I have a problem with my power supply? Cheers, Stanley |
From: <sd...@du...> - 2007-09-29 08:36:31
|
Stanley Lee wrote: > Once again, thanks to Jan and Raphael for their help for getting me > started with a template for the C codes on SDCC fusebit syntax. My > newest version of the LED blinking code is posted on > http://www.dutchforce.com/~eforum/index.php?showtopic=14788. I had numerous problems with the different sdcc startup codes. Which sometimes only let my programm run after pressing reset. Try to use --use-crt=crt0.o or --use-crt=crt0i.o instead of --use-crt=crt0iz.o and see if this helps. Im using --use-crt=crt0.o in my programms and this works. cheers, jan |
From: Maarten B. <sou...@ds...> - 2007-09-29 08:43:58
|
Stanley, > How can I tell whether I have a problem with my power supply? I think the only answer can be: use an oscilloscoop and look at the value and stability of your power supply. Maarten |
From: Stanley L. <sta...@gm...> - 2007-09-30 00:43:06
|
When I checked with the oscilloscope on the power supply regarding its stability, the supply voltage is very consistently regulated at 5V and the raw power supply voltage consistently at ~15V. Jan, I'm currently building the project using Piklab after I have the newest version successfully installed along with the newest version of sdcc source installation. Should I be switching to using a manual Makefile to build the project? Thanks, Stanley On 9/29/07, Maarten Brock <sou...@ds...> wrote: > > Stanley, > > > How can I tell whether I have a problem with my power supply? > > I think the only answer can be: use an oscilloscoop and look at the value > and stability of your power supply. > > Maarten > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Olgierd E. <ol...@te...> - 2007-09-30 01:06:52
|
May be you are connecting the usb port and the dc source at the same time, in that case yo can have big currents between the computer and board. I've had similar problems with a usb oscilloscope because it's very difficult to isolate the usb bus so it's ussually referenced to ground. I hoe it helps, Olgierd Eysymontt 2007/9/29, Stanley Lee <sta...@gm...>: > > Once again, thanks to Jan and Raphael for their help for getting me > started with a template for the C codes on SDCC fusebit syntax. My newest > version of the LED blinking code is posted on > http://www.dutchforce.com/~eforum/index.php?showtopic=14788<http://www.dutchforce.com/%7Eeforum/index.php?showtopic=14788> > . > > However, I am having a problem of my PIC18F2620 not starting the control > execution properly when I use my DC adapter as the power source. Eventually, > I will be using the microcontroller on a portable battery, but for now, I'm > using a DC adapter for development and testing purposes. I am suspecting > that either I'm not setting the fusebits properly or I'm experiencing a > problem with my power supply, which might require me to set up brown out > reset and power up timer. How can I tell whether I have a fusebit > configuration problem or whether I have a problem with my power supply? > > Cheers, > > Stanley > > |
From: Stanley L. <sta...@gm...> - 2007-09-30 01:18:25
|
Hi Olgierd, I'm not connecting the usb port and the dc source at the same time. I tried each power source separately, and took note of that in the problem report. Stanley On 9/29/07, Olgierd Eysymontt <ol...@te...> wrote: > > May be you are connecting the usb port and the dc source at the same time, > in that case yo can have big currents between the computer and board. I've > had similar problems with a usb oscilloscope because it's very difficult to > isolate the usb bus so it's ussually referenced to ground. > > I hoe it helps, > > Olgierd Eysymontt > > 2007/9/29, Stanley Lee <sta...@gm...>: > > > > Once again, thanks to Jan and Raphael for their help for getting me > > started with a template for the C codes on SDCC fusebit syntax. My newest > > version of the LED blinking code is posted on > > http://www.dutchforce.com/~eforum/index.php?showtopic=14788<http://www.dutchforce.com/%7Eeforum/index.php?showtopic=14788> > > . > > > > However, I am having a problem of my PIC18F2620 not starting the control > > execution properly when I use my DC adapter as the power source. Eventually, > > I will be using the microcontroller on a portable battery, but for now, I'm > > using a DC adapter for development and testing purposes. I am suspecting > > that either I'm not setting the fusebits properly or I'm experiencing a > > problem with my power supply, which might require me to set up brown out > > reset and power up timer. How can I tell whether I have a fusebit > > configuration problem or whether I have a problem with my power supply? > > > > Cheers, > > > > Stanley > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: <bo...@co...> - 2007-09-30 09:03:44
|
Stanley Lee wrote: > #for the .c.o directive below, do I need to replace it with the > <filename>.c <filename>.o instead of .c.o? i.e. how would I know which > source code to compile and build? > > .c.o: > $(CC) $(CFLAGS) $(INC) -c $< I'm no expert on makefiles, but perhaps you want to use %.o : %.c I think that means: "anyfilename.o depends on samename.c" When linker goes looking for the dependencies listed in your link target, $(OBJS), which in this case is a single file named "main.o", it will use that rule to know that main.o depends on main.c, and use the command that follows to compile main. > #rule to link the final executable > $(PROG_NAME): $(OBJS) > $(LNK) $(DEBUG) $(LDFLAGS) $(CRT) -Wl-s$(lkr_PIC_TYPE).lkr,-m > -mpic16 -p$(sdcc_PIC_TYPE) $+ -o $(@) -llibio$(sdcc_PIC_TYPE).lib - > llibc18f.lib I use "$< -o $@" where you have "$+ -o $(@)". I don't know if extra parentheses matter. According to the make manual, $+ means all of the dependencies including repeats, and $< means just the first. As long as there is just one, as in "%.o : %.c" it should not matter. > prog: $(PROG_NAME) > piklab-prog --programmer=direct --port=/dev/parport0 > --device=$(sdcc_PIC_TYPE) --command=program $(PROG_NAME) > > #would the prog directive be telling the makefile to flash the hexfile > to the microcontroller? That looks like what it is doing. > if I am using PICKIT2 programmer, would I be commanding the programmer > to look in /dev/usbxxx, x being number? I can't comment on pickit2, as I am not using it. Also, I am not even using pic, I am using z80, so I can't comment on the options related to pic, either. Randy |
From: Stanley L. <sta...@gm...> - 2007-09-30 03:20:37
|
Sorry for the additional spam, but I have a few more questions about the Makefile as I am on the way of switching away from using piklab ide and more towards using the Makefile. The questions are embedded in the Makefile: PROG_NAME = LED_toggle.hex OBJS = main.o DEBUG = #-DUSB_USE_UART #-DDEBUG_UART -DDEBUG -DDEBUG_PRINT PIC_TYPE = PIC18F2620 sdcc_PIC_TYPE = 18f2620 lkr_PIC_TYPE = 18f2620 TOOLSDIR = /usr/local/ CC = $(TOOLSDIR)/bin/sdcc CFLAGS = -mpic16 -V -p$(sdcc_PIC_TYPE) $(DEBUG) --denable-peeps --opt-code-size --optimize-cmp --optimize-df --fstack LNK = $(TOOLSDIR)/bin/sdcc INC = -I. LDFLAGS = -L/usr/local/share/sdcc/lib/pic16/ CRT = --use-crt=crt0.o -V #DEBUG = --denable-peeps --obanksel=9 --opt-code-size --optimize-cmp --optimize-df --fstack all: $(PROG_NAME) #for the .c.o directive below, do I need to replace it with the <filename>.c <filename>.o instead of .c.o? i.e. how would I know which source code to compile and build? .c.o: $(CC) $(CFLAGS) $(INC) -c $< #rule to link the final executable $(PROG_NAME): $(OBJS) $(LNK) $(DEBUG) $(LDFLAGS) $(CRT) -Wl-s$(lkr_PIC_TYPE).lkr,-m -mpic16 -p$(sdcc_PIC_TYPE) $+ -o $(@) -llibio$(sdcc_PIC_TYPE).lib -llibc18f.lib # prog: $(PROG_NAME) piklab-prog --programmer=direct --port=/dev/parport0 --device=$(sdcc_PIC_TYPE) --command=program $(PROG_NAME) #would the prog directive be telling the makefile to flash the hexfile to the microcontroller? if I am using PICKIT2 programmer, would I be commanding the programmer to look in /dev/usbxxx, x being number? clean: rm -f *.o *.rel *.lst *.cod *.hex *.map *.asm# change this to your program name Thanks, Stanley On 9/29/07, Stanley Lee <sta...@gm...> wrote: > > Hi Olgierd, > > I'm not connecting the usb port and the dc source at the same time. I > tried each power source separately, and took note of that in the problem > report. > > Stanley > > On 9/29/07, Olgierd Eysymontt <ol...@te...> wrote: > > > May be you are connecting the usb port and the dc source at the same > > time, in that case yo can have big currents between the computer and board. > > I've had similar problems with a usb oscilloscope because it's very > > difficult to isolate the usb bus so it's ussually referenced to ground. > > > > I hoe it helps, > > > > Olgierd Eysymontt > > > > 2007/9/29, Stanley Lee < sta...@gm...>: > > > > > > Once again, thanks to Jan and Raphael for their help for getting me > > > started with a template for the C codes on SDCC fusebit syntax. My newest > > > version of the LED blinking code is posted on > > > http://www.dutchforce.com/~eforum/index.php?showtopic=14788<http://www.dutchforce.com/%7Eeforum/index.php?showtopic=14788> > > > . > > > > > > However, I am having a problem of my PIC18F2620 not starting the > > > control execution properly when I use my DC adapter as the power source. > > > Eventually, I will be using the microcontroller on a portable battery, but > > > for now, I'm using a DC adapter for development and testing purposes. I am > > > suspecting that either I'm not setting the fusebits properly or I'm > > > experiencing a problem with my power supply, which might require me to set > > > up brown out reset and power up timer. How can I tell whether I have a > > > fusebit configuration problem or whether I have a problem with my power > > > supply? > > > > > > Cheers, > > > > > > Stanley > > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > |
From: Bodo W. <bod...@we...> - 2007-09-30 09:14:40
|
> Sorry for the additional spam, but I have a few more questions about the > Makefile as I am on the way of switching away from using piklab ide and > more towards using the Makefile. > [...] Please do a simple Google search with "make tutorial", and read at least two or three of them. It might help to keep the spam level low here. ;-) > #for the .c.o directive below, do I need to replace it with the > <filename>.c <filename>.o instead of .c.o? i.e. how would I know which > source code to compile and build? No, you don't have to replace it, because there is a rule below ("$(PROG_NAME): $(OBJS)") that tells make which object files belong to the program. > prog: $(PROG_NAME) > piklab-prog --programmer=direct --port=/dev/parport0 > --device=$(sdcc_PIC_TYPE) --command=program $(PROG_NAME) > > #would the prog directive be telling the makefile to flash the hexfile to > the microcontroller? if I am using PICKIT2 programmer, would I be > commanding the programmer to look in /dev/usbxxx, x being number? It's the other way around: you tell make to produce the goal "prog". Make finds the rule, checks that $(PROG_NAME) is up to date (if not, make builds it!), and then "piklab-prog" is called with the arguments shown. If you need another device, enter its name in the command line for "piklab-prog". Hope that helps. Bodo |
From: <bo...@co...> - 2007-09-30 09:31:22
|
bo...@co... wrote: >I use "$< -o $@" >where you have "$+ -o $(@)". > oops, I have confused my compile and link commands. My link command uses "$^ -o $@" $^ is like $+, but with no duplicates. Randy |
From: <sd...@du...> - 2007-09-30 09:31:23
|
Hi Sadly makefiles are hard to read. I usually write generic makefiles so i only need to do it once ;) Stanley Lee wrote: > PROG_NAME = LED_toggle.hex > OBJS = main.o > all: $(PROG_NAME) > > #for the .c.o directive below, do I need to replace it with the > <filename>.c <filename>.o instead of .c.o? i.e. how would I know which > source code to compile and build? > > .c.o: > $(CC) $(CFLAGS) $(INC) -c $< As someone said earlier, this rule just tells make how to produce the corresponding .o file from a .c file. The .o files are listed in the ONJS variable. If you have have split up your project to more than one file you just need to add them with whitespaces to the OBJS variable lie: OBJS main.o my_special_ad_routines.o somethin_else.o etc. > prog: $(PROG_NAME) > piklab-prog --programmer=direct --port=/dev/parport0 > --device=$(sdcc_PIC_TYPE) --command=program $(PROG_NAME) > > #would the prog directive be telling the makefile to flash the hexfile > to the microcontroller? if I am using PICKIT2 programmer, would I be > commanding the programmer to look in /dev/usbxxx, x being number? if you used piklab before to flash your pic, just look what commandline it used to do so. You can see them in the output window. Then copy this line to the makefile and your done. Thats how i did it. Also look at piklab-prog --programmer-list to see wether your programmer is supported. For the pickit2 i think you just need the replace the --programmer=direct --port=/dev/parport0 with --programmer=direct=pickit2 maybe togehter with the right port. |
From: Ken J. <Ken...@ie...> - 2007-09-30 10:24:08
|
I salute the switch to the Makefile, even if it's a pain. It makes a LOT of sense to keep all the details of a compilation (commands, switches, command-line variables, etc.) in one text file which can be controlled by a version control system. Most IDEs keep that information in some proprietary project file that may be binary, may change from version to version and may not be readable either by humans or other IDEs. Worse, sometimes people working on one project prefer different IDEs. Here's the GNU 'make' manual: <http://www.gnu.org/software/make/manual/html_node/> -Ken Jackson Stanley Lee writes: > Sorry for the additional spam, but I have a few more questions > about the Makefile as I am on the way of switching away from > using piklab ide and more towards using the Makefile. |
From: Xiaofan C. <xia...@gm...> - 2007-09-30 10:46:09
|
On 9/30/07, Stanley Lee <sta...@gm...> wrote: > Sorry for the additional spam, but I have a few more questions about the > Makefile as I am on the way of switching away from using piklab ide I think Piklab should work fine. If you have Piklab related problem, try ask in gnupic mailing list. The author Nicolas monitors gnupic mailing list. > > piklab-prog --programmer=direct --port=/dev/parport0 > --device=$(sdcc_PIC_TYPE) --command=program $(PROG_NAME) > > #would the prog directive be telling the makefile to flash the hexfile to > the microcontroller? if I am using PICKIT2 programmer, would I be commanding > the programmer to look in /dev/usbxxx, x being number? http://piklab.sourceforge.net/wiki/index.php/Command-line_Utility piklab-prog -p pickit2 -d 18f2620 -c program $(PROG_NAME) Take note that Piklab only supports PICkit 2 V1.x firmware. For PICkit 2 Linux related issues, please go to pickit-devel mailing list or gnupic list. Thanks. Xiaofan http://mcuee.blogspot.com |
From: Stanley L. <sta...@gm...> - 2007-10-03 04:25:07
|
I have only read the GNU make manual up to section 4.5, but I think I have read enough of the manual to realize that the tab character is required between all commands. So I have fixed that, but have received the following error the first time through: [Makefile script] # change this to your program name PROG_NAME = LED_toggle.hex # list your object files OBJS = main.o DEBUG = #-DUSB_USE_UART #-DDEBUG_UART -DDEBUG -DDEBUG_PRINT PIC_TYPE = PIC18F2620 sdcc_PIC_TYPE = 18f2620 lkr_PIC_TYPE = 18f2620 TOOLSDIR = /usr/local/ CC = $(TOOLSDIR)/bin/sdcc CFLAGS = -mpic16 -V -p$(sdcc_PIC_TYPE) $(DEBUG) --denable-peeps --opt-code-size --optimize-cmp --optimize-df --fstack LNK = $(TOOLSDIR)/bin/sdcc INC = -I. LDFLAGS = -L/usr/local/share/sdcc/lib/pic16/ CRT = --use-crt=crt0.o -V #DEBUG = --denable-peeps --obanksel=9 --opt-code-size --optimize-cmp --optimize-df --fstack all: $(PROG_NAME) .c.o: $(CC) $(CFLAGS) $(INC) -c $< #rule to link the final executable $(PROG_NAME): $(OBJS) $(LNK) $(DEBUG) $(LDFLAGS) $(CRT) -Wl-s$(lkr_PIC_TYPE).lkr,-m -mpic16 -p$(sdcc_PIC_TYPE) $+ -o $(@) -llibio$(sdcc_PIC_TYPE).lib -llibc18f.lib # #prog: $(PROG_NAME) # piklab-prog --programmer=direct --port=/dev/parport0 --device=$(sdcc_PIC_TYPE) --command=program $(PROG_NAME) clean: rm -f *.o *.rel *.lst *.cod *.hex *.map *.asm# change this to your program name [end of Makefile script] [error message] prak@prak-laptop:/media/sda5/Dairy Cow Research/datalogging scale/software/LED_toggle$ make /usr/local//bin/sdcc -L/usr/local/share/sdcc/lib/pic16/ --use-crt=crt0.o -V -Wl-s18f2620.lkr,-m -mpic16 -p18f2620 main.o -o LED_toggle.hex - llibio18f2620.lib -llibc18f.lib + "/usr/local//bin/gplink" -I"/usr/local//bin/../share/sdcc/lib/pic16" -I"/usr/local/share/sdcc/lib/pic16" -I"/usr/local/share/sdcc/lib/pic16/" - s18f2620.lkr -m -w -r -o LED_toggle.hex main.o crt0.o libio18f2620.lib libc18f.lib pic18f2620.lib libsdcc.lib 18f2620.lkr: No such file or directory make: *** [LED_toggle.hex] Error 1 [end of error message] I have inferred that the linker path LNK is in the wrong directory. So I changed to LNK = $(TOOLSDIR)/share/gputils/lkr/ for the microcontroller linker path b/c the linker file is found in that respective path, but instead got a permission error message. [error message] prak@prak-laptop:/media/sda5/Dairy Cow Research/datalogging scale/software/LED_toggle$ make /usr/local//share/gputils/lkr/ -L/usr/local/share/sdcc/lib/pic16/ --use-crt=crt0.o -V -Wl-s18f2620.lkr,-m -mpic16 -p18f2620 main.o -o LED_toggle.hex -llibio18f2620.lib -llibc18f.lib make: execvp: /usr/local//share/gputils/lkr/: Permission denied make: *** [LED_toggle.hex] Error 127 [end of error message] Does anyone have any idea on how to get around that? I have a feeling that it has something to do with 18f2620.lkr file. Thanks, Stanley On 9/30/07, Xiaofan Chen <xia...@gm...> wrote: > > On 9/30/07, Stanley Lee <sta...@gm...> wrote: > > Sorry for the additional spam, but I have a few more questions about the > > Makefile as I am on the way of switching away from using piklab ide > > I think Piklab should work fine. If you have Piklab related problem, > try ask in gnupic mailing list. The author Nicolas monitors > gnupic mailing list. > > > > > piklab-prog --programmer=direct --port=/dev/parport0 > > --device=$(sdcc_PIC_TYPE) --command=program $(PROG_NAME) > > > > #would the prog directive be telling the makefile to flash the hexfile > to > > the microcontroller? if I am using PICKIT2 programmer, would I be > commanding > > the programmer to look in /dev/usbxxx, x being number? > > http://piklab.sourceforge.net/wiki/index.php/Command-line_Utility > piklab-prog -p pickit2 -d 18f2620 -c program $(PROG_NAME) > > Take note that Piklab only supports PICkit 2 V1.x firmware. > For PICkit 2 Linux related issues, please go to pickit-devel mailing > list or gnupic list. Thanks. > > Xiaofan > http://mcuee.blogspot.com > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Xiaofan C. <xia...@gm...> - 2007-10-03 04:43:09
|
On 10/3/07, Stanley Lee <sta...@gm...> wrote: > prak@prak-laptop:/media/sda5/Dairy Cow Research/datalogging > scale/software/LED_toggle$ make No idea of your real problem. But firstly please use short path name and try again. I am not sure if sdcc likes the spaces in the directory name. |
From: Stanley L. <sta...@gm...> - 2007-10-03 05:35:51
|
I have moved everything to /media/sda5/LED_toggle/. However, I've been experiencing the same problem. The error message is shown below: prak@prak-laptop:/media/sda5/LED_toggle$ make /usr/local//share/gputils/lkr/ -L/usr/local/share/sdcc/lib/pic16/ --use-crt=crt0.o -V -Wl-s18f2620.lkr,-m -mpic16 -p18f2620 main.o -o LED_toggle.hex -llibio18f2620.lib -llibc18f.lib make: execvp: /usr/local//share/gputils/lkr/: Permission denied make: *** [LED_toggle.hex] Error 127 Above is with LNK = /usr/local/share/gputils/lkr/ prak@prak-laptop:/media/sda5/LED_toggle$ make /usr/local//bin/sdcc -L/usr/local/share/sdcc/lib/pic16/ --use-crt=crt0.o -V -Wl-s18f2620.lkr,-m -mpic16 -p18f2620 main.o -o LED_toggle.hex - llibio18f2620.lib -llibc18f.lib + "/usr/local//bin/gplink" -I"/usr/local//bin/../share/sdcc/lib/pic16" -I"/usr/local/share/sdcc/lib/pic16" -I"/usr/local/share/sdcc/lib/pic16/" - s18f2620.lkr -m -w -r -o LED_toggle.hex main.o crt0.o libio18f2620.lib libc18f.lib pic18f2620.lib libsdcc.lib 18f2620.lkr: No such file or directory make: *** [LED_toggle.hex] Error 1 Above is with LNK = /usr/local/bin/sdcc. Thanks, Stanley On 10/2/07, Xiaofan Chen <xia...@gm...> wrote: > > On 10/3/07, Stanley Lee <sta...@gm...> wrote: > > prak@prak-laptop:/media/sda5/Dairy Cow Research/datalogging > > scale/software/LED_toggle$ make > > No idea of your real problem. But firstly please use short path > name and try again. I am not sure if sdcc likes the spaces > in the directory name. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: <sd...@du...> - 2007-10-03 09:19:40
|
Hi Stanley Lee wrote: > I have moved everything to /media/sda5/LED_toggle/. However, I've been > experiencing the same problem. The error message is shown below: > > prak@prak-laptop:/media/sda5/LED_toggle$ make > /usr/local//share/gputils/lkr/ -L/usr/local/share/sdcc/lib/pic16/ > --use-crt= crt0.o -V -Wl-s18f2620.lkr,-m -mpic16 -p18f2620 main.o -o > LED_toggle.hex -llibio18f2620.lib -llibc18f.lib > make: execvp: /usr/local//share/gputils/lkr/: Permission denied > make: *** [LED_toggle.hex] Error 127 Sorry, but my Makefile was written with all tools installed under /usr/local/ which is the default location if you just download, compile and install them. Few suggestions to find the problem: 1. Check if gputils are installed and where (type "wich gplink") 2. Find the location if your lkr files. Easiest way is: find / . -name "*.lkr" Both *must* be either in /usr/bin/ and /usr/share or in /usr/local/bin and /usr/local/share. If this is not the case reinstall gputils and sdcc by just typing ./configure && make install with *no* --prefix=/what/ever/ Now edit the Makefile so that TOOLSDIR is set up with the right path either TOOLSDIR = /usr/ or TOOLSDIR = /usr/local/ according to the place you installed the gplink and sdcc After that pls edit one more lines in the Makefile i forgot, to make it more generic: LDFLAGS = -L$(TOOLSDIR)/share/sdcc/lib/pic16/ Now to the crtX problem: If sdcc cant find the crtX.o files this is because of the wrong library path given in the LDFLAGS variable. Afaik sdcc expects these files in the same directory as the pic16 library. After doing the above steps do a find / . -name "crt0*.o" they must be either in /usr/local/share/sdcc/lib/pic16 or /usr/share/sdcc/lib/pic16 together with all the other pic16 library files like libc18f.lib, pic18f2320.lib etc etc. One hint: Never install software to unusual places. You get screwed sooner or later. When i install gputils i just type ./configure and make install that all. Same for sdcc only that i do ./configure --disable-mcs51-port --disable-gbz80-port --disable-z80-port --disable-avr-port --disable-ds400-port --disable-ds390-port --disable-pic-port --disable-xa51-port --disable-hc08-port to only compile sdcc for pic16. A final make install puts the stuff in exactly the place where it is needed. Hope this helps jan |
From: Xiaofan C. <xia...@gm...> - 2007-10-03 05:59:52
|
On 10/3/07, Stanley Lee <sta...@gm...> wrote: > Above is with LNK = /usr/local/share/gputils/lkr/ That is wrong. LNK is for the linker not the linker script (LKR), ie LNK=/usr/local/bin/gplink or sdcc can be used to call the linker script. By the way, if you set up gputils and sdcc in the default directory, you will not need to go through so much troubles. http://ubicomp.lancs.ac.uk/%7Emartyn/sdcc_linux/ (Do not following the installation instruction -- it is outdated). Here is a nice example for sdcc with PIC. http://petertodd.org/tech/example-projects/bin/example-projects-20070527.tar.gz Xiaofan |
From: Stanley L. <sta...@gm...> - 2007-10-03 06:25:10
|
I didn't realize that LNK stands for the linker binary file. Anyway, what I did for the installation of gputils and sdcc was downloading the nightly snapshots and then manually installed it rather than doing a dpkg on a debian installation file (b/c that's the only way I found initially to get the latest version of both). After changing LNK to the path Xiaofan suggested, I now get the following error with gputils. [error start] prak@prak-laptop:/media/sda5/LED_toggle$ make /usr/local//bin/gplink -L/usr/local/share/sdcc/lib/pic16/ --use-crt=crt0.o-V - Wl-s18f2620.lkr,-m -mpic16 -p18f2620 main.o -o LED_toggle.hex - llibio18f2620.lib -llibc18f.lib /usr/local//bin/gplink: invalid option -- L /usr/local//bin/gplink: invalid option -- / /usr/local//bin/gplink: invalid option -- u /usr/local//bin/gplink: unrecognized option `--use-crt=crt0.o' /usr/local//bin/gplink: invalid option -- V /usr/local//bin/gplink: invalid option -- W /usr/local//bin/gplink: invalid option -- - /usr/local//bin/gplink: invalid option -- p /usr/local//bin/gplink: invalid option -- i /usr/local//bin/gplink: invalid option -- 1 /usr/local//bin/gplink: invalid option -- 6 /usr/local//bin/gplink: invalid option -- p /usr/local//bin/gplink: invalid option -- 1 /usr/local//bin/gplink: invalid option -- 8 /usr/local//bin/gplink: invalid option -- i /usr/local//bin/gplink: invalid option -- b /usr/local//bin/gplink: invalid option -- i /usr/local//bin/gplink: invalid option -- i /usr/local//bin/gplink: invalid option -- b /usr/local//bin/gplink: invalid option -- 1 /usr/local//bin/gplink: invalid option -- 8 /usr/local//bin/gplink: invalid option -- L make: *** [LED_toggle.hex] Segmentation fault (core dumped) [error end] My guess from reading gplink manual on terminal is that there is something wrong with the linker options, however I have trouble deducing from the Makefile what's wrong with the options. Stanley On 10/2/07, Xiaofan Chen <xia...@gm...> wrote: > > On 10/3/07, Stanley Lee <sta...@gm...> wrote: > > > Above is with LNK = /usr/local/share/gputils/lkr/ > > That is wrong. LNK is for the linker not the linker script (LKR), > ie LNK=/usr/local/bin/gplink or sdcc can be used to > call the linker script. > > By the way, if you set up gputils and sdcc in the default > directory, you will not need to go through so much troubles. > http://ubicomp.lancs.ac.uk/%7Emartyn/sdcc_linux/ > (Do not following the installation instruction -- it is outdated). > > Here is a nice example for sdcc with PIC. > > http://petertodd.org/tech/example-projects/bin/example-projects-20070527.tar.gz > > Xiaofan > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: <sd...@du...> - 2007-10-05 10:00:03
|
Stanley Lee schrieb: > Hi, The above places for sdcc, gputils etc. look good. > > Anyway, there is one strange thing that I have found. I have modified > jan's template as shown in the attached zip file and still got the > following error message: > [error message start] > prak@prak-laptop:/media/sda5/LED_toggle$ make What did you change in the Makefile looks like you exchanged sdcc to gplink in the LNK = $(TOOLSDIR)/bin/sdcc line. Did you? Use sdcc to link your files not gplink direclty. sdcc will use gplink with the correct paths/options etc. > However, when I have modified another Makefile and code similar to the > one Xiaofan's last reply suggested, I manage to get a hex file created > in the end. However, it had the same behaviour as the one I have made > with piklab, which is my code doesn't automatically execute whenever I > apply an external power supply. It only executes when I plug in my > PICKIT2 after instructing PICKIT2 to be on with the command "pk2 -on". > I'm beginning to suspect that this is a hardware problem, perhaps with > the power on timer and the brown out register. Please, if possible, send me 1. Your code 2. the Makefile I will check it on a pic18f2320 on my boards here. jan |
From: Stanley L. <sta...@gm...> - 2007-10-06 21:29:02
|
Hi, I have sent Jan a copy of the Makefile and source code. I will be testing modified version of the source code and Makefile on a PIC16F877a to see if anything different would result. Please feel free to ask me for the files if you're interested. Stanley On 10/5/07, sd...@du... <sd...@du...> wrote: > > Stanley Lee schrieb: > > Hi, > > The above places for sdcc, gputils etc. look good. > > > > > Anyway, there is one strange thing that I have found. I have modified > > jan's template as shown in the attached zip file and still got the > > following error message: > > [error message start] > > prak@prak-laptop:/media/sda5/LED_toggle$ make > > What did you change in the Makefile looks like you exchanged sdcc to > gplink in the > LNK = $(TOOLSDIR)/bin/sdcc > line. Did you? > Use sdcc to link your files not gplink direclty. sdcc will use gplink > with the correct paths/options etc. > > > However, when I have modified another Makefile and code similar to the > > one Xiaofan's last reply suggested, I manage to get a hex file created > > in the end. However, it had the same behaviour as the one I have made > > with piklab, which is my code doesn't automatically execute whenever I > > apply an external power supply. It only executes when I plug in my > > PICKIT2 after instructing PICKIT2 to be on with the command "pk2 -on". > > I'm beginning to suspect that this is a hardware problem, perhaps with > > the power on timer and the brown out register. > > > Please, if possible, send me > > 1. Your code > 2. the Makefile > > I will check it on a pic18f2320 on my boards here. > > jan > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Stanley L. <sta...@gm...> - 2007-10-06 23:43:23
|
Hi, Sorry for another email. I have received modified version of Jan's makefile. The compilation and build process is solved. However, I am encountering the same problem as I have experienced before, and that is the PIC18F2620 doesn't execute the operation of blinking the LEDs automatically right after external power is applied. I'm thinking of trying the same code (except for some fusebits/hardware tweaks on a PIC16F877A, PIC16F688, PIC16F690, or PIC16F628. Any suggestions if this thought is a feasible alternative to sideline the development? Cheers, Stanley On 10/6/07, Stanley Lee <sta...@gm...> wrote: > > Hi, > > I have sent Jan a copy of the Makefile and source code. I will be testing > modified version of the source code and Makefile on a PIC16F877a to see if > anything different would result. Please feel free to ask me for the files if > you're interested. > > Stanley > > On 10/5/07, sd...@du... <sd...@du... > wrote: > > > > Stanley Lee schrieb: > > > Hi, > > > > The above places for sdcc, gputils etc. look good. > > > > > > > > Anyway, there is one strange thing that I have found. I have modified > > > jan's template as shown in the attached zip file and still got the > > > following error message: > > > [error message start] > > > prak@prak-laptop:/media/sda5/LED_toggle$ make > > > > What did you change in the Makefile looks like you exchanged sdcc to > > gplink in the > > LNK = $(TOOLSDIR)/bin/sdcc > > line. Did you? > > Use sdcc to link your files not gplink direclty. sdcc will use gplink > > with the correct paths/options etc. > > > > > However, when I have modified another Makefile and code similar to the > > > one Xiaofan's last reply suggested, I manage to get a hex file created > > > in the end. However, it had the same behaviour as the one I have made > > > with piklab, which is my code doesn't automatically execute whenever I > > > apply an external power supply. It only executes when I plug in my > > > PICKIT2 after instructing PICKIT2 to be on with the command "pk2 -on". > > > > > I'm beginning to suspect that this is a hardware problem, perhaps with > > > the power on timer and the brown out register. > > > > > > Please, if possible, send me > > > > 1. Your code > > 2. the Makefile > > > > I will check it on a pic18f2320 on my boards here. > > > > jan > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > |
From: <sd...@du...> - 2007-10-07 10:00:35
|
Stanley Lee wrote: > Hi, > > Sorry for another email. I have received modified version of Jan's > makefile. The compilation and build process is solved. However, I am > encountering the same problem as I have experienced before, and that is > the PIC18F2620 doesn't execute the operation of blinking the LEDs > automatically right after external power is applied. I'm thinking of > trying the same code (except for some fusebits/hardware tweaks on a > PIC16F877A, PIC16F688, PIC16F690, or PIC16F628. Any suggestions if this > thought is a feasible alternative to sideline the development? > Checked your code on a testboard with a pic18f2220 (sorry, no oscilloscope here to test the blinking frequency) but they do blink here with a few changes/advises to your code: 1. Use unsigned int not int for your delay function. 2. i would add _PWRT_ON_2L when using the internal oscillator to give the osc a few steps to stabilize before executing first code. 3. You *need* to tell sdcc (someone correct me here if its wrong) where you want the stack to be. I usually put it onto gpr2 (or gpr1 for smaller devices, see lkr file for the address of the gpr(s)). For the pic18f2620 this would be #pragma stack 0x200 0xff /* (<- always first line in main.c) */ somewhere at the start of the program. You will encounter non predictable errors/misbehavior if your forgot this and sdcc sadly doesn't warn you about it. 4. also the dly = dly; is not needed just add a ; after the while like void delay(unsigned int dly) { while(--dly > 0) ; } Now your programm runs fine. jan |
From: Stanley L. <sta...@gm...> - 2007-10-09 01:25:42
Attachments:
main.c
|
Hi, I have incorporated Jan's suggestions into the code, and apparently got the same behaviour. Is it possible to get from you, Jan, the modified code that you have for the PIC18F2220 as I try on that particular mcu? Attached to the email is the code. Cheers, Stanley On 10/7/07, sd...@du... <sd...@du...> wrote: > > > > Stanley Lee wrote: > > Hi, > > > > Sorry for another email. I have received modified version of Jan's > > makefile. The compilation and build process is solved. However, I am > > encountering the same problem as I have experienced before, and that is > > the PIC18F2620 doesn't execute the operation of blinking the LEDs > > automatically right after external power is applied. I'm thinking of > > trying the same code (except for some fusebits/hardware tweaks on a > > PIC16F877A, PIC16F688, PIC16F690, or PIC16F628. Any suggestions if this > > thought is a feasible alternative to sideline the development? > > > > Checked your code on a testboard with a pic18f2220 (sorry, no > oscilloscope here to test the blinking frequency) but they do blink here > with a few changes/advises to your code: > > 1. Use unsigned int not int for your delay function. > 2. i would add _PWRT_ON_2L when using the internal oscillator to give > the osc a few steps to stabilize before executing first code. > 3. You *need* to tell sdcc (someone correct me here if its wrong) where > you want the stack to be. I usually put it onto gpr2 (or gpr1 for > smaller devices, see lkr file for the address of the gpr(s)). For the > pic18f2620 this would be > > #pragma stack 0x200 0xff /* (<- always first line in main.c) */ > > somewhere at the start of the program. You will encounter non > predictable errors/misbehavior if your forgot this and sdcc sadly > doesn't warn you about it. > > 4. also the dly = dly; is not needed just add a ; after the while like > void delay(unsigned int dly) > { > while(--dly > 0) ; > } > > Now your programm runs fine. > > jan > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: <sd...@du...> - 2007-10-09 08:42:19
Attachments:
code.tar.gz
|
Stanley Lee schrieb: > Hi, > > I have incorporated Jan's suggestions into the code, and apparently got > the same behaviour. Is it possible to get from you, Jan, the modified > code that you have for the PIC18F2220 as I try on that particular mcu? > Attached to the email is the code. that pretty strange. Attached to this mail you find the code. You could try the following: - exchange _MCLRE_MCLR_OFF_RE3_ON_3H with _MCLRE_MCLR_ON_RE3_OFF_3H and try if your code runs if you press reset. - you configure osc_output on RA6 (_OSC_INTIO7_1H) try to measure with an oscilloscope if clock is running while your pic refuses to do so. - try, if possible, to use an external clock or to lower the internal clock. jan |