MCC检查OSCCon修正的结果观察到意想不到的结果

还要注意的是，我对PIC24体系结构很陌生，不熟悉工作寄存器W0、W1、W2等。这可能有助于我的困难，但我不确定如何理解。



      以下为原文

    also to note, I am new to the PIC24 architecture and unfamiliar with the working registers, W0, W1, W2 etc. This may contribute to my difficulties here, but am unsure how to understand.

OSCCONL是OSCCon或OSCCCON+0SCCONH的低字节，OSCCon或OSCCCON+10X200的高字节是16位数字。（0x0200和0x00 FF）是零。



      以下为原文

    OSCCONL is the low byte of OSCCON or OSCCON+0
OSCCONH is the high byte of OSCCON or OSCCON+1
 
0x200 is a 16bit number.
(0x0200 & 0x00FF)) is zero.
 
You are writing zero to OSCCONL.

000000 1000000000 0x0200 000 000 11111111 0x00 FF真值表0 0 00 1 01 0 01 1 1



      以下为原文

    0000,0010,0000,0000    0x0200
0000,0000,1111,1111    0x00FF
 
AND truth table
0 0   0
0 1   0
1 0   0
1 1   1
 

哈哈，Gort，我知道这个…这就是为什么我张贴应该澄清了！“程序”部分列出了我设置的地方：内部振荡器=主振荡解释这意味着（与值‘0x0200’）OSCCON.NOSC＝0B010（主振荡器（XT，HS，EC）），但我SEECLR W2…MOV.B W2，[W3]这对你有意义吗？我完全糊涂了！



      以下为原文

    lol Gort, I know this... that was why I posted should have clarified! ;)
 
Note the 'Procedure' section listing where I set:

• Internal Oscillator = Primary Oscillator
  

I interpret this to mean (with the value '0x0200')

• OSCCON.NOSC = 0b010 (Primary Oscillator (XT, HS, EC))
  

But then I see

• CLR W2
  
• ...
  
• MOV.B W2, [W3]
  

Does this make sense to you? Totally confusing to me!
 
 

这是一个允许OSCCON写入的汇编器序列。因为文字值是零，所以使用了清晰的W2（CLR W2）。46美元和57美元是解锁序列值，必须立即跟随其他。0x100是OSCCon。MOV.OSCOCN，W3MOV.B编写[ OSCCon + 0 ]间接寻址。它使用间接寻址，否则它将不起作用。



      以下为原文

    That is an assembler sequence to allow OSCCON to be written to.
 
Because the literal value was zero, clear W2 (CLR W2) was used.
 
$46 and $57 are the unlock sequence values that must immediately follow each other.
 
0x100 is OSCCON.  mov #OSCCON,w3
mov.b writes [OSCCON+0]  indirect addressing.
 
It is using indirect addressing otherwise it will not work.
 
I've got this:
#ifdef EXTERNAL_CRYSTAL
    __builtin_write_OSCCONH(0x03); //Primary Oscillator (POSC) with PLL
#else
    __builtin_write_OSCCONH(0x01);  //Fast RC Oscillator with PLL
#endif
    __builtin_write_OSCCONL(OSCCON|0x01); //OSCCON|LPOSCEN
#ifdef EXTERNAL_CRYSTAL
    while (OSCCONbits.COSC!=0b011); //wait COSC = NOSC
#else
    while (OSCCONbits.COSC!=0b001); //wait COSC = NOSC
#endif
    while(OSCCONbits.LOCK!=1); //PLL lock
 
 

我曾经使用过，但是现在我使用这个：int StfOSFC（uint m，uint N1，uint n2，int调，bOOL外部）；Err＝StSoFc（187，8，2，-19.0）；如下所示：



      以下为原文

    I used to use that but now I use this:
 
int setfosc(uint M, uint N1, uint N2, int Tune, bool External);


err=setfosc(187,8,2,-19,0);
 
Goes like this:
.include "xc.inc"
.include "OSCLib2.inc"
.globl _setfosc
.section osccode,code
;----------------------------------------------------
.equ arg_M,        w0
.equ arg_N1,        w1
.equ arg_N2,        w2
.equ arg_Tune,        w3
.equ arg_External,  w4
.equ tmp,        w5
.equ divider,        w6
.equ new,        w7
;rtn error,        w0

