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

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 10F200 General Purpose Register Addressing'
2008\06\13@203226 by James Nick Sears

flavicon
face
Hey all, I'm working on what might be my first 10F project.  I want to
be sure my code will fit before I order boards, so I'm kind of working
blind here.  I'll probably go ahead and order a PDIP for prototyping,
but in the meantime any help is much appreciated.

On page 16 (PDF page 18) of the PIC10F200 datasheet (
http://ww1.microchip.com/downloads/en/devicedoc/41239A.pdf ) it says

"The General Purpose Register file is accessed, either directly or
indirectly, through the File Select Register (FSR).  See Section 4.9
"Indirect Data Addressing: INDF and FSR Registers"

Does this mean that an instruction like

movwf 0x18

will not work, and that everything has to go through FSR and INDF, or
just that indirect addressing is available?

Thanks,
-n.

2008\06\13@210344 by William Bross

picon face
n-
Look at the example 4-1.  It has examples of both direct access like you
are asking about and indirect access using the FSR to point to your
destination location.  The misplaced comma in the section of manual you
cite is a little confusing.  Quick answer to your question -- it works.

Bill


James Nick Sears wrote:

{Quote hidden}

2008\06\14@054312 by Tamas Rudnai

face picon face
Hi,

You can order 10F202 for prototyping, that is the same as 10F200 but has
twice as much program memory and a bit of more ram as well. When you
finished with the functionality, you can check the size of your code and ram
usage, and then you may try to optimize the code if necessary to fit into a
10F200.

> will not work, and that everything has to go through FSR and INDF, or
> just that indirect addressing is available?

You don't have to use FSR/INDF, but you can... However, I'd suggest not to
use numbers as ram addresses, but defining variables in 'cblock' or 'res'
instead.

Tamas


On Sat, Jun 14, 2008 at 1:32 AM, James Nick Sears <spam_OUTlistsTakeThisOuTspamjamesnsears.com>
wrote:

{Quote hidden}

> -

2008\06\14@060445 by Jan-Erik Soderholm

face picon face


Tamas Rudnai wrote:

> However, I'd suggest not to
> use numbers as ram addresses, but defining variables
> in 'cblock' or 'res' instead.

Not CBLOCK (more or less as "bad" as EQU).
Use the RES directive only.

Jan-Erik.

2008\06\14@060858 by David Meiklejohn

face
flavicon
face
James Nick Sears wrote:
>
> On page 16 (PDF page 18) of the PIC10F200 datasheet (
> http://ww1.microchip.com/downloads/en/devicedoc/41239A.pdf ) it says
>
> "The General Purpose Register file is accessed, either directly or
> indirectly, through the File Select Register (FSR).  See Section 4.9
> "Indirect Data Addressing: INDF and FSR Registers"
>
> Does this mean that an instruction like
>
> movwf 0x18
>
> will not work, and that everything has to go through FSR and INDF, or
> just that indirect addressing is available?

What they're getting at is that (unlike midrange parts), on baseline PICs,
like the 10Fs, FSR plays a role in both direct and indirect addressing.
Why?  It's because the bank selection bits are the top three bits of FSR.
That can be a real pain - it's an annoying limitation of that architecture,
although only really restrictive if you're trying to mix direct and indirect
register accesses, when more than 1 bank is involved.  If you're not doing
any indirect access, don't worry about it - just use "banksel" as usual, and
all will be fine.

David Meiklejohn
http://www.gooligum.com.au



2008\06\14@082724 by olin piclist

face picon face
James Nick Sears wrote:
> Hey all, I'm working on what might be my first 10F project.  I want to
> be sure my code will fit before I order boards, so I'm kind of working
> blind here.

So don't do the board until the code is done.  Since it will have 256
instructions at most it can't take that that long to write, and the
simulator should let you debug and verify it.  I have never yet debugged a
10F project with anything other than the simulator because it hasn't been
necessary.  And yes, I've done quite a few 10F projects.

> I'll probably go ahead and order a PDIP for prototyping,

Why?  That will require at least one more step to final boards because they
will need the SOT-23 package.  If the final boards will have a 8 pin DIP,
then there isn't much point to a 10F.  You might as well go with a small
12F.

> "The General Purpose Register file is accessed, either directly or
> indirectly, through the File Select Register (FSR).

They put the comma in the wrong place.  It should be after directly, not
after indirectly.

A quick look at the instruction set shows that direct addressing is
possible.  The 10Fs are just small package implementations of the 12 bit
core.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@084229 by Tamas Rudnai

face picon face
> Not CBLOCK (more or less as "bad" as EQU).
> Use the RES directive only.

It's less as bad as you cannot put two variables into the same location :-)
But I agree, using linker script and res is the proper way.

Tamas



On Sat, Jun 14, 2008 at 11:04 AM, Jan-Erik Soderholm <
.....jan-erik.soderholmKILLspamspam@spam@telia.com> wrote:

{Quote hidden}

> -

2008\06\14@090532 by olin piclist

face picon face
Tamas Rudnai wrote:
> but defining variables in
> 'cblock' or 'res' instead.

No!  CBLOCK doesn't define variables at all.  It only creates enumerated
constants.  If you see code with CBLOCK used to define variables, fire the
author and get out of there fast.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@091315 by olin piclist

face picon face
David Meiklejohn wrote:
> on baseline
> PICs, like the 10Fs, FSR plays a role in both direct and indirect
> addressing.

No, FSR is totally irrelevant to direct addressing on 10Fs.

> It's because the bank selection bits are the top
> three bits of FSR.

No.  10Fs don't have banks.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@093212 by olin piclist

face picon face
Tamas Rudnai wrote:
>> Not CBLOCK (more or less as "bad" as EQU).
>> Use the RES directive only.
>
> It's less as bad as you cannot put two variables into the same
> location :-)

Yes it is, precisely because you CAN create multiple symbols with the same
value.  If your code assumes these symbols each stand for separate RAM
locations, you've got a bug.

Again, CBLOCK is for creating enumerated assembly time constants.  For
example:

 cblock 0                   ;define the color IDs
        color_red
        color_grn
        color_blu
   endc

 cblock 0                   ;define command IDs
        cmd_nop             ;no operation
        cmd_setname         ;set the unit's name string
        cmd_hcf             ;halt and catch fire
   endc

COLOR_GRN and CMD_SETNAME have the same value of 1.  This is a perfectly
legal and reasonable use of CBLOCK.  However note that this has absolutely
nothing to do with RAM allocation.  Only the RES (reserve) directive does
that.

If a attempt is made to define multiple variables at the same address, it
will get caught.  For example, if in one module you write:

ram1    udata   h'40'
counter  res     1
myval    res     2

and then in another module:

ram2    udata   h'42'
newval   res     1
morestuff res    1

the assembler won't have a problem, but the linker will detect the overlap
and fail.  In this case you are attempting to put the second byte of MYVAL
at the same address as the first byte of NEWVAL.  Actually the linker sees
that the absolute sections .RAM1 and .RAM2 overlap, but the point is that
the system won't let you accidentally allocate two variables at the same
memory location.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@101024 by Dennis Crawley

picon face
On Saturday, June 14, 2008 10:07 AM [GMT-3=CET],
Olin Lathrop  wrote:

> Tamas Rudnai wrote:
>> but defining variables in
>> 'cblock' or 'res' instead.
>
> No!  CBLOCK doesn't define variables at all.  It only creates enumerated
> constants.  If you see code with CBLOCK used to define variables, fire the
> author and get out of there fast.

Yes. but is still confusing.
You can't reset Constants values once they been initialized. (e.g #define,
constant directives)
With Cblock you create constants related to an incremental address (yes you
can reserve consecutive addresses with res directive). You can change and
reset the value stored in that address, which is related to that constant.
People used to call them variables. Technically they are not, but they
behave as. :)

Rgs.
Dennis


2008\06\14@104248 by olin piclist

face picon face
Dennis Crawley wrote:
> Yes. but is still confusing.
> You can't reset Constants values once they been initialized. (e.g
> #define, constant directives)

First, #define doesn't create a constant.  That's what EQU does.  #define
defines a in-line string substitution macro, which is very different from a
constant.

Second, you can't easily redefine string substitution macros defined with
#define.  You'd have to do a #undef followed by a new #define.

