I
ian field
Guest
"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message
news:s3n4i39m1r9l7ouq5buog5tsbrhm42js97@4ax.com...
news:s3n4i39m1r9l7ouq5buog5tsbrhm42js97@4ax.com...
Thanks.
D
David L. Jones
Guest
On Oct 27, 1:10 am, "ian field" <dai....@ntlworld.com> wrote:
MPLAB comes into its own when you have all the other tools tied into
it, like the C compiler and the ICD2 programmer/debugger. Then you
only need one package to edit, compile, program, debug, and simulate.
If you don't have an MPLAB compatible programmer, and/or a compiler
that can be "integrated" into MPLAB, then you don't need to use MPLAB
at all.
There is nothing wrong with the MPLAB text editor. It supports the all-
important colour syntax highlighting, and has most of the usual
features of a good editor.
Dave.
Use the latest version of MPLAB, you'd be a fool not too.
MPLAB comes into its own when you have all the other tools tied into
it, like the C compiler and the ICD2 programmer/debugger. Then you
only need one package to edit, compile, program, debug, and simulate.
If you don't have an MPLAB compatible programmer, and/or a compiler
that can be "integrated" into MPLAB, then you don't need to use MPLAB
at all.
There is nothing wrong with the MPLAB text editor. It supports the all-
important colour syntax highlighting, and has most of the usual
features of a good editor.
Dave.
A
Anthony Fremont
Guest
Marra wrote:
modem. It re-times the recovered data bits and clocks them out one pin and
back into another pin. That pin feeds a serial bit-bang receive routine
that stuffs the received bytes into a circular queue. All interrupt driven
of course. The main level code takes bytes out of the queue and displays
them on a Hitachi based LCD. There were very few exta cycles available when
it is receiving data. Did this on a 16F84 at 4MHz.
It sure is.
The busiest I kept a PIC was with a caller-id project using a software
modem. It re-times the recovered data bits and clocks them out one pin and
back into another pin. That pin feeds a serial bit-bang receive routine
that stuffs the received bytes into a circular queue. All interrupt driven
of course. The main level code takes bytes out of the queue and displays
them on a Hitachi based LCD. There were very few exta cycles available when
it is receiving data. Did this on a 16F84 at 4MHz.
J
Jonathan Kirwan
Guest
On Fri, 26 Oct 2007 15:26:24 -0700, "David L. Jones"
<altzone@gmail.com> wrote:
There are times when an older version is a better or only choice.
Jon
<altzone@gmail.com> wrote:
Unless you fit under one of the exceptions I mentioned elsewhere.
There are times when an older version is a better or only choice.
Jon
T
Tom2000
Guest
On Fri, 26 Oct 2007 15:10:59 GMT, "ian field" <dai.ode@ntlworld.com>
wrote:
that matter, the latest version.
If you screw around with oddball tools and toolchains, you're going to
spin yourself in circles, shooting at multiple moving targets, and
you'll never get anything done.
Anything else at this stage of your learning is just absolutely crazy.
Tom
wrote:
While you're in the learning process, use MPLAB exclusively. And, for
that matter, the latest version.
If you screw around with oddball tools and toolchains, you're going to
spin yourself in circles, shooting at multiple moving targets, and
you'll never get anything done.
Anything else at this stage of your learning is just absolutely crazy.
Tom
E
Eeyore
Guest
ian field wrote:
Graham
I have used 'edit' but notepad is far nicer to use.
Graham
I
ian field
Guest
"Tom2000" <abuse@earthlink.net> wrote in message
news:9oe6i3tsp6u12c7a8v809v8kvgg26aqjhg@4ax.com...
news:9oe6i3tsp6u12c7a8v809v8kvgg26aqjhg@4ax.com...
Thanks, is there a C compiler that integrates into that?
T
Tom2000
Guest
On Sat, 27 Oct 2007 14:39:36 GMT, "ian field" <dai.ode@ntlworld.com>
wrote:
(If you'd like to try the 18F series, you might look at the 18F1320
as your first chip. Get a sample from Microchip. It's a good
all-around processor.)
And most, if not all, popular C compilers integrate nicely into the
MPLAB IDE. I use the CCS PCH compiler for my 18F work, and the
integration is seamless.
Tom
wrote:
student edition is free.
(If you'd like to try the 18F series, you might look at the 18F1320
as your first chip. Get a sample from Microchip. It's a good
all-around processor.)
And most, if not all, popular C compilers integrate nicely into the
MPLAB IDE. I use the CCS PCH compiler for my 18F work, and the
integration is seamless.
Tom
A
Anthony Fremont
Guest
ian field wrote:
Microchip makes a C compiler available on a 90-day (IIRC) trial basis. At
the end of 90 days, you uninstall and reinstall. Microchip is fully aware
that allot of people are doing this, they don't seem to mind.
C on the 16F's is a crap shoot since the PIC wasn't designed to be used as a
C platform. There are a couple of decent compilers available but they are
not really cheap. My advice is to don't bother wasting your time with SDCC
unless you like checking the output of the compiler as part of the debugging
process.
If you really want to use C on a PIC, then I again recommend the 18F parts.
Microchip makes a C compiler available on a 90-day (IIRC) trial basis. At
the end of 90 days, you uninstall and reinstall. Microchip is fully aware
that allot of people are doing this, they don't seem to mind.
C on the 16F's is a crap shoot since the PIC wasn't designed to be used as a
C platform. There are a couple of decent compilers available but they are
not really cheap. My advice is to don't bother wasting your time with SDCC
unless you like checking the output of the compiler as part of the debugging
process.
J
Jonathan Kirwan
Guest
On Sat, 27 Oct 2007 10:01:44 -0500, "Anthony Fremont"
<nobody@noplace.net> wrote:
then reinstalling the C18 compiler to get more time. It's just enough
of a hassle, perhaps, to encourage larger businesses to pay their
bills. And enough of a reminder for smaller ones to consider the idea
seriously and periodically -- eventually, the timing of the reminder
will find a more generous mind and the check will be forthcoming. I
can see some logic in the approach. For hobbyists, it would be no
necessary barrier but Microchip probably doesn't want to materially
inhibit widespread hobbyist use of their parts.
fantastic, but it's not all that bad, either. Livable. But I
wouldn't call it a crap shoot. It generally works, as long as you
have enough flash available.
progress" on the 16F, so I see your point here. I note that SDCC
targets the 8051 -- which makes me wonder if it supports analyzing
call trees with the idea of placing local stack frame variables into
static memory (when recursion isn't required.) On the 8051, this is a
big help most of the time and on other processors it _may_ be useful,
as well.
Jon
<nobody@noplace.net> wrote:
This is something I didn't know about -- the ease of uninstalling and
then reinstalling the C18 compiler to get more time. It's just enough
of a hassle, perhaps, to encourage larger businesses to pay their
bills. And enough of a reminder for smaller ones to consider the idea
seriously and periodically -- eventually, the timing of the reminder
will find a more generous mind and the check will be forthcoming. I
can see some logic in the approach. For hobbyists, it would be no
necessary barrier but Microchip probably doesn't want to materially
inhibit widespread hobbyist use of their parts.
I've looked over the generated assembly code and it isn't all that
fantastic, but it's not all that bad, either. Livable. But I
wouldn't call it a crap shoot. It generally works, as long as you
have enough flash available.
There is that.
Hehe. I haven't ever tried it, but the web site says that "work is in
progress" on the 16F, so I see your point here. I note that SDCC
targets the 8051 -- which makes me wonder if it supports analyzing
call trees with the idea of placing local stack frame variables into
static memory (when recursion isn't required.) On the 8051, this is a
big help most of the time and on other processors it _may_ be useful,
as well.
Jon
A
Anthony Fremont
Guest
Jonathan Kirwan wrote:
Microsoft uses this technique by allowing their software to
be copied (til now). They also make sure the youngsters (students) have
cheap and easy access to their software as well. Like crack, they give it
away....at first. ;-)
decent, but outside of that ......
8052. Given that, I can only imagine the code it generates for PICs
especially with their "in progress" disclaimer.
I do like this ARM stuff I've been playing with lately. C or assembler,
it's a beautiful place to tinker.
Exactly.
Microsoft uses this technique by allowing their software to be copied (til now). They also make sure the youngsters (students) have
cheap and easy access to their software as well. Like crack, they give it
away....at first. ;-)
Yeah, I should have used better words than that. The pay compilers are
decent, but outside of that ......
See, that's just the thing. I've never used SDCC on a PIC, just on the
8052. Given that, I can only imagine the code it generates for PICs
especially with their "in progress" disclaimer.
I do like this ARM stuff I've been playing with lately. C or assembler,
it's a beautiful place to tinker.
I
ian field
Guest
"Michael A. Terrell" <mike.terrell@earthlink.net> wrote in message
news:47225643.A3EB84BE@earthlink.net...
news:47225643.A3EB84BE@earthlink.net...
At the moment I can't even get my head round the PIC ORG instruction!
J
Jonathan Kirwan
Guest
On Mon, 29 Oct 2007 21:05:08 GMT, "ian field" <dai.ode@ntlworld.com>
wrote:
Best way to understand it is to "think like a linker" not like an
assembler.
Imagine the simplest linker case. It starts out with a blank sheet of
paper, with nothing at all written down on it. The assembler is
allowed to write notes into the .OBJ files and the linker has to read
these notes and modify this initially blank sheet. The assembler is
allowed to do the following:
(1) provide a string of bytes
(2) specify an address
And let's add this assumption: both the assembler and the linker
share the idea that upon start they each will assume that the address
begins as zero, if not otherwise given.
So the assembler converts sequences of instructions into strings of
bytes and writes these as type (1) strings into the OBJ file. Also,
if the assembler "sees" an ORG statement, it writes out any prior
accumulation of a string of bytes and finishes that record and then
writes out a new type (2) record providing that address given in the
ORG statement. Then the assembler goes back to its default of just
writing out strings of bytes.
The linker on the other hand, starts out with two things -- that blank
sheet and an initial assumed address of zero. (In other words, a
'pointer' that points to the top of the blank sheet.) It then reads
up the strings of bytes from the OBJ and places them down on the blank
sheet, one by one, just appending one to the other as it reads. In
the process of that, it also moves the address along down the page as
it goes, so that the internal address always points to the next
available place on the sheet to write. If the linker encounters an
ORG, or type (2) record, then it simply moves the address pointer as
indicated and then continues adding bytes from the strings, starting
then at that point.
ORG just moves the linker's address pointer for the current memory
page it is working on.
In the end, the final memory page may be somewhat disconnected --
there may be blank areas where nothing was written. How it handles
generating the final executable file in those cases will depend on
what makes sense in that context. But that's about all that goes on,
earlier.
Now, most linkers permit multiple pages. These are called "segments"
but basically these are named pages. (Often, there is permitted one
"unnamed" page, as well.) Each of these segments has its own separate
pointer about where the next string is to be written on that page (the
"current location on that page.") The linker keeps track of what the
current page is and what the current location on that page is, also.
If the linker sees strings of bytes in the OBJ, it just appends them
at the current location on the current page and moves the current
location, accordingly.
The assembler or compiler is permitted to jump tracks, so to speak,
and instruct the assembler to move to a different page or segment, at
any time. Additional strings are then written to that page, instead
of an earlier one. So the expanded list of records would be:
(1) provide a string of bytes
(2) specify an address
(3) specify a named or unnamed page
There can also be so-called "absolute pages" and "relative pages." By
this, the assembler or compiler can have two types of pages -- one
which is forced to a specific location in memory and others where the
linker is permitted some freedom about moving them around when it
needs to composite the final executable. Those which must go at
specific locations are placed first, usually. Then those which can be
moved around are inserted or added where ever they can fit. The order
in which this takes place can vary -- for example, it could be sorted
by name and placed in that order.
Also, it is possible to support segments which overlap -- by this,
another type of page is permitted which can be grouped in such a way
that allocations overlap (the pages are laid down on top of each other
like transparencies might be in order to composite a final image.)
These are so-called "common segments." FORTRAN uses these types, for
example, and so does some BASIC implementations.
Does that help?
Jon
wrote:
That is often explained poorly from the point of view of assembly.
Best way to understand it is to "think like a linker" not like an
assembler.
Imagine the simplest linker case. It starts out with a blank sheet of
paper, with nothing at all written down on it. The assembler is
allowed to write notes into the .OBJ files and the linker has to read
these notes and modify this initially blank sheet. The assembler is
allowed to do the following:
(1) provide a string of bytes
(2) specify an address
And let's add this assumption: both the assembler and the linker
share the idea that upon start they each will assume that the address
begins as zero, if not otherwise given.
So the assembler converts sequences of instructions into strings of
bytes and writes these as type (1) strings into the OBJ file. Also,
if the assembler "sees" an ORG statement, it writes out any prior
accumulation of a string of bytes and finishes that record and then
writes out a new type (2) record providing that address given in the
ORG statement. Then the assembler goes back to its default of just
writing out strings of bytes.
The linker on the other hand, starts out with two things -- that blank
sheet and an initial assumed address of zero. (In other words, a
'pointer' that points to the top of the blank sheet.) It then reads
up the strings of bytes from the OBJ and places them down on the blank
sheet, one by one, just appending one to the other as it reads. In
the process of that, it also moves the address along down the page as
it goes, so that the internal address always points to the next
available place on the sheet to write. If the linker encounters an
ORG, or type (2) record, then it simply moves the address pointer as
indicated and then continues adding bytes from the strings, starting
then at that point.
ORG just moves the linker's address pointer for the current memory
page it is working on.
In the end, the final memory page may be somewhat disconnected --
there may be blank areas where nothing was written. How it handles
generating the final executable file in those cases will depend on
what makes sense in that context. But that's about all that goes on,
earlier.
Now, most linkers permit multiple pages. These are called "segments"
but basically these are named pages. (Often, there is permitted one
"unnamed" page, as well.) Each of these segments has its own separate
pointer about where the next string is to be written on that page (the
"current location on that page.") The linker keeps track of what the
current page is and what the current location on that page is, also.
If the linker sees strings of bytes in the OBJ, it just appends them
at the current location on the current page and moves the current
location, accordingly.
The assembler or compiler is permitted to jump tracks, so to speak,
and instruct the assembler to move to a different page or segment, at
any time. Additional strings are then written to that page, instead
of an earlier one. So the expanded list of records would be:
(1) provide a string of bytes
(2) specify an address
(3) specify a named or unnamed page
There can also be so-called "absolute pages" and "relative pages." By
this, the assembler or compiler can have two types of pages -- one
which is forced to a specific location in memory and others where the
linker is permitted some freedom about moving them around when it
needs to composite the final executable. Those which must go at
specific locations are placed first, usually. Then those which can be
moved around are inserted or added where ever they can fit. The order
in which this takes place can vary -- for example, it could be sorted
by name and placed in that order.
Also, it is possible to support segments which overlap -- by this,
another type of page is permitted which can be grouped in such a way
that allocations overlap (the pages are laid down on top of each other
like transparencies might be in order to composite a final image.)
These are so-called "common segments." FORTRAN uses these types, for
example, and so does some BASIC implementations.
Does that help?
Jon
I
ian field
Guest
"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message
news:84jci31svako135nfm2uqj0labt0hnu046@4ax.com...
learned more about all the stuff that has to be written in the ASM file
before the program coding even starts. The book I've just started (PIC in
practice) skips over all this stuff until chapter 6, there is a reference to
a file called "Header.ASM" which is apparently to be included in all the
projects in the book but there is next to no explanation of the first group
of lines that set things up before the coding is entered.
news:84jci31svako135nfm2uqj0labt0hnu046@4ax.com...
Thanks - I've saved your reply so I can refer back to it later when I've
learned more about all the stuff that has to be written in the ASM file
before the program coding even starts. The book I've just started (PIC in
practice) skips over all this stuff until chapter 6, there is a reference to
a file called "Header.ASM" which is apparently to be included in all the
projects in the book but there is next to no explanation of the first group
of lines that set things up before the coding is entered.