w = TRIS_B equivalent in Assembly
jgjonola
Posts: 27
Quick question (I hope) :
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:
·
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
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
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)
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
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