> With Cblock you create constants related to an incremental address

No.  CBLOCK only creates constants with incremental *values*.  You can
misuse this mechanism to create constants that happen to have addresses of
RAM locations, then use the constants as the names of variables, but that
would be very bad programming.

> (yes you can reserve consecutive addresses with res directive).

In fact that is the *only* way to do so in MPASM.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@120054 by Apptech

face
flavicon
face
>> Yes. but is still confusing.
>> You can't reset Constants values once they been
>> initialized. (e.g
>> #define, constant directives)

> First, #define doesn't create a constant.  That's what EQU
> does.  #define
...


I can see from this exchange that, while the underlying
concepts are very simple, the way the material is presented
to people causes confusion. Olin obviously has a very
thorough grasp of what does what and of how it can and
should and shouldn't be used.

So - I have no doubt that this is all spelt out in
documentation, but it's easy for beginners to be confused by
such. Is there a reference available that spells this out
clearly enough that a studious beginner can understand it
well and get it right? The corrections and directions from
Olin that are scattered through the recent posts look like
an excellent start to such a guide if it doesn't already
exist.



       Russell


2008\06\14@121253 by Tamas Rudnai

face picon face
I think the confusing is around MPLAB documentation, where when they mention
absolute programming they advise is to use CBLOCK for variable definition.
It has obvious disadvantages like overlapping CBLOCKs as mentined and the
unchecked size of blocks.

Tamas


On Sat, Jun 14, 2008 at 3:44 PM, Olin Lathrop <olin_piclistspamKILLspamembedinc.com>
wrote:

{Quote hidden}

> -

2008\06\14@121453 by James Nick Sears

flavicon
face
On Sat, Jun 14, 2008 at 8:29 AM, Olin Lathrop <.....olin_piclistKILLspamspam.....embedinc.com> wrote:
> James Nick Sears wrote:
>> Hey all, I'm working on what might be my first 10F project.  I want to
>> be sure my code will fit before I order boards, so I'm kind of working
>> blind here.
>
> So don't do the board until the code is done.  Since it will have 256
> instructions at most it can't take that that long to write, and the
> simulator should let you debug and verify it.  I have never yet debugged a
> 10F project with anything other than the simulator because it hasn't been
> necessary.  And yes, I've done quite a few 10F projects.

That's the plan.  Hence the question.

>
>> I'll probably go ahead and order a PDIP for prototyping,
>
> Why?  That will require at least one more step to final boards because they
> will need the SOT-23 package.  If the final boards will have a 8 pin DIP,
> then there isn't much point to a 10F.  You might as well go with a small
> 12F.

Because it costs $1, I can wire the whole thing up on a breadboard in
5 minutes, and after I do I can test the whole project before I order
boards.  And because the final board will have the 3x2 DFN and I don't
feel like dead bugging it with a microscope.

{Quote hidden}

Thanks, I just now noticed that all the instructions specify 0 <= f <=
31.  Got it.

-n.

2008\06\14@121749 by James Nick Sears

flavicon
face
On Sat, Jun 14, 2008 at 9:34 AM, Olin Lathrop <EraseMEolin_piclistspam_OUTspamTakeThisOuTembedinc.com> wrote:

{Quote hidden}

Sounds great, but I just tested with this:

processor 10F200
include <p10f200.inc>

ram udata h'10'
red        res        0
grn        res 1
blu        res 2

ram2 udata h'11'
bad res 0

and it assembled and linked with no errors.  Do I have something set
up wrong in my environment, or am I misunderstanding something?  Not
that it's a big deal in this case -- I'm pretty sure I can handle
assigning 16 bytes manually without overlapping, but would be good to
know for the future.

-n.

2008\06\14@121922 by James Nick Sears

flavicon
face
Oops, strike that last message.  Just realized that the param in res
is the number of bytes, not the index into the data section.  Sorry
bout that, it's been awhile since I've touched asm.

-n.



On Sat, Jun 14, 2008 at 12:17 PM, James Nick Sears
<listsspamspam_OUTjamesnsears.com> wrote:
{Quote hidden}

2008\06\14@125745 by Wouter van Ooijen

face picon face
> No!  CBLOCK doesn't define variables at all.  It only creates enumerated
> constants.  If you see code with CBLOCK used to define variables, fire the
> author and get out of there fast.

Hmmm... I am self employed, so firing myself might be a bit difficult.
But I teach my students to use CBLOCK, I could ask the school to fire
me. Just in case they don't accept my resignation: what is the
alternative (in absolute mode)?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\06\14@132232 by Tamas Rudnai

face picon face
No, you don't use it, you only teach it :-)


On Sat, Jun 14, 2008 at 5:57 PM, Wouter van Ooijen <KILLspamwouterKILLspamspamvoti.nl> wrote:

{Quote hidden}

> -

2008\06\14@141740 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote:
>> No!  CBLOCK doesn't define variables at all.  It only creates enumerated
>> constants.  If you see code with CBLOCK used to define variables, fire the
>> author and get out of there fast.
>
> Hmmm... I am self employed, so firing myself might be a bit difficult.
> But I teach my students to use CBLOCK, I could ask the school to fire
> me. Just in case they don't accept my resignation: what is the
> alternative (in absolute mode)?
>

What Olin ment (and should have written of course)
is "do not use absolute mode"...

Jan-Erik.

2008\06\14@154050 by olin piclist

face picon face
Apptech wrote:
> Is there a reference available that spells this out
> clearly enough that a studious beginner can understand it
> well and get it right?

Yes, the MPASM/MPLIB/MPLINK manual.  In this case the chapter "Directive
Language".  All the directives, including #define, CBLOCK, and RES are
individually described in detail.  That's where I learned it from.

Most of the book is a must-read before writing MPASM code, but this chapter
in particular must not be skipped.  At the very least you need to read it to
understand the general mechanisms MPASM uses and know what's available.
Then you go back and look up details as you write code.  Anyone who thinks
they can save time by not reading it all is being "penny wise and pound
foolish".  In the end, you're going to spend a lot more time until you will
have eventually read it anyway.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@160523 by olin piclist

face picon face
Tamas Rudnai wrote:
> I think the confusing is around MPLAB documentation, where when they
> mention absolute programming they advise is to use CBLOCK for
> variable definition.

But you shouldn't be using absolute mode anyway.  It still exists for
backwards compatibility with ancient code, but is very bad programming given
today's MPASM/MPLIB/MPLINK suite.  Unfortunately  Microchip doesn't actively
discourage absolute mode as they should, and a lot of references to it are
still scattered in the documentation, giving someone not reading carefully
the idea that absolute mode is somehow OK to use.  They should remove all
absolute mode references and put them in a appendix "Absolute Mode For
Backward Compatibility".


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@161145 by olin piclist

face picon face
James Nick Sears wrote:
> processor 10F200
> include <p10f200.inc>
>
> ram udata h'10'
> red res 0
> grn res 1
> blu res 2
>
> ram2 udata h'11'
> bad res 0
>
> and it assembled and linked with no errors.

But you didn't allocate any space to BAD.  Your whole RAM2 section is empty.
Change "bad res 0" to "bad res 1" and you will get a link error.

Looking at this again, you didn't read the manual about RES, did you?  YOU
HAVE TO READ THE MANUAL.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@161317 by olin piclist

face picon face
James Nick Sears wrote:
> Oops, strike that last message.  Just realized that the param in res
> is the number of bytes, not the index into the data section.

That's better.  Now try creating overlapping sections and see that the
linker does indeed give you a error.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@161839 by olin piclist

face picon face
Wouter van Ooijen wrote:
> Hmmm... I am self employed, so firing myself might be a bit difficult.
> But I teach my students to use CBLOCK, I could ask the school to fire
> me. Just in case they don't accept my resignation: what is the
> alternative (in absolute mode)?

The alternative is to use relocatable mode.  You really shouldn't be
teaching your students using absolute mode.  It promotes bad programming,
provides no means to allocate RAM, plus other drawbacks.  Set them up with a
template linker file and tell them to ignore the "linker magic" until
they're ready to understand it.  Make them learn right from the start that
variables are reserved with RES.  You can still start out with a single file
with one UDATA section and CODEs instead of ORGs, then get more fancy when
you teach them about the linker magic later.  In the mean time they are no
worse off than in absolute mode, but they won't be learning bad habits they
have to unlearn later.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@180045 by William \Chops\ Westfield

face picon face

On Jun 14, 2008, at 12:42 PM, Olin Lathrop wrote:

>> Is there a reference available that spells this out
>> clearly enough that a studious beginner can understand it
>> well and get it right?
>
> Yes, the MPASM/MPLIB/MPLINK manual.  In this case the chapter  
> "Directive
> Language".  All the directives, including #define, CBLOCK, and RES are
> individually described in detail.  That's where I learned it from.

While I don't doubt that the individual directives are "described in  
detail" in the MPASM manual, I *DO* doubt that the descriptions are  
sufficient for a beginner to really understand the differences  
between constants, string substitutions, macros, variables, reserved  
storage, and literals (and who knows what else.)  That sort of  
understanding generally has to come from having dealt with several  
different languages and different assemblers, struggling with the  
differences in concepts between C's "#define", "const", and "enum" vs  
Pascal's "const" and "set."  A compiler class MIGHT help, but they  
tend to focus on parsing whichever style of language is currently  
popular...

It doesn't help that C's capabilities in this area are primitive, or  
that mpasm combines typical assembler syntax with some C capabilities  
thrown in...

I suppose that a write-up describing the basic principles would be  
possible (with examples from various languages!)  I haven't seen one;  
I'm not even sure what it would be called...

BillW

2008\06\14@180701 by William \Chops\ Westfield

face picon face

On Jun 14, 2008, at 1:07 PM, Olin Lathrop wrote:

> But you shouldn't be using absolute mode anyway.

I would think that absolute mode would have value in teaching and  
understanding a microcontroller and assembler.  "limited resources  
that you must manage yourself in explicit detail."  Have the linker  
do all the work?  You might as well have a "Data Division"...

BillW

2008\06\14@184343 by olin piclist

face picon face
William Chops" Westfield" wrote:
> I would think that absolute mode would have value in teaching and
> understanding a microcontroller and assembler.  "limited resources
> that you must manage yourself in explicit detail."  Have the linker
> do all the work?  You might as well have a "Data Division"...

First, you don't always need to manage things yourself in explicit detail.
In fact usually not, although it's important to be able to on occasion.
Second, relocatable mode allows you the same control that absolute mode does
when you want it.

Take a absolute program and replace every ORG with a absolute CODE, and
replace every CBLOCK used to define variable symbols with a absolute UDATA
followed by RES for each symbol.  Now you've got a relocatable mode program
with exactly the same control as the absolute mode program except that:

1 - The linker will catch it when you accidentally force two variables to
the same RAM address.

2 - The linker can tell you if a code module crosses a page boundary.  If
you really want it to cross a page boundary, you can set up the linker file
to allow it.

3 - You can break the code into multiple seperately assembled modules, each
with its own namespace for local symbols.

4 - If you port the code to another PIC, the tools will tell you if you are
trying to put something in code or data memory where the new chip doesn't
have program memory or general RAM.

If you then continue on and embrace relocatable mode instead of fighting it
you also get automatic allocation of modules to pages with a guarantee that
code in no single module crosses a page boundary.

Relocatable mode is a superset of absolute mode, with some nice things added
so that you don't have to hard code addresses and other assumptions in the
source like you have to in absolute mode.  It lets you write better code
with no downside.  OK, you do have one additional file, the linker file.
The latest Microchip linker files that come with MPLAB pretty much just work
unless you're doing something unusual, so you only need to copy one of them
or one of mine from my PIC development environment at
http://www.embedinc.com/pic.

It's really time to put absolute mode behind us.  Way behind us.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\14@191727 by Jan-Erik Soderholm

face picon face
William "Chops" Westfield wrote:

[About abs vs. reloc mode code...]

> I suppose that a write-up describing the basic principles would be  
> possible (with examples from various languages!)

Actualy I've done that, at least for PIC assembler.
This is for my Swedish speaking customers/friends,
but I guess you'll get the general idea... :-)

http://www.jescab.se/Relocmode.html
http://www.jescab.se/abs_reloc.html

Regards,
Jan-Erik.

2008\06\15@073530 by David Meiklejohn

face
flavicon
face
Olin Lathrop wrote:
>
> David Meiklejohn wrote:
> > on baseline
> > PICs, like the 10Fs, FSR plays a role in both direct and indirect
> > addressing.
>
> No, FSR is totally irrelevant to direct addressing on 10Fs.
>
> > It's because the bank selection bits are the top
> > three bits of FSR.
>
> No.  10Fs don't have banks.

Yes, Olin - as usual, you are right (I checked).

However - if Microchip ever releases a 10F with more data memory, I'd put
money on it using FSR<7:5> for bank selection, like every other 12-bit core
PIC...


David Meiklejohn
http://www.gooligum.com.au




2008\06\15@101528 by Nicola Perotto

picon face
Hi David,
you are completely wrong!
I just read the datasheet of 10F220, 12F629 amd 12F510 and the FSR
register is always an whole 8 bit data pointer.
Cheers
  Nicola


David Meiklejohn wrote:
{Quote hidden}

2008\06\15@115840 by olin piclist

face picon face
Nicola Perotto wrote:
> Hi David,
> you are completely wrong!
> I just read the datasheet of 10F220, 12F629 amd 12F510 and the FSR
> register is always an whole 8 bit data pointer.

Then you didn't read very well.  In the 10F22x data sheet (DS41270E) section
4.9 "Indirect Addressing" on page 20 it very clearly says that the upper 3
bits of FSR are unimplemented and read as 1.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\15@162228 by Nicola Perotto

picon face
You are right, I simplified because my english is bad...
What I wnated to say is that FSR is a simple pointer with no particolar
use of any bit (of course if the memory is small some bit are unused).


Olin Lathrop wrote:
{Quote hidden}

2008\06\15@192017 by David Meiklejohn

face
flavicon
face
Nicola Perotto wrote:

> You are right, I simplified because my english is bad...
> What I wnated to say is that FSR is a simple pointer with no particolar
> use of any bit (of course if the memory is small some bit are unused).
>
>
>> Nicola Perotto wrote:
>>
>>> Hi David,
>>> you are completely wrong!
>>> I just read the datasheet of 10F220, 12F629 amd 12F510 and the FSR
>>> register is always an whole 8 bit data pointer.

Nicola - before you say I'm completely wrong, go read that 12F510 data
sheet again.

I agree that on the 10Fs, the upper 3 bits of FSR are not used for paging
- because the 10Fs only have a single page (as Olin said).  And since the
12F629 is a midrange device (unlike 10F* and 12F5*), FSR isn't used for
paging.

But - please go back and look at page 25 of the 12F510 data sheet
(DS41268D).  Bit 5 of FSR is used for bank select - for direct addressing.
So on the 12F510 (and 12F509, 16F505, 16F506, 16F57, 16F59 etc.) FSR is
in fact used in direct addressing.  Not just indirect.


David Meiklejohn

2008\06\16@024756 by Tamas Rudnai

face picon face
Guys, before you go till the first blood, take a look at that datasheet
again. It could be confusing as in Table 4-1 and 4-2 does not even mention
anything about paging with the FSR. In fact, with the 12F510 they even
mention a wrong power-on reset value (100x xxxx, however only bit 5 is used
as banking). The only indication that something is weird with FSR is that
the upper 3 bits are not full set after the POR. Same mistake with the
12C5xx and 12F508/12F509/16F505 datasheets.

Tamas


On Mon, Jun 16, 2008 at 12:19 AM, David Meiklejohn <RemoveMEdavidTakeThisOuTspamgooligum.com.au>
wrote:

{Quote hidden}

> -

2008\06\16@032719 by Apptech

face
flavicon
face
> Guys, before you go till the first blood, take a look at
> that datasheet
> again. It could be confusing as in Table 4-1 and 4-2 does
> not even mention
> anything about paging with the FSR. In fact, with the
> 12F510 they even


All this seems to me like an excellent indication that there
is a place for a simple and definitive guide written at a
level that a typical beginner and/or amateur user could
understand.

Long long long ago I read a book that taught me
proportionately more about microprocessors compared to what
I already knew than any other book or course has even done.
I started knowing nothing and ended it knowing much of what
I needed to know to become competent in the subject. The
absolute level of knowledge is not the issue. That book was
immensely hard for me to absorb. I went over it time and
again and remember how immensely hard it was to get a good
overall picture. I have not read the book for decades now.
But I am certain that if I were to do so there would be
nothing hard or puzzling in it. It would probably appear
trivial and simplistic. The book? - "Osborne 1 - an
introduction to microprocessors". The author in fact did a
superb job of explaining all the key concepts well enough
that they could be understood if you worked at it. But I was
not the only one who found it hard. He went on to write
"Osborne 2 - some real devices". That was extremely useful
and by then I could follow it with ease. He THEN went on to
write "Osborne 0 - <title escapes me>". Osborne 0 was the uP
101/ uP for dummies etc book. If I had had it first (it was
then years away) it would have greatly eased my rites of
passage. So probably best that I didn't. Nowadays Osborne 0
would probably seem almost banal. But it's probably about
right for beginners. It's very very very hard for an expert
to realise how very very hard some "utterly trivial" matters
can seem.

SO I suspect that there is a place for an "Osborne 0 -
Fundamental PIC data access & addressing issues".

Any takers?

Odds are the available references are the Osborne 1 of the
subject. So trivial to eg Olin* that it may be hard to not
feel that people are not trying very hard if they have
trouble following them. So obtuse to a beginner that they
can't see why eg Olin may find it hard not to be impatient
with them. Both highly understandable if you ever learned
your basic uP principles from "Osborne 1" :-)


       Russell

* I cite Olin as the example high-expert here, as he is one.
While his approach to responding on this thread isn't quite
the way I would have handled it, I have been impressed at
his reserve and cool calm competence. Hopefully an Osborne 0
of PICs will eventuate somewhere (he may have to write it
:-) ) to make the role easier in future.


2008\06\16@053139 by Tamas Rudnai

face picon face
> SO I suspect that there is a place for an "Osborne 0 -
> Fundamental PIC data access & addressing issues".

That's a good idea. Actually once I was thinking about a project to collect
issues as "everything that is missing from the datasheet" style.

If no one desperately want to do this I can start working on it.

Tamas



On Mon, Jun 16, 2008 at 8:24 AM, Apptech <spamBeGoneapptechspamBeGonespamparadise.net.nz> wrote:

{Quote hidden}

> -

2008\06\16@064527 by David Meiklejohn

face
flavicon
face
Tamas Rudnai wrote:
>
> Guys, before you go till the first blood, take a look at that datasheet
> again. It could be confusing as in Table 4-1 and 4-2 does not even
> mention
> anything about paging with the FSR. In fact, with the 12F510 they even
> mention a wrong power-on reset value (100x xxxx, however only bit 5 is
> used
> as banking). The only indication that something is weird with FSR is
> that
> the upper 3 bits are not full set after the POR. Same mistake with the
> 12C5xx and 12F508/12F509/16F505 datasheets.