_setfosc:   ;int setfosc(uint M, uint N1, uint N2, int Tune, bool External);
    ;M [2..513] ?
    cp        arg_M,#2
    bra        ltu,error_M
    mov        #513,tmp
    cp        arg_M,tmp
    bra        gtu,error_M
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;N1 [2..33] ?
    cp        arg_N1,#2
    bra        ltu,error_N1
    mov        #33,tmp
    cp        arg_N1,tmp
    bra        gtu,error_N1
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;N2 [2,4,8] ?
    cp        arg_N2,#2
    bra        z,$+10
    cp        arg_N2,#4
    bra        z,$+6
    cp        arg_N2,#8
    bra        nz,error_N2
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;attempt tune external xtal?
    btss    arg_External,#0
    bra        $+6
    cp0        arg_Tune
    bra        nz,error_exttune
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;tune [-32..+31] ?
    cp        arg_Tune,#31
    bra        gt,error_tune
    mov        #-32,tmp
    cp        arg_Tune,tmp
    bra        lt,error_tune
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;set M
    dec2    arg_M,arg_M
    mov        arg_M,PLLFBD
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;set N1
    dec2    arg_N1,divider    ;PLLPRE
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;set N2
    lsr        arg_N2,arg_N2
    dec        arg_N2,arg_N2
    sl        arg_N2,#6,arg_N2    ;PLLPOST
    ior        divider,arg_N2,divider
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;DOZE=FCY/8, FRCDIV=FRC/1, DOZEN=0
    mov        #0b11<<12,tmp
    ior        divider,tmp,divider
    mov        divider,CLKDIV
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;set tune
    and        #0b111111,arg_Tune
    mov        arg_Tune,OSCTUN
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;xtal internal/external
    mov.b   #0b001,new
    btsc    arg_External,#0
    mov.b   #0b011,new
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;unlock osccon high byte
    mov     #OSCCON+1,tmp
    mov.b   #0x78,w0
    mov.b   #0x9a,w1
    mov.b   w0,[tmp]
    mov.b   w1,[tmp]
    mov.b   new,[tmp]        ;new oscilator
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;unlock osccon low byte
    mov     #OSCCON,tmp
    mov.b   #0x46,w0
    mov.b   #0x57,w1
    mov.b   w0,[tmp]
    mov.b   w1,[tmp]
    bset    OSCCON,#OSWEN   ;request NOSC
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;current osc
wait_cosc:
    mov.b   OSCCON+1,wreg
    lsr        w0,#4,w0
    cp.b    w0,new
    bra        nz,wait_cosc
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ;lock
wait_lock:
    btss    OSCCON,#LOCK
    bra        wait_lock
    retlw   #FERROR_OK,w0
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error_M:
    retlw   #FERROR_M,w0
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error_N1:
    retlw   #FERROR_N1,w0
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error_N2:
    retlw   #FERROR_N2,w0
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error_exttune:
    retlw   #FERROR_EXTTUNE,w0
    ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error_tune:
    retlw   #FERROR_TUNE,w0
;----------------------------------------------------
.end
 

我还有两个函数。未签名的long GETBestCufReq（未签名的长XTAL，未签名的long -FoSC，未签名的长余量，int标志）；未签名的long GETCPUFRQ（未签名的长XTAL，BOOL外部）；我不使用MCC。



      以下为原文

    I also have two functions.
unsigned long getbestcpufreq(unsigned long XTAL, unsigned long _FOSC, unsigned long Margin, int Flag);
unsigned long getcpufreq(unsigned long XTAL, bool External);
 
I don't use MCC.

如果你确信你没有把错误的值（例如0x0200）放入MCC输入，你所显示的代码实际上是MCC生成的，那么我建议你用Microchip来买一张票。我从来没有使用过MCC，但它也是一个相当新的产品，几乎肯定是HAV。电子错误。（我说过，我早就想到这样的事情早就定了）苏珊



      以下为原文

    OP - if you are certain that you have not put the wrong value (e.g. the 0x0200) into the MCC input and the code you have shown is actually MCC generated, then I would suggest that you raise a ticket with Microchip.
I've never used MCC but it is also a fairly new product and will almost certainly have bugs. (Having said that I would have thought that something like this would have been fixed long ago).
Susan

嗯，在做了几年的蛮力（裸露金属）之后，我开始使用MCC进行评估和比较的目的（PIC24FJ1024GB610，PIC24FJ128GB204，和其他）。我在MCC SimultAudialIZEIZE（）函数中看到了类似的东西，并且我认为论点的性质和伴随的评论是愚蠢的，至少可以说。如果我稍微有点挑剔的话，我会说它完全是误导性的（但不是真正的）错误。下一个底线是：分配在OSCCONL的R/W位中存储零点，不影响OSCCONH。这是完全有效的，尽管在争论和误导性评论中有误导性的表达。如果你，不知何故，期望它给OsCONH分配一些东西，那么你必须调整你的期望。例如，如果将MCC时钟设置为HS，MCC生成的配置PrimaMax就要注意这一点，并且不需要分配给OSCCONH使其工作，因为OSCCONH中的NOSC位的初始值将由实用型来确定。重置）OSCCONL的R/W位的值将全部为零，我不知道为什么MCC决定写这个，而不用麻烦写OSCCONH。初始化程序显然是在系统上电或其他重置之后工作的。如果初始化后，您的代码更改了OSCCONL和OSCCONH，那么，稍后，调用SurristAudioLimalIZE（），它将将OSCCONL更改为默认值，而不是OSCCONH。我看不出这有什么价值。对于O.P.如果您修改了OSCCONH和/或OSCCONL，在MCC之外，结果是非功能的，请与我们共享您的实际初始化代码（和配置参数）。同时，告诉我们你正在使用的PIC，并确切地解释你想要做什么。真正的底线是：MCC可能对很多事情有用，但它并不总是有用的，只是为那些正在学习C或正在学习特定图片的人写可读代码的一个例子。问候，戴夫



      以下为原文

    Well, after a few years of doing things brute-force (bare metal), I have started using MCC for evaluation and comparison purposes  (PIC24FJ1024GB610, PIC24FJ128GB204, and others).  I see stuff like this in all of the MCC OSCILLATOR_Initialize() functions and I find the nature of the argument and the accompanying comment to be silly, to say the least.  If I were being a little more critical, I would say that it's downright misleading (but not a "real" bug).
 
