PIC16F88 usart troubles: WVProfessor

[Nigel Goodwin]

I've not played with a 16F88, but other 16F PIC's don't do that, memory is arranged in 2K pages, but programmes will increment over the join without problem. Where you do need to be careful is with jumps, where you need to set PCLATH if changing pages - there's an MPASM assembler 'macro' which does the jump code for you.

Are you sure that isn't your problem?, certainly your previous 'bug' was just your own mistake, and this may well be the same?.

What are you writing to use over 2K of assembler anyway?.

 

[Pommie]

You are of course correct. The good news is that I am a member of the secret society and I can let you in on the secret. To call a routine in the second program area you have to set PCLATH to 0x08 (bsf PCLATH,3 works).

I wrote a macro to get around this problem,

_fcall		macro	Address
        if (Address & 0x800) ==0
            bcf	PCLATH,3
	else
            bsf PCLATH,3
        endif
    call (Address & 0x7ff) | ($ & 0x1800)
        if ($ & 0x800) ==0
            bcf	PCLATH,3
	else
            bsf PCLATH,3
        endif
  endm

Edit, as Nigel states, Microchip provide a similar macro but their's doesn't set PCLATH back to the current bank after the call.
Edit2, as Nigel also states, the 88 does exactly the same as all other 16 series chips, 0x7ff then 0x800.

Mike.

 

[WVProfessor]

Thanks for the reply. I didn't think anyone monitored these old threads. But I definitely need help. I have bin away from the PICs for a few months and near forgot everything. Same way with Linux. I try not to run computers in the summer. But we just had a cold spell in West Virginia.

- there's an MPASM assembler 'macro' which does the jump code for you.

I am not running MPASM. I am using something that runs on a pentium II and the "push" here is to regress to old 486 machines. Don't blame that idea on me. My XP machine crashes several times every time it is turned on, and that is with a different drive and a re-install.

Are you sure that isn't your problem?, certainly your previous 'bug' was just your own mistake, and this may well be the same?.

Well it was certainly sneaky and unexpected.

I tried code that bridged the 800 point and it failed just like my friend said it would. He didn't have the fix and abandoned me lately. Maybe I can look at it again and post the code. It likely is in a folder somewhere.
He gave me a big test board with an 8085 in it, made by Hampden Engineering, an MCB-1. We would be switching to those except there is no code handy for using the serial port.
I write in assembly only. C is not explained well enough for me.

What are you writing to use over 2K of assembler anyway?.

I think I have an outline for my software. All it does is run a real slow A/D and store the results in a 512K flash chip. Since the A/D output is two words that amounts to 32K measurements.
Then when I take this little board over to the PC I can download the flash memory through a serial port. I haven't played with the clocks yet. I will try to pick the divider chain that has the longest count.
It is the messages that take up so much memory.
A quickbasic program in the PC will decode the data and attach the time for display maybe in Excell.

I thought having to use PCLATH at all was terrible and the instruction set is crippled and the the chip really doesn't do the I2C I need automatically. I don't use interrupts because that is too complicated. I don't like multiplexing I/O. This is what comes with a cheap part.

 

[Nigel Goodwin]

I am not running MPASM. I am using something that runs on a pentium II and the "push" here is to regress to old 486 machines. Don't blame that idea on me. My XP machine crashes several times every time it is turned on, and that is with a different drive and a re-install.

If you're not running the MicroChip assembler, then what are you running?.

MPASM is a DOS program, and MPASMWIN is it's Windows version.

Well it was certainly sneaky and unexpected.

Common and explained in the datasheets.

I tried code that bridged the 800 point and it failed just like my friend said it would. He didn't have the fix and abandoned me lately. Maybe I can look at it again and post the code. It likely is in a folder somewhere.

No one else here has mentioned a problem?, or heard of it, PCLATH is only needed for jumps.

He gave me a big test board with an 8085 in it, made by Hampden Engineering, an MCB-1. We would be switching to those except there is no code handy for using the serial port.
I write in assembly only. C is not explained well enough for me.

Serial port code is trivial to write, that shouldn't be any obstacle.

I think I have an outline for my software. All it does is run a real slow A/D and store the results in a 512K flash chip. Since the A/D output is two words that amounts to 32K measurements.
Then when I take this little board over to the PC I can download the flash memory through a serial port. I haven't played with the clocks yet. I will try to pick the divider chain that has the longest count.
It is the messages that take up so much memory.
A quickbasic program in the PC will decode the data and attach the time for display maybe in Excell.

