Searching \ for '[PIC] Programming a 16f84 vs 16f877' 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/devprogs.htm?key=programming
Search entire site for: 'Programming a 16f84 vs 16f877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Programming a 16f84 vs 16f877'
2005\11\13@110450 by Shay

flavicon
face

Just as an example, let's say I have a program for a 16f84 which I'd
like to put onto a 16f877.  Take the one found on this page for example:

http://www.mstracey.btinternet.co.uk/pictutorial/progtut4.htm

How do I find out what needs to be changed with the program so it will
work on the 16f877?  I'm not so much asking for specifics about these
chips as I am trying to figure out how to convert a program to go from
chip type A to chip type B.  The 2 I listed are just a couple examples I
found.  I still haven't figured out what chip I should start with but am
now leaning towards the 16f877.

Thanks,
Shay

2005\11\13@113652 by olin piclist

face picon face
Shay wrote:
> Just as an example, let's say I have a program for a 16f84 which I'd
> like to put onto a 16f877. ...
> How do I find out what needs to be changed with the program so it will
> work on the 16f877?

If it was written right, then there shouldn't be much beyond the config bits
and processor declaration that needs to changed in the source code that the
assembler won't tell you about.  The difference between various 16 family
PICs is the amount and layout of memory and the peripheral set.  The memory
layout is represented in the linker file, and if you try to access
peripherals in the new chip that old didn't have then the assembler will
give you an error because the SFR for that peripheral won't be defined.  All
you should have to do is define the new PIC type in the source, reference
the include file for that type, write a new __CONFIG definition, and use the
linker file for the new PIC.

Of course if the code was badly written (like most examples, including most
from Microchip) then you'll have more problems.  If so, now would be a good
time to see the light and do it right.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\13@113848 by John J. McDonough

flavicon
face
Shay

Not much, really, depending on how well you wrote the 84 code.

The GPR's on the 877 (and almost all other 16F's) start at 0x20 instead of
0xc.  If you used relocatable code you do nothing to account for this.  If
you used cblock, you change the location of the cblock.  If you use equ's,
you change a bunch of equ's.  If you hard coded memory locations, good luck.

Same thing with the SFR's.  A few of them moved.  If you hard coded SFR
locations then you have a lot of work in front of you.

One of the registers moved banks (I don't recall offhand which) and one of
the bits associated with the interrupts changed registers.  You will need to
deal with this if you used interrupts.  But if you used the banksel
directive instead of bcf at least the bank changing won't be much of an
issue.

The thing that gets most people doing this move is the I/O devices.  On the
F84, everything is a digital I/O by default.  On any chip with inputs that
might someday have an analog voltage, the default condition is to be analog.
So any pins you use as digital that are shared with something analog (on the
877, this is most of them) you will need to initialize the port to digital
before setting the I/O direction.

For most programs, there really are few changes unless you did dumb things
like hard coding addresses.  A lot of hobbyists do this, and a lot of the
16F84 examples out there are really horrible.  But if you did sensible
things, then a little extra initialization at the front and changing a value
on the cblock are typically all it takes.

Now, as your program grows, there are a few gotchas.  On the 84, all the GPR
locations are echoed in all banks.  Not so on the 877, so you will be doing
a lot more more banksels.  And when you code gets beyond 2K, you need to
start worrying about lcalls and pagesels.  But these are for later.  To just
do the port, it should be simple.

--McD


{Original Message removed}

2005\11\13@114054 by John J. McDonough

flavicon
face
Whoops, I just looked at your link.

This is a classic example of what NOT to do.  This is very, very bad.

;*****Set up the Constants****

STATUS         equ       03h                 ;Address of the STATUS register
TRISA             equ       85h                 ;Address of the tristate
register for port A
PORTA           equ       05h                 ;Address of Port A


DO NOT TO THIS.  Don't ever do this.  Run away from any program that does
this.

{Original Message removed}

2005\11\14@084113 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Shay" <spam_OUTshayTakeThisOuTspamhighstyleweb.com>
Subject: [PIC] Programming a 16f84 vs 16f877


> found.  I still haven't figured out what chip I should start with but am
> now leaning towards the 16f877.

Shay

Neither I, nor anyone else, responded to this comment.

As both Olin and I mentioned, moving between the various 16F's really isn't
much of an issue.  The 877 is a fairly old chip, and it is kind of
expensive.  But it does give you lots of pins to play with, and pins are
resource you typically run out of first.

As I mentioned in an earlier post, one thing you have to do with most parts
is some initialization of various I/O devices.  On most PICs, every pin has
multiple functions.  If you are just learning, this can get pretty
confusing.  The 16F84 is a sort of special case.  Only one pin has multiple
uses and it defaults to the same behavior as the other pins.  So getting
started, the 84 is a little easier than most of the others.

On the other hand, the F84 is close to, if not the most expensive 18 pin
part.  Almost every other 16F has more stuff (memory, I/O) at a lower price.
Once you get you head around the initialization of the various I/O devices,
almost any other part is a better choice.

If you are on a program of learning the PIC, I would suggest buying a 16F84
and a 16F628.  Do some simple stuff on the 84, then port it to the 628.  The
628 has more memory, and a few pins have the additional I/O initialization
to worry about.

Once you are comfortable with those, then try the same sort of exercise on
the 87x series.  This is a really neat group of parts.  The 87x parts are
very similar.  They only differ in the number of pins and memory size.
(Well, the 872 lacks one I/O device ... I don't recall offhand what it is).

The 84, 628, and 87x (but not the A versions except for the 84) are
supported by the widest range of public domain software.  However, newer
parts like the 16F88 have some pretty neat features.  So as you get set up,
think about those other parts.  If you arrange to have some flexibility in
your development environment, switchnig between chips is pretty simple
business.  And then you can spend only as much as you have to for the PIC in
your projects.  Plus, sometimes you see a really good deal on something.  If
you have more flexibility in what you can use, you can take advantage of
more of those deals.

If you are not put off by the price, get an ICD2 for programming and
debugging.  If the price scares you, build or buy an in-circuit programmer.
There are a million designs you can build for under $20 (if your PC has a
REAL serial port).  Programmers like Wouter's Wisp628 or Olin's EasyProg are
inexpensive to buy, too.  I think both are still under $40 if you include
shipping, and they free you from the "real serial port" limitation.  If you
buy a Wisp pick up a few PICs from Wouter too, and save a separate shipping
bill.  Programmers with their own socket may look neat, but operationally
they are a real hassle.  Read the ICSP document on Microchip's website and
do things that way.  It makes life a lot easier.

--McD

2005\11\14@093159 by olin piclist

face picon face
John J. McDonough wrote:
> If you are on a program of learning the PIC, I would suggest buying a
> 16F84 and a 16F628.

I don't agree with this philosophy, but that's been beat to death many times
here before.  However if you do go this route, at least use a 16F648A or
16F88 instead of the obsolete 16F628.  For low volume projects, it doesn't
make sense to save a few pennies for the slightly cheaper part with less
memory.  Also, if you want a 16F part with 40 pins, get the 16F877A instead
of the obsoleted (for new designs at least) 16F877.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\14@101607 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Olin Lathrop" <.....olin_piclistKILLspamspam@spam@embedinc.com>
Subject: Re: [PIC] Programming a 16f84 vs 16f877


> here before.  However if you do go this route, at least use a 16F648A or
> 16F88 instead of the obsolete 16F628.  For low volume projects, it doesn't

It depends a little on Shay's take on development.

If he builds a programmer, then the 16F84, 16F84A, 16F628, 16F87x are
supported by a wide range of public domain software.  Support for the 88,
648A, and 87xA is pretty limited.  Non nonexistent by any means, but not
nearly as widespread as the older parts.

*BUT*, if he gets an ICD2 (best aproach IMO), or a Wisp or EzProg, then you
are absolutely right.  The 88 is a really nice chip, and the 648A barely
costs more than the 628 and has twice the memory.

I like the 84A to 628 move as a simple learning step, but once you have the
developent capability, the 648A is exactly the same as the 628 from that
perspective.  Although I personally prefer the 16F88, the change from the
84A is a bigger step, and so a little scarier.

Sounds to me as if Shay has been reading datasheets and the like, and if
that's the case, and if he can get a little help (maybe from this group), it
might serve him well to skip the 84 step and go straight to an 88 and/or
877A.

But I've seen so many foks who are scared off by all the I/O choices.  I
know we differ on this, Olin.  And I don't like how many people seem to get
stuck on the 84 which is the lamest of the available chips.  But I like the
getting stuck on the 84 better than getting frustrated and not getting
anywhere.  At least the guy stuck on the 84 might someday find the project
that gets him to try something better, and once he does, he figures out how
easy it is to move between parts.  The guy who gets nowhere stays nowhere.

--McD

2005\11\14@104801 by Maarten Hofman

face picon face
> > here before.  However if you do go this route, at least use a 16F648A or
> > 16F88 instead of the obsolete 16F628.  For low volume projects, it doesn't
>
> It depends a little on Shay's take on development.
>
> If he builds a programmer, then the 16F84, 16F84A, 16F628, 16F87x are
> supported by a wide range of public domain software.  Support for the 88,
> 648A, and 87xA is pretty limited.  Non nonexistent by any means, but not
> nearly as widespread as the older parts.

I would say: get a better programmer. Even the lowly JDM that I got
from Olimex was able to program the 16F628A, 16F877A and 16F688
without problems. If you have a programmer that can't program new
parts, you're bound to get frustrated anyway.

> *BUT*, if he gets an ICD2 (best aproach IMO), or a Wisp or EzProg, then you
> are absolutely right.  The 88 is a really nice chip, and the 648A barely
> costs more than the 628 and has twice the memory.

Comparing the 16F648A with the 16F628 is unfair. Compare it with the
16F628A, it is 13% more expensive, which I won't call "barely". Of
course, I believe in designing something first, and then implementing
it, and therefore I would know approximately how much memory I would
need before I get the part. As an all purpose 18-pin device, the 16F88
would indeed be superior, but please don't forget the 16F688, which is
a wonderful 14-pin device (AND fully compatible with the PICkit-2 and
its demoboard).

> I like the 84A to 628 move as a simple learning step, but once you have the
> developent capability, the 648A is exactly the same as the 628 from that
> perspective.  Although I personally prefer the 16F88, the change from the
> 84A is a bigger step, and so a little scarier.

I already mentioned how much I hated the fact that my first PIC was a
16F84A. It was as close to wasting time as I ever got in my life
(apart from getting physics classes about location/speed/acceleration
without knowledge of differential equations). Please, don't let anyone
else suffer again...

> But I've seen so many foks who are scared off by all the I/O choices.  I

It takes two to five lines of code to make almost any 16F chip behave
like a 16F84A. These lines are known and well documented, and if
someone has found this list, they will find those lines. Beyond the
initial step of those lines of code, you only gain options, that you
can ignore, or use to simplify things even further.

Greetings,
Maarten Hofman.

2005\11\14@112515 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Maarten Hofman" <cashimorspamKILLspamgmail.com>
Subject: Re: [PIC] Programming a 16f84 vs 16f877


> I would say: get a better programmer. Even the lowly JDM that I got
> from Olimex was able to program the 16F628A, 16F877A and 16F688
> without problems. If you have a programmer that can't program new
> parts, you're bound to get frustrated anyway.

It's not the hardware ... its the software.  Any of the "classic" designs
will program virtually any part.  Most of the designs are supported by
hundreds of programs.  However, only a handful of those programs will handle
the newer parts.  If Shay were to, say, build a SERPIC or PARPIC, or NoPPP,
and he were to happen across one of those few programs with a lot of
flexibility, then he would be well advised to jump right into the F88 or
648A.  However, finding those is like finding a needle in a haystack, and as
best I can tell, those that support a lot of parts also happen to be those
that have issues with installation.

Personally, I would NOT go out and buy a JDM or Olimex.  Better a Wisp or
EasyProg.  Better support, more open software, and guys we trust.  But it
depends on how Shay sees the world.  If he wants the cheapest route
possible, then building from scratch is the way to go, and building the
programmer yourself does remove a lot of the fear.  On the other hand, if
money isn't the object, then go get something good like the ICD2.

> It takes two to five lines of code to make almost any 16F chip behave
> like a 16F84A.

Absolutely.  But until you find those lines (and while they are documented,
finding that information borders on impossible), and convince yourself
that's all it takes, all those options on every pin is terrifying to many.

> initial step of those lines of code, you only gain options, that you
> can ignore, or use to simplify things even further.

Yep, I agree.  Once you get past the hump, there are all sorts of goodies,
and they aren't all that tough to learn.  But getting past the fear is a
major issue for many.

--McD

2005\11\14@125904 by Shay

flavicon
face

I think I might go the route of getting a 16f84 first, then moving to a
16f628.  Especially since a book a bought a while back only uses the 84.. :)

John J. McDonough wrote:

> {Original Message removed}

2005\11\14@130351 by Shay

flavicon
face


John J. McDonough wrote:

{Quote hidden}

*shrug*

>
> If he builds a programmer, then the 16F84, 16F84A, 16F628, 16F87x are
> supported by a wide range of public domain software.  Support for the
> 88, 648A, and 87xA is pretty limited.  Non nonexistent by any means,
> but not nearly as widespread as the older parts.
>
> *BUT*, if he gets an ICD2 (best aproach IMO), or a Wisp or EzProg,
> then you are absolutely right.  The 88 is a really nice chip, and the
> 648A barely costs more than the 628 and has twice the memory.
>
I plan on buying one that is either built, or very easy to build.  I
don't have problems before I even get out of the gate..

> I like the 84A to 628 move as a simple learning step, but once you
> have the developent capability, the 648A is exactly the same as the
> 628 from that perspective.  Although I personally prefer the 16F88,
> the change from the 84A is a bigger step, and so a little scarier.
>
> Sounds to me as if Shay has been reading datasheets and the like, and
> if that's the case, and if he can get a little help (maybe from this
> group), it might serve him well to skip the 84 step and go straight to
> an 88 and/or 877A.
>
Yes and No.  I took some EE classes in college, but those were ~7 years
ago..  so I kinda remember some things, but not very much.. just enough
to have an idea that I don't know enough.