I suppose this is relevant to the discussion that comes up sometimes, when
someone says "RTFM", the response to that is that data sheets can be hard to
interpret.  I agree with that to some extent, but in this case I think that
Microchip have made it as clear as can be.

Where would I look for information about how banking works?  In the 12F510
data sheet, that's section 4.2, "Data Memory Organization".  It states "The
General Purpose Register file is accessed either directly or indirectly
through the File Select Register (FSR)."  This is the very statement that
started this discussion - clearly whoever wrote the 10F200 data sheet copied
that text from another device's data sheet (forgetting, as I did, that it
doesn't strictly apply to the 10F200).  But for the 12F510, that statement
about the role of FSR is there, where it belongs, and it's perfectly true.
It's also illustrated by a diagram: Figure 4-2 shows the 12F510 register
map, with the role of FSR<5> clearly shown at the top of it.

Now, you could argue that if you didn't happen to look at the section on
banking, you wouldn't know about the role of FSR in banking on the 12F510
(and similar baseline PICs).  But I'd argue that that's a pretty fundamental
part of the data sheet to look at - I normally glance that that, for any
PIC, to see quickly how the registers are laid out.

Anyway, I'll leave it here on this one!  :-)


David Meiklejohn




2008\06\16@070101 by David Meiklejohn

face
flavicon
face
Tamas Rudnai wrote:
(Russell had written:)
> > SO I suspect that there is a place for an "Osborne 0 -
> > Fundamental PIC data access & addressing issues".
>
> That's a good idea. Actually once I was thinking about a project to
> collect
> issues as "everything that is missing from the datasheet" style.

Yeah - I wrote in my last note about how "RTFM" isn't always a good answer,
because some things are hard to figure out from just looking at the data
sheets.  Sure, they explain the toolset well (in plenty of detail, in
general - even explaining traps like the RMW issue - so I wouldn't say that
anything was really "missing" from them), but not how to put it all
together, or what these things might be used for, or how people generally go
about doing things.  For some people it's just too hard a wall to climb -
they end up copying and adapting bits of code (thinking of the Microchip
forum here...) without ever quite understanding what they are doing or why.

That's why I started writing tutorials myself:
http://www.gooligum.com.au/tutorials.html.  They are based (so far) on the
baseline architecture, which I came to know reasonably well, which is why I
was banging on about the role of FSR in addressing.  It's covered in a
couple of the baseline assembler tutorials: lesson 3 on banking, while
lesson 10 demonstrates indirect memory access (with an application that
annoyed Olin - I take his point, but I think the filter example serves its
purpose).

I don't claim that those tutorials are the answer for "Fundamental PIC data
access & addressing issues" by any means, although they've been well
received.  Personally I'd find my own tutorials too slow paced for me to
want to learn from, but then I'm not my target audience.

So Tamas, you can't wait for someone else to write up that project, because
everyone has their own style that will appeal to different people.  So
please go ahead and put it together, and I'm sure plenty of us will benefit
from it.


David Meiklejohn



2008\06\16@082055 by olin piclist

face picon face
Apptech wrote:
> It's very very very hard for an expert
> to realise how very very hard some "utterly trivial" matters
> can seem.

Those of us who know this stuff all learned it at some point.  And us old
farts had to do that without the internet with its enourmous library and
world wide experts to answer questions.  As a result, we had to sit down and
actually *think* about a problem and maybe experiment instead of blurting
out a question the moment we got stuck.

Now don't get me wrong.  I think the internet can be a great learning tool
and should be used as such, but a infinite amount of immediately available
information is not in itself a teacher.  In fact, it can sometimes prevent
or delay true learning because it's too easy to just look up a answer when
needed.  That gets you the answer, but it doesn't mean you have learned the
principles to come up the answer yourself next time.

All too often today's students try to short cut their assignments by asking
for answers at the first sign of trouble.  They seem to have forgotten the
purpose of the assignment is not the end result, but the process which is
intended to foster learning.

Maybe a basic introduction to microcontrollers would have some value, but
there is plenty of existing material out there.  The PIC datasheets are
actually a very good source since they tell you what you need to know and
are well written.

My first introduction to the subject was when my high school got a PDP-8
(sortof a 12 bit PIC in a rack mounted box) my junior year.  I had only
interacted with computers via Basic and Fortran before.  I took the manual
home over spring vacation and figured I'd learn this computer's language.
What I found was totally different than expected.  I hadn't thought about a
computer at the instruction level before.  There was this huge gap between
Basic code and these instructions to the point where I couldn't even see how
the two related.  I remember wondering how I missed the multiply and divide
instructions because I knew I could multiply and divide in Basic.  Then I
got to some example code that implemented a multiply, and it slowly started
to make sense.

I probably read the two books three times each during that week, each time
filling in information that was so out of context in the previous pass that
it didn't make any sense then.  By the time school started again, I could
toggle in simple programs and had a reasonable understanding what was going
on.  When I got stuck, I had to figure it out.  None of the teachers knew
any of this stuff.  There was nobody else to ask.  I had no choice but to
sit down and actually learn it.

The point is, all the information was in the two manuals, just like all the
similar information is in a PIC datasheet.  All it takes is motivation and
some effort.  I did it with the equivalent of a PIC manual in one week in
1973 with no internet and nobody to ask, not even the computer to experiment
with until I'd read the manuals three times.