If it's messages that are taking all your space, then check my tutorials, the 8x8 LED matrix one shows how to do large tables.

I thought having to use PCLATH at all was terrible and the instruction set is crippled and the the chip really doesn't do the I2C I need automatically. I don't use interrupts because that is too complicated. I don't like multiplexing I/O. This is what comes with a cheap part.

It's a RISC processsor, low cost and incredibly powerful, I don't think any CPU's do I2C 'automatically' - that's what programmers (people) are for.

From what you say it looks like you're trying to build a simple data-logger?, this is pretty easy using a PIC, and a common project.

 

[Pommie]

... and the the chip really doesn't do the I2C I need automatically. I don't use interrupts because that is too complicated. I don't like multiplexing I/O. This is what comes with a cheap part.

The 88 doesn't have a Master serial port and so it is really only suitable as an I²C slave. If you switch to a 16F883 then you will find I²C much easier and pretty much automatic.

Mike.

 

[WVProfessor]

Real simple data logger

My assembler is gpasm involked with a batch fole that says:
GPASM -a inhx8m %1.asm

The only relavant documents that I have are:
PIC16F87/88 Data Sheet DS39487B
Flash Memory Programming Specification DS39607B
PICmicro Midrange MCU Family Reference Manual DS33023A

Not read in detail:
GPutils 0.13.2 Bowmen & Franklin
MPASM User's Guide
Applications Development with MPLAB

I am always looking for more documents. There is a book about this stuff that is very helpful but I don't have my own copy. The book name is unknown. I might find it.

In the '88 Data Sheet under PCLATH in the Bank1 register listing it calls out some page number like 135 and I go to 135 only to see the register initialization states and no write-up on PCLATH-most disappointing as that blank is all the information I can find.

The file showing the 800 address problem has disappeared. It will take time to get some more answers. It turned hot.

Generally finding out even the most simple dumb thing plays hell with me. I went to Micro... Who makes the PIC chips? their web site, and the documentation is horrible. Stuff they say they have is missing. Then folks say "I did it" but if they don't send me the file I can never find it. Data sheets should be the size of an encyclopedia. They omit so much. Generally websites are required to be organized to make it hard to find anything because that pleases advertizers.

 

[Pommie]

You should download the latest data sheet 30487C and the description of PCLATH is in section 2.3 on page 25 (27 in PDF reader).

Mike.

 

[WVProfessor]

found a message

More trouble with code on the PIC.
I just read something interesting and it complicates the 16F88 programming somewhat. These little buggers can be fascinating and frustrating at the same time.

This is from page 25, section 2.3 of the pic16f87/88 pdf docs.
The program counter is 13 bits wide which allows 8192 (8K) of program.
The upper 5 bits are in PCLATH and the lower 8 bits in PCL, which we know.

The stack is 13 bits wide by 8 deep (not 3, as in the 16F628), so you can have 8 calls outstanding before the stack overflows (and crashes). The RETURN instruction returns to the full 13 bit address space, so it can return to a call from anywhere in memory.

HOWEVER, and this is where it gets sticky, a goto or call instruction sets only 11 bits, 8 in pcl and 3 in pclath. That limits the calls and gotos to 2K of space. To call to a routine in high memory (and this is code straight from the manual), you must:

BCF PCLATH,4 ;Select high page
BSF PCLATH,3 ;(800-8FF)
CALL SUB ; call subroutine in high memory
...
ORG 900h ; High memory subroutine
SUB ...
RETURN ; Goes back to calling routine OK

Another counterintuitive wonder.
I'm wondering if

we shouldn't go back to the 68HC11?

Not finished must go.

 

[futz]

Another counterintuitive wonder.
I'm wondering if

we shouldn't go back to the 68HC11?

Not finished must go.

The Moto 68HC's are sweet processors. Very nice to code for in assembler. Unfortunately I hardly ever look at mine anymore. Almost all PICs and a little AVR these days.

 

[Nigel Goodwin]

HOWEVER, and this is where it gets sticky, a goto or call instruction sets only 11 bits, 8 in pcl and 3 in pclath. That limits the calls and gotos to 2K of space. To call to a routine in high memory (and this is code straight from the manual), you must:

BCF PCLATH,4 ;Select high page
BSF PCLATH,3 ;(800-8FF)
CALL SUB ; call subroutine in high memory
...
ORG 900h ; High memory subroutine
SUB ...
RETURN ; Goes back to calling routine OK

