Searching \ for '[PIC] Porting from 16f648a to 16f690 trouble. ASM' 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/ios.htm?key=port
Search entire site for: 'Porting from 16f648a to 16f690 trouble. ASM'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Porting from 16f648a to 16f690 trouble. ASM'
2011\05\20@222218 by threewheeler6

picon face

I have written a program for the 648a to read an old nes controller's key
presses for a lock of sorts. You put into program mode type in a code it
saves it in eeprom. You put it in run mode and it compares the code you
enter to the one in eeprom. It can hold a code up to 9 keys long. Wrong code
signaled by a red led correct code signaled by a green led. My program works
like expected on the 684a but when ported to the 690 it is full of bugs. It
will not read the mode jumper to got into program mode reliably, and when it
does it will not return from the eeprom write routine and signal a
successful save. If i reed the eeprom on the chip after the write, only the
first byte (it holds the number of characters in the key) is written, but
not the following bytes(the key itself). The only thing changed was the
config bits, the pin definitions, and compairitor/ad settings.
Is, there any odd quirks I should know about that may be stopping this
otherwise working code from working?

  Thank You

     EEprom code:

  EE_Restore ;Restores the non-volalal key aray from eeprom location
starting at "eekey"
       movlw        key
       movwf        temp1
       movlw        eekey
       movwf        temp2
       movlw        0x00
       call        EE_Read_Byte        ;restore number of bytes in key
       movwf        keycount
       movwf        bit_count
EE_Restore_1
       movfw        temp1
       movwf        FSR
       movfw        temp2
       call        EE_Read_Byte
       movwf        INDF
       incf        temp1,f
       incf        temp2,f
       decfsz        bit_count,f
       goto        EE_Restore_1
       return
EE_Prog        ;write the aray starting at "key" into eeprom location starting at
"eekey"
       movlw        key
       movwf        temp1        
       movlw        eekey
       movwf        temp2
       movfw        keycount
       movwf        bit_count
       movwf        temp
       movlw        0x00
       call        EE_Write_Byte;put "keycount" in first location of eeprom
EE_Prog_1
       movfw        temp1        ;key array pointer
       movwf        FSR
       movfw        INDF
       movwf        temp;load into temp reg for EE_Write_Byte
       movfw        temp2        ;ee adress aray pointer
       call        EE_Write_Byte
       incf        temp1,f
       incf        temp2,f
       decfsz        bit_count,f
       goto        EE_Prog_1
       return

EE_Read_Byte                                ;reads an eeprom location in W and returns value of that
location in W
       banksel EEADR
       movwf EEADR        ;Address to read
       bsf EECON1,RD ;EE Read
       movfw EEDATA ;W = EEDATA
       banksel        PORTB        ;BANK 0
       return                        ; and return

EE_Write_Byte
       banksel        EEADR
       movwf        EEADR                ; setup adress
       banksel        temp                        movfw        temp        ; get byte
       banksel        EEDATA
       movwf        EEDATA                ; setup byte to write
       banksel        EECON1        ; bank3 !!
       bsf        EECON1,WREN        ; enable writes
       movlw        H'55'                ; required sequence !!
       movwf        EECON2
       movlw        H'AA'
       movwf        EECON2
       bsf        EECON1,WR        ; begin write procedure        
       bcf        EECON1,WREN        ; disable writes (does not affect current write cycle)
       
       banksel        PIR1
       btfss  PIR1,EEIF        ; wait for interrupt flag to be set
       goto   $-1                        bcf    PIR1,EEIF        ;clear eewrite irq flag
       return


     -- View this message in context: old.nabble.com/Porting-from-16f648a-to-16f690-trouble.-ASM-tp31668860p31668860.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2011\05\21@090019 by Olin Lathrop

face picon face
threewheeler6 wrote:
> My program works like expected on the 684a but when ported to
> the 690 it is full of bugs.

That means it's full of bugs either way, but that everything was just right
before so that the symptoms didn't manifest themselves.

I just tried to look up a 16F684A and couldn't find it.  Provide a link to
the datasheet.

> It will not read the mode jumper to got into program
> mode reliably,

That's obviously a good place to start chasing down why it's not working.
What have you found so far?

{Quote hidden}

First, this wouldn't have assembled with MPASM since opcodes must start in
column 2 or later.  If you're using a nonstandard assembler, you should
point that out.

