Searching \ for '[PIC] Number Guess Project Critique Request' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Number Guess Project Critique Request'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Number Guess Project Critique Request'
2005\01\06@134312 by Nathanial Hendler

flavicon
face
Hello,

I'm not sure what the etiquette is for this, but I figured I'd ask anyway.
I've completed my first PIC project (beyond flashing an LED and turning them on
and off with buttons, etc), and I was wondering if someone would take a look at
my code and give me feedback.  I'm looking for anything; suggestions of better
ways to do things, code style/layout, etc.

It's a simple game where you try to guess a random number between 0 and 15.  It
keeps track of how many guesses and lets you know if you beat the previous
mark.  It uses a 74LS48 to decode BCD to a 7 segment display and has 3 extra
LEDs to show you if your guess was too high, too low, or a winning guess.

Here's the code...

http://retards.org/projects/number_guess/number_guess-1.0.asm

Thanks,
Nathanial Hendler
Tucson, AZ USA
http://retards.org/

2005\01\06@161625 by Tim_webb

flavicon
face
just an Idea if you were trying to reduce components and current draw, you could write firmware to eliminate the 74S48 BCD to 7 segment display driver, that is if you have enough pins in your pic still.  I didn't see which pic you are using and how many pins you have left, you would only need 3 more pins in addition to the current 4 you are using for the BCD output.

{Original Message removed}

2005\01\06@163810 by Jan-Erik Soderholm

face picon face
tim_webb@agilent.com wrote :

> I didn't see which pic you are using...

It said "LIST P=16f84" in the original source.
And that was maybe one of the things I thought of
commenting, but didn't...

Jan-Erik.

> and how many pins you have left, you would only need 3 more
> pins in addition to the current 4 you are using for the BCD output.
>



2005\01\06@165206 by olin_piclist

face picon face
Nathanial Hendler wrote:
> I'm looking for anything; suggestions of better ways
> to do things, code style/layout, etc.

OK, since you asked:

> ;   PIC 16F84

There are better PICs out there that do more and cost less.  The 16F84 is
also so small that its easy to get into bad programming habits that ignore
paging and don't deal with banking the way they should.

For a replacement, take a look at the 16F648A or the 16F88.

{Quote hidden}

It's good to see you documented the I/O well, and generally tried to
document what is going on in the header.  Far too few people do this at all,
let alone do it well.

>   CBLOCK H'0C'

This is not good.  CBLOCK merely defines a list of symbols with successive
values.  It does not allocate memory.  Only you know that the value of these
symbols happen to be memory addresses.  The right way to do this is to use
the RES directive.  It reserves memory, and won't let you accidentally
reserve the same location twice.  You will also get an error if the
variables don't fit, etc.

>          delay_count
>          temp_w
>          temp_status
>          random_number
>          game_number
>          user_number
>          guess_count
>          high_score
>          blink_count

You missed a golden opportunity for a short explanation of what each
variable is for.  Just an end of line comment behind each one would have
been valuable.

>          game_flags          ;bits used to track status of the game
> #DEFINE FLAG_GAME game_flags, 0 ;unused
> #DEFINE FLAG_BLINK game_flags, 1 ;blink leds?

It's a good idea to define each flag bit symbolically.  For the next level
up, see the /FLAG directive of my preprocessor, which if part of my PIC
development environment described at http://www.embedinc.com/pic.  This
automatically allocates bytes to hold the flags as needed.  It also creates
symbols for the flag bit, the register containing the flag bit, and the bit
number within the register.

> #DEFINE BUTTON_START PORTB, 4
> #DEFINE BUTTON_SELECT PORTB, 4
> #DEFINE BUTTON_UP PORTB, 5
> #DEFINE BUTTON_DOWN PORTB, 6
> #DEFINE LED_UP PORTA, 0      ;guess is too high LED
> #DEFINE LED_DOWN PORTA, 1    ;guess is too low LED
> #DEFINE LED_WON PORTA, 2

Symbolic definitions of I/O pins is good.  This way there is one place to
change if pins get moved around, code gets ported to a different PIC, etc.
To take this a step further, take a look at the /INBIT and /OUTBIT
directives of my preprocessor.

>          ORG     0

ORG implies absolute mode, which is a bad idea from a bygone era that only
promotes irresponsibly written software.  Use relocatable mode and the
linker, and don't look back.

>          ORG     4
>
>                              ; Save registers
>          movwf   temp_w      ;save W
>          swapf   STATUS, W   ;save STATUS
>          movwf   temp_status

This is fine for the PIC you used, but a more general interrupt service
routine will need to deal with PCLATH.  With a little assembly time logic,
you can write this once and have the assembler automatically insert the code
when it's needed.  Or, you can use my QQQ_INTR.ASPIC interrupt routine
template where I've already done all that.

>          incf    random_number, f

This is again OK for a 16F84, but also shows one of the dangers of starting
with such a small processor.  In general PIC programming, you always have to
think about the bank for every reference to data memory.  This can be hard
to learn after the fact.  Go do a project on a 16F876 or something and you
won't get away with this.

I deal with this with my DBANKIF and related macros in STD.INS.ASPIC.  These
use assembly time state to track the bank and emit only the instructions
necessary, if any, to make sure the desired bank is set.  They therefore do
no harm when not needed, but lets you write code that works on any processor
without overhead of bank swapping on processors that don't need it.

>          call    blink_leds  ;we're blinking, go do it

You should think long and hard about making calls from the interrupt
routine.  Every stack location use during an interrupt is not available to
any foreground code that runs with interrupts enabled.  In this case I might
have made BLINK_LEDS a macro since it's so short.  Another option would be
to set a flag that causes the foreground code to blink the LED when it gets
around to it.

>          movlw   B'00000111'
>          option

The individual bits should be documented.  You can't expect someone to
remember exactly which options bits do what.  For example:

        movlw   b'00000111'
                ; 0-------  enable port B internal pullups
                ; -0------  select falling edge for INT pin
                ; --0-----  timer 0 source is instruction clock
                ; ---0----  timer 0 edge select, not used
                ; ----0---  assign prescaler to timer 0
                ; -----111  select prescaler divide of 256
        option

>          clrf    guess_count ;guess_count = 0

That's a useless comment.  From the instruction alone it is obvious that
GUESS_COUNT is being set to zero.  That gives you an opportunity to explain
the next higher up logic, like why GUESS_COUNT needs to be zero, what it's
for, etc.  For example (if I guessed correctly what this does):

        clrf    guess_count ;init number of guesses user has made

> select_button:
>          movlw   D'12'       ;debounce
>          call    nmsec
>          btfss   PORTB, 4

You defined nice symbols for all the port pins, but it's worse than useless
if you don't then use them thoughout.  The definitions up top will lead
someone to believe that they are the only thing that needs to be changed if
a pin is moved around.  If they weren't there (I'm not recommending this) at
least someone would know they have to go digging.  What you've done is the
worst of both worlds.

>          movlw   D'12'       ;debounce
>          call    nmsec
>          btfss   PORTB, 5
>          goto    $ -1
>          movlw   D'12'
>          call    nmsec
>          btfss   PORTB, 5
>          goto    $ -5

Ouch!  This is VERY bad practise.  I will go so far as saying never use GOTO
$-n to go more than one instruction back.  It is way too easy to slip some
instructions in there and not notice that that the GOTO has to be changed
several lines later.  DON'T DO THIS.


All in all you've done a reasonable job given your first attempt.  Your
level of documentation is better than most I've seen, although that doesn't
say much.  You seem to have the most of the right concepts, although they
need to be followed thru.  Your next project should be on a large 16 family
PIC so that you're forced to deal with paging and banking.  Otherwise you
may develop bad habits that are hard to break, or build up a code base that
isn't very portable.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\01\07@040815 by Nathanial Hendler

flavicon
face
On Thu, Jan 06, 2005 at 04:51:56PM -0500, Olin Lathrop wrote:
>
> There are better PICs out there that do more and cost less.  The 16F84 is
> also so small that its easy to get into bad programming habits that ignore
> paging and don't deal with banking the way they should.
>
> For a replacement, take a look at the 16F648A or the 16F88.

I have a 16F873 that I can use for my next project.  Will that be a better chip
for me to learn with?  Most of the tutorials that I've seen online use the
16F84 though, so that's why I decided to use it.

> >   CBLOCK H'0C'
>
> This is not good.  CBLOCK merely defines a list of symbols with successive
> values.  It does not allocate memory.  Only you know that the value of these
> symbols happen to be memory addresses.  The right way to do this is to use
> the RES directive.  It reserves memory, and won't let you accidentally
> reserve the same location twice.  You will also get an error if the
> variables don't fit, etc.

I've never heard of or seen the RES directive before.  I will make sure to look
into it.

> It's a good idea to define each flag bit symbolically.  For the next level
> up, see the /FLAG directive of my preprocessor, which if part of my PIC
> development environment described at http://www.embedinc.com/pic.

You've mentioned your preprocessor in other posts as well.  It seems very nice,
but I'm using the gpasm and linux for my development and your system appears to
require windows/dos.

> ORG implies absolute mode, which is a bad idea from a bygone era that only
> promotes irresponsibly written software.  Use relocatable mode and the
> linker, and don't look back.

It seems that all the tutorials and introductions to the pic I've seen use ORG.
I don't know that I've seen any examples of it done any other way.  Do you know
of any examples?  I don't know what "relocatable mode" is.

{Quote hidden}

That is very nice, I will definitely take up the practice of display bits like
that.

> Your next project should be on a large 16 family PIC so that you're forced to
> deal with paging and banking.  Otherwise you may develop bad habits that are
> hard to break, or build up a code base that isn't very portable.

Like I said, I'd like my next project to be using the 16F873, but I don't think
I've found any good examples of how to do paging and banking.  Most tutorials
avoid it.  I just haven't found any good examples.  Can you recommend any code
to me to look at?

Thanks for the time you put into looking over my code.  There were many
comments you made that will be with me the next time I sit down and write my
next program.  Thanks again!

Nathan

2005\01\07@081829 by Jan-Erik Soderholm

face picon face
> I have a 16F873 that I can use for my next project.  Will
> that be a better chip for me to learn with?

That's a big question.
One thing is *why* you are learning PICs.
If you are going to *specificaly* learn the PIC16-
line of PICs, that would probably be OK. If you are learning
PICs in general, some would point you to the PIC18-line
of processors. If you are mainly building our own projects
on a hobbyist level, the PIC18-line is a bit easier to learn
and use.

> Most of the tutorials that I've seen online use the
> 16F84 though, so that's why I decided to use it.

Yes, that is a problem, 95% of the tutorials out on
"the net" have passed theirs "best before" date a
long time ago.

> I'm using the gpasm and linux...

Does gpasm support relocatable code development ?
Does that environment has something that replaces MPLINK ?

> It seems that all the tutorials and introductions to the pic
> I've seen use ORG.

Yes, that is a probolem... :-)

> I don't know that I've seen any examples of it done any other
> way.  Do you know of any examples?

I seems to remember that someone on the net did write a
tutorial to relocatable code. And there was a thread some
months ago where I posted a code example (short but
complete and buildable as-is) using reloc code. You could
search the PICLIST archives on http://www.piclist.com...

>  I don't know what "relocatable mode" is.

In short, you write your source code without specifying
any (or just a few) hardcoded addresses. Then the linker
(MPLINK) puts it al together and calculates all addresses.
This makes it possible to write code that can easily be used in
multiple projects without to many (or any at all) changes.

Jan-Erik.




2005\01\07@082801 by olin_piclist

face picon face
Nathanial Hendler wrote:
> You've mentioned your preprocessor in other posts as well.  It seems
> very nice, but I'm using the gpasm and linux for my development and
> your system appears to require windows/dos.

Oh, well.  I have to get work done and don't have time for attitude problems
against Microsoft.

> It seems that all the tutorials and introductions to the pic I've seen
> use ORG.

Yes, there is a lot of bad or old code out there, some of it from Microchip.

> I don't know what "relocatable mode" is.

Then you need to read the MPASM/MPLINK manual.

> Like I said, I'd like my next project to be using the 16F873,

If I remember right the '873 is a downsized '876, which doesn't have the
global RAM in the last 16 locations of each bank.  I would use the 16F876
instead.  It is definitely a full architecture PIC 16 and will force you to
pay attention to banking and paging.

> but I
> don't think I've found any good examples of how to do paging and
> banking.

It's not that hard to do.  The hard part is getting into the mindset to
always think about it.  I don't know why this requires examples.  Read the
data sheet, understand, then do.

> Most tutorials avoid it.

So screw the tutorials.  Try to *understand* what's going on instead of
copying what someone else did.  Then you can write the tutorials.

> Can you recommend any code to me to look at?

I did, but you apparently haven't looked at it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\01\07@104305 by Scott Dattalo

face
flavicon
face
On Fri, 7 Jan 2005, Jan-Erik Soderholm wrote:

<snip>

>> I'm using the gpasm and linux...
>
> Does gpasm support relocatable code development ?

Yes.

> Does that environment has something that replaces MPLINK ?

Yes, gplink is an MPLINK compatible linker.