So no, I don't have much tolerance for someone whining about how the PIC
manuals are so hard, especially when the vast library of the internet, the
PIC simulator, and the PICs themselves are readily available.  I have no
problem helping someone when they get stuck, but they have to have tried to
do their own homework first.

Frankly, the ones that can't be bothered aren't worth the bother anyway.
Those that have a true passion for electronics and microcontrollers are
going to preservere, and will be better off for having put in their own
effort.  Those that don't have the passion will only ever be mediocre
engineers at best, and would be better off finding something else to do.

By the way, I still have one of the two book, the DEC "Small Computers
Handbook".


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\16@085710 by Mike snyder

picon face
On 6/16/08, Olin Lathrop <TakeThisOuTolin_piclistEraseMEspamspam_OUTembedinc.com> wrote:
>
> By the way, I still have one of the two book, the DEC "Small Computers
> Handbook".
>

The PDP-8 manuals are available at

http://highgate.comm.sfu.ca/pdp8/

It is pretty interesting as to how much details they go into - even
into the manufacturing process...

2008\06\16@090206 by Mark Rages

face picon face
On Mon, Jun 16, 2008 at 7:23 AM, Olin Lathrop <RemoveMEolin_piclistspamTakeThisOuTembedinc.com> wrote:
> Apptech wrote:
>> It's very very very hard for an expert
>> to realise how very very hard some "utterly trivial" matters
>> can seem.
>

... <elided "it was hard for me, it should be hard for you too" argument>

>
> Frankly, the ones that can't be bothered aren't worth the bother anyway.
> Those that have a true passion for electronics and microcontrollers are
> going to preservere, and will be better off for having put in their own
> effort.  Those that don't have the passion will only ever be mediocre
> engineers at best, and would be better off finding something else to do.

I saw this same elitist argument on slashdot a few years ago when the
easy-to-install Linux distributions came about. Something like "It
took me a week to install Debian, these newbs with the fifteen minute
Ubuntu install are going to be the downfall of Linux!"

The argument was just as wrong for Linux, as it's wrong here.  The
community was strengthened by the infusion of people who do not lead
lives centered around computers.  People with design sense, people who
want things to work as simply as possible and who wouldn't tolerate
complexity just because it comes with the history of Unix.

The same argument has been directed at Wikipedia (by credentialed
academics) and weblogging (by professional journalists).  Amateur
newcomers using their tools badly, without training, and who haven't
learned all the hard lessons yet.

In the case of microcontrollers, it makes even less sense to restrict
their application to people with "passion" for microcontroller
programming.  By their very nature, micros are best suited to solving
problems in other domains.  So someone with a passion for robotics, or
data collection, or industrial control, can indulge *that* passion by
reading "PICs for dummies" and be only an adequate microcontroller
user.   This does not weaken the PIC community. It strengthens it.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
markragesEraseMEspam.....midwesttelecine.com

2008\06\16@090245 by Tamas Rudnai

face picon face
> All too often today's students try to short cut their assignments by
asking
> for answers at the first sign of trouble.  They seem to have forgotten the
> purpose of the assignment is not the end result, but the process which is
> intended to foster learning.

But it's also the way how today they teach students in many schools. They
don't teach how to thinking or solving problems or gathering information
from books / internet. They teach only how to pass exams and then the
trouble starts when the first problem occurs at their very first job. I
remember I was learning assembly of the 6502 when I was 15, I had an Apple
II and there was no other book than some German ones - and of course I did
not speak German at all, but still could get all the trouble to get it
understand and got all information out what I needed. Also reverse
engineering was a very good teacher of mine - I think now if you just pass a
solution of a multiplication to a student they will use it but don't really
bother to get it understand what it does and how it works.

I hope now there will be some response saying the opposite I said and tell
me how I am wrong as students are very much interested on understanding
these. Maybe Wouter could tell me his experience with his pupils?

Tamas



On Mon, Jun 16, 2008 at 1:23 PM, Olin Lathrop <EraseMEolin_piclistspamembedinc.com>
wrote:

{Quote hidden}

> -

2008\06\16@094101 by Nicola Perotto

picon face
I'm a little younger but have learned to program my Commodore Vic20 in
your same way.
Only with the Basic manual and a book on assember.
And for every new pic I use, I read the datasheet.
I was wrong on the 12F510 just because (never used and never read his
datasheet) i read in a hurry only the first page where i found FSR...
I'm sorry for my mistake, David.
Cheers
     Nicola

Olin Lathrop wrote:
{Quote hidden}

2008\06\16@095118 by Wouter van Ooijen

face picon face
> SO I suspect that there is a place for an "Osborne 0 -
> Fundamental PIC data access & addressing issues".

If only such books were still written! When I was 18 they were available
only in the reading room of the university library - I spend many an
hour there!

But IIRC 0 was the fundamentals, 1 was the 'real products'? Or do you
envision a 0 for the PIC and a filled with all the different chips?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\06\16@130319 by Alan B. Pearce

face picon face
>> Frankly, the ones that can't be bothered aren't worth the bother anyway.
>> ...
>
>I saw this same elitist argument on slashdot a few years ago when the
>easy-to-install Linux distributions came about. ...
>
>The argument was just as wrong for Linux, as it's wrong here. ...

I don't believe the argument is wrong here. Things like Linux installations
can be made easier by suitable install programs. Yes programming MCUs can be
made easier by using high level languages but that is defeating the purpose
of learning the chip.

Having to read the documentation is just as necessary whichever way you go -
the high level or the low level route. Yes you can install Linux with a plug
and play CD, but what do you do after that??? You still have to read
documentation to get the system to do anything - been down that route a
couple of times myself, got the GUI up, now where do I go from here ...

Equally programming a small micro requires one to read the documentation to
find out the quirks of the chip. I could 'just' try and fire up a 1W white
LED directly from the I/O pins, and then go screaming to a mail group such
as this about how my circuit 'doesn't work'. What does the documentation say
about the output capability of the I/O pin is the question I'll probably get
back. Doesn't matter what one does, the documents are there to help. If it
is obscure then the time comes to ask questions to clear it up.

Quite frankly I think Olin gave a pretty straight to the point answer
without being snarky. He has pointed out why to use certain directives, and
where the details on them are. I have learnt quite a bit from Olins dev
environment about how the MPLAB linker system works, and the macros Olin has
written, and how they complement the linker suite.

Olins comment that is quoted in the first line of this mail is all too true
in my experience. The people that do get things done, whether it is high
grades for their degree or almost anything else, they have done it by
applying themselves, and that is all that is being asked for here. The
pointers on where to look have been given, now it is up to the learner to go
learn.

2008\06\16@130712 by Alan B. Pearce

face picon face
>> All too often today's students try to short cut their assignments by
>> asking
>> for answers at the first sign of trouble.  They seem to have forgotten
>> the
>> purpose of the assignment is not the end result, but the process which is
>> intended to foster learning.
>
>But it's also the way how today they teach students in many schools. They
>don't teach how to thinking or solving problems or gathering information
>from books / internet.

And they are also the ones who won't make it to Masters or Doctorate level,
may get an unclassified bachelors degree in some obscure arts subject as a
best effort, then go become a high paid whatever in a company where they
keep handing the work down to the minions who have done the study and know
what they are talking about.

2008\06\16@133602 by James Nick Sears

flavicon
face
On Mon, Jun 16, 2008 at 1:02 PM, Alan B. Pearce <RemoveMEA.B.PearceEraseMEspamEraseMErl.ac.uk> wrote:
>>> Frankly, the ones that can't be bothered aren't worth the bother anyway.
>>> ...
>>
>>I saw this same elitist argument on slashdot a few years ago when the
>>easy-to-install Linux distributions came about. ...
>>
>>The argument was just as wrong for Linux, as it's wrong here. ...
>
> I don't believe the argument is wrong here. Things like Linux installations
> can be made easier by suitable install programs. Yes programming MCUs can be
> made easier by using high level languages but that is defeating the purpose
> of learning the chip.

For you perhaps, but not for everyone.  Some of us do MCU projects
because of the MCU.  Others do MCU projects because of the projects.
Most of us are somewhere in between.  But out in the real world most
people don't give 2 craps about an MCU, but they might have an
interesting project they want to make happen.  Are you guys really
saying that you think that's a bad thing?