> But I've seen so many foks who are scared off by all the I/O choices.  
> I know we differ on this, Olin.  And I don't like how many people seem
> to get stuck on the 84 which is the lamest of the available chips.  
> But I like the getting stuck on the 84 better than getting frustrated
> and not getting anywhere.  At least the guy stuck on the 84 might
> someday find the project that gets him to try something better, and
> once he does, he figures out how easy it is to move between parts.  
> The guy who gets nowhere stays nowhere.
>
Nah, that doesn't scare me.. as long as I can figure out how to use the
ones I need.  Keeping it simple for the first few projects will help I
think.  Eventually, I will want to move up to something with more as my
projects get bigger.

Thanks,
Shay

2005\11\14@131713 by Shay

flavicon
face

Hmm.. I was thinking of going with an EzProg but it doesn't look like it
supports the 16f84.

I really do want to stick with something simple.. so maybe the Wisp..    
nobody mentioned the DIY kits though.. don't like these?
http://kitsrus.com/upuc.html#k150

-Shay

John J. McDonough wrote:

> {Original Message removed}

2005\11\14@132307 by Wouter van Ooijen

face picon face
> I think I might go the route of getting a 16f84 first, then
> moving to a
> 16f628.  Especially since a book a bought a while back only
> uses the 84.. :)