See the gputils project page for more details:

http://gputils.sourceforge.net/

Scott

2005\01\07@105602 by Alan B. Pearce

face picon face
>> You've mentioned your preprocessor in other posts as well.  It seems
>> very nice, but I'm using the gpasm and linux for my development and
>> your system appears to require windows/dos.
>Oh, well.  I have to get work done and don't have time for attitude

>problems against Microsoft.



I am not sure that it is an attitude problem against Microsoft, more a case
of using tools to hand. However I wonder how well the preprocessor would run
under something like WINE. I suspect it may do quite well, as it is
essentially written as a DOS based application, not a windows one.

2005\01\07@120505 by Nathanial Hendler

flavicon
face
On Fri, Jan 07, 2005 at 08:27:29AM -0500, Olin Lathrop wrote:
> Nathanial Hendler wrote:
> >You've mentioned your preprocessor in other posts as well.  It seems
> >very nice, but I'm using the gpasm and linux for my development and
> >your system appears to require windows/dos.
>
> Oh, well.  I have to get work done and don't have time for attitude problems
> against Microsoft.

Whoa.  ?  I'm only saying that the reason I am unable to explore your
preprocessor is because it runs on windows/dos, and that's not what I use.  I
also don't use a ice cube trays, but I have nothing against them.  Perhaps you
were talking about some one else's attitude problem, and I have just
misunderstood?

> Then you need to read the MPASM/MPLINK manual.

Will do.

> If I remember right the '873 is a downsized '876, which doesn't have the
> global RAM in the last 16 locations of each bank.  I would use the 16F876
> instead.  It is definitely a full architecture PIC 16 and will force you to
> pay attention to banking and paging.

Ok.  And what do you think about the suggestion that I look into the 18F
architecture?

> >Can you recommend any code to me to look at?
>
> I did, but you apparently haven't looked at it.

Are you easily frustrated by all newbies, or is it just me? ;)  You are so
willing to offer help, I have to assume that I'm being really thick here.  You
gave me a link to your website, which has lots and lots of code, which appears
to require your preprocessor, which I can not run.  Anyway, I'll read the
datasheets and MPASM/MPLINK manuals, and give everyone here a rest.

Thanks for your help.

Nathan

2005\01\07@132845 by olin_piclist

face picon face
Alan B. Pearce wrote:
> I am not sure that it is an attitude problem against Microsoft, more a
> case of using tools to hand. However I wonder how well the preprocessor
> would run under something like WINE. I suspect it may do quite well, as
> it is essentially written as a DOS based application, not a windows one.

I don't know what WINE is, but the preprocessor is Windows based.  It is a
full 32 bit app that makes Win32 calls, not DOS calls.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\01\07@133302 by olin_piclist

face picon face
Nathanial Hendler wrote:
> You are so willing to offer help, I have to assume that I'm being
> really thick here.

And that's supposed to make me want to help you?

> You gave me a link to your website, which has lots and lots of
> code, which appears to require your preprocessor, which I can not run.

Yes, but you asked for examples.  You don't have to build a piece of code
for it to serve as an example.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\01\07@135250 by Alex Harford

face picon face
On Fri, 7 Jan 2005 13:28:12 -0500, Olin Lathrop wrote:
> Alan B. Pearce wrote:
> > However I wonder how well the preprocessor
> > would run under something like WINE.
>
> I don't know what WINE is, but the preprocessor is Windows based.  It is a
> full 32 bit app that makes Win32 calls, not DOS calls.

WINE stands for Wine Is Not an Emulator.

It's an open source implementation of the Win32 API for Linux, but
it's not 100% complete, so some of the more obscure calls may not work
properly.

Alex

2005\01\07@141132 by Dennis J. Murray

picon face
Olin:

WINE is a pretty good Windows EMULATOR that runs under Linux.  I've had
very good luck running DOS applications under WINE and MOSTLY good luck
with Windows apps.

I'd be very surprised if your preprossor didn't run just fine under it!

Dennis

Olin Lathrop wrote:

{Quote hidden}

2005\01\07@141751 by Dennis J. Murray

