全局不关总中断的 RTOS，CosyOS-III-V1.2.0, 送 擎天柱-AI8051U转89C52核心板

Cos***

Yang.*** 发表于 2024-5-14 17:59
楼主是不是可以在1楼做一个目录索引或者搞个 FQA 之类的？这样可以方便各位开发者

比如 #180 楼，非常好的 ...

感谢你的建议，确实应该搞一个常见问题的汇总和解答，我下一步会着手做这件事。

关于 系统时钟 与 系统滴答周期 的匹配问题，分为 错误 和 警告，
#error 系统滴答定时器溢出，必须减小系统时钟或系统滴答周期。
#warning 每秒钟的系统滴答周期数不为整数，建议重新调整系统滴答周期。
#warning 每秒钟的系统滴答周期数不为整数，建议重新调整系统时钟或系统滴答周期。
错误是无法容忍的；
警告会让你看着不爽；
但你也可以忽略这些警告，只是说 实际的滴答周期，会与设定值之间有一定误差，这会导致 软件定时器 不准。
你也可以在 mcucfg_80251.h 中，删除这些产生警告的代码。

你系统滴答周期 定义为 1250，不会有任何问题和风险，只是应用 uDelay_ms, uDelay_s, uDelay_m, uDelay_h, 时，时间就时常会不准确了。
这个问题要看你想怎么解决。
对于我来说，系统时钟 没必要 11.0592、22.1184 等，
波特率有一些误差没关系的，只要在允许范围内；
重点还是 系统时钟 要为整数MHZ，这样系统节拍才能准确。
系统时钟最好还要能被12整除，
这样 所有 定时器 无论 1T、12T，定时都是准确的。
如 6MHZ、12MHZ、15MHZ、24MHZ、33MHZ等，都能被12整除。
总之，建议 系统时钟 能被12整除，这样可确保 系统节拍 和 所有 用户定时器 的定时都是准确的。

youl***

不愧为国芯，国之大器继续创造辉煌。

Yang.***

Cos*** 发表于 2024-5-14 19:01
感谢你的建议，确实应该搞一个常见问题的汇总和解答，我下一步会着手做这件事。

关于 系统时钟 与 系统滴 ...

大佬啊，鄙司有很多 11.0592 的库存，是不是一个很合理的理由

"时间时长会不准确了" 应该怎么理解？

就我的应用来说，实时性可能比较重要，剩下的时间就是指示用的，比如，间隔1秒闪灯之类的运行等，报警灯之类的，误差个0.5秒都能接收把

Cos***

Yang.*** 发表于 2024-5-15 09:14
大佬啊，鄙司有很多 11.0592 的库存，是不是一个很合理的理由

"时间时长会不准确了" 应该怎么理解？

那你就用11.0592，
#define SYSCFG_SYSCLK                    11059200
然后
#define SYSCFG_SYSTICKCYCLE              1000

然后，在 mcucfg_80251.h 中，删除这些产生警告的代码。
而后，接受  系统滴答、软件定时器 的误差即可。

Cos***

Yang.*** 发表于 2024-5-15 09:14
大佬啊，鄙司有很多 11.0592 的库存，是不是一个很合理的理由

"时间时长会不准确了" 应该怎么理解？

"时间就时常会不准确了" 应该怎么理解？

意思是说有时候，按时间延时可能会不准。
因为 系统滴答周期 为 1250us，
例如你 uDelay_ms(21),  编译后为 uDelay_tc((1000UL * 21) / 1250)，uDelay_tc(16)；
而实际上，(1000UL * 21) / 1250 应该等于 16.8，产生些许误差。

至于有时误差是多少，大不大，你需要自己算一下，看是否能满足你 的要求。

Yang.***

Cos*** 发表于 2024-5-15 17:37
"时间就时常会不准确了" 应该怎么理解？

意思是说有时候，按时间延时可能会不准。

我看了一下cosyII 2.2.1 beta 关于 tick 的实现方式，尝试理解了一下，基本思路就是设置一个 tick 到 当前 task 的 timer，systick 中断中会 timer-- ，当 !timer 的时候调度一下

这个方式的好处当然是快，省资源，但是时间计算的的误差会累计，比如，
timer = 16 实际是16.8 这个 0.8 会被舍去，一直舍去，一直累计下去，如果对累计误差不感冒，这都没有问题

另外一种方式就是多设计一个 start，在设置 timer 的时候，同时设置 start = s_tick_counter;
所以，可以通过 s_tick_counter-start>=timer 来判断，这样就最小程度的减少了累计误差，只是每次的误差都有0.8，这样会多一个start变量，增加资源占用。但是，cosy 是国际化大操作系统，更加精确是不是会更好？

班门弄斧勿怪勿怪

Cos***

Yang.*** 发表于 2024-5-15 18:18
我看了一下cosyII 2.2.1 beta 关于 tick 的实现方式，尝试理解了一下，基本思路就是设置一个 tick 到 当 ...

首先，感谢你的建议！
软件定时器本就有着天生的1个滴答周期的误差，对于 CosyOS 来说，误差是 -1tick。
实际你在应用的时候，就以1250为例，如果延时时间是10ms、20ms等情况，也就不会有余数了，不会有误差。


只有在循环中多次延时，才会有累计误差。

你的想法是很好的，应提出表扬，但我不会轻易采用，因为这不仅会增加很多计算时间，还有一些深层问题，弄不好会出错的，是得不尝失的。
还是推荐用户 系统时钟能被12整除，并系统滴答周期为1000us 的方式；或是用户自己使用时注意这个误差的问题。

深层问题，
如 计数器 要分两次 读出，
如果不关闭总中断，可能会被中断打断，TH0、TL0 中读出的数据非同时，可能已经不是一次的数据；
被打断之前已经读完的可能已经是历史了、已经发生改变，再与被打断之后读出的拼接，其结果是错误的；
再有，即使关闭总中断，由于 自动重装载的原因，读出的也有可能不是 一次的数据。

lmy***

今天开会，直播课没有看成，只能看录播

Yang.***

s_cmdline_sendbuff 这个声明并定义了但是没有使用一定有隐藏技能！
是不是可以用在 printf？那就提供一个官方 putchar 实现呗
还是什么其他功能？

不好意思，看走眼了，好像实现不了，这玩意儿定时发送的

Yang.***

在 STC32G12K128 上 使用 COSYII 2.2.1 时候 4/5 中断都可以正常中断
但是 DMA_ADC_VECTOR （48）中断，却中断不了。
用 DMA_ADC_STA |= 0x01，又可以正常进入对应的中断。


如果不使用 COSYII 操作系统，直接 main 里用同样的代码初始化又可以正常中断。

好奇怪，求解

进一步测试发现，这个跟时钟的配置有关系

如果 SYSCFG_SYSCLK 配置成 11059200
且SYSCFG_SYSTICKCYCLE 配置成 1250 就会导致 DMA_ADC_VECTOR （48）中断 进不去

如果 SYSCFG_SYSCLK 配置成 12000000
且SYSCFG_SYSTICKCYCLE 配置成 1000 就没有这个问题 DMA_ADC_VECTOR （48）中断 可以正常进


我晕了个大了，我之前问过 11059200 和 1250 的时钟配置有没有隐患，楼主回复说没有，我就没有往这个事情上想，没想到还真有问题

不知道这算不算一个bug，还是说我不应该用 11059200/1250 的搭配？