What is already available to you as knowledge, tools, chips, etc. cna
indeed be a good reason to go for that particular antiquity. Whether it
was a good idea to buy that book is another discussion :)

Wouter van Ooijen

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


2005\11\14@133449 by Maarten Hofman

face picon face
> I think I might go the route of getting a 16f84 first, then moving to a
> 16f628.  Especially since a book a bought a while back only uses the 84.. :)

If those are your choices, do yourself a favor and start with the
16F628 instead of the 16F84. Conversion of any code you might
encounter in the book is relatively simple:

1. Change variables
The range of variables on the 16F628 start at 0x20 instead of 0x0C.
This means you will either have to:
a) do nothing, in case the book uses proper relocatable code.
b) change CBLOCK 0x0C into CBLOCK 0x20
c) change any register definition (EQU) pointing to a register between
0x0C and 0x1F to one that is higher or equal to 0x20.

2. Initialize CMCON register to change all pins to 16F84(A) configuration
This is done with the following code:
 movlw 0x07
 movwf CMCON
If you want you can put this between a check whether CMCON exists, in
which case the code will remain compatible with the 16F84.

3. With 1-2 you will fix most of the simple code. However, some code
for the 16F84 blithely assumes that registers are accessible
regardless of the settings of RP0 (and RP1). You can either fix this,
or, if you use less than 17 registers, make sure (in step 1) that all
registers point to 0x70 to 0x7F. Also, if the code uses an interrupt
routine and the interrupt routine ignores proper RP0 (and RP1)
setting, you will either need to add that to the interrupt routine, or
move all interrupt variables to the 0x70 to 0x7F region. See the
16F628(A) manual for a good way to save and restore variables from
interrupts properly.

