16F877 RAM Question


Closed Thread
Results 1 to 9 of 9
  1. #1
    Join Date
    Aug 2003
    Posts
    985

    Default 16F877 RAM Question

    Hi Guys,
    I am currently working with a 16F877, and looking at the datasheet, it
    appears to have 336 total bytes of RAM. The issue I'm having is that my
    PBP program defines 71 bytes, and if I define and use a couple more bytes,
    my program goes totaly battly, leading me to beleive that I'm out of RAM.

    I understand that PBP uses RAM for library routines, and I am using a lot of
    library subroutines, but is this an expected number of bytes for a 16F877?

    Is there some special thing I need to do in order to use extra bytes on the
    chip, or must it be done in assembler?
    Cheers, Art.

  2. #2
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    mmm, is it me or i think you mix 2 things here, codespace and RAM wich is far different.

    Where you get your 71 bytes results???
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  3. #3
    Join Date
    Aug 2003
    Posts
    985


    Did you find this post helpful? Yes | No

    Default

    I'm talking about RAM only.
    There are 4 banks that are supposed to contain 96, 80, 80 & 80
    bytes of RAM??

  4. #4
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Art
    I understand that PBP uses RAM for library routines, and I am using a lot of
    library subroutines,
    well i should read your post better the first time. For subroutine, it will take much CodeSpace than RAM, except if you have ton's of variable definition.

    Personnally i never filled the whole RAM but... BUT hehe many times the CodeSpace.

    BUT, there's a but that i'm not sure of but someone will have the pleasure to set me straight if i'm wrong, PBP will probably manage the whole thing for you... i guess it will place the extra RAM blah blah in the CodeSpace section... pure guess here !
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  5. #5
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    PBP uses the same couple or three dozen variables over and again for it's routines. They are reused. Those variables aren't created again if you use the routine in several places. In an 16F877, with 370 bytes, you should have at least 330 bytes of RAM that you can assign for your own use. This all depends on your code, but you have to be doing some pretty drastic things, or have some huge arrays assigned to use up that much resource.

    Btw... PBP doesn't swap RAM into codespace. RAM is RAM, and codespace is codespace, the two aren't mixed unless YOU deliberately do it in your program.

  6. #6
    Join Date
    Aug 2003
    Posts
    985


    Did you find this post helpful? Yes | No

    Default

    Hmm
    Code:
    ADR var word : dat var byte : EEunit var byte		'define I²C address, data & unit variables
    delay var byte						'define delay time variable
    T1 var byte : T2 var byte : T3 var byte			'define real time buffers
    T4 var byte : T5 var byte : T6 var byte			'
    A1 var byte : A2 var byte : A3 var byte			'define alarm time variables
    A4 var byte : AA var bit  : AL var bit			'define alarm condition variable bits
    D1 var byte : D2 var byte : DB var byte			'define display digit buffers
    D3 var byte : D4 var byte				'
    D5 var byte : D6 var byte				'
    B0 var byte						'define GPS data bytes
    B2 var byte : B3 var byte				'
    B4 var byte : B5 var byte				'
    B6 var byte : B7 var byte				'
    DP var bit 						'define decimal point status bit
    JS var bit						'define joystick status variable
    DC var byte						'define display comparison variable
    RC var byte						'define real time clock comparison variable
    mode var byte						'define mode variable byte
    colcnt var byte						'define colon delay counter variable byte
    sndbuff var byte					'define sound buffer value variable byte
    soundcalc var byte : snd var byte			'define sound calc variable byte
    L0 var byte : L1 var byte : L2 var byte			'define variables for Lat & Longitudinal coordinates
    L3 var byte : L4 var byte : L5 var byte			'
    L6 var byte : L7 var byte : L8 var byte			'
    L9 var byte : LA var byte : LB var byte			'
    LC var byte : LD var byte : LE var byte			'
    LF var byte : LG var byte : N1 var byte			'
    LNG var byte : LAT var byte 				'
    last var DB.bit7 : first var DB.bit0			'define display buffer first & last bits for swapping
    msel var bit : ply var bit				'define mode display / play and pause status bits
    LTA var byte : LTD var byte				'define lookup table value & data bytes
    '
    roll var byte : Rcnt var byte				'define display animation control variables
    roll1 var roll.bit0 : roll2 var roll.bit1		'
    roll3 var roll.bit2 : roll4 var roll.bit3		'
    roll5 var roll.bit4 : roll6 var roll.bit5		'
    rollo var byte						'
    rollo1 var rollo.bit0 : rollo2 var rollo.bit1		'
    rollo3 var rollo.bit2 : rollo4 var rollo.bit3		'
    rollo5 var rollo.bit4 : rollo6 var rollo.bit5		'
    rolls var byte						'
    rolls1 var rolls.bit0 : rolls2 var rolls.bit1		'
    rolls3 var rolls.bit2 : rolls4 var rolls.bit3		'
    rolls5 var rolls.bit4 : rolls6 var rolls.bit5		'
    F1 var byte : F2 var byte : F3 var byte			'
    F4 var byte : F5 var byte : F6 var byte			'
    '
    SM var bit						'define search match status bit
    as you can see, there aren't a lot of variables.
    I think that the library variables are being added to total the 96 bytes
    in the first bank of RAM and then the compiler is clapping out there.
    If I add just a few more byte size variables and set them to any value
    to make sure they are used, my program will no longer start

    If I remember correctly from my 16F84 days, PBP uses some variables
    to pass values from the user's PBP routines to it's own library routines.
    with a bit of assembler hacking I have managed to claim some of these
    "middle man" variables in the past.
    Art.

  7. #7
    Join Date
    Aug 2003
    Posts
    985


    Did you find this post helpful? Yes | No

    Default

    I have made an interesting discovery.
    My program only contains two lines that change the bank select bit RP1.
    This means that my PBP program can only be accessing the first two RAM banks which is only a little more than half that the chip provides.

    It seems I will have to change the RP1 bit manualy in assembler to use the rest of the RAM. Surely I'm not the only one who has encountered this?



    ... well it seems I answered my own question.
    A little later I have found out that some of the exixting asm in my PBP code
    that addresses RAM does so incorrectly when PBP changes the location of
    that RAm without my asm code knowing about it.
    So a little thing like:
    @ incfsz _colcnt,f
    @ goto _decpnt
    can cause the whole program to break when the variable 'colcnt' requires
    a change tot he bank select bits in order to address it. or at least that's what
    I think is happening at the moment...

    Anyway I have solved my original problem
    Last edited by Art; - 6th August 2005 at 06:16.

  8. #8
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    No, something's not right.

    I've used PBP with 16F876 extensively, which is the smaller I/O brother of the 877 without problem. I've maxed out the RAM and the Program Codespace and know PBP works to the limit of the PIC with versions 2.44, 2.45 and 2.46.

    Now if you are embedding Assembler which is going to Bank Switch or do anything other than rudimentary functions or access Registers that PBP isn't, then you must save the current environment on entry and restore it on exit. Otherwise you will not leave the PIC in the state PBP expects it to be.

    What version of PBP are you using?

  9. #9
    Join Date
    Aug 2003
    Posts
    985


    Did you find this post helpful? Yes | No

    Default

    I think maybe I didn't explain myself too well.
    At this stage I am able to use all of the chip's RAM with a pure PBP program.

    I think the reason why my code originaly stuffed up when I used more than a
    certain amount of RAM is that I had asm routines that accessed RAM without
    any bank switching.
    Therefore, the addition of more RAM to my program might have allocated
    existing variables to areas of RAM that would require bank switching by my
    asm code when addressing them.

    I hope that makes better sense.. everything is working now I have gone back
    to pure basic. At some stage I like to convert it to all asm for optimising, but
    best wait until it's close to finished.
    Art.

Similar Threads

  1. On-Chip RAM
    By DaveC3 in forum mel PIC BASIC Pro
    Replies: 12
    Last Post: - 28th July 2008, 11:16
  2. problem using 16f877
    By yrch in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 20th February 2006, 19:58
  3. Timer Question 16f877
    By Bonxy in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 8th November 2005, 09:40
  4. PIC 16F877 Question
    By koossa in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 5th August 2005, 19:06
  5. 18f452 tables in ram - code?
    By rshanks in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 1st October 2004, 06:06

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts