Shop OBEX P1 Docs P2 Docs Learn Events
w = TRIS_B equivalent in Assembly — Parallax Forums

w = TRIS_B equivalent in Assembly

jgjonolajgjonola Posts: 27
edited 2005-08-16 03:57 in General Discussion
Quick question (I hope) smile.gif :

In sx/b if i want to find out how the direction register of port b is set, i might do temp=tris_b...

In assembly, if i do:

mov w, !rb

i get an error.· So how do i get the status of !rb?· Basically, before i set the direction of rb i want to OR it with the new values so that i only affect the pins that i intend to...· I have tried to follow some code from compiled sx/b and here is what it shows for sx/b:
·
TRIS_B        EQU  $FB

MOV FSR, #TRIS_B        ;result = TRIS_B
MOV result, IND


Can someone explain what is going on with this bit of code (im obviously new to assembly).

I understand that the FSR points to a memory location, right?· So are we basically moving a memory pointer to $FB? and then IND contains whatever is at the FB location? if so, how would i do the same with port c, mov FSR, $FC?· How do i know what memory location is what?· HELP!!!· [noparse]:)[/noparse]

Thanks,
John Gjonola




Post Edited (jgjonola) : 8/15/2005 10:12:36 PM GMT

Comments

  • pjvpjv Posts: 1,903
    edited 2005-08-15 23:00
    Hi John;

    In SX/B, images of the values of the port direction (TRIS) registers are maintained in RAM under SX/B control, and hence they are always accessible.

    In assembler this is not so:

    For the SX28 and smaller processors, the TRIS registers are internal to the processor, and NOT directly readable, although they are writable. If their states are not predictable at any point in your program, then you will need to keep a copy of them in RAM as SX/B does.

    In case of the SX48/52, these TRIS registers ARE directly readable through extended MODE settings, so in that case you need not keep a copy in RAM.

    This can all be found in the product documentation of the UBICOM website.

    Hope that clears thing up for you.

    Cheers,

    Peter (pjv)
  • NateNate Posts: 154
    edited 2005-08-15 23:15
    John,

    As you have discovered, you cannot 'read' the direction of the port registers.

    When I have an application that changes the direction of the port registers as the program is running, I set up 3 variables called TRIS_A, TRIS_B and TRIS_C.· These variables are just sets of bits that are flags for the actual directions of the registers.· I initalize these flag variables to match the directions of the port direction registers (usually %11111111).· Then, any time during the program I want to change the direction of a port, I perform the changing operation (AND, OR, MOV, SETB etc) on the variable (TRIS_A, TRIS_B or TRIS_C)·and then do a "MOV !ra, TRIS_A" (or "MOV !rb, TRIS_B", or "MOV !rc, TRIS_C).· This allows me to keep the port variable current with the current status of the port and in turn have a dummy port direction variable that I can monitor.

    I also used SX/B examples to come up with this scheme, but at this point in time I cannot remember why SX/B uses the index register to do the transfer. (Perhaps a little more efficient when you are changing all three port direction registers one after the other?· You could roll through the variables simply using an INC command?)

    Anyhow, thats how I do it, and I'm sure there are others that have other (and perhaps better) ways of port direction monitoring.

    Nate
  • jgjonolajgjonola Posts: 27
    edited 2005-08-16 03:57
    Ahh! I see now. I had wrongly assumed that since it was done in SX/B it, you must be able to do it in assembly directly. I didn't even consider the fact that they might be using their own code to do this. I assumed that the vars that they used were pointing to a place in memory that was specifically reserved for those direction registers. Now it's all clear!

    Thanks again you guys! I can't wait until I get good enough to answer other peoples questions instead of asking them all. If there were only 48 hours in a day [noparse]:([/noparse]

    John Gjonola
Sign In or Register to comment.