4. If the code uses EEPROM, note that EEADR and EEDATA are no longer
in bank 0. This means that before accessing EEADR or EEDATA you will
need to do:
 banksel EEADR
and afterwards, when using a register in bank 0 again, you need to
 banksel <that register>
again. See the 16F628(A) manual for a good way to access EEPROM memory.

5. If the code uses the EEIE bit in INTCON, use EEIE from PIE1
instead, and make sure to surround it with the appropriate banksel
statements (see 4). The same counts for EEIF in INTCON, which moved to
PIR1.

6. Add _LVP_OFF to the CONFIG statement to free up RB4. If you want to
keep your electronics simpler too, you can also disable the reset pin
(in which case it doesn't need to be pulled up anymore) and use an
internal oscillator (in which case you don't need a crystal anymore).
Add the appropriate CONFIG bits for this, if you want, but make sure
your programmer/software will still work under that configuration.

This seems like a long list, but I also had a book that only use the
16F84A, and I discovered that very little needed to be changed, most
of the time. If you write your own programs, and they are not going to
use the limits of the particular PICmicro, it is recommended to NOT
use CBLOCK (and certainly not EQU) to give your registers names, but
instead use relocatable code.

Greetings,
Maarten Hofman.

2005\11\14@141715 by Shay

flavicon
face

ok, if it's that easy I might be talked into doing it.  Would I do
16f628 or 16f628A?  Not sure what the difference is between those
with/without the A.. just an update of some sort?

I see that the EasyProg supports the 16f628.. so maybe I'm back to
getting that..

Decisions.. decisions..

Maarten Hofman wrote:

{Quote hidden}

2005\11\14@143104 by olin piclist

face picon face
Shay wrote:
> ok, if it's that easy I might be talked into doing it.  Would I do
> 16f628 or 16f628A?  Not sure what the difference is between those
> with/without the A.. just an update of some sort?

Do the 16F648A.  It's the same thing with twice the program memory.  This
extra memory can be completely ignored if you don't use it, but then you'll
have chips around with more depth for future projects.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\14@144207 by Maarten Hofman

face picon face
> ok, if it's that easy I might be talked into doing it.  Would I do
> 16f628 or 16f628A?  Not sure what the difference is between those
> with/without the A.. just an update of some sort?

The differences that I have noticed are:
1) there are programmers (like the El Cheapo) that can program the
16F628, but not the 16F628A/16F648A, even with modern software.
2) Some revisions of the 16F628A/16F648A suffer from a bug that
requires you to basically halt your program while writing to the
EEPROM memory. This is rarely an issue, as most of the time you'll be
waiting for it to finish anyway.
3) The 16F628A is cheaper and can be interchanged for the 16F648A with
very little effort (the 16F648A is about the same price as the 16F628,
and therefore a good deal, unless your design states you don't need
the additional 2KWord).
4) Some mode bits have changed (ER -> RC, BOD -> BOR, PWRT can be
controlled separately, INTRC is called INTOSC, only one CP bit).
5) The Timer1 oscillator has been limited to 32.768 kHz, instead of
anything up to 200 kHz.
6) The dual speed oscillator no longer works in ER mode.
7) The 16F628A/16F648A consumes a lot less power.
8) All versions of the 16F628A/16F648A can handle 20 MHz. With the
16F628 there are different versions for different frequencies.

Greetings,
Maarten Hofman.

2005\11\14@144542 by Shay

flavicon
face
Olin Lathrop wrote:

> Shay wrote:
>
>> ok, if it's that easy I might be talked into doing it.  Would I do
>> 16f628 or 16f628A?  Not sure what the difference is between those
>> with/without the A.. just an update of some sort?
>
>
> Do the 16F648A.  It's the same thing with twice the program memory.  This
> extra memory can be completely ignored if you don't use it, but then
> you'll
> have chips around with more depth for future projects.
>
>
Are the code changes, going from a 16f84 to a 16F648A, the same as what
Maarten said they would be going to a 16F628?

-Shay

2005\11\14@145235 by Maarten Hofman

face picon face
> Are the code changes, going from a 16f84 to a 16F648A, the same as what
> Maarten said they would be going to a 16F628?

I have no personal experience with the 16F648A, but since the
datasheet is identical for 16F627A, 16F628A and 16F648A, I would say
yes. The only difference seems to be the memory size (1 KWord, for the
16F627A, 2 KWord for the 16F628A and 4 KWord for the 16F648A).

Note that previously I gave a list of differences between the 16F628
and the 16F628A: most of these differences are really obscure. If your
programmer can support it, using the 'A' part is the wiser choice.

Greetings,
Maarten Hofman.

2005\11\14@145609 by Maarten Hofman

face picon face
> I have no personal experience with the 16F648A, but since the
> datasheet is identical for 16F627A, 16F628A and 16F648A, I would say
> yes. The only difference seems to be the memory size (1 KWord, for the
> 16F627A, 2 KWord for the 16F628A and 4 KWord for the 16F648A).

Oops... The 16F648A also has more data memory (256 instead of 224) and
more EEPROM memory (256 bytes instead of 128 bytes). However, these
are still not significant changes from the 16F628A, so my list of
changes should still work fine.

Greetings,
Maarten Hofman.

2005\11\14@150139 by Wouter van Ooijen

face picon face
> > ok, if it's that easy I might be talked into doing it.  Would I do
> > 16f628 or 16f628A?  Not sure what the difference is between those
> > with/without the A.. just an update of some sort?
>
> Do the 16F648A.  It's the same thing with twice the program
> memory.  This
> extra memory can be completely ignored if you don't use it,
> but then you'll
> have chips around with more depth for future projects.

But do check your programming software for 628A/648A support. For you as
user the 628 and 628A/648A are almost identical, but for the programmer
software they are different. Same for the 16F877 and the 16F877A.

Wouter van Ooijen

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


2005\11\14@150308 by olin piclist

face picon face
Shay wrote:
> Are the code changes, going from a 16f84 to a 16F648A, the same as what
> Maarten said they would be going to a 16F628?

Pretty much.  There is probably a small difference in the config word
between the 16F628 and the 16F648A, but then again these will both be
different from the 16F84 anyway.  The only reason the 16F628A exists is to
be a low cost version of the 16F648 when the extra code space isn't needed.
This can matter a lot for high volume designs, but for hobby use it's better
to have the more capable chips around for the few extra cents each.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\14@151447 by M Graff

flavicon
face
Maarten Hofman wrote:

> 3) The 16F628A is cheaper and can be interchanged for the 16F648A with
> very little effort (the 16F648A is about the same price as the 16F628,
> and therefore a good deal, unless your design states you don't need
> the additional 2KWord).

In fact, I bought and assembled the DIY K149 USB-based programmer (and
love it, btw) which comes with a '628A chip installed as the controller.
   Part of the firmware update procedure uses a second '628A to flash
the new firmware onto, then you swap.  I had only '648A chips, and they
Just Worked in place of the '628A.

--Michael

2005\11\14@154000 by Wouter van Ooijen

face picon face
> In fact, I bought and assembled the DIY K149 USB-based
> programmer (and
> love it, btw) which comes with a '628A chip installed as the
> controller.
>     Part of the firmware update procedure uses a second '628A
> to flash
> the new firmware onto, then you swap.  I had only '648A
> chips, and they
> Just Worked in place of the '628A.

For my Wisp628 programmers I use 16F628, 16F628A or 16F648A, whichever I
have at hand, using the same .hex file. Of course I prefer the 16F628A,
which is the cheapest of the three.

Wouter van Ooijen

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


2005\11\14@161424 by John Nall