picon face
OK, Alex. I know this is slightly off-topic, and I know what WINE stood
for, but I've always thought of it as an emulator. It sure has the look
& feel of an emulator. So--------- what exactly IS it (other than "an
open source implementation.....")????

If this is going to be a long explanation, please send it to me off list.

Thanks!
Dennis

Alex Harford wrote:

{Quote hidden}

2005\01\07@141903 by Rob Young

picon face
I think it was one of Olin's (or Russell's, posts are coming out of sequence
so it gets hard to follow) posts that asked what WINE is with respect to
Linux/Unix.  This is from the FAQ at http://www.winehq.com.  Also, this post might
be just on the edge of acceptable for a [PIC] tag.  If somebody replies to
this to discuss WINE and Linux maybe we should move to [OT].

I remember trying to run the MPLAB stuff with WINE some time ago (3 or 4
years) and it didn't work.  Did it just for my own entertainment, didn't
then and still don't know enough about Linux to fix WINE issues at the
source code level.

----- begin quote from FAQ -----

2. General Questions about Wine

2.1. What is Wine and what is it supposed to do?
Wine is a program which allows the operation of DOS and MS Windows programs
(Windows 3.x and Win32 executables) on UNIX operating systems such as Linux.
It consists of a program loader, which loads and executes a Windows binary,
and a set of libraries that implements Windows API calls using their UNIX or
X11 equivalents. The libraries may also be used for porting Win32 code into
native UNIX executables, often without many changes in the source. Wine is
free software, and its license (contained in the file LICENSE in each
distribution) is the LGPL.

----- end quote from FAQ -----


For what it is worth, I rely heavily on the pre-processor the various
compilers I use and that does tend to make code portability a little tough
sometimes.  But I have found that most compilers/pre-processors have some
kind of #pragma or other self-identifying function that can be used to wrap
around non-portable instructions and make things portable.  Do that too much
and things get to looking ugly and hard to read.

Rob Young

2005\01\07@162309 by M. Adam Davis

flavicon
face
An emulator completely decodes and executes the functions of the object
or system being emulated itself.  ie, a true x86 emulator can run on any
platform, regardless of ISA, endianness, etc.

WINE does not emulate the windows API, it merely transforms windows API
calls into appropiate linux function calls.  Further, it does not
translate the machine language of the programs it is running - it sends
them to the processor as a regular program and intercepts function calls
which it then transforms into linux function calls.

Therefore you could not run WINE on powerpc linux without adding an x86
emulator (such as bochs) under both the program running and WINE.

It's actually quite a drastic difference to the programmer and system
administrator, but to the end user there is little to no difference.  As
far as the end user is concerned, an emulator is something that makes
something else work on something it was not designed to work on.  WINE
fits this description just fine.  (Let me throw in a few more somethings
for added confusion:  The something that somethinged the other
somethings was something to behold)

But there is no good common single term to describe what this does
better than 'emulator'

-Adam

Dennis J. Murray wrote:

{Quote hidden}

2005\01\07@185240 by William Chops Westfield

face picon face
On Jan 7, 2005, at 1:23 PM, M. Adam Davis wrote:

>> I know what WINE stood for, but I've always thought of it as an
>> emulator.

The recursive "X is not Y" abbreviations have a long history in "open
source"
software, and a certain amount of hack value is associated with them
if you can come up with ANY justification for the "is not" part.  The
earliest ones that I dealt with were FINE (FINE Is Not EMACS, for
tops10)
and MINCE (MINCE Is Not Complete Emacs, for CPM), dating back to the
late 1970's.  WINE sounds like a "library and system call translation
layer" to me.

In any case, I doubt that Olin would have objections to someone
documenting
a way to run his utilities under linux; but he clearly doesn't have the
time
or inclination to do so himself, which is plenty fair if you ask me...

BillW

2005\01\08@103512 by Byron A Jeff

face picon face
On Fri, Jan 07, 2005 at 12:20:16PM -0500, Nathanial Hendler wrote:
> On Fri, Jan 07, 2005 at 08:27:29AM -0500, Olin Lathrop wrote:
> > Nathanial Hendler wrote:
> > >You've mentioned your preprocessor in other posts as well.  It seems
> > >very nice, but I'm using the gpasm and linux for my development and
> > >your system appears to require windows/dos.
> >
> > Oh, well.  I have to get work done and don't have time for attitude
> > problems against Microsoft.
>

> Whoa.  ?  I'm only saying that the reason I am unable to explore your
> preprocessor is because it runs on windows/dos, and that's not what I use.  
> I also don't use a ice cube trays, but I have nothing against them.  Perhaps
> you were talking about some one else's attitude problem, and I have just
> misunderstood?

Well put. But Olin does have a point. Windows is the virtual standard for
PC based computing. Using anything else, which puts you decidedly out of the
mainstream, requires making a choice. And since Windows is the virtual
standard, that choice usually has some underlaying reason for it.

