PIC32MZ出现故障左移

你到底得到了什么？你正在使用的PIC的零件号是多少？您使用的是什么版本的MPLABX？



      以下为原文

    What are you actually getting?
What is the part number of the pic you are using? What version of MPLabX are you using?

它是PIC32 MZ2048 ECM100-I/PF和MPLAB X，它是V3-45，和声1.0.9。



      以下为原文

    it's  a pic32mz2048ecm100-I/PF  and the MPLAB X it's the v3-45 with Harmony 1.0.9
 

你使用的“字节”的确切定义是什么？我怀疑它被当作一个有符号的值，所以0x85变成0xFF85。



      以下为原文

    What is the exact definition for "BYTE" that you are using?
I suspect it is being treated as a signed value, so 0x85 becomes 0xFF85.

亲爱的NKurzman，在阅读您的回复后，我在最新版本中更新了MPLAB X，但没有改变。我已经做了更多的测试，我可以说8位的移位LASFT不能正常工作……我发现一个组合总是错误的结果。WYCRC＝LoWyCRC+HuiHyrCRC & lt；8；如果LYCRC具有第七位（开始按位计数0）高，并且HyLyCRC具有BIT0HI，则总是错误的。GH.LUWYCRC＝1xxx XXXX二进制标记NoTuxHycCRX= xxxxxxx1 ByyRyNo.例如，使用相同的公式，下面的组合结果是可以的：LoWO-CRC= 0x11 HygO-CRC= 0xAAOWOWCRC＝0x11 HygOCRC＝0xDbOWOWCRC＝0x75 HuiHOCRC＝0xDB带总是坏结果：LoWORCRC＝0x85HuiKCRC＝0xDB -gt；给出-Gt；WYCRC＝0xDA85？？？？？？？LoWYCRC＝0x90 HuiO-CRC= 0x01--gt；给出-Gt；WYCRC＝0x90090！？！这是一个ALU问题的编译器问题？我很担心，因为我不自信找到一个解决方案，并给我的客户提供一个可靠的产品。



      以下为原文

    Dear NKurzman , after reading your reply I have update the MPLAB x at the latest release, but nothing change. I have done more test and I can say that the shift lesft of 8bits doesn't work properly ...I have found one combination that give always a wrong result.
w_CRC=low_CRC+ high_CRC<<8 ; it's always wrong if l_CRC have the 7th bit (starting to count by bit 0) high, and the high_CRC have the bit0 high.
low_CRC = 1xxx xxxx binary notation
high_CRC= xxxx xxx1 bynary notation
for example using the same formula the results are ok with the follow combinations:
low_CRC  = 0x11       high_CRC  = 0xAA
low_CRC  = 0x11       high_CRC  = 0xDB
low_CRC  = 0x75       high_CRC  = 0xDB
 
and always bad results with :
low_CRC  = 0x85       high_CRC  = 0xDB              -> give -> w_CRC = 0xDA85 ?!?!?
low_CRC  = 0x90       high_CRC  = 0x01               -> give -> w_CRC = 0x0090 !?!? 
 
it's a compiler problem o an ALU problem?
I'm very worried about it because I dont feel confident to find a solution and give a reliable product to my customer

亲爱的QHB，很抱歉没有明确地说，在我的项目字节中，它被声明为：



      以下为原文

    Dear qhb,
sorry for do not have clearly said that particular, in my project BYTE it's declared as:
 
typedef unsigned char
 

亲爱的QHB，很抱歉没有明确地说，在我的项目字节中，它被声明为：



      以下为原文

    Dear qhb,
sorry for do not have clearly said that particular, in my project BYTE it's declared as:
 
typedef unsigned char
 

亲爱的QHB，很抱歉没有明确地说，在我的项目字节中，它被声明为：



      以下为原文

    Dear qhb,
sorry for do not have clearly said that particular, in my project BYTE it's declared as:
 
typedef unsigned char
 

可以肯定的是，试着在测试中用“unChar Car”替换“字节”。



      以下为原文

    Just to be sure, try replacing "BYTE" with "unsigned char" in your tests.
 

