Searching \ for 'MPLAB import still...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/ios.htm?key=port
Search entire site for: 'MPLAB import still...'.

Truncated match.
PICList Thread
'MPLAB import still...'
1997\10\02@115527 by Reginald Neale

flavicon
face
Many thanks to those who offered suggestions for troubleshooting my
problems trying to import files into MPLAB. To review, files emailed to me
refuse to compile, although files entered directly into the editor work
fine. I'm using MPLAB v3.12.00 on a 75MHz Pentium running Win95. I have the
handicap of being from the Mac world. It doesn't help that I'm only a
visitor here in PC land, forced to emigrate by Microchip's refusal to
support the Mac platform. Yes, I know there are 3rd-party Mac tools now,
but they weren't available when I bought my laptop.

Several people suggested that control characters not visible on the screen
were messing things up. This was confirmed through use of the DOS utility
DEBUG. Now I see that in order to compile without errors, MPLAB is
requiring each line to end with 0Ah and 0Dh (CR & LF). This, apparently, is
how UNIX normally treats a text file. But other platforms typically use
just one of the control characters for ending a line.

Is there any way to force MPLAB's text editor to accept files created with
other platforms, short of transcribing them? I notice there is an option
for special treatment of control-Z, but don't understand why that would be
necessary.

Am I missing something simple here? I Read The Friendly Manual, the
sections on File Modes and Templates, but don't see the answer.

Regards,
Reg

1997\10\02@120810 by Shane Nelson

flavicon
face
On Thu, 2 Oct 1997, Reginald Neale wrote:

> Several people suggested that control characters not visible on the screen
> were messing things up. This was confirmed through use of the DOS utility
> DEBUG. Now I see that in order to compile without errors, MPLAB is
> requiring each line to end with 0Ah and 0Dh (CR & LF). This, apparently, is
> how UNIX normally treats a text file. But other platforms typically use
> just one of the control characters for ending a line.

I thought unix normally uses just a LF. But DOS and Windoz and
such use CRLF.

> Is there any way to force MPLAB's text editor to accept files created with
> other platforms, short of transcribing them? I notice there is an option
> for special treatment of control-Z, but don't understand why that would be
> necessary.

There are a few dos based programs that will attempt to correct
any CRLF problems.  I can't recall any off hand but have used
them in the past. A netsearch should turn up something...

Another thing you can try is:
1. open it in dos's edit program
2. make a small change... add a space, then delete it. This is to
force edit to save the changes it made when loading the text
file.
3. Exit edit and save the changes.

What I believe happens is edit will go through and correct all
the LF's to become CRLF's.  After you save the changes it made
mplab should be able to handle it.

.scn

1997\10\02@130536 by Stephen H Alsop

flavicon
face
I had to change from the Mac world to using a PC in order to run MPLAB, etc
- I had to open all of my Mac files and resave using BBEDIT (a Mac editing
prog) which allows you to save with CR + LF

Stephen H Alsop    email: spam_OUTsteveTakeThisOuTspams.ssystems.easynet.co.uk
S&S Systems Ltd   www: http://easyweb.easynet.co.uk/~s.ssystems
Tel: 01909 773399 * Fax: 01909 773645 * Mobile: 0973 305527

: Many thanks to those who offered suggestions for troubleshooting my
: problems trying to import files into MPLAB. ....
.....MPLAB is
: requiring each line to end with 0Ah and 0Dh (CR & LF). This, apparently,
is
: how UNIX normally treats a text file. But other platforms typically use
: just one of the control characters for ending a line.
:
: Is there any way to force MPLAB's text editor to accept files created
with
: other platforms, short of transcribing them? I notice there is an option
: for special treatment of control-Z, but don't understand why that would
be
: necessary.
:
: Regards,
: Reg

1997\10\02@135025 by Martin R. Green

picon face
Actually, you have this backward.  UNIX (like the MAC, it sounds like)
terminates a line with only an LF.  It is DOS and Windows (all versions)
that want CRLF.

Note that some of the extraneous characters you are getting may be because
you are using an editor that inserts control characters into the text for
formatting instructions, etc.  Make sure you always save source file in
plain text format, if your editor supports that.  If not, get another
editor.

----------
From:   Reginald Neale[SMTP:.....nealeKILLspamspam@spam@SERVTECH.COM]
Sent:   Thursday, October 02, 1997 11:55 AM
To:     PICLISTspamKILLspammitvma.mit.edu
Subject:        MPLAB import still...

<SNIP>

Several people suggested that control characters not visible on the screen
were messing things up. This was confirmed through use of the DOS utility
DEBUG. Now I see that in order to compile without errors, MPLAB is
requiring each line to end with 0Ah and 0Dh (CR & LF). This, apparently, is
how UNIX normally treats a text file. But other platforms typically use
just one of the control characters for ending a line.

<SNIP>

1997\10\02@144710 by Bob Blick

flavicon
face
Hi Reg,

Debug? Whew. Get "Hedit", it's a shareware hex editor, might be a little
easier to look at things, especially if you like Windows better than DOS.

Get PFE, "Programmer's File Editor". It's freely distributable, or
shareware, or something like that. It's what I use for editing code, and
you can switch between unix text and PC text easily. Might even handle
that Mac text you have left over.

Both of those should be available at the common download sites.

Cheerful regards,

Bob

P.S. I love that line about "Microchip's refusal to support the Mac
platform". I imagine there are lots of other platforms they would refuse
if given the chance. :-) I used to have an Amiga, so I know what you are
feeling, get over it.

On Thu, 2 Oct 1997, Reginald Neale wrote:

{Quote hidden}

1997\10\02@150117 by John Payson

picon face
> Actually, you have this backward.  UNIX (like the MAC, it sounds like)
> terminates a line with only an LF.  It is DOS and Windows (all versions)
> that want CRLF.

There are three different line-ending conventions in common use:
 CR-only
 LF-only
 CF/LF

The CR-only dates back to early teletypes which had a switch which would
allow CR to advance the paper (I don't know how EBCDIC printers prior to
that delimitted line records, but I do remember that the first character
on a line would control how the paper should move _BEFORE_ printing that
line:

blank - advance one line before printing
plus  - do not advance paper before printing
zero  - advance two lines before printing
one   - advance to first printable line on next page before printing
other - printer-specific.  Some operators set up the printer so that a "2"
        would advance to the perforation at the top of the next "up"-facing
        page (very handy when using fanfold paper, since a triple-struck
        row of asterisks there would be on the outside of the stack (hence
        visible) and the job-label page would be facing upward.  Note that
        use of an inimplemented code would often cause the printer to rapidly
        feed through blank paper (at a rate of several feet per second) until
        the operator stopped it (on earlier models) or the carriage-control
        tape mechanism watchdogged (on later models).

I think the LF-only convention came after DEC decided to make its VTxx term-
inals perform a carriage return (as well as a linefeed) upon receipt of an
LF code.  I don't know whether earlier terminal manufacturers had done this
as well.

For programs written in "C", the linefeed is the official newline character
within a program; the file I/O routines on PC implementations will strip
carriage returns on input and add them on output.  For PostScript (the
printer language) CR's and LF's are equivalent except that any CR following
a recognized LF will be ignored, and any LF following a recognized CR will
be ignored.

> Note that some of the extraneous characters you are getting may be because
> you are using an editor that inserts control characters into the text for
> formatting instructions, etc.  Make sure you always save source file in
> plain text format, if your editor supports that.  If not, get another
> editor.

Some assemblers may have trouble with tab characters; personally I hate tabs
but some editors like to use them.  I don't think MPASM should have any diff-
iculty with them.

1997\10\02@164550 by William Chops Westfield

face picon face
In theory, using the FTP program will convert end-of-line formats for you
if you specify "ascii" mode for the file transfer.  Don't know what that
means now that actual FTP programs are rare...

BillW

1997\10\02@164802 by Matt Bonner

flavicon
face
Bob Blick wrote:

> Debug? Whew. Get "Hedit", it's a shareware hex editor, might be a little
> easier to look at things, especially if you like Windows better than DOS.
>

> Get PFE, "Programmer's File Editor". It's freely distributable, or
> shareware, or something like that. It's what I use for editing code, and
> you can switch between unix text and PC text easily. Might even handle
> that Mac text you have left over.
>
Try also, UltraEdit-32.  Also a shareware Hex editor, converts from and
to Unix/Mac, toggles "Wrap" and <cr><lf>.  Does lots more.
--Matt

1997\10\02@165837 by jorgegf

flavicon
face
Hi

...
Reginald Neale wrote:
>
...
{Quote hidden}

...

I think you figured it out exactly the oposite way.

In UNIX systems we have only one character for ending a line, know as NL
(newline) and coded as 0Ah; also we don't use any special character to
mark the end of a file.
In fact MS-DOS dos use the sequence CR-LF (0Dh 0Ah) to mark the EOL and
is very common to see a control-Z beeing used as the last character of a
file (EOF), in special with plaintext files (.TXT).
This might have been inherited from CP/M (DR) but I'm not sure anymore,
it had been a long time since the days of TRS-80, CP/M and 8" floppies.

So, it seems natural that beeing a PC based platform MPLAB expects CR-LF
terminated lines.

You have to be extra carefull when transfering text files bettwen
platforms, because sometimes the OS tools do make changes on text files.
For instance 'doscp' in SCO Unix does convert NL to CR-LF and vice-versa
during the copy; the same probably happens whit other platforms. In this
cases you have to check if there is a switch to tell the command to
trreat the file as binary wich normally disables any translation.

       best regards

       Jorge F

1997\10\02@172650 by Reginald Neale

flavicon
face
>P.S. I love that line about "Microchip's refusal to support the Mac
>platform". I imagine there are lots of other platforms they would refuse
>if given the chance. :-) I used to have an Amiga, so I know what you are
>feeling, get over it.
>
Yeah, I'm pretty much over it, it only rankles me a little....

Thanks for the tip, I'll see if I can locate those items.

Regards,
Reg

1997\10\03@034835 by Tom Handley

picon face
  Bob, I agree about PFE. It's an excellent editor and the author
deserves to be rewarded but he releases it as `freeware'.

  As far as LF/CR/CRLF and the Amiga, I use to be an Amiga developer for
10 years and the first C program I wrote on that platfrom was a MAC/CR,
PC/CRLF, to LF converter using the original "Lettuce" compiler in '85.
I could go on and on about the Amiga but not in this forum... It's a
damn shame how that ended up...

  - Tom

At 11:40 AM 10/2/97 -0700, Bob Blick wrote:
[snip]>
>Get PFE, "Programmer's File Editor". It's freely distributable, or
>shareware, or something like that. It's what I use for editing code, and
>you can switch between unix text and PC text easily. Might even handle
>that Mac text you have left over.
[snip]
>P.S. I love that line about "Microchip's refusal to support the Mac
>platform". I imagine there are lots of other platforms they would refuse
>if given the chance. :-) I used to have an Amiga, so I know what you are
>feeling, get over it.
[snip]

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...