Second, this code exhibits disregard for banking, including both the direct
and indirect banks.  Perhaps there are special circumstances that allow
banking to be ignored here, but then there should be comments explaining the
unusual circumstances.  Third, there are hardly any comments.

This code was a disaster waiting to happen, and now it did.  The best way to
deal with it is to ditch the code, fire whoever wrote it, then get someone
competent to replace it from the specs only.  Allowing this code to live on
even in some small way will only cause more trouble.


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

2011\05\21@183705 by cdb

flavicon
face
On Sat, 21 May 2011 09:00:53 -0400, Olin Lathrop wrote:
:: First, this wouldn't have assembled with MPASM since opcodes must
:: start in column 2 or later.  If you're using a nonstandard assembler, you
:: should point that out.

Not wanting to start a bun/bagel fight, but it did format as the second column in my email client when viewing it, and he does use banksel in the called eeprom subroutines.

As you intimate it would be useful to see the pin jumper code to see if this is where things go awry.

Colin


--
cdb, spam_OUTcolinTakeThisOuTspambtech-online.co.uk on 22/05/2011
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au

2011\05\21@190057 by cdb

flavicon
face
On Fri, 20 May 2011 19:22:17 -0700 (PDT), threewheeler6 wrote:
:: The only thing changed was the
:: config bits, the pin definitions, and compairitor/ad settings.

As the 16F628/48a devices are 18 pin and the 16F690 is 20 pin (DIP package) are you sure you've physically matched the right pins to the correct code function?

Have you taken account of the extra PI registers for the EE flags and interrupts?

Are you clearing ANSEL to make PORTA digital, as CMCON1 is off at start up?

Colin

--
cdb, .....colinKILLspamspam@spam@btech-online.co.uk on 22/05/2011
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au

2011\05\21@204655 by Oli Glaser

flavicon
face
On 21/05/2011 23:37, cdb wrote:
> On Sat, 21 May 2011 09:00:53 -0400, Olin Lathrop wrote:
> :: First, this wouldn't have assembled with MPASM since opcodes must
> :: start in column 2 or later.  If you're using a nonstandard assembler,
> you
> :: should point that out.
>
> Not wanting to start a bun/bagel fight, but it did format as the second
> column in my email client when viewing it, and he does use banksel in the
> called eeprom subroutines.
>

It did on mine too..
@ Olin - what mail client are you using?

> As you intimate it would be useful to see the pin jumper code to see if
> this is where things go awry.

Yes, might be helpful to see the schematic too, along with a more specific account of the bugs. I can't recall the exact differences between a 648 and 690 but I suspect it's something to do with the initialisation - ANSEL, ANSELH, comparators and such being set correctly.
Writing some debug code to test each bug separately (e.g. start with the basics and do things like making sure each pin is set up properly), or using MPLAB SIM to step through the code might be useful.

2011\05\22@083328 by Olin Lathrop

face picon face
Oli Glaser wrote:
>> Not wanting to start a bun/bagel fight, but it did format as the
>> second column in my email client when viewing it, and he does use
>> banksel in the called eeprom subroutines.
>
> It did on mine too..
> @ Olin - what mail client are you using?

Plain old Outlook Express.  However, I don't think it's the client.  The OP
probably left tabs in the code if several of you saw it differently.


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

2011\05\22@102728 by Dave Tweed

face
flavicon
face
Olin Lathrop wrote:
> Oli Glaser wrote:
> > > Not wanting to start a bun/bagel fight, but it did format as the
> > > second column in my email client when viewing it, and he does use
> > > banksel in the called eeprom subroutines.
> >
> > It did on mine too..
> > @ Olin - what mail client are you using?
>
> Plain old Outlook Express. However, I don't think it's the client. The OP
> probably left tabs in the code if several of you saw it differently.

Yes, the OP used hard tabs to indent his code, so it IS your client, which
apparently can't handle it.

But it's easy enough in Outlook Express to view the raw source file of an
email message to check. Every time you carp about this without checking first
makes you look foolish.

-- Dave Twee

2011\05\22@111442 by threewheeler6

picon face



CDB-3 wrote:
>
> Have you taken account of the extra PI registers for the EE flags and
> interrupts?
>
>
Colin, thank you. I must have overlooked that the EEIF bit was in PIR2 and
not PIR1 I feel a little stupid now. Everyone else, thank you for all your
help. I'm learning more everyday.
-- View this message in context: old.nabble.com/Porting-from-16f648a-to-16f690-trouble.-ASM-tp31668860p31675602.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2011\05\22@111704 by Olin Lathrop

