Post by thread:[PIC] Can't assemble?

Ooookay...I need a sanity check. I'm trying to assemble the following file: www.k9spud.com/vwcdpic/devel/vwcdpic-2.7d/vwcdpic-2.7d.asm - if you click the link you need to agree to the GPL licence on this code and sign in using username "I" and password "agree". Anyway, it's been awhile since I've compiled a complete file like this from somewhere else and I'm running up against a rather hard brick wall. I used the project wizard, creating a new MPASM project and targeting the correct processor. I add my .asm file, try to assemble...and get "DOS Error: File not found". Behind that popup looks to be the MPASM window stuck on "Building symbol table...". That's the only error I get, not super helpful. So...does anyone have any ideas as to why I can't get this simple file to work? Frustrating! Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams

At 08:54 PM 4/13/2008, you wrote: >Ooookay...I need a sanity check. I'm trying to assemble the following >file: www.k9spud.com/vwcdpic/devel/vwcdpic-2.7d/vwcdpic-2.7d.asm >- if you click the link you need to agree to the GPL licence on this >code and sign in using username "I" and password "agree". > >Anyway, it's been awhile since I've compiled a complete file like this >from somewhere else and I'm running up against a rather hard brick >wall. I used the project wizard, creating a new MPASM project and >targeting the correct processor. I add my .asm file, try to >assemble...and get "DOS Error: File not found". Behind that popup >looks to be the MPASM window stuck on "Building symbol table...". > >That's the only error I get, not super helpful. So...does anyone have >any ideas as to why I can't get this simple file to work? > >Frustrating! > >Josh Builds fine for me (12F675) using MPLAB 8.02. Path issue? ---------------------------------------------------------------------- Debug build of project `M:\josh\josh.mcp' started. Preprocessor symbol `__DEBUG' is defined. Sun Apr 13 21:28:34 2008 ---------------------------------------------------------------------- Clean: Deleting intermediary and output files. Clean: Done. Executing: "C:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe" /q /p12F675 "josh.asm" /l"josh.lst" /e"josh.err" /d__DEBUG=1 Loaded M:\josh\josh.cod. ---------------------------------------------------------------------- Debug build of project `M:\josh\josh.mcp' succeeded. Preprocessor symbol `__DEBUG' is defined. Sun Apr 13 21:28:34 2008 ---------------------------------------------------------------------- BUILD SUCCEEDED >Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" spam_OUTspeffTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com

On Sun, Apr 13, 2008 at 9:34 PM, Spehro Pefhany <.....speffKILLspam@spam@interlog.com> wrote: > Builds fine for me (12F675) using MPLAB 8.02. Path issue? Aha! It was a filename issue...you saved it as josh.asm, but the original name was vwcdpic-2.7d.asm. I guess MPASM doesn't like multiple periods in a filename. Thanks! Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams

On 14/04/2008, Josh Koffman <joshybearKILLspamgmail.com> wrote: > Aha! It was a filename issue...you saved it as josh.asm, but the > original name was vwcdpic-2.7d.asm. I guess MPASM doesn't like > multiple periods in a filename. Interesting. And since MPLAB first release was due long after Win95 was introduced, I can't really see why they are using old and dead DOS file-routines for it. I thought these silly limitations were gone long time ago, but obviously some people/companies still stick to them by using weird compilers. The C-compiler I'm using in MPLAB works fine with multiple periods. -- - Rikard - http://bos.hack.org/cv/

On Mon, Apr 14, 2008 at 1:59 AM, Rikard Bosnjakovic <.....rikard.bosnjakovicKILLspam.....gmail.com> wrote: > And since MPLAB first release was due long after Win95 was introduced, > I can't really see why they are using old and dead DOS file-routines > for it. I thought these silly limitations were gone long time ago, but > obviously some people/companies still stick to them by using weird > compilers. Well I shouldn't be too surprised...MPLAB still has that path name length restriction (or it still does in my current 7.x versions). Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams

Josh Koffman wrote: > On Mon, Apr 14, 2008 at 1:59 AM, Rikard Bosnjakovic > <EraseMErikard.bosnjakovicspam_OUTTakeThisOuTgmail.com> wrote: >> And since MPLAB first release was due long after Win95 was introduced, >> I can't really see why they are using old and dead DOS file-routines >> for it. I thought these silly limitations were gone long time ago, but >> obviously some people/companies still stick to them by using weird >> compilers. > > > Well I shouldn't be too surprised...MPLAB still has that path name > length restriction (or it still does in my current 7.x versions). *ONLY* if you're still building old absolute-mode code. I thought all/most was using relocatable-mode code today... (And I guess that is the case with the multiple-dots limitation also, but I'm not 100% sure about that...) Jan-Erik. > > Josh

On 14/04/2008, Jan-Erik Soderholm <jan-erik.soderholmspam_OUTtelia.com> wrote: > > Well I shouldn't be too surprised...MPLAB still has that path name > > length restriction (or it still does in my current 7.x versions). > > *ONLY* if you're still building old absolute-mode code. That doesn't make sense. MPASM's inability for multiple periods in filename really hasn't got to do anything regarding absolute or relocatable mode. -- - Rikard - http://bos.hack.org/cv/

Note that I replied about the "long path issue"... It would not surprice me if the "mutliple-dots" is related to the same base cause. But maybe it isn't... Jan-Erik. Rikard Bosnjakovic wrote: {Quote hidden}> On 14/04/2008, Jan-Erik Soderholm <@spam@jan-erik.soderholmKILLspamtelia.com> wrote: > >> > Well I shouldn't be too surprised...MPLAB still has that path name >> > length restriction (or it still does in my current 7.x versions). >> >> *ONLY* if you're still building old absolute-mode code. > > That doesn't make sense. > > MPASM's inability for multiple periods in filename really hasn't got > to do anything regarding absolute or relocatable mode. > >

On Mon, 14 Apr 2008 12:12:30 +0200 Jan-Erik Soderholm <KILLspamjan-erik.soderholmKILLspamtelia.com> wrote: > It would not surprice me if the "mutliple-dots" > is related to the same base cause. But maybe > it isn't... Note that even Windows gets worked up on multiple dots at some point. I had W trying to rename .tar.gz files to other variants with all the resulting problems (hidden 'cause windows hides the extensions by default). So the problem may not be entirely Microchip's. John

On 14/04/2008, John Coppens <RemoveMEjohnTakeThisOuTjcoppens.com> wrote: > Note that even Windows gets worked up on multiple dots at some point. I > had W trying to rename .tar.gz files to other variants with all the > resulting problems (hidden 'cause windows hides the extensions by > default). So the problem may not be entirely Microchip's. With hidden extensions, anything bad can happen. That's why you unhide the extensions. For the sake of testing, renaming an image "foo.png" too "foo.bar...doodledoo.png" resulted in zero problems here. -- - Rikard - http://bos.hack.org/cv/

Rikard Bosnjakovic wrote: > On 14/04/2008, John Coppens <spamBeGonejohnspamBeGonejcoppens.com> wrote: > >> Note that even Windows gets worked up on multiple dots at some point. I >> had W trying to rename .tar.gz files to other variants with all the >> resulting problems (hidden 'cause windows hides the extensions by >> default). So the problem may not be entirely Microchip's. > > With hidden extensions, anything bad can happen. That's why you unhide > the extensions. > > For the sake of testing, renaming an image "foo.png" too > "foo.bar...doodledoo.png" resulted in zero problems here. Doesn't prove anything. The particular part of the MPLAB toolset that is used when building absolute mode code might still have that problem (just as the max path lenght problem). Jan-Erik.

Quoting Jan-Erik Soderholm <TakeThisOuTjan-erik.soderholmEraseMEspam_OUTtelia.com>: {Quote hidden}> Rikard Bosnjakovic wrote: >> On 14/04/2008, John Coppens <RemoveMEjohnTakeThisOuTjcoppens.com> wrote: >> >>> Note that even Windows gets worked up on multiple dots at some point. I >>> had W trying to rename .tar.gz files to other variants with all the >>> resulting problems (hidden 'cause windows hides the extensions by >>> default). So the problem may not be entirely Microchip's. >> >> With hidden extensions, anything bad can happen. That's why you unhide >> the extensions. >> >> For the sake of testing, renaming an image "foo.png" too >> "foo.bar...doodledoo.png" resulted in zero problems here. > > Doesn't prove anything. > The particular part of the MPLAB toolset that > is used when building absolute mode code might > still have that problem (just as the max > path lenght problem). > > Jan-Erik. I've also had problems with spaces in file names with compilers not being able to find things they need. So, I use the old batch file command "subst" to force the desired directory into a short (usually 8.3) directory ("folder") and file name mold, with no spaces, and the problems go away. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" s...EraseME.....interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com