picon face
Wouter van Ooijen wrote:
> > For my Wisp628 programmers I use 16F628, 16F628A or 16F648A, whichever I
> have at hand, using the same .hex file. Of course I prefer the 16F628A,
> which is the cheapest of the three

You lost me there, Wouter.  You mean the Wisp628, when programming a
chip, doesn't check the device ID against the device the hex file was
assembled for?   I guess I always just kind of assumed it did.  (Which
kind of invites the reply: "That's what you get for assuming!" I guess.  :-)

2005\11\14@165929 by Wouter van Ooijen

face picon face
> Wouter van Ooijen wrote:
> > > For my Wisp628 programmers I use 16F628, 16F628A or
> 16F648A, whichever I
> > have at hand, using the same .hex file. Of course I prefer
> the 16F628A,
> > which is the cheapest of the three
>
> You lost me there, Wouter.  You mean the Wisp628, when programming a
> chip, doesn't check the device ID against the device the hex file was
> assembled for?

It can't, the .hex file does not contain an identification of the chip
it was assembled/compiled for. This is a pity, uChip should at least
propose a standard way to do this. But given the sad fact that a some
programmers/programming-software and software authors still don't seem
to know that fuses information should be included in the .hex file I
doubt such a standard would be widely accepted.

Note that in some cases a programmer can't even verify which chip it is
programming: for instance the 16C84 and 16F84 do not contain a device
ID. And there are some PIC types that have the same device ID as another
PIC type

Note that a Wisp628 does not do much in this aspect. It is the PC
software that does the intelligent decisions. For XWisp that is: if you
specify a chip on the command line, and that chip has an ID, and that ID
is not found (using the reading method appropriate for the specified
chip), then the programming is aborted with an error. Or if you don't
specify a chip, and it can't read an ID that it recognises (it will try
both 16F and 18F reading) the programming is also aborted with an error.

Wouter van Ooijen

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


2005\11\14@171523 by olin piclist

face picon face
John Nall wrote:
> You lost me there, Wouter.  You mean the Wisp628, when programming a
> chip, doesn't check the device ID against the device the hex file was
> assembled for?

I'm not Wouter, but I want to point out that HEX files unfortunately contain
no direct information on what PIC they are intended for.  This is one of the
reasons my programming softwre has the -PIC command line option.  It allows
specifying the target PIC, and the software will refuse the operation if it
finds a different PIC.

While I'm at it, Wouter was showing how compatible the 16F628, 16F628A, and
16F648A are by explaining that he can program any of these chips from the
same HEX file and they all work as controllers for his Wisp628.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\14@172837 by olin piclist

face picon face
Wouter van Ooijen wrote:
> Note that in some cases a programmer can't even verify which chip it
> is programming: for instance the 16C84 and 16F84 do not contain a
> device ID.

And it appears all the 12 bit core devices don't have an ID.  At least the
few I've looked at don't.

> And there are some PIC types that have the same device ID
> as another PIC type

I made the assumption when I first started creating programmers that all
PICs would have a unique ID.  It seemed to be the case, and that after all
is the point of having a chip ID.  However, I later discovered that some 18F
parts have the same ID as some 16F parts.  The assumption of a single unique
ID was in several places in my software, so this took some work to address.
I dealt with this by making IDs only valid within namespaces, and each PIC
family got a different namespace.  As part of the algorithm to read the ID,
you have to know what PIC family you are talking to, so this still gives
each PIC a unique ID in the end.  So far I've got separate namespaces for
the 16 family (14 bit core), 18 family (16 bit core), and 30 family (24 bit
core).  Each of these require completely different algorithms to read the
chip ID, so there is no ambiguity.

Do you know of overlapping IDs within a family?  That would be really bad.
One of the features I like is to hook the programmer up to any PIC and it
tells you which PIC it is, as long as it has a chip ID.  So far this works
for all the PICs I've supported.

> Note that a Wisp628 does not do much in this aspect. It is the PC
> software that does the intelligent decisions. For XWisp that is: if
> you specify a chip on the command line, and that chip has an ID, and
> that ID is not found (using the reading method appropriate for the
> specified chip), then the programming is aborted with an error. Or if
> you don't specify a chip, and it can't read an ID that it recognises
> (it will try both 16F and 18F reading) the programming is also
> aborted with an error.

Yup, my software works the same way.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\14@174849 by John Nall

picon face
Olin Lathrop wrote:
>> > While I'm at it, Wouter was showing how compatible the 16F628, 16F628A, and
>> 16F648A are by explaining that he can program any of these chips from the
>> same HEX file and they all work as controllers for his Wisp628.
>>    
Right.  I knew that, but was asking a question which arose (in my mind)
from what he said.  Of course, he answered it, as did you also -- the
hex file doesn't contain any identifying information as to what chip it
was assembled for.  OK, that is clear.  I didn't know that.  Now I do.  
("Dear diary, on November 14, 2005, much to my surprise and chagrin, I
learned that . . ."  :-)

Thanks,
John

2005\11\14@175947 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> Do you know of overlapping IDs within a family?  That would
> be really bad.

I'm not the one that you call "you", but anyway... :-)

I think there are some PIC18 types
where there is one "base" modell and then a very similar
model with just some extra peripherial. Might have been one
of the "motor control" modells. I think it was Rob Hammerling¨
that reported this. The base model and the one with the
"motor controll" peripherial shared IDs. And as far as I know,
they are completely similar from the point of view of
the HEX file, one had just a few extra SFRs.

Now, of course it *could* be interesting  to know which
of them is currently in the programmer ! :-)

Jan-Erik.


2005\11\14@180028 by Wouter van Ooijen
face picon face
> Do you know of overlapping IDs within a family?  That would
> be really bad.

IIRC there is some chip with motor control firmware, which has the same
ID as the corresponding chip without the firmware. You could argue that
they are the same chip, but to preserve the firmware the chip has to be
erased differently. I have a vaugue recollection of some other chips
that had the same documented ID, but this might have been 'just' a
documentation error.

Did you check the 12rf 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


2005\11\14@181201 by John Nall

picon face
Wouter van Ooijen wrote:
> > Note that a Wisp628 does not do much in this aspect. It is the PC
> software that does the intelligent decisions.
Yes . . . I used the term "Wisp628" in the sense of the whole package,
but realize that there are lots of different pieces involved.  Anyway,
you (and Olin) answered the basic question -- the hex file doesn't
contain the device ID of the device that the program was assembled for.  
I think that is a gross deficiency, and obviously you do too.  But lots
of deficiencies in life, and so we just keep on trucking.  (I would name
some of them, but then James would moderate me, and I promised him that
I would behave. . . :-)

John

2005\11\14@185951 by olin piclist

face picon face
Jan-Erik Soderholm wrote:
> I think there are some PIC18 types
> where there is one "base" modell and then a very similar
> model with just some extra peripherial. Might have been one
> of the "motor control" modells.

Yes, but those really are the same chip.  The motor control 18F is just
firmware as I understand it.  The real difference is how it's documented.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\14@190224 by olin piclist

face picon face
Wouter van Ooijen wrote:
> Did you check the 12rf chips?

No, but do they even have IDs in the first place?  That's another case of
the same die too.  A rfPIC is a regular PIC and RF chip in the same package.
They don't even bond wires between the two.  If you want the to communicate,
you have to connect them externally.  And they are surprised they didn't
sell that well.  Duh!


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\14@192716 by Wouter van Ooijen

face picon face
> > Did you check the 12rf chips?
>
> No, but do they even have IDs in the first place?  That's
> another case of the same die too.

Same die, but still a different print on the outside.

IIRC the older 12C RF chips had no ID (like most 12-bits), but these
12F's (some 12F's are 14-bits) do.

Wouter van Ooijen

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


2005\11\15@020903 by Chen Xiao Fan

face
flavicon
face
The rfPIC12F675 has the same device ID as the 12F675. I happen
to get one to test out PICkit 2 and it works.

Some findings:
PIC12 baseline devices do not have an device ID so far.
rfPIC12F675 has the same device ID as 12F675 (0FC0).
16F639 has the same device ID as 16F636 (10A0).
16F684 has the same device ID as 18F4520 (1080).
18F2439 has the same device ID as 18F242.
18F2539 has the same device ID as 18F252.
18F4439 has the same device ID as 18F442.
18F4539 has the same device ID as 18F452.
...

Regards,
Xiaofan

{Original Message removed}

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