Searching \ for '[PIC] Found difference between 16F628 and 16F628A' 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=16F
Search entire site for: 'Found difference between 16F628 and 16F628A'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Found difference between 16F628 and 16F628A'
2005\08\31@090836 by Maarten Hofman

face picon face
Rochester, 31 augustus 2005.
Dear all,
Yesterday I received my $12.50 JDM programmer from eBay and now I can finally program the 16F628A (for some reason the El Cheapo can handle the 16F628, but not the 16F628A, regardless of software used). So I happily reassembled my application for the new target, programmed the device and used it. At first all seemed to be working fine, but then I started noticing little glitches.  I was already aware of some differences (the 16F628A consumes less power and uses a different programming method) and I had read in the datasheet that the configuration bits changed, that code protection is no longer partial, that timer 1 and the internal oscillator work differently but this was something else.  I debugged for a while, and then I discovered that the 16F628A doesn't allow you to read the EEPROM while it is writing to it. On the 16F628, if you read the EEPROM while writing to it, it returns 0xFF and writes the correct value. On the 16F628A, if you read the EEPROM while writing to it, it returns 0xFF but also stores 0xFF into it, instead of the requested value. This is a rather unfortunate difference, which is why I decided to let you know.  Of course, I tested this only with two 16F628 and two 16F628A that I bought at the same time. It might be that some 16F628 exhibit the same behaviour and that some 16F628A don't. But it really seems like something that has been introduced in the 16F628A.  Greetings,
Maarten Hofman.

2005\08\31@093501 by olin piclist

face picon face
Maarten Hofman wrote:
>  I debugged for a while, and then I discovered that the 16F628A doesn't
> allow you to read the EEPROM while it is writing to it. On the 16F628,
> if you read the EEPROM while writing to it, it returns 0xFF and writes
> the correct value. On the 16F628A, if you read the EEPROM while writing
> to it, it returns 0xFF but also stores 0xFF into it, instead of the
> requested value.

I don't see a problem here since you shouldn't be attempting to read the
EEPROM while a write is in progress.

> This is a rather unfortunate difference,

No, just unfortunate programming.


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

2005\08\31@101240 by Maarten Hofman

face picon face
>
> I don't see a problem here since you shouldn't be attempting to read the
> EEPROM while a write is in progress.

Nowhere where I read it does it say that you're not allowed to do this. And on the 16F628, it works.

> This is a rather unfortunate difference,
>
> No, just unfortunate programming.

I would call it "squeezing all out of a PICmicro that is in it". Yesterday I spent two hours trying to find a way to reduce a piece of code by one instruction, so I would have enough time to do a proper clrf on PCLATH before shifting values in it (I wanted to use my program on the 16F688, and because of its larger memory the contamination in the top bits of PCLATH caused it to fail). I don't think there is any time for me to add another instruction in the loop to check whether I am writing to the EEPROM and not read from it. Calling it unfortunate programming before you know what I am doing... Well, it just hurts.
Yes, the code uses very ugly shortcuts. I use input variables and jump to fixed locations in memory based on them. I require that 90% of the variables in the first two banks are in a fixed location, as they are directly accessible through RS-232. However, it is able to do stuff that I doubt would be possible if I did keep the code neat.

2005\08\31@114327 by Shawn Tan

flavicon
face
> > I don't see a problem here since you shouldn't be attempting to read the
> > EEPROM while a write is in progress.
>
>  Nowhere where I read it does it say that you're not allowed to do this.
> And on the 16F628, it works.

It's a 'data-hazard'.. And they don't guarantee that you'll get 0xFF either in
the data sheet...

> > This is a rather unfortunate difference,
> >
> > No, just unfortunate programming.
>
>  I would call it "squeezing all out of a PICmicro that is in it". Yesterday
> I spent two hours trying to find a way to reduce a piece of code by one

You can poll the WR flag to ensure that the data is properly written... maybe
you can do that instead... test the flag before reading it.. I assume that
you're reading the eeprom, checking for 0xFF, and discarding it if it is.. It
should take the same number of cycles...

cheers..

--
with metta,
Shawn Tan

2005\08\31@124013 by Maarten Hofman

face picon face
>
> It's a 'data-hazard'.. And they don't guarantee that you'll get 0xFF
> either in
> the data sheet...

I doubt I'll get 0xFF every time either. I don't really care what I get, as long as the result is written correctly into the EEPROM. This is the case on the 16F628, but not on the 16F628A. Also, how big is this hazard? If I write to location X can I not read from any location? Or just not from location X?
> You can poll the WR flag to ensure that the data is properly written... maybe
> you can do that instead... test the flag before reading it.. I assume that
> you're reading the eeprom, checking for 0xFF, and discarding it if it is.. It
> should take the same number of cycles...
Polling the WR flag adds another instruction. Currently I just get the result and use it, even if it is wrong. It creates a little glitch on the screen, but at least it doesn't destroy the horizontal synchronization of the line. I consider the horizontal sync important, and all of my code is optimized to keep that in tact.
Also, I appreciate Olin for his efforts to get people to use a poper coding style, and I agree that my code for "Drake version 2" would've benefited greatly from this, and I will correct this in version 3. At the time that I wrote it I didn't even know it was possible to write relocatable code and registers. However, there is a cost to writing code that way, and in the case of the TV daughterboard, the cost is too high: it would require me to move up to an 18F running at >20 MHz, which would certainly increase the price of the microcontroller to more than $1.61, and most likely increase power consumtion to above the current 13mA.
Greetings,
Maarten Hofman.

2005\08\31@153257 by Jan-Erik Soderholm

face picon face
Maarten Hofman wrote :

> If I write to location X can I not read from any location?
> Or just not  from location X?

Simply don't read at all while a write operation is running.

> it would  require me to  move up to an 18F running at >20 MHz,
> which would certainly increase the price of the microcontroller
> to more than $1.61, and most likely increase power
> consumtion to above the current 13mA.

In what way would that be a problem ?

Anyway, what is your solution ?
Stick with the non-A 628 ?

Jan-Erik.



2005\08\31@163114 by Maarten Hofman

face picon face
>
> > If I write to location X can I not read from any location?
> > Or just not from location X?
>
> Simply don't read at all while a write operation is running.

Seems wasteful. I'm pretty certain the 16F628A allows reading from other locations than the one written to without any problems (I'll test it). As said, there is nothing in the documentation limiting reads during writes, and it works fine on the 16F628.

> it would require me to move up to an 18F running at >20 MHz,
> > which would certainly increase the price of the microcontroller
> > to more than $1.61, and most likely increase power
> > consumtion to above the current 13mA.
>
> In what way would that be a problem ?

I'm trying to keep the total price of my system below that of a gameboy, and the TV daughterboard below the price of the parallax version. With the 18F price would go up $1.10 and power consumption 1.6mA (less than I thought). However, the EEPROM issue would still exist. Granted, I would be able to do more fancy things, but I would be able to with the only $0.24 more expensive 16F688 too, and the 16F688 would at least give me a smaller package and lower power consumption. In general, though, I'd say that a higher price AND higher power consumption without gaining significant benefits is a problem. I know many companies try to reduce their system by a single resistor to lower the price.

Anyway, what is your solution ?
> Stick with the non-A 628 ?

No... The 16F628 is more expensive and consumes a lot more power. I think the best solution is that the user documentation will state that you can't change a user defined character while it is displayed on screen. As said, once I figure out how to clear the PCLATH within the time allotted, I might switch to the 16F688 instead. I wonder how that EEPROM responds...
Greetings,
Maarten Hofman.


'[PIC] Found difference between 16F628 and 16F628A'
2005\09\01@040444 by Alan B. Pearce
face picon face
>I'm trying to keep the total price of my system below that of a gameboy,
>and the TV daughterboard below the price of the parallax version. With
>the 18F price would go up $1.10 and power consumption 1.6mA (less than I
>thought). However, the EEPROM issue would still exist.

I think you need to be more specific about what you are writing to EEPROM.
It strikes me that you should have copied the EEPROM contents to RAM, and
accessing that. If you are using the EEPROM as your character generator, why
are you writing to it on the fly?????

2005\09\01@090503 by Maarten Hofman

face picon face
>
> I think you need to be more specific about what you are writing to EEPROM.
> It strikes me that you should have copied the EEPROM contents to RAM, and
> accessing that. If you are using the EEPROM as your character generator,
> why
> are you writing to it on the fly?????

The EEPROM is used to house the user defined graphics. If a user decides to create their own graphic, they can send it to the system using RS-232 and it is stored in EEPROM. However, while this is happening, the system still needs to update the TV screen (keeping synchronization is the most important task of the system, everything else is secondary), and therefore access the EEPROM if there are any user defined characters on screen. The reason why I don't use RAM is because I only have a few registers left, and I need at least 64 of them.
On the 16F688 I decided to do things differently: I will no longer allow user defined characters to be mixed with regular characters. A line can be defined as "is user defined" "is graphical" or "is alphanumeric". This means I only need one test instead of 14 tests per line to see if the EEPROM is being written to, which is doable.
Also, it was never a problem for me. I just wanted people to know about this undocumented difference between the 16F628 and the 16F628A. I thought it would be useful to people.
Greetings,
Maarten Hofman.

2005\09\01@114039 by William Chops Westfield

face picon face
On Sep 1, 2005, at 6:05 AM, Maarten Hofman wrote:

> The EEPROM is used to house the user defined graphics. If a user
> decides to
> create their own graphic, they can send it to the system using RS-232
> and it
> is stored in EEPROM. However, while this is happening, the system still
> needs to update the TV screen (keeping synchronization is the most
> important
> task of the system, everything else is secondary), and therefore
> access the
> EEPROM if there are any user defined characters on screen.

While I sympathize (somewhat, anyway) with highly tuned code that
has stopped working due to the differences between 628 and 628a, I
gotta argue with your assumption there.  Surely downloading user
graphics happens seldom enough that you can blank the screen while
they are being saved to EEPROM?  I'm reminded of the timex-sinclair
zx80 that would blank the screen a lot while running the basic
interpreter.  It wasn't great, but it was usable...

BillW

2005\09\01@114944 by Michael Rigby-Jones

picon face


{Quote hidden}

The ZX81 had a "fast" mode that blanked the screen and sped up basic execution by orders of magnitude.  The "slow" mode allowed display, but could only run the basic interpeter during horizontal retrace (IIRC).

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\09\01@122719 by Maarten Hofman

face picon face
>
> >While I sympathize (somewhat, anyway) with highly tuned code
> >that has stopped working due to the differences between 628
> >and 628a, I gotta argue with your assumption there. Surely
> >downloading user graphics happens seldom enough that you can
> >blank the screen while they are being saved to EEPROM? I'm

 It didn't really stop working, the functionality just decreased a little: The user now has to make sure the screen doesn't contain any user defined graphics when they change them. And I can well imagine a user that would want to continuously change user defined characters, so they can adapt the graphics to each game level's environment. And I agree that is was a design choice to maintain synchronisation at all cost, and that things would be easier without it.

>reminded of the timex-sinclair zx80 that would blank the
> >screen a lot while running the basic interpreter. It wasn't
> >great, but it was usable...

Yes, it blanked the screen, but it kept some form of synchronisation (the screen turned black, it didn't turn into noise). Of course, both the ZX80 and ZX81 did the synchronisation in external logic, rather than using the Z80. It was a very clever setup.

> The ZX81 had a "fast" mode that blanked the screen and sped up basic
> execution by orders of magnitude. The "slow" mode allowed display, but could
> only run the basic interpeter during horizontal retrace (IIRC).

The slow mode operated whenever the external logic was handling the synchronisations (both horizontal and vertical). This gave the CPU about 20% time to do calculations. The ZX80 didn't have this slow mode.
Greetings,
Maarten Hofman.

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