PORTB will not initialize LOW, only HIGH?

Thread Starter

ronbowalker

Joined Jun 26, 2009
23
I am trying to initialize a PIC16F819 and it will not take the PORTB pins to a LOW setting on initialization. It does PORTA just fine, and it does both TRISA and TRISB settings correctly. What is it I am missing here?
'''''''''''''''''''''''''''''
OSCCON = %01100000 '4mHz
ADCON1 = 7 'Digital
'Initialize Inputs/Outputs
TRISA = %01110100
TRISB = %01000000
'Initialized Highs/Lows
PORTA = %10000001
PORTB = %00000000
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
I have also tried to use the (PORTB.0 = 0) way, and it too does not work.
Neither does (LOW PORTB.0).
Never had this problem with any of the other chips I have used.
Here is the .INC file info for MPASM......
__CONFIG _INTRC_IO & _WDT_OFF & _PWRTE_OFF & _LVP_OFF & _MCLR_OFF & _BODEN_OFF & _DEBUG_OFF
 

Thread Starter

ronbowalker

Joined Jun 26, 2009
23
PICBASIC PRO.......MPASM is what I am using.

Change Banks? Not familiar with this......sorry.

Thanks for the help, keep it coming!
 

Papabravo

Joined Feb 24, 2006
21,159
PICBASIC PRO.......MPASM is what I am using.

Change Banks? Not familiar with this......sorry.

Thanks for the help, keep it coming!
You cannot acces all file registers all the time. There are not enough address bits in an instruction for that to happen. The solution is to group the file registers into two or more banks. The register file bank address bits are in the STATUS register and have names like RP1 and RP0. They are initialized to 0 zero at power up reset. If the file register you wish to access is not in bank 0 then you have to set the bank address bits, then access the register and return them back to bank 0. Bank 0 contains the file registers that you are most lkely to want to access. Got the PICture -- so to speak.
 

Thread Starter

ronbowalker

Joined Jun 26, 2009
23
Thanks for the info Papabravo, I am reading the Datasheet again, and it speaks of none of this.....writting to TRISA, TRISB, PORTA and PORTB has always worked on other chips in this fashion, so what is up with this one? I have had a hard time with these PIC16F819 chips and I am going to look for a better nano chip to use. I am loosing faith that this chip is worth any more of my time, is tha PIC16F87/88 better?
 

Markd77

Joined Sep 7, 2009
2,806
Not sure about the 819 but on PIC12F675 I use this:
BSF STATUS, RP0 ; Select Bank 1
MOVLW B'00100001' ; Value used to
; initialize data
; direction
MOVWF TRISIO ; Set GP<4-1> as output, GP0 input
BCF STATUS, RP0 ;bank 0
 

Thread Starter

ronbowalker

Joined Jun 26, 2009
23
Thanks "Alberto", you are on the same page that I am.....but it still is not setting up properly. I have several of these chips and they are all doing the same "Incorrect" setup.

Also to "t06afre" thanks....but being a rookie at this makes me not understand the data sheets as well as you might.

Datasheet shows PORTA and PORTB to be in Bank0.
TRISA and TRISB to be in Bank1.
PORTB in Bank2.
PORTA in Bank3

So what would the proper code be to write to the proper Bank0/3, since PORTA & B is located in two places? Is this where my errors are?
 

Markd77

Joined Sep 7, 2009
2,806
Some of the registers are available from more than one bank so with your pic you could write to PORTA from bank 0 or 3. It looks like TRISA and B are only in bank1. The code I posted above should therefore work.
The data memory is partitioned into multiple banks that
contain the General Purpose Registers and the Special
Function Registers. Bits RP1 (Status<6>) and RP0
(Status<5>) are the bank select bits.
RP1:RP0 Bank
00 0
01 1
10 2
11 3
 

AlexR

Joined Jan 16, 2008
732
PIC Basic along with most other high level languages automatically does the bank switching for you so you can ignore any references to bank switching.

Your code looks fine to me so about all I can suggest is that you try it with a different PIC to rule out the possibility of a faulty chip.
 

Papabravo

Joined Feb 24, 2006
21,159
Well you found out that TRISA and TRISB are both in bank 1 so that is progress. That PORTA and PORTB are in multiple places is actually a convenience if you can keep track of such things. Personally I feel that doing things consistenly the same way every time helps beginners write robust code out of the gate. Later as you gain confidence you can get 'clever' and save a word here or there. IMHO an algorithm that works first time every time and is obvious and maintainable, beats one that saves a word or a cycle here and there.
 

AlexR

Joined Jan 16, 2008
732
Well you found out that TRISA and TRISB are both in bank 1 so that is progress. That PORTA and PORTB are in multiple places is actually a convenience if you can keep track of such things. Personally I feel that doing things consistenly the same way every time helps beginners write robust code out of the gate. Later as you gain confidence you can get 'clever' and save a word here or there. IMHO an algorithm that works first time every time and is obvious and maintainable, beats one that saves a word or a cycle here and there.
The OP is using PICBasic Pro. It does does not need bank switching! No high level language compilers need bank switching! The only time you need to worry about bank switching in if you write in assembler.
Adding bank switching will at best have no effect and at worst needlessly bloat the code.
 

Papabravo

Joined Feb 24, 2006
21,159
Excuse me, but the the OP's original statement was ambiguous. What he said was

"PIBASIC PRO....MPASM is what I'm using"

Now MPASM is clearly assembly language IIRC. Your blanket statement about compilers and high level languages using bank switching or not is most certainly incorrect.
 

AlexR

Joined Jan 16, 2008
732
Excuse me, but the the OP's original statement was ambiguous. What he said was

"PIBASIC PRO....MPASM is what I'm using"
Nothing ambiguous about it.
PICBasic produces assembler code as an intermediate step of compiling the source code. The user has the choice of telling it to use the built-in assembler or use Microchip's MPASM to turn the intermediate assembler code into machine code.
The OP is stating that he is using PICBasic PRO and it is set up to use MPASM.

Now MPASM is clearly assembly language IIRC. Your blanket statement about compilers and high level languages using bank switching or not is most certainly incorrect.
Its not? OK show me an example of a high level language that needs bank switching. I certainly don't know of any.
Actually grouping instructions to minimise bank switching is part of the code optimisation process that high level language compiles employ. They are smart enough to know when bank switching is needed and certainly don't want some dumb human messing things up by throwing in bank switching commands manually.
 

Papabravo

Joined Feb 24, 2006
21,159
Some HHLs handle the details for you and this can be a double edged sword as it appears to be in this case. When I use them, (HLLs), I always look for the compiler output. The original motivation for the design of a popular HLL was that it specifically not handle these details but leave the programmer free to do or not do as he pleased. That later compiler writers have chosen to ignore this design requirement is hardly my fault. The point is that the OP has a situation which is neither obvious nor transparent and in this case using the HLL has obviously obsucred the issue and impeded his progress toward solving his problem.

Ronald Reagan had it right when he said "Trust, but verify." Good sentiments those.
 

AlexR

Joined Jan 16, 2008
732
ronbowalker:
As I said before, your code looks OK so in all probability it is a hardware fault but before you throw out your PIC16F819 just make sure that you have selected the correct device type in your compiler IDE. That is the only other reason I can think of your code not working.

Papabravo:
As you rightly say HLLs leave the programmer free to concentrate on the broad structure of the program and leave the detail to the software to sort out. They also do extensive optimisation of the final assembly code so adding low level commands such as your own bank switching would be a total waste of time as these would be optimised out in the final code.
Any HLL compiler that required low level commands such as bank switching to be entered by the programmer would of necessity produce very poorly optermised code. Maybe in days yore there was such a compiler but modern compilers handle all the low level functions internally taking care of the mechanics and leaving the programmer free to concentrate on the logical design of the program.

The OP is using a mature and is well known program that has an excellent track record for producing reliable code.
So, if the OP has defined the correct chip type, source code is logically correct and it compiles without error then you can be 99.9% certain that it is producing correct machine code and the error must be elsewhere, probably a hardware fault or circuit error. The compiler would certainly not be messing up something as fundamental as bank switching on a port configuration.
 
Top