完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
德赢Vwin官网
论坛|
我用MCC检查OSCCon修正的结果，观察到意外的结果-总结1。尝试修改振荡器配置会产生意想不到的、非工作的结果。2。（0x0200和0x00 FF）不是一个有效的输入吗？DISSCOM产生“0”的值，这是意料之中的问题。这是预期的吗？如何使用MCC成功配置振荡器？过程开放MPLAB（V4.15）文件-GT；独立项目PIC24FJ256GA702，ICD3，XC16（V1.33）工具-＆GT；嵌入式-GT；MPLAB代码配置器V3（V3.55.1）系统模块-GT；内部振荡器-GT；主振荡器资源管理-gt；生成结果（MCC.C）空隙振荡器初始化（VO）ID）{…Y.BuuthtiNoWrdEngOSCONCOL（（UIT88T）（0x0200和0x00 FF））；拆卸！虚空振荡器初始化（无效）！{0x55 8c:LNK×0x0！/CF没有时钟故障；EXOCONCOLL（（UTI88T）（0x0200和0x00 FF））；0x568e:CLV WX0x5690:W00x5692: MOVα0x57，W1 0x594: MOVα0x100，W3 0x596:MOV.B W0，[W3] 0x598:MOV.B W1，[W3] 0x59a:MOV.BW2，[W3]希望我在这里漏掉一些或误读的东西，让我知道哟！你的想法或解决方案！
以上来自于百度翻译 以下为原文 I was inspecting the results of OSCCON modification using MCC and observed unexpected results - Summary 1. Attempts to modify the oscillator configuration generate unexpected, non-working results. 2. (0x0200 & 0x00FF) is not a valid input? Dissassembly generates value of '0' for this as expected. Question
Open MPLAB (v4.15) File->New Project->Standalone PIC24FJ256GA702, ICD3, XC16 (v1.33) Tools->Embedded->MPLAB Code Configurator v3 (v3.55.1) System Module->Internal Oscillator->Primary Oscillator Resource Management->Generate Result (mcc.c) void OSCILLATOR_Initialize(void) { ... __builtin_write_OSCCONL((uint8_t) (0x0200 & 0x00FF)); ... } Disassembly !void OSCILLATOR_Initialize( void ) !{ 0x558C: LNK #0x0 ! // CF no clock failure; NOSC... ! __builtin_write_OSCCONL((uint8_t) (0x0200 & 0x00FF)); 0x558E: CLR W2 0x5590: MOV #0x46, W0 0x5592: MOV #0x57, W1 0x5594: MOV #0x100, W3 0x5596: MOV.B W0, [W3] 0x5598: MOV.B W1, [W3] 0x559A: MOV.B W2, [W3] Hopefully I am missing something or misreading something here, let me know your thoughts or solution! 
0
|
|
相关推荐
15个回答
|
|
|
还要注意的是，我对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:
|
|
|
|
|
|
这是一个允许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 |
|
|
|
|
|
|
|
|
|
|
只有小组成员才能发言，加入小组>>
5238 浏览 9 评论
2027 浏览 8 评论
1950 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3202 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2253 浏览 5 评论
772浏览 1评论
663浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
590浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
672浏览 0评论
572浏览 0评论
/6 
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
3703
评论
淘帖
1253