Next-To-Bottom line:
The assignment stores zeros in the r/w bits of OSCCONL and does not affect OSCCONH.  This is perfectly valid, in spite of the misleading expression in the argument and the misleading comment.
 
If you, somehow, expect it to assign something to OSCCONH, then you must adjust your expectations.  If, for example, you set MCC clock to HS, the MCC-generated configuration pragmas take care of this, and no assignment to OSCCONH is required to make it work, since the initial values of the NOSC bits in OSCCONH will be determined by the pragmas.
 
As a side note: Since the default (power-up or other reset) values of the r/w bits of OSCCONL will all be zeros, I don't know why MCC decided to write this, and not bother with writing OSCCONH.  The initialization routine is obviously designed to work after a system power-up or other reset.  If, after initialization, your code changes OSCCONL and OSCCONH and then, some time later, calls OSCILLATOR_Initialize() again, it will change OSCCONL to default values, but not OSCCONH.  I can see no value in that.
 
To the O.P.
If you have modified OSCCONH and/or OSCCONL, outside of MCC and the result is non-functional, please share your actual initialization code (and the configuration parameters) with us.  Also, tell us what PIC you are using and explain exactly what you are trying to do.  Maybe someone can help get to the bottom of it.
 
The Real Bottom Line:
MCC may be useful for many things, but it's not always useful as an example of writing readable code for people who are just learning C or are just learning the ins and outs of a particular PIC.
 
Regards,

Dave

“我觉得争论的本质和附带的评论是愚蠢的”他还是我？



      以下为原文

    "I find the nature of the argument and the accompanying comment to be silly"
 
Him or me?

嗯…在函数调用的参数中MCC生成的表达式是愚蠢的。为什么会有人写（0x0200和0x00 FF）来表示零？误导的MCC产生的评论伴随着这件事开始，是否有其他的事情是愚蠢的，好吧，我不是有意暗示任何事情。问候，戴夫。



      以下为原文

   
Ummm... The MCC-generated expression in the argument of the function invocation is silly.  Why the heck would anyone write (0x0200 & 0x00FF) to mean zero?
__builtin_write_OSCCONL((uint8_t) (0x0200 & 0x00FF))
 
The misleading MCC-generated comment that accompanies this begins with
// CF no clock failure; NOSC...
 
Whether any other things are silly, well, I didn't mean to imply anything.
 
Regards,
 
Dave

我也不知道为什么，（0x0200和0x00 FF），考虑到OSCCon低点和OSCCon高需要单独解锁是没有任何意义的。稍后我会查一下这些值。我以为你是说我的代码是愚蠢的。悲伤：



      以下为原文

    I don't why either, (0x0200 & 0x00FF), it doesn't make any sense considering that OSCCON low and OSCCON high need to be unlocked separately.
 
I'll look up the values later.
 
I thought you were saying that my code was silly. sad:

一点也不。很抱歉，我没有明确表达我的感受（关于MCC代码的可读性）。请注意，戴夫。



      以下为原文

   


Not at all.  I'm sorry I didn't express my feelings (about the readability of MCC's code) very clearly.
 
Regards,
 
Dave

天哪，谢谢你，Gort！我产生以下例程和验证，见附件，如果有兴趣：



      以下为原文

    My goodness thank you Gort!
 
I generated the following routine & validated, see attached if interested:
 
void OSCCON_Write(uint16_t val) {
 //Gen values
 uint8_t val_low = (uint8_t)(val);
 uint8_t val_high = (uint8_t)(val>>8);

 //Write values
    __builtin_write_OSCCONL(val_low);
    __builtin_write_OSCCONH(val_high);

 return;
}
   Attachment(s)

Clocks.zip (0.97 KB) - downloaded 29 times

灿烂的。



      以下为原文

    Brilliant.