RTCC时间不会增加

嗨，你确定SOSC真的在工作吗？32.768手表的晶体工作在小信号电平，可能很难检查硬件。你可以尝试设置Timer1以运行在同一个振荡器，它有较少的控制位，通常更容易调试，直到你确定振荡器正在工作。迈西尔

除了启用二级振荡器之外，正如Mysil所指出的，我还发现需要其他一些东西来使事情顺利进行。参考我在这里的文章http://www..hip.com/for./m1032892.aspxScroll down以发布#14So，为了测试，看看我们是否在同一个页面上，我重新开始然后您将main()更改为如下内容：注意，对于初步测试，我不想调试按钮按下的内容，所以我只测试RTCC。（事实上，对于初步测试，我使用内部31kHz振荡器而不是使用晶体，这样我就不用担心其他的影响。）我的哲学是测试OTAT（一次只做一件事）。当我修改您的项目以使用PIC16F19156，并将main()函数更改成我所建议的时，事情进展得很顺利。13：RTCCON=13：RTCCON=0x014：RTCCON=0x812018-03-03-03-03-03-12-12-14:04:0x812012018-03-03-12-01-03-12-01:04040404040404040404040X0101:RTCCON=0X0101：0X018-2012018-03-03-03-12-014：RTCCON=0000X018-2012018-03-03-03-03-12-14:0404040404040404040404040404X012012018-2012012018-2018-03-03-03-03-03-03-03-12-12-12-12-12-141414141414141414o上个星期，微软的评论开始了，首先请接受我对我们延迟的回应的歉意。目前我们的支持积压中有很多客户，这影响了我们的响应时间。感谢您提醒我们注意。我已经订购了一个零件，这样我就可以进行一些测试。我一得到结果就告诉你。很可能还需要两个星期才能进行任何测试，因为我有一个外地培训活动。一旦我完成测试，我会让你知道我的结果。再次感谢-Rich******Micro.Comments End**************。

你好，戴夫和MySILY谢谢你的帮助！在将戴夫的代码修改应用到矿井后，它同样与带有SOSC(32.768kHz外接晶体)的PIC16F19176板配合良好。

我很高兴听到它对你有用。我的芯片是不同的，但来自同一个家庭，我认为它可能。但是……我的测试只是一个测试。我想在不改变任何MCC生成的内容的情况下进行计数。对于完整的应用程序，任何需要设置和清除WREN的地方，在设置或清除RTCEN之后在RTCC时钟的循环顺序上插入延迟。这是一个硬件的问题（可能是一个bug），或者只是文档中缺少的东西。最终，可能会有一个硬件差错项或文档更新，传递给MCC组，让它们围绕“问题”工作。我注意到对于UART速度，你有一个高飞的MCC设置，但是你（和我）得到了一个接近9600波特的比特率。在MCC中将其设置为9600波特不会导致可用的串行流的原因是：在您的mcc.c（以及由该芯片的一个全新的项目生成的mcc.c）中，它将OSCTUNE寄存器设置为0x20。现在，对于这个芯片，0x20给出了最低可能的可调谐MFIFT频率。正确的默认值（中心值）是0x00。如果将OSCTUNE设置为0x00，则可以使用MCC生成正确的UART设置。注意，对于MFINT计时的系统，错误的OSCTUNE设置会影响所有依赖于系统时钟的模块（定时器、pwm频率设置等），而不仅仅是UA。我想强调的是，如果MFINT是系统时钟的源，或者更准确地说，如果MFINT是特定模块的时钟源，那么这只影响程序。我通常在“真实”的项目中使用水晶，但是为了测试和评估，我希望一切正常工作。当我没有最终产品中使用的水晶（或板布局）时，MFINT便于测试。MCC还为其他某些芯片生成不正确的OSCTUNE设置。我已经测试过（例如，PIC16F15355），但是对于我看到的那些其他芯片，可调性变化大约为+-2%。UART仍然使用不正确的OSCTUNE值，即使MFINT本身关闭百分之一或甚至2（假设另一端没有很大的错误）。然而……对于'16156芯片，可调性大约是+-11%（喘息），UART绝对不能用名义va工作。在SPBRG。（也就是说，如果系统频率下降了11%，那么根据基于系统频率的数据表公式计算的值是不可接受地关闭的。在我提出这个问题之前，我一直等到您确认RTCC正在计数，因为我不想把两个不同的问题混在一起。）ER在泥泞的软件/硬件水。你的UART与你的设置一起工作。底线：使用MCC的方式，你通常这样做。除了系统模块之外，在“寄存器”选项卡上计时，并在OSCTUNE设置中输入0x00，而不是MCC的值0x20。然后回到EUSART模块，将波特设置设置设置为实际的期望值（对于您的情况是9600，但我通常使用更高的系统时钟速度和t上的115200波特）。现在，当生成MCC设置准备编译时，它将显示“合并”窗口中的差异。如果存在任何其他差异（除了OSCTUNE），则适当地解决它们，并确保OSCTUNE的“获取”正确的值0x00。任何介于零和最大计数之间的值）都是有效的中心频率设置，所以如果您正在使用其他芯片，不要自动假定它应该设置为零。最后（我保证）：[2]我为'19156设备提交了一份关于OSCTUNE的MCC错误报告。也许有一天他们会绕过它，尤其是因为这个芯片对定时的影响是如此之大，以至于波特设置非常笨拙。（试着想象一下定时设置和其他东西……心烦意乱。）

谢谢你的信息！至于我使用外部32.768kHz振荡器(SOSC)的情况，为了获得时间精度，我在你的代码中添加了一些行，它似乎工作得很好。还注意到，在调用MCC生成函数“RTCC_TimeSet(struct tm*initialTime)”之后，RTCC计时也停止了；“所以我必须在ca之后执行上面的代码。“RTCccjTimeSET（StuttTM *初始化时间）”；“使RTCC工作。问候，杰伊

嗯，如果你看看这个函数的源代码，在rtcc.c中你会看到我到底在说什么。正如我提到的，你必须在代码中的任何地方添加延迟指令，RTCWREN在改变RTCEN之后很快被改变。注意，为了将延迟指令添加到函数的源代码中，你必须#i在RTCC.C中排除“MCC.H”，因此在使用的任何地方都定义了xxTalthFrq。这是能够使用_u._ms()所必需的。我注意到，有几个函数禁用RTCEN并启用它，即使没有必要。你可以调查（例如，实验）看看哪些是多余的，或者你可以简单地在每个你看到模式的地方添加延迟。我的建议是：不要只是为了现在需要的功能而做；到处都做，以便在以后需要添加新功能时不会感到惊讶。然后，在验证RTCC功能之后，您可以继续进行项目的其余部分。

是的，完全理解你说的话，我会的。非常感谢！问候，杰伊