MCC没有生成正确的代码？

你总结了相当多的“问题”：除非你在RESP上定义一些刺激。模拟输入，模拟器将提供相同的广告结果。ADFM是一个真正的位InAdCON1。如果MCC不删除正确的代码，修改生成的代码以消除这些错误并不太困难。我不会篡改ADR3SX寄存器的内容。（根据数据表，对AdRESX寄存器的写入没有作用。所以所给出的代码将无法正常工作。还有什么？



      以下为原文

    You're summariing quite a number of "issues":

• Unless you define some stimulus on the resp. analog input, the simulator will deliver the ever-same AD result.
  
• ADFM is a real bit in ADCON1. If MCC doesn't del8ver the correct code, it is not too difficult to modify the code generated to eliminate such errors.
  
• I wouldn't fiddle with the ADR3Sx register's contents. (According to the datasheet, a write to the ADRESx registers has no effect. So the code given won't work as desired.)
  

What else ...?

HI在MCC生成的代码中看不到问题。它对ADC结果的意图一无所知，或者我们为什么选择左对齐或右对齐。因此，它只返回AdRESH的16位内容：ADRESL。我们如何使用它是我们手工编写的代码。我知道最多的COMM。使用左对齐是只使用结果中最重要的8位并丢弃较低的2位。当然，这可以直接通过只获取ADRESH和忽略ADRESL来完成。但是，这可能不是左对齐的用例的100%，所以MCC生成的代码JUS。T返回AdRESH的16位：AdRESL AS，然后我们做我们想要的/需要的。MCC可能有一些用途，但是没有Oracle猜测我们的意图是什么。它真正做的是给我们那些不想学习数据表和知道名称和内部结构的人提供帮助。每一个SFR，至少对于基本的东西来说。底线，需要优化的东西，自己做。



      以下为原文

    Hi
 
I don't see a problem in the MCC generated code.
It knows nothing about our intentions relating to the ADC result or why we choose left or right justified.
So all it does e return the 16 bit contents of ADRESH:ADRESL.
How we use it is something that goes in our hand crafted code.
 
I know the most common use for left justification is to use only the most significant 8 bits of the result and discard the lower 2bits.
Of course, this can be done directly by fetching only the ADRESH and ignoring ADRESL.
But that may not be the 100% of the use cases for left justification, so the MCC generated code just returns the 16bits of ADRESH:ADRESL as is, and then we do what we want/need with them.
 
MCC may have some use, but not has an oracle guessing what are our intentions.
 
What it really does is give a hand to those of us that don't want to study the datasheet and know the names and internal structure of each SFR, at least for the basic stuff.
 
 
Bottom line, want something optimized, do it yourself.
 
 
Best regards
Jorge
 

这只不过是在模拟器上没有像以前那样在真实的PIC上尝试过的。感谢DU000 0 0 01 01，我知道改变代码并得到你想要的东西并不难，在这种情况下，3行，但是MPLAB X；MCC是很好的工具，只想看到它做正确的事情。主张。广告结果/量化不是问题，需要ADRESVALL值必须输入用户模拟（无刺激），所以ADRES仍然OK +不应该改变。关键点是ADFM＝0不旋转/移位AdResto的MSB的结果，随后是ADRESL和AdRESL的静止2 LSB到AdRESL的MSB，如文献中所述。MCC代码抛出：ADRES（10BIT）＝0x03FF；ADFM＝0，= & Gt；ADRESH＝0x03 ADRESL＝0XFF。它必须是＝&＞；ADRESH＝0XFF ADRESL＝0xC0。这是我得到模拟器工作的方式，改变代码以获得ADRESX值作为预期，任务不由MCC完成。只需写入ANADRESE值，并从ADCGETGET转换结果中观察行为。如果没有校正，就没有左对齐。MCC的目的是使能；生成；配置…快速和容易的代码，并做它必须做的预期这项任务完成。这是Microchip团队的努力和工作，我从20年左右的时间里很欣赏这个工具。只想看到这个工具工作的最好的。这是一个旧报告的bug尚未解决，但仍在V.3.55.1。



      以下为原文

    This is only on simulator haven´t tried on real PIC as said before.
 
Thanks du00000001,
I know it´s not difficult to change code and get what you want, in this case 3 lines, but MPLAB X; MCC are nice tools, just want to see it doing right what it have to do.
 

In years never need stimulus on AD for my purposes. The AD result/quantification is not the problem, indeed the ADRES value must be inputted typing it by user for simulation (no stimulus), so ADRES remains OK + no changes as should be. The point is that ADFM = 0 does not rotates/shifts the result of MSBs of ADRES to the MSB of ADRESH followed by ADRESL and the resting 2 LSB of ADRESL to MSB of ADRESL as stated in document.
MCC code throws:
ADRES(10bits) = =0x03FF; ADFM = 0, => ADRESH = 0x03 ADRESL = 0xFF.
                                        It must be  => ADRESH = 0xFF ADRESL = 0xC0.                                       

It´s the way I get simulator working, changing code to get ADRESx values as expected, task not done by MCC. Just write an ADRES value and watch the behavior from ADC_GetConversionResult. If not corrected, no Left Justif. achieved.

MCC is intended to enable; generate; configure... quick and easy the code and do what it have to do expecting that task done. This is a hard effort/job from Microchip team and I appreciate this tool a lot from 20 years or so. Just want to see this tool working the best possible.
This is an old reported bug not solved yet still on ver. 3.55.1.
 

我想你没有理解ADFM：这改变了ADC在ADREST中的结果。ADFM＝1将给出最大输入电压的0x03:0XFF的读数，而ADFM＝0将给出0CFF:0xC0。读取寄存器的代码是相同的，因此不需要MCC生成不同的C。当ADFM改变时，ODE似乎是时候让你得到一些真正的PIC来看看硬件是如何工作的。我只希望你的“5年以上的经验”不局限于“5年左右的模拟器”。



      以下为原文

    I suppose you didn"t yer understand ADFM: this changed thway the ADC presents itsresults in ADRES.
ADFM = 1 will give a reading of 0x03:0xFF for the maximum input voltage while ADFM = 0 will give 0cFF:0xC0.
The code to read the registers is the same so there is no need for MCC to generate different code when ADFM changes.
 
Seems it's time for you to get some real PIC to see how the hardware works. And I can only hope your "5+ years of experience..." are not limited to "5+ years playing around with the simulator".

我想你必须把眼镜换成你的猴子。在回答之前阅读和理解并且是冒犯的。这个例子显示了ADFM 0，ADRES3FF必须是FFC0，而不是3FF。现在明白了吗？ADRES（10BIT）＝0x03FF；ADFM＝0，＝& gt；ADRESH＝0x03 ADRESL＝0xFF。它必须是＝& gt；ADRESH＝0XFF ADRESL＝0xC0。



      以下为原文

   
I think you must change the glasses to your monkey. Read and understand prior to answer and be offensive.
This example shows ADFM 0, ADRES 3ff must be ffc0 and not 3ff as in simulator. GOT IT NOW?
ADRES(10bits) = 0x03FF; ADFM = 0, => ADRESH = 0x03 ADRESL = 0xFF.
                                        It must be  => ADRESH = 0xFF ADRESL = 0xC0.

在你的帖子之前很久。如果MCC生成代码来设置ADCON1中的ADFM位（你没有提供MCC产生的ADC init代码）！这可能是模拟器的问题。如果MCC没有生成正确的初始化，纠正初始化，不要篡改不能在真实硬件上被篡改的寄存器！模拟器就像MCC一样，是一个很好的工具，但是从错误中解放出来。



      以下为原文

    Got it long before your post.

• Provided MCC generates code to set the ADFM bit in ADCON1 (you didn't provide the ADC init code generated by MCC!), this might be an issue of the simulator.
  
• If MCC doesn't generate the correct initialization, correct the initialization and do not fiddle with registers that cannot be fiddled with on the real hardware!
  

The simulator - just like MCC - is a nice tool but way from being error-free.
Feel free to rant on instead of properly analyzing the situation.

你发现了冷水…！！！



      以下为原文

   
YOU DISCOVERED THE COLD WATER...!!!

对于MCC所生成的代码，无论是配置ADC还是使用它，都没有什么问题。这里的错误是，对函数的期望只是简单地返回ADRESH的16位内容：AdRESL AS，而不是对所选择的AL中隐含的8位或10位结果进行预处理。着火。意思是额外的6位包含在返回值中，程序员必须在代码中处理它。



      以下为原文

    Hi
 
There is nothing worng with the code generated by MCC, both for configuring the ADC and to use it.
 
What is wrong here, are the expectations about the functionsadc_result_t ADC_GetConversionResult(void);
adc_result_t ADC_GetConversion(adc_channel_t channel);They simply return the 16bit contents of ADRESH:ADRESL as is, and not pre-processed for the 8bit or 10bit results implicit in the chosen alignement.
 
Meaning the extra 6 bits are included in the returned value and the programmer has to handle that in code.
 
 
Best regards
Jorge
 

@ A.IosueJokester。那么，你的问题到底是什么？



      以下为原文

    @ A. Iosue
Jokester. So, what exactly is your problem?