Warning messages concerning "cutting constant" in RS08 code

[jackabo]

In my code for my MC9RS08KA2 A/D conversion I am getting multiple warnings about "cutting constant: Value X is not in range [0..255]." One of these examples is when I use the "mov" instruction in this line of code:

mov #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE), SOPT

The warning is "Warning : A1415: Cutting constant: Value 513 ($0201) is not in range [0..255]."

The address location of SOPT is 0201 and I believe that the warning is because the value exceeds what is in the range of 1 byte. The fact that I am accessing an address should make this not matter though. Does anyone know how to deal with this issue? Will this most likely cause my code to not work as I want it to? I would think it would if it doesn't write into the correct memory location since it is cutting off the most significant part of the number. Is there a way to fix this warning? Thanks.

Jackabo

Message Edited by J2MEJediMaster on 2007-04-12 10:52 AM

[jackabo]

Bigmac,

  So you are saying that since i have mov #HREG, PAGESEL (where HREG is equal to $08) then all of the instructions after this do not require what was said in earlier posts. this being code such as:

MOV #((SOPT) >> 6 ) & $FF,PAGESEL
MOV #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE), ((SOPT) & $3F) + $C0)

Am I understanding that you are saying that all i need to write now is

MOV #HREG, PAGESEL

MOV #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE), MAP_ADDR_6(SOPT)

You've been a great help and I don't want you to waste any more of your time so you can just give me a quick answer. Thanks a lot.

    Jackabo

[peg]

Hi jackabo,

It seems to me that the lines of code that have given you trouble have been "lifted" from AN3266.

It also seems to me that the code written in AN3266 is meant to be used with a custom .inc file rather than the one that comes with Codewarrior. The .inc file that comes with Codewarrior does not equate HREG and equates the register names to their absolute addresses.

It seems that the .inc file that the AN3266 code would define HREG to $08 (the POR value of PAGESEL) and the start of the high registers.

The equates for the high register would then be defined as (offsets from HREG) + $C0.

This would then allow the code presented in AN3266 to assemble.

There are other registers that require EQU adaption to window offset before this can happen!

You, it seems are having trouble as you are using the code from AN3266 but the .inc file that comes with Codewarrior 5.1.

So then it remains up to you as to whether you prefer:

MOV #HREG, PAGESEL

MOV #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE),SOPT

with a equate of $08 to HREG and $C1 to SOPT

_OR_

MOV #HIGH_6_13(SOPT),PAGESEL
MOV #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE), MAP_ADDR_6(SOPT)

_OR_

MOV #((SOPT) >> 6 ) & $FF,PAGESEL
MOV #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE), (((SOPT) & $3F) + $C0)

all produce the same result and all look equally ugly

Message Edited by peg on 2007-03-2107:13 PM

Message Edited by peg on 2007-03-2107:14 PM

Message Edited by peg on 2007-03-2107:15 PM

Don't worry I'll get it right eventually.......

Message Edited by peg on 2007-03-2107:17 PM

Getting close now.....

Message Edited by peg on 2007-03-2109:16 PM

Surely this is it now...

Message Edited by peg on 2007-03-2109:43 PM

[peg]

Hi Alban,

Perhaps you could ask the author of AN3266 to make a comment here.

This code in this document is more like "Getting Confused with RS08" rather than getting started.

[Alban]

Hey Peg, and all readers,

Your 60 edits really made me laugh !!!

I'll ask him. The main thing was that the Application Note was done and dusted before the MCU and tools  were actually finished.

Not really a reason to get it wrong, I know.

Cheers,

Alban.

[peg]

Hi Alban,

I had figured it was probably to do with the tools not being ready. I don't believe it is wrong, just confusing.

For the benefit of new users (where the document is aimed) I think this should be cleared up. Perhaps just publishing the code along with the .inc or EQU's is enough.

[Alban]

Dear Peg,

From what I understood, the Author wanted to release a corrected version.

I don't know if it has been delayed at his stage, the reviewing process or technical publications.

I'll follow this up to resolution.

Alban - At Your Service !

[jackabo]

Bigmac,

   In the AN3266 Appendix A code for A/D conversion they have the line of code as follows:

"bset SRTISC_RTIACK, SRTISC"

This was giving me a warning because SRTISC is out of range of one byte. However, you said that "The BSET instruction is applicable to page 0 addresses only." Does this mean that the code is wrong? Am I misunderstanding something? Thanks again for your help.

Jackabo

[bigmac]

Hello Jackabo,

I notice that the following line of code to setup the PAGESEL register does precede the line in question -

 mov #HREG,PAGESEL

Therefore, it would seem that the various high page registers, including SRTISC and SOPT, are actually defined by their relative positions within the paging window rather than their absolute addresses.  Obviously, this will depend on the contents of the include file MC8RS08KA2.inc, that the application note references, and may differ from the CW offering, as you have found.

