Problem with PortB Tris


Closed Thread
Results 1 to 10 of 10

Hybrid View

  1. #1
    Join Date
    Apr 2011
    Location
    Kent, UK
    Posts
    52


    Did you find this post helpful? Yes | No

    Default Re: Problem with PortB Tris

    I agree, hardware I2c is the way to go, but thats alot of effort to make it work. The I2cREAD/WRITE work so well outside an interrupt environment.

  2. #2
    Join Date
    May 2006
    Location
    Del Rio, TX, USA
    Posts
    343


    Did you find this post helpful? Yes | No

    Default Re: Problem with PortB Tris

    FWIW, here is an include file I put together (a long time ago) to use the Hardware I2C. It may be useful. It uses arrays as buffers to input and output data.
    HI2C_Subs.bas
    It uses arrays as buffers to input and output data. This real time clock include shows how the H12C is used.
    RTC_Subs.bas
    It's been a while since I've used/looked at it, so there is likely quite a bit that could be improved. But, it worked when I used it. I just can't remember all the details of how.

  3. #3
    Join Date
    Apr 2011
    Location
    Kent, UK
    Posts
    52


    Did you find this post helpful? Yes | No

    Default Re: Problem with PortB Tris

    Interesting.
    I will try and pick it apart to see how you ran the module, then try and write my own interpretation so I will then understand how it works.

    Cheers,
    Tim.

  4. #4
    Join Date
    May 2006
    Location
    Del Rio, TX, USA
    Posts
    343


    Did you find this post helpful? Yes | No

    Default Re: Problem with PortB Tris

    Here are some things I’d look into changing or using now that I look at it again. First, some easier changes:

    - Not so much a change to the routines, but in how they are called. Use the new (ish) ARRAYWRITE command to load the array buffer, and the ARRAYREAD command to read the array buffer. The nice thing about these is that they use the modifiers for formatting strings, like DEC and HEX
    - The routines use 2 array buffers, one for input (I2CRDBuff) and one for output (I2CWRBuff). I think this could be reduced to only one array buffer pretty easily. It would save on RAM (may not be an issue) and likely simplify things a little.

    Much bigger changes which would require a more significant amount work:

    - Implement interrupts (via DT’s Instant Interrupts) to do the sending/receive of data ‘behind the scenes’. Basically, load up the array, point the I2C to the correct address, and pull the trigger. The rest will take care of itself while your main program goes on its way doing something else.
    - Implement an assembly macro to execute the routines (similar to how the LCD bar graph macro works). This would simplify coding in the main program module.

    Who knows, maybe I may look into it as well if time permits. Gives me something to stay out of trouble.

Similar Threads

  1. Replies: 6
    Last Post: - 12th March 2011, 13:11
  2. 16f886 interrupt on portB problem
    By antonjan in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 8th October 2008, 20:06
  3. 16F689 PORTB.7 Problem
    By jderson in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 5th April 2008, 06:43
  4. Problem With Bootloader And Portb.3
    By bobonapoletano in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 31st December 2005, 16:10
  5. Problem with peek in portB
    By hawk72501 in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 27th August 2005, 12:01

Members who have read this thread : 0

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