USB DEVICE CONTROL in NUT&VOLTS by A.Enzmann

This is the place for any magazine-related discussions that don't fit in any of the column discussion boards below.
Engineer1138
Posts: 458
Joined: Thu Feb 05, 2004 1:01 am
Location: Minneapolis, MN
Contact:

Post by Engineer1138 »

Plasma cutter -- that sounds like a fun project.

Have you seen what the guys on cnczone.com are doing?
copperclad
Posts: 24
Joined: Tue May 30, 2006 11:43 am
Location: rochester ny
Contact:

Post by copperclad »

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 :grin: ) 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 :smile:
copperclad
Posts: 24
Joined: Tue May 30, 2006 11:43 am
Location: rochester ny
Contact:

Post by copperclad »

hi
i was able to get the supplied hex file working without too much trouble , just me chugging up the learning curve :???: :smile: , 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 :smile:

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 :sad: 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
SETEC_Astronomy
Posts: 582
Joined: Tue May 09, 2006 12:44 am
Contact:

Post by SETEC_Astronomy »

Did you try putting the .h files in the compilers include folder? it would be either C:\your software\include or C:\program files\yoursoftware\include something like that. I always have to put include files from other programs into those folders.
copperclad
Posts: 24
Joined: Tue May 30, 2006 11:43 am
Location: rochester ny
Contact:

Post by copperclad »

hi setec
yes i was busy trying that and getting nowhere :sad: , 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 :grin: and all of a sudden it works like a charm , except that it still wont produce a hex file :sad: , 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 :smile:
standoff
Posts: 3
Joined: Wed Aug 02, 2006 9:42 pm
Contact:

Still getting fatal error U1077 return code 01

Post by standoff »

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
standoff
Posts: 3
Joined: Wed Aug 02, 2006 9:42 pm
Contact:

Making progress but Still having problems

Post by standoff »

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'
Rudy E
Posts: 6
Joined: Wed Aug 16, 2006 12:52 am
Contact:

Post by Rudy E »

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"
copperclad
Posts: 24
Joined: Tue May 30, 2006 11:43 am
Location: rochester ny
Contact:

Post by copperclad »

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

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

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
Rudy E
Posts: 6
Joined: Wed Aug 16, 2006 12:52 am
Contact:

Post by Rudy E »

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 :???: :cool:
copperclad
Posts: 24
Joined: Tue May 30, 2006 11:43 am
Location: rochester ny
Contact:

Post by copperclad »

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 :smile:
Rudy E
Posts: 6
Joined: Wed Aug 16, 2006 12:52 am
Contact:

Post by Rudy E »

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 :sad: 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.
standoff
Posts: 3
Joined: Wed Aug 02, 2006 9:42 pm
Contact:

USB

Post by standoff »

Rudy,

Did you notice the MPLAB 7.41 has the CCS compiler for free?

Jerry
Rudy E
Posts: 6
Joined: Wed Aug 16, 2006 12:52 am
Contact:

Post by Rudy E »

Hi Jerry,

Yes I did but he doesn't work for the 18Fxxxx chip :sad: (I tried :cool:)
xander
Posts: 3
Joined: Fri Aug 18, 2006 4:44 am
Contact:

USB Article in Nuts & Volts

Post by xander »

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

Who is online

Users browsing this forum: Ahrefs [Bot] and 36 guests