If this is true, the following modification would be needed to handle an absolute address for SRTISC -

 bset SRTISC_RTIACK,MAP_ADDR_6(SRTISC)

The same issue would appear to affect other lines of code within the application note (including the ones that manipulate SOPT), so you would need to review and correct, where necessary.

Regards,

Mac

[jackabo]

Hey guys,

  Thanks for all the replies and all the help. One final question on the subject. If I were to have an instruction such as "bset SOPT" giving me a warning would i now have these lines of code to fix it?

MOV #((SOPT) >> 6 ) & $FF,PAGESEL

BSET ((SOPT) & $3F) + $C0)

Jackabo

[bigmac]

Hello Jackabo,

---

jackabo wrote:

... One final question on the subject. If I were to have an instruction such as "bset SOPT" giving me a warning would i now have these lines of code to fix it?

MOV #((SOPT) >> 6 ) & $FF,PAGESEL

BSET ((SOPT) & $3F) + $C0)

Jackabo

The BSET instruction is applicable to page 0 addresses only, even for the HCS08 devices.  However, the instruction, as you have written it, does not include the bit number to be set - this would also cause an error.  Assuming bit 0 is to be set, the corrected code might be as follows -

 MOV  #(SOPT >> 6),PAGESEL

 BSET 0,((SOPT & $3F) + $C0)

Regards,

Mac

[CompilerGuru]

There are special operators to extract the bits of an address which have to be written to PAGESEL, and to compute the address in the range 0xC0..0xFF which has to be used for the access.

Here's an example:

 MOV #HIGH_6_13(SOPT),PAGESEL
 MOV #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE), MAP_ADDR_6(SOPT)

Basically the bits 6..14 of SOPT have to be written to PAGESEL first, and then for the access the bits 0..5 have to be used for the access with an additional offset of $C0.

if SOPT is absolute (it probably is) you can get the same with this code:

 MOV #((SOPT) >> 6 ) & $FF,PAGESEL
 MOV #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE), ((SOPT) & $3F) + $C0)

The advantage of the HIGH_6_13,MAP_ADDR_6 is that they work for both relocatable and absolute labels.

Daniel

PS: I did not try the examples, could be they contain some typos.

[bigmac]

Hello Jackabo,

The following macro alternative would also seem to work for paged locations -

movI: macro ; value,location
      mov   #(\2 >> 6),PAGESEL
     mov   #\1,((\2 & $3F) + $C0)
     endm

with the following usage -

      movI  (mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE),SOPT

Regards,

Mac

[bigmac]

Hello,

I have had some additional thoughts on assembly coding of the RS08.

I have noticed (from AN3266 and RS08QRUG) that the assembler provides some "pseudo addressing modes" so that code written for the RS08 may have a similar form to the other HC(S)08 devices.

I am curious why this does not seem to apply to the emulation of extended address instructions.  HC(S)08 assembler can automatically choose between direct and extended address modes, for source and destination of data.  So in the case of the RS08 devices, the emulation of this might be a reasonable expectation, to simplify the coding process.  I am thinking of instructions such as LDA, STA, LDX, STX, ADD, SUB, etc.

For example, a simple instruction such as LDA SOPT would require that it be known the label was at an extended address, and I assume would involve entry of the following rather unwieldy emulation code -

 MOV #HIGH_6_13(SOPT),PAGESEL
 LDA MAP_ADDR_6(SOPT)

Alternatively, a macro could be used for such cases.  However, I think it would make life much easier for the programmer had a pseudo extended addressing mode been available, that was automatically applied, as necessary.

Of course, this does not apply to the MOV instruction, for which extended addressing does not apply, for the other '08 MCUs.

Regards,

Mac

[jackabo]

bigmac,

    Thanks for the quick reply. I believe that I am using the paging window in my code. Here is the code that I have used for the paging window with the mov instruction:

HREG equ $08

...

...

...

mov #HREG, PAGESEL

mov #(mSOPT_COPE | mSOPT_COPT | mSOPT_STOPE), SOPT

Is this correct? Am I doing something wrong that is causing the warnings? Thanks again.

Jackabo

[peg]

Hi jackabo,

The move instruction, even on a full S08 can only move an 8-bit value to a location addressable with 8-bits.

SOPT is as you have said $0201 this is %1000000001. This is 10 bits. This is the problem alluded to by the Codewarrior error message.

I am not familiar enough with the RS08 but this is why these high registers are usually initialised by a LDA, STA pair in S08 code. (The old way, pre-S08)

[bigmac]

Hello Jackabo,

The problem seems to be that the mov instruction cannot be use to directly load an immediate value into a register outside of an 8-bit addressing range.  The SOPT register is in this category.  With the shortage of instructions that allow the handling of 14-bit values, I suspect you would need to address this register using the paging window.

Regards,

Mac

Message Edited by bigmac on 2007-03-1904:29 PM