Need SASM to not truncate Mode value to 4 bits!?!
Hi,
Just wondering why the SASM assenbler truncates the mode value to 4 bits?
According to the datasheet for the SX52/48 I need to set the mode to $16, and $17.
(5 bit numbers)
Generates a warning that the mode is truncated to 4 bits.
The mode needs to be 5 bits according to the SX52 datasheet
(SX52 Datasheet, section 3.3.1)
This seems to be an error in SASM for the SX52 (SX-Key v3.10)!
Any ideas?
Thanks!
Dan
·
Just wondering why the SASM assenbler truncates the mode value to 4 bits?
According to the datasheet for the SX52/48 I need to set the mode to $16, and $17.
(5 bit numbers)
;Configure PWM control registers. MODE $16 ;Mode to Write Timer Cntrl B. MOV !RB,T1CNTB MOV !RC,T2CNTB MODE $17 ;Mode to Write Timer Cntrl A. MOV !RB,T1CNTA MOV !RC,T2CNTA
Generates a warning that the mode is truncated to 4 bits.
The mode needs to be 5 bits according to the SX52 datasheet
(SX52 Datasheet, section 3.3.1)
This seems to be an error in SASM for the SX52 (SX-Key v3.10)!
Any ideas?
Thanks!
Dan
·
Comments
MOV W,#$16
MOV M,W
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available now... SX-Video OSD module $59.95 www.sxvm.com
"Save your money. Pay with cash."
·
To clarify Bean's post a bit more, the SX48/52 does NOT support immediate 5 bit writes to the MODE register such as you can with the SX28. You MUST use the w to load up the 5 bits.
Cheers,
Peter (pjv)
I finally figured it out.
I did notice that·trying to write a 4 bit value using the mov w,#x,
and then mov m,w it doesn't seem to work. I tried several tests of this,
and could not get the indirect loading of M to work at all with 4 bit
values. Only the mode (mov M,#literal) seemed to work. I eventually
ended up with a macro that looks at bit 5, and choses the correct
command(s) based on the value being moved to mode.
I'll have to·test it a bit more later. I Will post results if I get around to it.
I'm currently supporting 8 active designs with SX in them...·· ...you'd think by
now, I'd have all of this stuff figured out!··
-Dan
here is the macro you might use:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
and was wondering if mov m,#lit clears bit 5 of the m register?
The weird thing about what I'm seeing is that...
...doesn't seem to work for 4 bit values? I must be missing something....· ...What am I·missing?
-Dan
When the "small" SXes were designed, setting the mode register to any value from $00 to $0F was more than sufficient to select the various port configuration options. Therefore, the MOV m, #lit instruction was defined to handle four bits only. If you take a look at the binary instruction code for mov m, #lit it looks like this:
0000 0101 LLLL
as you can see, the lower four bits are used to define the value to be written into m.
BTW, the
mode lit
instruction is a syntax alternative only, the assembler generates the same instruction code for this one as for mov m, #lit.
Later, when the "large" SX48/52s were designed, more than 16 modes for port configuration, and the general purpose timers were required, IOW, the lower four bits in the m register were not enough. Without messing up all the instruction codes, it was not possible to modify the mov m, #lit instruction in a way that it would set 5 bits instead of four. Therefore, on SX48/52 devices, you should always use the instruction pair
mov w, #lit
mov m, w
instead. Please note that, different from instructions like
mov fr, #lit
which are expanded by the assembler into
mov w, #lit
mov fr, w
this is not the case with mov m, #lit. Here the assembler generates the single-word code as shown before.
Concerning your question if mov m, #lit clears bit 5 in the m register, I made a simple test by single-stepping the following sequence on an SX52:
mov w, #$ff
mov m, w ; results in m = $1f
mov m, #0 ; results in m = $10
As you can see, the mov m, #lit does _not_ reset bit 5, and the mov m, w instruction only modifies the lower 5 bits in m (I assume that the m register internally has only four bits on SX2? devices, and 5 bits on SC48/52 devices).
Although I heard of people having the optinion that debuggers are for wimps only, somethimes the debugger is a fine tool for exploring a certain behavior of the SX, like in this case.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
OUCH !!!!!;
That wimp comment by whomever hurt!
I do a lot of work with the SXes, pretty much all in assembler, and I think the DEBUG feature is about as good as things get. In fact, I'm positive it is the only reason why I can get relatively large assembler efforts up and running.
Without DEBUG (and of course context save on interrupt), I probably would still be in that lowly "PIC" land.
Cheers,
Peter (pjv)
well, I can't disclose who made that wimp comment but this guy probably does know each single bit inside the SX that he always writes bug-free code at the first place
Besides this, I especially like the SX debugger because it allows you to really "look" into the silicon. Often, it is faster writing some lines of test code, and single step through it to see what happens instead of trying to find the right explanation in the data sheets (if there is any).
IMO, the debugger is good for debugging applications but is it also good for exploring the SX-internals, and thus it is also a great learning tool. So - finally - I have to out myself - I also belong to the group of wimp SX programmers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
What do you mean that the code doesn't work for 5 bit values? if that code is in a macro, and the first parameter is defined, it works just fine. You might what to add a line like
· what = \1
so that the listing will show you what the macro is recieveing as the first parameter.
There is a lot of information about this at
http://www.sxlist.com/techref/ubicom/sxports.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james at sxlist,com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
I think I figured it out. This is really messed up! You can use a mov m,#lit to
set mode to select the direction registers on the SX52, if you set #lit to
#$0F.
Example!
·You can write the direction registers in the sx52 with...
and...
but NOT...
I had been using the·the·wrong value for mode to·set directions, but it workes
if you use the mov m,#lit command!
See, I'm not nuts...·· ...I was missing something small.
-Dan
as I had suggested in my last post, you might check the results of the
mov m, #lit
and
mov w, #lit
mov m, w
instructions on an SX52 with some sample code and the debugger.
It's that simple:
Think of the m register in the SX48/52 having 5 bits only. The
mov m, #lit
instruction can only modify the lower four of these five bits, leaving the fifth bit unchanged.
The
mov m, w
instruction copies the lower 5 bits in w into the five bits in m with the upper three bits in w being ignored.
Think of the m register in the SX2? having 4 bits only. The
mov m, #lit
instruction modifies the four bits in the m register.
Similarly, the
mov m, w
instruction copies the lower 4 bits in w into the four bits in m with the upper four bits in w being ignored.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
You are absolutely correct in your assessment.
It also behooves one to realize that on RESET of an SX48/52, that same 5th bit is NOT AFFECTED. So after a reset (not the same as a POWER-UP), the 5th bit may be set, or reset, depending of the previous state.
For greater certainty then, one should only modify the MODE register in an SX48/52·by transferring the content of W through a mov m,w instruction.
Cheers,
Peter (pjv)
The SX52 data sheet says that M=$0F is only used to READ the port direction registers, and that $1F is used only for WRITES to the direction registers. Refer to the table in the SX52 datasheet (pg 12???).
Let me clear something up. IN ALL CASES, the M register was = $0F.
Again, with "mov m,#$0F" the direction registers WILL change. (debugged M = $0F)
The dirs WILL NOT change with "mov w,#0F" followed by "mov M,w".(debugged M = $0F)
The gotcha here isn't the number of bits, it's the $0F value.
On the SX52 M is supposed to equal $1F to write changes to the direction registers,
but if bit 5 = 0, and you move literal to M, the direction registers will accept changes.
Whereas if you move m,w with $0f in w it will not work.
This is subtle. The gotcha here is that if you port code from an SX28 to a SX52, you may
have a very difficult bug to find (this is how I discovered it)
I debugged this several times. You can write direction registers with m = $0f, and you're not
supposed to be able to do so!
-Dan
P.S. Why does this freaking window double space at random!·This double spaced thing is really starting to P!$$ me off!
OK, you seem to have an odd situation here. I will repeat your tests tomorrow, and see if I can make any sense out of it.
Thanks for the heads up.
Cheers,
Peter (pjv)
Well I did some in-depth testing, and I certainly get different results from what you are reporting.
On an SX52:
with the M register = $0F, the mov !port,w instruction can only READ the direction registers into w
with the M register = $1F, the mov !port,w instruction can only WRITE the direction registers from w
These two statements hold, regardless of the method by which the m register was set; that is either by moving a literal to m, OR by moving a literal to w and that to m.
By moving w to m, of course all 5 bits can be effected, whereas by moving an immeditate literal to m, only the lower four bits are effected, and the fifth bit IS UNCHANGED, hence holding its previous value.
So it may APPEAR that directly writing the literal $0F to w gains access to writing the direction registers; it would only be the case if the 5th bit had already been previously set.
Dan, in no way can I get denial of access to the direction registers as you describe, when I move #$1F to w, and then w to m.
I wonder if somehow the sequence of logic in your debug session showed the wrong indication of the 5th bit...... how, I have no idea.
Please repeat your tests and let us know your findings; this just is not making any sense.
Also please remember that starting the software from RESET, does NOT CHANGE the 5th bit in the m register, whereas I believe that power-up will set it.
Cheers,
Peter (pjv)
the results I had the other day. I was very carefully watching the M register the other day too.·I wonder if I had a hickup in the SX-Key sofware (I've seen registers get stuck on screen, where a reboot of the software was required!).
The other (more likely)·possibility is that I'm nuts, and need to be hauled away!
Oh Well, after this exercise, I understand the SX52 a lot·better!
-Dan
That's probably the only good thing in having to chase problems (or as in your case chasing a ghost), you do end up learning a whole bunch more, and enventually one's insight gets greatly improved.
Glad it's resolved for you.
Cheers,
Peter (pjv)