face picon face
Dave Tweed wrote:
> Yes, the OP used hard tabs to indent his code, so it IS your client,
> which apparently can't handle it.

It probably can, but it's a question of where the tab stops were set.  I
have never set them deliberately in OE.  I have no idea how its tab stops
are set or where it inherits them from.

However, the point is that there is no standard interpretation of tab
characters, which is why they shouldn't be left in code you show others.

> But it's easy enough in Outlook Express to view the raw source file
> of an email message to check. Every time you carp about this without
> checking first makes you look foolish.

Leaving tabs in code is a well know stupidity.  No, when providing free help
I'm not going to go out of my way to check on various stupid things someone
may have done in formatting their code.  Someone asking a question here may
not know about PICs, but they have some obligation to follow basic common
sense, including not leaving tabs in code.


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

2011\05\22@115105 by Bob Blick

face
flavicon
face
Hi Olin,

You should have chosen this message or ones before to change the tag to
[OT]

Do not mess up [PIC] with talk of mail clients and tab settings.

Neither one of them is on topic.

Tabs versus spaces is just like emacs versus vi. At best it is religion.
At worst it is... worse, I guess.

Just to clarify,

Talk sbout mail clients = [OT]
Talk about tab settings = [OT]

Bob


On Sun, 22 May 2011 11:17 -0400, "Olin Lathrop"  wrote:
{Quote hidden}

> -

2011\05\22@123535 by Dave Tweed

face
flavicon
face
Olin Lathrop wrote:
> Dave Tweed wrote:
> > Yes, the OP used hard tabs to indent his code, so it IS your client,
> > which apparently can't handle it.
>
> It probably can, but it's a question of where the tab stops were set. I
> have never set them deliberately in OE. I have no idea how its tab stops
> are set or where it inherits them from.
>
> However, the point is that there is no standard interpretation of tab
> characters, which is why they shouldn't be left in code you show others.

It doesn't matter what the "tab stops" are. As long as there is a tab
character there, there should be some visible evidence of it; otherwise,
OE is just broken.

The "standard interpretation" of tab characters is that they count as
whitespace, which is all we're concerned about here.

> > But it's easy enough in Outlook Express to view the raw source file
> > of an email message to check. Every time you carp about this without
> > checking first makes you look foolish.
>
> Leaving tabs in code is a well know stupidity. No, when providing free help
> I'm not going to go out of my way to check on various stupid things someone
> may have done in formatting their code. Someone asking a question here may
> not know about PICs, but they have some obligation to follow basic common
> sense, including not leaving tabs in code.

But your stated standard is what's acceptable to the standard Microchip
assembler, and the code as posted meets that standard. The fact that you can't
see that it meets that standard -- and then you complain about this to the
list, time after time, rather than simply ignoring the post altogether -- is
what makes you look foolish.

If you can be bothered to post a reply, then you can be bothered to click
"View --> Message Source" (IIRC) first.

-- Dave Twee

2011\05\22@124623 by Bob Blick

face
flavicon
face
Hi Dave,

Tab settings  = [OT]
Email clients = [OT]

Bob

On Sun, 22 May 2011 12:35 -0400, "Dave Tweed" wrote:
{Quote hidden}

> -

2011\05\22@133630 by Joe Wronski

flavicon
face
 On 5/22/2011 11:17 AM, Olin Lathrop wrote:
>
> Leaving tabs in code is a well know stupidity.

I guess that would be true if the tool used to compile the code was known to be column based or intolerant of white space variations, but was that really the issue here?

--
Joe Wronski
Stillwater Embedded Engineering
http://www.stillwatereng.net

2011\05\22@134732 by Bob Blick

face
flavicon
face
Hi Joe,

Tab settings  = [OT]
Email clients = [OT]

Bob

On Sun, 22 May 2011 13:36 -0400, "Joe Wronski" wrote:
>   On 5/22/2011 11:17 AM, Olin Lathrop wrote:
> >
> > Leaving tabs in code is a well know stupidity.
>
> I guess that would be true if the tool used to compile the code was
> known to be column based or intolerant of white space variations, but
> was that really the issue here?

-- http://www.fastmail.fm - mmm... Fastmail...

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