Plasma cutter -- that sounds like a fun project.
Have you seen what the guys on cnczone.com are doing?
USB DEVICE CONTROL in NUT&VOLTS by A.Enzmann
-
- Posts: 458
- Joined: Thu Feb 05, 2004 1:01 am
- Location: Minneapolis, MN
- Contact:
-
- Posts: 24
- Joined: Tue May 30, 2006 11:43 am
- Location: rochester ny
- Contact:
hi
thanks , i just checked it out and see a thread for USBCNC , most of the small CNC machines run off the printer port , and USB seems to be the new trend , USB has been beyond most people at the hobbiest level ( me ) and with the new pic's the door is starting to open , the USBCNC is designed around a 18f4550 chip , but i am guessing any of the pic 18fXXXX- usb chips would do fine
my plasma cutter is just 2 axis with motors ( 8 bit out ) , over travel ( 4 bits in ) and a joystick interface ( 5 bits in )
30" X 30" bed with about 48" per minute cutting and +or- about 0.003"
i can feed it G-code or PLT files and there are a bunch of free downloads that let you convert about any CAD or drawing to these , i built it about 8 years ago and wrote the software in 386 based assembly , the software will run off any 486 machine with a math coprocessor , dana
thanks , i just checked it out and see a thread for USBCNC , most of the small CNC machines run off the printer port , and USB seems to be the new trend , USB has been beyond most people at the hobbiest level ( me ) and with the new pic's the door is starting to open , the USBCNC is designed around a 18f4550 chip , but i am guessing any of the pic 18fXXXX- usb chips would do fine
my plasma cutter is just 2 axis with motors ( 8 bit out ) , over travel ( 4 bits in ) and a joystick interface ( 5 bits in )
30" X 30" bed with about 48" per minute cutting and +or- about 0.003"
i can feed it G-code or PLT files and there are a bunch of free downloads that let you convert about any CAD or drawing to these , i built it about 8 years ago and wrote the software in 386 based assembly , the software will run off any 486 machine with a math coprocessor , dana
-
- Posts: 24
- Joined: Tue May 30, 2006 11:43 am
- Location: rochester ny
- Contact:
hi
i was able to get the supplied hex file working without too much trouble , just me chugging up the learning curve , but i realized i want to compile the main.c file and get it so i can edit it to work , from the article he seems to be useing SDCC and GPUTILS and i went to sourceforge and downloaded them and after spinning my wheels trying to get GPUTILS to load ( i had the linux version ) i went back and found the loader for win32
iso i have SDCC installed and it seems to work and GPUTILS is installed but , when i try to compile main.c from the article it bombs not sure what the problem is , it can't seem to find usart.h or pic18fregs.h , i have tried putting them in different directories but still no luck , dana
i was able to get the supplied hex file working without too much trouble , just me chugging up the learning curve , but i realized i want to compile the main.c file and get it so i can edit it to work , from the article he seems to be useing SDCC and GPUTILS and i went to sourceforge and downloaded them and after spinning my wheels trying to get GPUTILS to load ( i had the linux version ) i went back and found the loader for win32
iso i have SDCC installed and it seems to work and GPUTILS is installed but , when i try to compile main.c from the article it bombs not sure what the problem is , it can't seem to find usart.h or pic18fregs.h , i have tried putting them in different directories but still no luck , dana
-
- Posts: 582
- Joined: Tue May 09, 2006 12:44 am
- Contact:
-
- Posts: 24
- Joined: Tue May 30, 2006 11:43 am
- Location: rochester ny
- Contact:
hi setec
yes i was busy trying that and getting nowhere , and posted on another forum and come to find out i have the lastest (official) release of sdcc >02.5.0< and it doesn't support the 18f2455 , for that you need whats called the daily snapshot the latest snapshot is version 02.5.6 june 6 , 06 and all of a sudden it works like a charm , except that it still wont produce a hex file , it does build a .lst and an .asm clean as a whistle though , i am thinking it is messed up in the link department still but i am guessing , when i get it working i will post the details here , thanks , i'll keep you posted , dana
yes i was busy trying that and getting nowhere , and posted on another forum and come to find out i have the lastest (official) release of sdcc >02.5.0< and it doesn't support the 18f2455 , for that you need whats called the daily snapshot the latest snapshot is version 02.5.6 june 6 , 06 and all of a sudden it works like a charm , except that it still wont produce a hex file , it does build a .lst and an .asm clean as a whistle though , i am thinking it is messed up in the link department still but i am guessing , when i get it working i will post the details here , thanks , i'll keep you posted , dana
Still getting fatal error U1077 return code 01
Just wondering if anybody can help on the compiling of the pichid. I'm compiling in VS2005 and it runs but returns 2 fatal errors. fatal error U1077: '"C:\Program Files\SDCC\bin\sdcc.EXE"' : return code '0x1'
and prj0019E: A tool returned an error code from "Performing Makefile project actions"
I have also tried the latest snapshots with no luck. 7-21 to 8-02 snapshots, all the same errors.
Anybody have any ideas?
Thanks, Jerry
and prj0019E: A tool returned an error code from "Performing Makefile project actions"
I have also tried the latest snapshots with no luck. 7-21 to 8-02 snapshots, all the same errors.
Anybody have any ideas?
Thanks, Jerry
Making progress but Still having problems
Well I've been poking around and put some lib files(all the ones specified when running gplink.exe) into my project file. The UIEbits.ACTVIE were actually defined as UIEbits.ACTIVIE, fixed that. The error thats killing things is "_stack symbol alread exists." I have no idea where the problem is now, other than the stack symbol is being defined twice. Any help would sure be appreciated. Here is what is happening:
1>------ Build started: Project: PICHID, Configuration: Debug Win32 ------
1>Performing Makefile project actions
1>Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
1>Copyright (C) Microsoft Corporation. All rights reserved.
1> gplink.exe -I. -I\lib -m -t 128 pic18f2550.lib libio18f2550.lib libc18f.lib libsdcc.lib crt0.o main.o usb.o -s 18f2550.lkr -o USBHID.hex
1>warning: processor mismatch in "main.o"
1>warning: processor mismatch in "usb.o"
1>error: _stack symbol already exists
1>NMAKE : fatal error U1077: '"C:\Program Files\gputils\bin\gplink.exe"' : return code '0x1'
1>------ Build started: Project: PICHID, Configuration: Debug Win32 ------
1>Performing Makefile project actions
1>Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
1>Copyright (C) Microsoft Corporation. All rights reserved.
1> gplink.exe -I. -I\lib -m -t 128 pic18f2550.lib libio18f2550.lib libc18f.lib libsdcc.lib crt0.o main.o usb.o -s 18f2550.lkr -o USBHID.hex
1>warning: processor mismatch in "main.o"
1>warning: processor mismatch in "usb.o"
1>error: _stack symbol already exists
1>NMAKE : fatal error U1077: '"C:\Program Files\gputils\bin\gplink.exe"' : return code '0x1'
I had the same problem but after moving the needed libs from the provided SDCC version into the project it worked, that is it compiles but the generated hex doesn't work. It's also smaller than the original hex file (USBHID.hex)? The only 2 warnings I have are:
1>warning: processor mismatch in "main.o"
1>warning: processor mismatch in "usb.o"
1>warning: processor mismatch in "main.o"
1>warning: processor mismatch in "usb.o"
-
- Posts: 24
- Joined: Tue May 30, 2006 11:43 am
- Location: rochester ny
- Contact:
hi
sorry i didn't see your posts sooner , i have had basically the same problems , i can get the hex file listed to run the chip fine but although i can get the source file to compile , the produced hex file comes out a different size and then doesn't run , i have been hoping A.Enzmann would see this thread and toss in a clue , i am thinking i will work more on it this winter , hopefully with better luck , dana
kind of discouraging that nuts & volts would put up an article on this without enough info to get it to work , there seems to be all of three people here who were interested in it and it looks like we have all bombed out on it
using the latest snapshot of the compiler seemed to help , but the truth is Enzmann must have been using a copy from about a year ago , and the compiler seems to be constantly updated and does't seem to be backwardly compatable , so the three or four moving targets to this project may have been in alignment when he wrote this up , but there doesn't seem to be enough info in the article to get
the listed source file to compile into the listed hex file
i know Enzmann got it to work with the tools he mentions but somewhere in between submitting the article and editing it , and printing it , there was a lose in the information needed to get it to to work
most of the help i recieved on this project was from tecodev over at the sourceforge forum , i never would have gotten as far as i did without the help he provided me , here's a link to that thread
http://sourceforge.net/forum/forum.php? ... um_id=1865
sorry i didn't see your posts sooner , i have had basically the same problems , i can get the hex file listed to run the chip fine but although i can get the source file to compile , the produced hex file comes out a different size and then doesn't run , i have been hoping A.Enzmann would see this thread and toss in a clue , i am thinking i will work more on it this winter , hopefully with better luck , dana
kind of discouraging that nuts & volts would put up an article on this without enough info to get it to work , there seems to be all of three people here who were interested in it and it looks like we have all bombed out on it
using the latest snapshot of the compiler seemed to help , but the truth is Enzmann must have been using a copy from about a year ago , and the compiler seems to be constantly updated and does't seem to be backwardly compatable , so the three or four moving targets to this project may have been in alignment when he wrote this up , but there doesn't seem to be enough info in the article to get
the listed source file to compile into the listed hex file
i know Enzmann got it to work with the tools he mentions but somewhere in between submitting the article and editing it , and printing it , there was a lose in the information needed to get it to to work
most of the help i recieved on this project was from tecodev over at the sourceforge forum , i never would have gotten as far as i did without the help he provided me , here's a link to that thread
http://sourceforge.net/forum/forum.php? ... um_id=1865
Hi,
Thanks for the link.
It is indeed very strange because I'm using the exact SDCC version provided in the USB.zip file, even the gplink.exe was provided to create the hex file. I swap around some lib, inc, etc... files but still get the same result.
In the past I created a (hex) disassembler or decompiler (only for pic10,12,16 and 18 ). Running both files trough the decompiler gives me two totally different asm files, most parts are the same but switched places and around 400 bytes of code is missing from the generated hex file. My pc doesn't detect the pic so the problem could be in the usb descriptors or how the compiler handles these descriptors, but I'm not certain of that.
Maybe it is a VS2005 (Professional Edition) problem
Thanks for the link.
It is indeed very strange because I'm using the exact SDCC version provided in the USB.zip file, even the gplink.exe was provided to create the hex file. I swap around some lib, inc, etc... files but still get the same result.
In the past I created a (hex) disassembler or decompiler (only for pic10,12,16 and 18 ). Running both files trough the decompiler gives me two totally different asm files, most parts are the same but switched places and around 400 bytes of code is missing from the generated hex file. My pc doesn't detect the pic so the problem could be in the usb descriptors or how the compiler handles these descriptors, but I'm not certain of that.
Maybe it is a VS2005 (Professional Edition) problem
-
- Posts: 24
- Joined: Tue May 30, 2006 11:43 am
- Location: rochester ny
- Contact:
hi Rudy
i don't usually give up on a project like this , but after banging my head against it for a few weeks , i realized we must be missing a few pieces of the puzzle , but after seeing this post today , i am thinking although the nuts & volts article doesn't supply enough info on getting this chip to work , it does show usb is available on this chip , and maybe other programs are on the web now that will compile , i'll post back here if i can find anything , thanks , dana
i don't usually give up on a project like this , but after banging my head against it for a few weeks , i realized we must be missing a few pieces of the puzzle , but after seeing this post today , i am thinking although the nuts & volts article doesn't supply enough info on getting this chip to work , it does show usb is available on this chip , and maybe other programs are on the web now that will compile , i'll post back here if i can find anything , thanks , dana
I agree, something is missing from this project to recreate a working hex file. This chip works very good with usb but until now I couldn't find any working example on a freeware compiler like SDCC I have some good examples on the CCS compiler but $175 is a little to much to do some experiments on this pic.
Same for me, if I find anything, I'll post back here.
Same for me, if I find anything, I'll post back here.
USB
Rudy,
Did you notice the MPLAB 7.41 has the CCS compiler for free?
Jerry
Did you notice the MPLAB 7.41 has the CCS compiler for free?
Jerry
USB Article in Nuts & Volts
All,
Not being aware of this forum, it took Rudy E. contacting me to see the problem list.
The main problem appears to be related to the use of SDCC 2.5 to compile the source code. The Nuts & Volts folks were supposed to post the actual version of SDCC used for the article (which was a nightly build from late 2005). It doesn't seem to be on the ftp site.
No matter. The latest SDCC release, 2.6, is now available from SourceForge (http://sourceforge.net/project/showfile ... oup_id=599). This one supports the 2455 and siblings.
If you do a normal install, the include and lib files will be placed differently than expected in the article. To correct for this, ensure that the environment variable SDCC_HOME is setthe root of the install directory (probably c:\progra~1\sdcc). I've had problems with spaces in path names using GPUtils & SDCC, so you should probably use the short directory names. In the makefile CFLAGS and GPLINK_FLAGS need to be changed as follows:
CFLAGS= -I. -I$(SDCC_HOME)\include\pic16 $(OPTS) -mpic16 -pp18f$(CHIP)
GPLINK_FLAGS= -I. -I$(SDCC_HOME)\lib\pic16 $(LIBS) $(OFILES) $(LOBJS) -s $(LINKER_SCRIPT)
At this point you should be able to compile and link the code. I haven't tried running the hex file yet - I'll report after I get home and can give it a try.
WARNING: I've had some problems on a different project with the pre-built library files for the 2455. They went away when I recompiled the libraries with the 2455 as the default processor. This presents some extra work. While the source for the libraries is in the standard install, the makefiles for the libraries are not. You have to download the source code archive and extract the stuff in "device/lib/pic16. Open a Cygwin command shell in the pic16 directory, run "./configure", run make, then copy the resulting .lib and .o files back to the appropriate SDCC install directory.
More to come...
Xander
Not being aware of this forum, it took Rudy E. contacting me to see the problem list.
The main problem appears to be related to the use of SDCC 2.5 to compile the source code. The Nuts & Volts folks were supposed to post the actual version of SDCC used for the article (which was a nightly build from late 2005). It doesn't seem to be on the ftp site.
No matter. The latest SDCC release, 2.6, is now available from SourceForge (http://sourceforge.net/project/showfile ... oup_id=599). This one supports the 2455 and siblings.
If you do a normal install, the include and lib files will be placed differently than expected in the article. To correct for this, ensure that the environment variable SDCC_HOME is setthe root of the install directory (probably c:\progra~1\sdcc). I've had problems with spaces in path names using GPUtils & SDCC, so you should probably use the short directory names. In the makefile CFLAGS and GPLINK_FLAGS need to be changed as follows:
CFLAGS= -I. -I$(SDCC_HOME)\include\pic16 $(OPTS) -mpic16 -pp18f$(CHIP)
GPLINK_FLAGS= -I. -I$(SDCC_HOME)\lib\pic16 $(LIBS) $(OFILES) $(LOBJS) -s $(LINKER_SCRIPT)
At this point you should be able to compile and link the code. I haven't tried running the hex file yet - I'll report after I get home and can give it a try.
WARNING: I've had some problems on a different project with the pre-built library files for the 2455. They went away when I recompiled the libraries with the 2455 as the default processor. This presents some extra work. While the source for the libraries is in the standard install, the makefiles for the libraries are not. You have to download the source code archive and extract the stuff in "device/lib/pic16. Open a Cygwin command shell in the pic16 directory, run "./configure", run make, then copy the resulting .lib and .o files back to the appropriate SDCC install directory.
More to come...
Xander
Who is online
Users browsing this forum: No registered users and 4 guests