To extend your analogy (metaphor?) it's like you deciding to use ice cube
trays when every fridge comes with an ice maker.

It's probably that he's seen enough raving Linux lunatics, such as myself
;-), to make that snap assessment.

OTOH Olin is well on his way to being an open community guy. He publishes
much of is code, and the protocols for his line of programmers are openly
documented.

> > Then you need to read the MPASM/MPLINK manual.
>
> Will do.

Then go and read Craig Franklin's GPLINK manual which comes with the gputils
that you are using. You have a linker, you just have to learn to use it.

>
>> If I remember right the '873 is a downsized '876, which doesn't have the
>> global RAM in the last 16 locations of each bank.  I would use the 16F876
>> instead.  It is definitely a full architecture PIC 16 and will force you
>> to pay attention to banking and paging.
>
> Ok.  And what do you think about the suggestion that I look into the 18F
> architecture?

It's always a good suggestion as the memory architecture is greatly
simplified. While it still has forms of banking, the extended instruction
set does have instructions for accessing any memory location directly.
Take a read of chapter 7 of the 18C reference manual for a complete
description.

But Olin's point still stands: the tools have a linker which will manage
both program and data memory allocation. We should all be using it. Every
other system up the chain that we use does this as an underlaying foundation
so that it's transparant to us. However when you get to bare metal you have
to make linking an explicit activity. In short it requires some forethought
and some work to setup. And the inertial combination of limited information,
tons of absolute code floating around, and early success with absolute code
deters most folks from progressing beyond its use. Olin and most other
professionals have enough projects that they need to build a library of core
routines to give a scaffolding (sp) to each project. Most hobbyist won't
take the time to build that infrastructure. So they simply never get around
tuit ;-)

Olin, on the flip side most newbies and hobbyist just want early project
success. That's why tutorials are important to them because it leads them
to early success without having to decypher the entire Rosetta Stone first.

As an example I present Craig Franklin's GPLINK tutorial:

http://gputils.sourceforge.net/reloc_howto.html

Note that Craig points out the same thing that Olin does: there's no
substitute for the complete manual.

But a document like this gives the opportunity to get your feet wet, have
early success, and then follow up with a complete dissection of full manual.

>
> > >Can you recommend any code to me to look at?
> >
> > I did, but you apparently haven't looked at it.
>
> Are you easily frustrated by all newbies, or is it just me? ;)

It's not just you. Of course Olin's code is negated by the need for his
preprocessor. OTOH you didn't bring to the table that you were using Linux
and gputils.

So call it even and move on.

Craig's tutorial has what you need to get started.

> Anyway, I'll read the
> datasheets and MPASM/MPLINK manuals, and give everyone here a rest.

There is one last point to be made. The use of relocatable objects is choice.
While it is Olin's strong opinion, it is an opinion. If absolute code using
the 16F of your choice works for you, then use it. Just be aware that
the linker is designed to lay out code and variables for you, and to make
it easier for you to reuse modules of code.

But it isn't an ABOSLUTE ;-) requirement.

I would also suggest that you take up any gplink inquires up on the
gputils list. You can find that information at http://gputils.sf.net

And don't let Olin scare you away. No matter what the presentation, everyone
here does want to help.

BAJ

2005\01\08@123434 by Peter L. Peres

picon face


On Fri, 7 Jan 2005, Olin Lathrop wrote:

> Alan B. Pearce wrote:
>> I am not sure that it is an attitude problem against Microsoft, more a
>> case of using tools to hand. However I wonder how well the preprocessor
>> would run under something like WINE. I suspect it may do quite well, as
>> it is essentially written as a DOS based application, not a windows one.
>
> I don't know what WINE is, but the preprocessor is Windows based.  It is a
> full 32 bit app that makes Win32 calls, not DOS calls.

WINE is a windows emulator that emulates the win32 environment at dll
and syscall level. It allows win32 programs to run under *nix/X11 . For
example MPLAB up to 6.x at least runs in WINE under *nix . Most programs
made by a certain well-known software company will not run under WINE
for the simple reason that they use a lot of system calls and dll
functions which are not documented in their own documentation, so they
cannot be implemented.

Peter

2005\01\10@060932 by Alan B. Pearce

face picon face
>I've begun to look into using Olin's preprocessor with WINE on linux

>as was suggested and will let people know how it works out for me.



I for one, will be interested in seeing how you get on.

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