嗨，一些C数据类型取决于你使用的MCU体系结构…当你从8移动到16或者是32时，这是特别棘手的。为了避免这些问题，建议使用在类型无关的Head Dyfs.h中定义的类型。如果我的内存是正确的，那么XC编译器就是这么做的。



      以下为原文

    Hi,
Some C data types depend upon the MCU architecture you use...it is especially tricky when you move from 8 to 16 or to 32.
To avoid these kind of issues it is recommend to use the types defined in the header typedefs.h which is architecture independant. If my memory is correct this is what XC compilers do.
I suggest you use the types from typedefs.h to avoid issues
Regards
 

使用“不”+…看起来从下字节的MSB被汇总为高阶字节。



      以下为原文

    Use | not + ...
It would look like MSB from lower byte is summed to the high-order byte

我想的是一样的，但是加上应该工作。但是尝试一下：LoWYCRC（HylyCRC & lt；lt；8）；



      以下为原文

    I was thinking the same, but plus should work.
But try:
low_CRC | (high_CRC<<8);

我想我可以得到它。它是一个自动的整数提升。HyixCRC& lt；lt；8不能装入一个未签名的字符，因此它被自动提升到一个已签名的int，这样它就可以保存结果。TrYWOLL CRCR*（（无符号INT）HygYCRC & LT；lt；8）（编辑：固定缺失括号）。



      以下为原文

    I think I may have it. It's automatic integer promotion.
high_CRC<<8 cannot fit into an unsigned char, so it is being automatically promoted to a signed int so it can hold the result.
Try
low_CRC | ((unsigned int)high_CRC << 8)
 
(edit: fixed missing parenthesis)
 
 

是的，Qhb，我总是习惯于“我”。我认为这是“Orn”，而且总是，而不是一个和。你是从它的子部分创建一个词，而不是对它进行总结。



      以下为原文

    yeah, Qhb
I was always used to "|" - in my opinion this is "ORing" and always was, and not an sum...
You are creating a word from its subparts, not summing them.

在“& lt & lt”操作之前，应该将BothOrthand推广到已签名的int（32比特长）。但是如果“Hyu-CRC”是未签名的，那么促销应该是零。只有在签名时，它才会被扩展。



      以下为原文

   


Both operands should be promoted to signed int (32-bit long) before the "<<" operation. But if "high_CRC" is unsigned, the promotion should zero-extend it. It'll be sign-extended only if it is signed.

我用模拟器做了一些测试（XC32 V1.42，MPLAB X V3.15），但是无论使用还是（或）+（+），我总是得到相同的结果0xBD85。



      以下为原文

    I did some tests (XC32 v1.42, MPLAB X v3.15) with the simulator, but I always got the same result 0xDB85 no matter using OR(|) or PLUS(+). 
typedef unsigned char BYTE;
void test()
{
   unsigned short int w_CRC;
 
   BYTE low_CRC=0x85;  // test case 1
   BYTE high_CRC=0xDB;
 
   //unsigned char low_CRC=0x85;  // test case 2
   //unsigned char high_CRC=0xDB; 

   w_CRC= low_CRC + (high_CRC<<8);
   w_CRC= low_CRC | (high_CRC<<8);
   w_CRC= low_CRC + (high_CRC<<8);
}

有人发布反汇编代码吗？



      以下为原文

    Could anyone post disassembly code?

如果字节是无符号类型，这是唯一正确的结果。唯一合理的解释是字节是QHB前面提出的一种符号类型。如果字节被签名，0xDA85是预期的结果，因为那时您有0xFF85+0xDb00＝0x1DA85，然后在转换为无符号短时被截断。



      以下为原文

   
 
Which is the only correct result if BYTE is an unsigned type.  The only plausible explanation is that BYTE is a signed type as suggested earlier by qhb.  0xDA85 is the expected result if BYTE is signed, because you then have 0xFF85 + 0xDB00 = 0x1DA85, which is then truncated when converting to unsigned short.

小心那个测试代码。编译器不能对所有代码进行编码。使WYCRC挥发。并在测试之间设置为零。



      以下为原文

    Be careful with that test code.