This is what we've been telling you throughout this thread, you need to be careful jumping over 2K barriers.

 

[Pommie]

More trouble with code on the PIC.
I just read something interesting and it complicates the 16F88 programming somewhat. These little buggers can be fascinating and frustrating at the same time.

This is from page 25, section 2.3 of the pic16f87/88 pdf docs.
The program counter is 13 bits wide which allows 8192 (8K) of program.
The upper 5 bits are in PCLATH and the lower 8 bits in PCL, which we know.

The stack is 13 bits wide by 8 deep (not 3, as in the 16F628), so you can have 8 calls outstanding before the stack overflows (and crashes). The RETURN instruction returns to the full 13 bit address space, so it can return to a call from anywhere in memory.

HOWEVER, and this is where it gets sticky, a goto or call instruction sets only 11 bits, 8 in pcl and 3 in pclath. That limits the calls and gotos to 2K of space. To call to a routine in high memory (and this is code straight from the manual), you must:

BCF PCLATH,4 ;Select high page
BSF PCLATH,3 ;(800-8FF)
CALL SUB ; call subroutine in high memory
...
ORG 900h ; High memory subroutine
SUB ...
RETURN ; Goes back to calling routine OK

Another counterintuitive wonder.
I'm wondering if

Not finished must go.

This is why I wrote the macro posted on the previous page. Maybe you should try to read/understand other posters replies. You seem to be very quick to criticize and very slow to acknowledge when someone helps, or maybe that is a symptom of your lack of reading replies. BTW, how is the I²C going.

Mike.

 

[skyhawk]

HOWEVER, and this is where it gets sticky, a goto or call instruction sets only 11 bits, 8 in pcl and 3 in pclath.

This is a wrong concept. PCLATH is a distinct register from the PC. PCLATH is only changed by a write operation on it such as BCF, BSF, MOVWF. On a call or goto instruction the lower 11 bits of the PC come from the instruction and the upper two bits from PCLATH(4:3), but PCLATH(2:0) is unchanged. In normal sequential operation the entire 13 bit PC is incremented so the program steps from 7FF to 800 without complications. PCLATH plays no part in sequential operation. PCLATH is only needed because the 14 bit instruction word is not longer enought to hold an op code and a full 13 bit address. It is only used for call, goto, or a write operation to PCL. See figure 4-2 in the data sheet.

 

[Pommie]

Just to add to Skyhawk's excellent explanation, on a write to PCL all relevant bits (4 to 0) of PCLATH are used.

Mike.

 

[WVProfessor]

No find

Straight from Microchip's website:
Your search 30487 did not match any documents. Please refine your search.
I can't find much help on their site. I finally got it and downloaded. It looks identical to revB which I printed.

The price for the 16F883 is right and I have thought about going to 40 pins. I just have a bunch of 20 pin sockets. 40 pins hopefully means the I/O could be set up once and then left for ever. I could have a real 8 pin parallel port with additional lines on the side for hand shake. Not needed for the current project though.

The 68 hc11 has too many pins as does the 8086 (and too high a price). I would rather have dips. The fewer pins the better till it gets down to 20. I like the $2 price of the '883.

I don't know how to use Pommie's macro because it is not the kind of assembly code that I put in GPASM. I can't understand it. I don't even know what (Address & 0x800) means. Is it C?

So am I right to say that PCLATH hides in the background and only clobbers the top part of the pc during jumps. And it doesn't get reset until you do it with an instruction?

 

[Nigel Goodwin]

I don't know how to use Pommie's macro because it is not the kind of assembly code that I put in GPASM. I can't understand it. I don't even know what (Address & 0x800) means. Is it C?

No, it's a macro, it causes the assembler to create assembler code when it's assembled - I've no idea if the non-standard assembler you're running will accept it or not.

 

[WVProfessor]

A more standard assembler?

I found Microchip's MPASM on my Pentium II and started playing with it. I did the first short tutorial and all the answers came out correct. I suspect I have it loaded correctly and am proceeding to the second long tutorial.
I may get it to work with my program.
Simulation seems like a trickey thing. Since I have peripherals that act in complex ways It will be painful to sit there and click the mouse every time the peripheral has to respond. Does that mean that I must build an additional program that simulates the peripheral? What software allows that?
So am I stuck using the hardware? I have programmed my little chip many hundreds of times. When will it get worn out?

Where do you put the macro? How does it work? Is it carefully placed for every instance or only once at the beginning?