Whether you think it's a bad thing or not, it's happening.  The
barrier to entry is lowering and people are getting projects up and
running from zero knowledge in record time thanks to the combination
of growing power/mm^2 and higher level languages and tools and
libraries to leverage that power.  Ever hear of Arduino?  99% of the
projects people do here with PICs could be done with Arduino just as
well and in far less time.  The only thing you miss is the 1337 h4x04
status of hacking your own ASM code.  But you know what?  The people
doing those projects don't care.  They're happy doing interesting work
and getting positive feedback and press for it.

Is this to say that everything can be done in HLL and that there's no
need for experts?  Of course not.  I actually do most of my MCU work
in PIC work in C, because I value my time more than I value the puzzle
of getting ASM code working (yes, I do enjoy that too, but I also
enjoy a lot of other things that I don't have time to do, and the
money I make from completing projects -- not just embedded stuff, but
also web, software, design, etc), but this project, because I'm going
to squeeze it onto a 10F demands that I write ASM.  Great, the right
tool for the right job at the right time.  But if there's a way to
make things easier for people, to deride that just because the people
that benefit don't share your singular devotion to the PIC
microcontroller platform is asinine.

I understand the importance of struggle en route to mastery.  But what
you don't understand is that mastery is not everyone's end goal in
every undertaking.  Some people actually see this stuff as a means to
an end.

-n.

2008\06\16@163535 by Apptech

face
flavicon
face
> Having to read the documentation is just as necessary
> whichever way you go -
...


> Equally programming a small micro requires one to read the
> documentation to
> find out the quirks of the chip. ...

> Doesn't matter what one does, the documents are there to
> help. If it
> is obscure then the time comes to ask questions to clear
> it up.
...

> The people that do get things done, whether it is high
> grades for their degree or almost anything else, they have
> done it by
> applying themselves, and that is all that is being asked
> for here. The
> pointers on where to look have been given, now it is up to
> the learner to go
> learn.

I've been watching this thread with some concern.
IMHO, this is the sort of material that can grow into
aflame war quite suddenly when someone gets pushed past some
invisible limit while others are quite oblivious that other
people may be getting annoyed.

The point I was trying to make in my "Osborne 0 for PICs"
suggestion was not that people don't have to do the work to
understand properly but that the concepts involved are
unusual enough that, when faced with what may be foreign
concepts such as "FSR" / high bits / always 1 or not /
direct vs indirect / page - bank - .../ ... which are
FUNDAMENTALLY trivial, the net result  can be to utterly
overwhelm the senses/sensors such that the beginner wanders
in a haze indefinitely and confuses and is confused by
various overlapping sub concepts.

"... applying themselves ..." & "... all that is being asked
..." & " ... go learn ..." & "and 'if it was good enough for
me' uphill in the snow both ways no shoes cardboard box
bottom of a lake"ing can have vastly different meanings
depending on where you are standing and on how good your
vision is re what is involved. Extra non-essential work may
be character forming and bracing and add to the mystique of
the processor concerned and assist you in becoming a
productive and beautiful person, or not, but may not well be
core to what is being tried to be achieved.

I'm  not suggesting that hard work isn't needed, but rather
that the area can generate an arbitrarily high amount of
extra work that is unnecessary and which a truly expert
educator could cut through with a masterful document. (The
apparently banal Osborne 0 versus the apparently trivial but
actually dense Osborne 1). Microchip documents may well
contain all the information (although the occasional error
and misplaced comma which has trivial effect on Olin can
take a week out of the life of a beginner) but Microchip are
certainly not "truly expert educators". There is a vast bow
wave of assumed competence and assumed familiarity in the
material which a just ordinary grand-master after a while
fails to see. It takes an utterly transcendent-master to see
the layers of unnecessary confusion present in the plethora
of material and reach through it to lead the
wannabee-masters to glory. I know that we have utterly
transcendent grand masters here and, should they wish to
turn their talents to it, they would be able to create the
path through the Fire Swamp which otherwise causes so many
to founder. The mechanisms of older PIC addressing are
arcane and quite unlike those of many almost equally
venerable IC's (eg the now widely evolved Motorola MCxx68xx
family which started with the original MC6800 never had the
banking/paging/partial register issues of the early PICS)(I
started with the MC6800 writing machine code by hand without
an assembler and was fortunate that the processor had such a
clean addressing structure).(Actually I started with the
NatSemi SC/MP but that's another story).

It may be that the tutorial material mentioned here the
other day is close enough to the PIC Osborne 0 for
beginners. It probably needs a cooperative gaggle of
beginners and transcendent masters to find out.

Meanwhile, " ... you obviously don't understand ..."ings in
either direction, may or may not be true but may tend to
ruffle feathers more than intended.



       Russell









2008\06\16@173020 by sergio masci

flavicon
face


On Mon, 16 Jun 2008, Olin Lathrop wrote:

{Quote hidden}

Hi Olin,

Speaking as an "old fart" myself I understand exactly what you mean.
However I think you are missing one very important point - computer
related stuff was much less complicated when we were young. We were able
to learn the basics and build on this as technology advanced. We were not
presented with the bewildering mess that many students face today. Trying
to learn something from scratch on your own seems to be a bigger challenge
now than it used to be 30 years ago. For one thing, reference books were
incredible works compared to most of the junk that comes out today.

It is easy to find an incorrect explination and for that to hamper you as
you are trying to learn.

Yes there are some students who just want you to do their assignments but
there are also people that are not lazy and really are genuinly bewildered
and need help.

Regards
Sergio Masci

2008\06\16@191009 by Apptech

face
flavicon
face
>> SO I suspect that there is a place for an "Osborne 0 -
>> Fundamental PIC data access & addressing issues".

> If only such books were still written! When I was 18 they
> were available
> only in the reading room of the university library - I
> spend many an
> hour there!

> But IIRC 0 was the fundamentals, 1 was the 'real
> products'? Or do you
> envision a 0 for the PIC and a filled with all the
> different chips?

IIRC and I think I do, but I would:

In time order.

1    An introduction
2    Real products
0    Lower level intro.



Russell

2008\06\17@081541 by David Meiklejohn

face
flavicon
face
sergio masci wrote:
>
> Trying
> to learn something from scratch on your own seems to be a bigger
> challenge
> now than it used to be 30 years ago. For one thing, reference books
> were
> incredible works compared to most of the junk that comes out today.
>
> It is easy to find an incorrect explination and for that to hamper you
> as
> you are trying to learn.

Indeed that's one of the problems with the Internet.  Who do you trust?

For example, there's a ton of PIC tutorials out there (including mine).  How
do you know what's useful?  Many of them teach bad habits, such as using
absolute mode.  Some things are just plain wrong.  Heck, I've found errors
in my own tutorials when I've gone back and revised them!

Glancing at my own bookshelf, I see "6502 Software Design" by Leo J.
Scanlon, and "68000 Assembly Language Programming", by Kane, Hawkins and
Leventhal, both published in 1981 and both of which I learned a great deal
from - plenty of good advice in both.  Certainly I haven't seen every PIC
book out there, but what I have seen just isn't up to that standard.


David



2008\06\17@083409 by Jinx

face picon face
> Who do you trust?
>
> "6502 Software Design" by Leo J. Scanlon, and "68000
> Assembly Language Programming", by Kane, Hawkins and
> Leventhal, both published in 1981

I have Leventhal's two books on 6502 from the same period,
which I first used on the Commodore 64 and then later 6805
micros. They were university text books and had been vetted.
I still occassionally refer to the methodology. The assembly
listing of the C64 Kernel ("What's Really Inside The Commodore
64") was a great aid to understanding how a micro-based OS
works

2008\06\17@083726 by KPL

picon face
>
> Indeed that's one of the problems with the Internet.  Who do you trust?
>
> For example, there's a ton of PIC tutorials out there (including mine).  How
> do you know what's useful?  Many of them teach bad habits, such as using
> absolute mode.  Some things are just plain wrong.  Heck, I've found errors
> in my own tutorials when I've gone back and revised them!
>
> Glancing at my own bookshelf, I see "6502 Software Design" by Leo J.
> Scanlon, and "68000 Assembly Language Programming", by Kane, Hawkins and
> Leventhal, both published in 1981 and both of which I learned a great deal
> from - plenty of good advice in both.  Certainly I haven't seen every PIC
> book out there, but what I have seen just isn't up to that standard.
>
>
> David


Excuse me, I'll put some words from the opposite side here.
I'm one of those hopeless beginners who just want to solve some
control problems, and PIC seemed a good solution. It seemed a good
reason to learn PICs a bit deeper, it's just plain interesting stuff
anyway.
But we need to do our day jobs, we need to do a lot of different
things at home, we need to get out of home for some fresh air, so
unfortunately we do not have enough time for everything. Life is too
short to learn everything very deeply.
Web is no help here, since it makes bad habits. We are used to learn
small web pages with nice pictures, and after some time we are not
able to read a longer text any more, we get distracted all the time by
something else. It's much easier for me to read few pages of some
tutorials, and may be some example code from piclist.com and solve my
problem, instead of learning all the stuff from official manuals which
are mostly written for professionals who know exactly what they are
looking for.


--
KPL

2008\06\17@083921 by David Meiklejohn

face
flavicon
face
Apptech wrote:
>
> Microchip documents may well
> contain all the information (although the occasional error
> and misplaced comma which has trivial effect on Olin can
> take a week out of the life of a beginner) but Microchip are
> certainly not "truly expert educators".

Maybe they are, or maybe they're not, but data sheets are intended to be
reference, not teaching, devices.  A good data sheet is complete, accurate,
organized in such a way that information is quickly found, and clear.  But
it is not their role to say "this is how you do it".  That's what
application notes are for.  And seminars, tutorials, books and such.

> There is a vast bow
> wave of assumed competence and assumed familiarity in the
> material which a just ordinary grand-master after a while
> fails to see.

Not sure I agree with the transcendent/grand-master stuff, but certainly
data sheets assume a level of knowledge and competence, as a reference work
should.

By the way, as a writer of tutorials, I agree with your point that there is
a role for introductory material that leads beginners through the "Fire
Swamp" (as you put it).  I just don't agree that there's anything much wrong
with Microchip's data sheets.  Yes, I have found errors in them, but on the
whole I think they're quite good.

> The mechanisms of older PIC addressing are
> arcane and quite unlike those of many almost equally
> venerable IC's (eg the now widely evolved Motorola MCxx68xx
> family which started with the original MC6800 never had the
> banking/paging/partial register issues of the early PICS)

Segmented memory on the 8080, perhaps?

> (I
> started with the MC6800 writing machine code by hand without
> an assembler and was fortunate that the processor had such a
> clean addressing structure).

Ah, memories. I used to write 6502 code in hex, sans assembler, while I
should have been studying for my final years in high school.  The scary
thing is that, nearly 30 years later, I can still remember that 'A9' is "LDA
immediate" and 'A2' is "LDA indexed with X".  And yet my wife says I have a
terrible memory!  :-)

>  It may be that the tutorial material mentioned here the
> other day is close enough to the PIC Osborne 0 for
> beginners. It probably needs a cooperative gaggle of
> beginners and transcendent masters to find out.

As I said, I've had positive feedback on my tutorials, but they are not for
everyone, were never intended to be, and cannot be, because we all come at
the subject matter with different backgrounds and abilities and
expectations.  So the best solution is to have a number of solutions, and
let people choose the educational material that's right for them.


David Meiklejohn
http://www.gooligum.com.au




2008\06\17@084258 by Tamas Rudnai

face picon face
I have to disagree here, especially for PIC there are many very good helpers
and tutorials. When I started with PICs just downloaded a free online book
and read it, Then wrote as many led flashers and whatsoever that needed to
get those things clear up. In the meantime read you guys wrote here +
Microchip forum + Google +++ . Much easier than old times, where I had only
one book for 6502, and only a disassembler and a hex editor to enter my
code. When I wanted to ask someone who knew 6502 I had to wait till summer
for the AUGE (if you guys live here in Europe still remember what is this
acronym stands for?), so had to wait for AUGE getting together and find
someone who had enough time for me to explain. Way more easy to learn
nowadays, but many people tend to be more lazy: "I can ask it on forum so
why bother to read articles and books? Plus why bother to understand
algorithms when I can download one that works - if not I can ask people to
fix it for me.." Also it's a bit of problem that people things that
microcontrollers are microcomputers. There is an CPU, ALU, memory and can
write a "program" on it using C or Basic....

Tamas


On Tue, Jun 17, 2008 at 1:15 PM, David Meiklejohn <RemoveMEdavidspam_OUTspamKILLspamgooligum.com.au>
wrote:

{Quote hidden}

> -

2008\06\17@093030 by sergio masci

flavicon
face


On Tue, 17 Jun 2008, Tamas Rudnai wrote:

{Quote hidden}

Sorry Tamas you've missed the point. You've already had your "baptism of
fire" with the 6502 so it is easier for you to know what you want to look
for when looking at a new MCU. Someone who does not have your experience
has to do a hell of a lot of learning before he even has a chance of
understanding how to implement arrays in assembler let alone that he
should be looking for a special addressing mode (indexing / indirect /
base relative / etc). Then for the PIC he needs to see the connection
between the addressing mode and the FSR and somehow tie that in with the
use of IND (which as we know is a special case of direct addressing with
the address field in the instruction set to 0).

To put this another way: how do you do a search for details of indirect
addressing on a PIC if you don't even know what indirect addressing is
(let alone what it is called).

Yes there are lazy people but I have come to belive that many people that
would like to use a cheap MCU like the PIC are simply overwhelmed by how
much there is to learn.

Regards
Sergio Masci

2008\06\17@104952 by Thomas C. Sefranek

face picon face
-----Original Message-----
From: RemoveMEpiclist-bouncesTakeThisOuTspamspammit.edu [EraseMEpiclist-bouncesspamspamspamBeGonemit.edu] On Behalf Of
Olin Lathrop
Sent: Saturday, June 14, 2008 6:46 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC]: 10F200 General Purpose Register Addressing

>Take a absolute program and replace every ORG with a absolute CODE,

For grins, I tried this on my working code...

Error[149]   C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 27 : Directive
only allowed when generating an object file
Warning[220] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 28 : Address
exceeds maximum range for this processor.
Error[118]   C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 28 : Overwriting
previous address contents (000D)
Warning[220] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 28 : Address
exceeds maximum range for this processor.


SO Re-reading the latest version of the MPASM User's Guide,
I entered their example of the CODE directive, it is even WORSE.

Warning[203] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 27 : Found opcode
in column 1. (RESET)
Warning[211] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 27 : Extraneous
arguments on the line.
Warning[220] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 27 : Address
exceeds maximum range for this processor.
Error[118]   C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 27 : Overwriting
previous address contents (000D)
Warning[220] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 28 : Address
exceeds maximum range for this processor.
Warning[220] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 28 : Address
exceeds maximum range for this processor.

Yea, yea, I need a different, more complex build environment, one that will
Take weeks to implement successfully to get this to run.

>It's really time to put absolute mode behind us.  Way behind us.

Not in my world, if I want "the magic', I'll use C.
(I tried that C too, no joy! Too much complexity and built in error.)

So far, I do just fine coding the 79 CAN connected PICs in our latest
machine in absolute mode, ...it works, and my limited brain actually "gets
it".

Clearly, I'm just one of those gimmy kinda guys trying to get thru my
homework on someone else's dime.  :)


>********************************************************************
>Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
>(978) 742-9014.  Gold level PIC consultants since 2000.

You don't have to beat me up Olin, I'm old enough to RTFM, the problem may
be I'm too old to comprehend them.
It's been too long Olin, I hope you are well.
Tom


 *
 |  __O    Thomas C. Sefranek  RemoveMEWA1RHPKILLspamspamARRL.NET
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41MHz PL74.4

ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

2008\06\17@105107 by Alan B. Pearce

face picon face
>To put this another way: how do you do a search for details of
>indirect addressing on a PIC if you don't even know what indirect
>addressing is (let alone what it is called).

Does the midrange manual have anything to say on this? I don't recall
browsing that bit as I am happy with my understanding of FSR and indirect
addressing.

2008\06\17@111918 by Jan-Erik Soderholm

face picon face
Thomas C. Sefranek wrote:

> -----Original Message-----
> From: piclist-bouncesSTOPspamspamspam_OUTmit.edu [spamBeGonepiclist-bouncesSTOPspamspamEraseMEmit.edu] On Behalf Of
> Olin Lathrop
> Sent: Saturday, June 14, 2008 6:46 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC]: 10F200 General Purpose Register Addressing
>
>> Take a absolute program and replace every ORG with a absolute CODE,
>
> For grins, I tried this on my working code...
>
> Error[149]   C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 27 : Directive
> only allowed when generating an object file

You have not added the/a "Linker Script" file to your project.
So MPLAB still thinks that you're using abs-mode code and generates
the wrong MPASM command (and no MPLINK command).


> Yea, yea, I need a different, more complex build environment,...

No, you just have to do a few changes/fixes.

> one that will
> Take weeks to implement successfully to get this to run.

Again, a few minutes, maybe...


Jan-Erik.

2008\06\17@112238 by Alan B. Pearce

face picon face
>Clearly, I'm just one of those gimmy kinda guys trying to get
>thru my homework on someone else's dime.  :)

No, clearly you are attempting to deal with relocatable code in absolute
mode. Use the batch file method to compile and link, then it all just plain
works.

Spending an hour having a look at Olins build environment really will pay
dividends in understanding how the relocatable environment works. He has
done all the leg work for you, you just need to 'fill in the code'. I did
exactly this with the I2C example code that Microchip publish in AN734 &
AN735, along with the good Friars serial code that has served many people
well. Converted them all to interrupt code along the way as well.

2008\06\17@114112 by olin piclist

face picon face
Thomas C. Sefranek wrote:
>> Take a absolute program and replace every ORG with a absolute CODE,
>
> For grins, I tried this on my working code...

Without the code there is little I can say about this.

> Error[149]   C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 27 :
> Directive only allowed when generating an object file

This means you didn't tell the assembler to use relocatable mode.

> Warning[220] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 28 : Address
> exceeds maximum range for this processor.
> Error[118]   C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 28 :
> Overwriting previous address contents (000D)
> Warning[220] C:\SVN\NP\MOLLYQ200\CODE\DISPLAY\DISPLAY.ASM 28 : Address
> exceeds maximum range for this processor.

Without the code I can't tell what this is.  It's even possible that some of
this may be detecting a memory out range or overlap.

> Yea, yea, I need a different, more complex build environment, one
> that will Take weeks to implement successfully to get this to run.

Or use mine.  http://www.embedinc.com/pic.  I can even come over there and
get it all set up for you if you want.

In any case, if you've got a absolute mode MPLAB project, it can't be that
hard to convert it to a relocatable mode project.  I don't build from the
IDE, but I've heard people talking about "adding the linker file" to the
project, and MPLAB understands you mean relocatable mode.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\17@122052 by Thomas C. Sefranek

face picon face
Thank you for taking the time, I will let you (all) know my progress.
(I've done this before, and did not like the results...  but I can't
remember what was the problem.)

 *
 |  __O    Thomas C. Sefranek  KILLspamWA1RHPspamBeGonespamARRL.NET
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41MHz PL74.4

ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

{Original Message removed}

2008\06\17@122226 by Thomas C. Sefranek

face picon face
Thanks, Olin's offer to come over and set it up for me, is enough for me to
Do my homework myself.  (I shame easily.)

 *
 |  __O    Thomas C. Sefranek  EraseMEWA1RHPspamEraseMEARRL.NET
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41MHz PL74.4

ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

{Original Message removed}

2008\06\17@122533 by Thomas C. Sefranek

face picon face
Aw shucks Olin,

I would only let you spend your time on my behalf if it was a dire
necessity.  Let me plunder your work and I'll let you know where I get with
it.  For some reason (old age memory...) I didn't get it right last time I
tried.

Thank you for offering.
Tom

 *
 |  __O    Thomas C. Sefranek  @spam@WA1RHP@spam@spamspam_OUTARRL.NET
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41MHz PL74.4

ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

{Original Message removed}

2008\06\17@145839 by Jan-Erik Soderholm

face picon face
Thomas C. Sefranek wrote:

> Thank you for taking the time, I will let you (all) know my progress.
> (I've done this before, and did not like the results...  but I can't
> remember what was the problem.)

I know the pages are in Swedish, but the coulor coding
of the important parts might come though anyway... :-) :-)

http://www.jescab.se/Relocmode.html
http://www.jescab.se/abs_reloc.html

Enjoy.

Best Regards,
Jan-Erik.

2008\06\17@190916 by David Meiklejohn

face
flavicon
face
Olin wrote:
>
>  I don't build from the
> IDE, but I've heard people talking about "adding the linker file" to the
> project, and MPLAB understands you mean relocatable mode.

Yes, it's as easy as that.  There's no hidden absolute/relocatable mode
checkbox or anything.

2008\06\17@191645 by David Meiklejohn

face
flavicon
face
Alan B. Pearce wrote:
>
> Spending an hour having a look at Olins build environment really will pay
> dividends in understanding how the relocatable environment works.

Or - spending an hour reading the MPASM and MPLINK manuals will pay off,
as well.
Setting up a relocatable project in MPLAB isn't difficult - I really don't
see why anyone thinks that relocatable mode is harder to deal with than
absolute.  Maybe it is, but I just personally don't see it.  I think the
biggest problem is simply that most tutorial and example code out there
(including a lot of Microchip's) is absolute, so people learned that
first.

2008\06\18@150009 by KPL

picon face
> Or - spending an hour reading the MPASM and MPLINK manuals will pay off,
> as well.

btw, reading that manual (mpasm/mplink user's guide, 33014j.pdf) I got
a question.
In section 6, exactly where talking about relocatable code, there are examples.
6.3:
     code   ;Address determined
            ;by the linker.
Start clrw
     option

Everything is clear about them, but there is this directive (?)
"option" which I have not seen before and can not find any description
in the same document. What is it and what is it for?


--
KPL

2008\06\18@151223 by Tamas Rudnai

face picon face
In baseline tere is no OPTION register, but an instruction called OPTION...
See it in the datasheet in the "Instruction set summary" and also in the
MPLAB help / MPASM help file in the 12bit unstructions.

Tamas


On Wed, Jun 18, 2008 at 8:00 PM, KPL <spamBeGonekpl.listesspamKILLspamgmail.com> wrote:

{Quote hidden}

> -

2008\06\18@153411 by KPL

picon face
OK, thanks.
I never have used baseline pic.

Now I see there was a description of that in appendix of the same document.


On Wed, Jun 18, 2008 at 10:12 PM, Tamas Rudnai <.....tamas.rudnaispam_OUTspamgmail.com> wrote:
{Quote hidden}

>> --

2008\06\18@160132 by Tamas Rudnai

face picon face
I know, many things seems to be weird if you start working on baseline after
mid-range -- but I suppose that's the same if you go to mid-range from 18F
etc.


On Wed, Jun 18, 2008 at 8:34 PM, KPL <TakeThisOuTkpl.listesKILLspamspamspamgmail.com> wrote:

{Quote hidden}

2008\06\18@162039 by KPL

picon face
No, I am not even starting, just once again tried reading that user's
guide, after repeated recommendations here:)
I'll stick with midrange for now for less confusion.

On Wed, Jun 18, 2008 at 11:01 PM, Tamas Rudnai <spamBeGonetamas.rudnai@spam@spamspam_OUTgmail.com> wrote:
> I know, many things seems to be weird if you start working on baseline after
> mid-range -- but I suppose that's the same if you go to mid-range from 18F
> etc.
>
>

--
KPL

2008\06\19@071652 by olin piclist

face picon face
KPL wrote:
>       code   ;Address determined
>              ;by the linker.
> Start clrw
>       option
>
> Everything is clear about them, but there is this directive (?)
> "option" which I have not seen before and can not find any description
> in the same document. What is it and what is it for?

Option is a instruction on some old 14 bit core PICs and current 12 bit core
PICs.

By the way, that is a bad example above.  You have to be careful, many
Microchip code examples are bad.

You should always give a section name to a code directive.  If you don't,
the assembler picks one for you anyway, which can have unexpected side
effects.  The section names also show up in the MAP file.  If you don't give
them clear names, it won't be so easy to tell how much space each piece of
code took.

Another bad habit this example illustrates is putting a instruction on the
same line as a label.

Let's say this code is in your LCD driver module.  A good example would be:

lcd    code
start
       <first instruction goes here>


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

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