The complier may not code it all.
Make w_CRC volatile.
And set it to zero between tests.

我在没有使用优化的情况下生成了加号（+）的程序集。这里是Test.cand的汇编基本测试1（）和Test2（）是相同的…++FYI，我尝试了NKurzman的建议，“ValueNosialNoint短WINCRC；”，程序集输出是相同的。



      以下为原文

    I generated the assembly for the PLUS(+) case without using optimization.  Here is the test.c
typedef unsigned char BYTE;

unsigned short int w_CRC;

void test1()
{
    
    BYTE low_CRC=0x85;
    BYTE high_CRC=0xDB;
    
    w_CRC= low_CRC + (high_CRC<<8);

    return;
}


void test2()
{
    
    unsigned char low_CRC=0x85;
    unsigned char high_CRC=0xDB;
       
    w_CRC= low_CRC + (high_CRC<<8);
        
    return;
}

 
and the assembly
 .file 1 "test.c"
 .section .mdebug.abi32
 .previous
 .gnu_attribute 4, 3

 .comm w_CRC,2,2
 .section .text,code
 .align 2
 .globl test1
 .set nomips16
 .set nomicromips
 .ent test1
 .type test1, @function
test1:
 .frame $fp,16,$31 # vars= 8, regs= 1/0, args= 0, gp= 0
 .mask 0x40000000,-4
 .fmask 0x00000000,0
 .set noreorder
 .set nomacro
# End mchp_output_function_prologue
 addiu $sp,$sp,-16
 sw $fp,12($sp)
 move $fp,$sp
 li $2,-123 # 0xffffffffffffff85
 *** $2,0($fp)
 li $2,-37 # 0xffffffffffffffdb
 *** $2,1($fp)
 lbu $2,0($fp)
 andi $3,$2,0xffff
 lbu $2,1($fp)
 andi $2,$2,0xffff
 sll $2,$2,8
 andi $2,$2,0xffff
 addu $2,$3,$2
 andi $2,$2,0xffff
 sh $2,%gp_rel(w_CRC)($28)
 nop
 move $sp,$fp
 lw $fp,12($sp)
 addiu $sp,$sp,16
 j $31
 nop

 .set macro
 .set reorder
# Begin mchp_output_function_epilogue
# End mchp_output_function_epilogue
 .end test1
 .size test1, .-test1
 .align 2
 .globl test2
 .set nomips16
 .set nomicromips
 .ent test2
 .type test2, @function
test2:
 .frame $fp,16,$31 # vars= 8, regs= 1/0, args= 0, gp= 0
 .mask 0x40000000,-4
 .fmask 0x00000000,0
 .set noreorder
 .set nomacro
# End mchp_output_function_prologue
 addiu $sp,$sp,-16
 sw $fp,12($sp)
 move $fp,$sp
 li $2,-123 # 0xffffffffffffff85
 *** $2,0($fp)
 li $2,-37 # 0xffffffffffffffdb
 *** $2,1($fp)
 lbu $2,0($fp)
 andi $3,$2,0xffff
 lbu $2,1($fp)  # <--------- unsigned load byte
 andi $2,$2,0xffff  # <-------- logical and immediate
 sll $2,$2,8   # <---- shift left logical
 andi $2,$2,0xffff
 addu $2,$3,$2   # <--- unsigned interger add
 andi $2,$2,0xffff
 sh $2,%gp_rel(w_CRC)($28)
 nop
 move $sp,$fp
 lw $fp,12($sp)
 addiu $sp,$sp,16
 j $31
 nop

 .set macro
 .set reorder
# Begin mchp_output_function_epilogue
# End mchp_output_function_epilogue
 .end test2
 .size test2, .-test2
 .ident "GCC: (Microchip Technology) 4.8.3 MPLAB XC32 Compiler v1.42"
# Begin MCHP vector dispatch table
# End MCHP vector dispatch table
# Microchip Technology PIC32 MCU configuration words
 
Basically test1() and test2() are the same...
 
++ FYI, I tried NKurzman's recommendation with "volatile unsigned short int w_CRC;", the assembly output is the same.