CosyOS-II-STC8H中，默认情况下，系统时钟是定时器0，pendSV是外部中断0，DEBUG监控是串口2。因CosyOS-II-STC8H未使用stc8h的库函数，不知道printf()是如何联到串口1的？
stc-xuewei 发表于 2024-7-1 21:09
CosyOS-II-STC8H中，默认情况下，系统时钟是定时器0，pendSV是外部中断0，DEBUG监控是串口2。因CosyOS-II-S ...
printf()是C51标准库函数，调用的是标准库的putchar()，就是连接到串口1。
如果想更换其它串口，只能自己重写putchar()。
有点照本宣科的感觉。
tzz1983 发表于 2024-6-30 20:13
非常感谢, 等会我去尝试
我找到 PUSH DR56 导致 访问 xdata 异常的原因了！
不是 不能 PUSH DR56，
是因为各个任务在首次调度的时候，是直接恢复现场，
所以，各个任务栈数据的初始化 要正确，DPXL 对应的字节需要正确的初始化，
直接把 DPXL 赋值给它就行。
示例：*(s_u8_t *)(node_news->bsp + MCUCFG_BASICSTACKSIZE - 5) = DPXL;
因为 DPXL 在启动文件中已经被正确赋值了：
这样，就可以 PUSH/POP DR56 了。
现在，我这里测试都已经 OK 了。
本帖最后由 tzz1983 于 2024-7-3 10:16 编辑
CosyOS 发表于 2024-7-2 23:14
我找到 PUSH DR56 导致 访问 xdata 异常的原因了！
不是 不能 PUSH DR56，
是因为各个任务在首次调度的时 ...
非常感谢您的关心
不过我这里不是这个问题, 任务初始化时,我一直有对DPXL的处理的
之前是这样子的, 从来没有因为POP DR56出现过问题
即便是现在我改了,问题还是没解决
现在我的问题是, 只要把任务控制块放在XDATA, 就是出现各种不服.(仅限任务控制块, 其它OS全局变量放在XDATA不影响)
另外一点很有意思, 就是启用URAT1 的DMA时才会出问题, URAT1中断模式没有问题.
我仔细检查了DMA相关的代码, 确实找不到问题, 那代码量也不大.
那现在问题来了, 到底是因为 DAM 未知的影响(或软件/或硬件的),还是OS移植本身的问题 , 很难判断。
访真也很难起作用, 即抓不到出问题的那个时间节点.
CosyOS 发表于 2024-6-27 19:44
CosyOS-II 最新版 V3.0.0 发布！
新版特性：
我刚刚把之前 CosyOS-II V2.2.2 升级到 V3.0.0
过程很丝滑，比较简单
自动进入省电/休眠/掉电模式 已经增加到配置中 ，终于不用改内核代码
CosyOS 发表于 2024-6-30 13:33
根据我的经验，当内核对象在 XDATA 时，需注意以下事项：
1、generate reentrant fuctions，不要打勾。
回馈一个问题:
虽然通过研究发现，一个可重入函数，即使局部变量被定义在xdata中，仍然还是分配在可重入栈中，
也就是“可重入优先原则这个说法并不严谨.以下6种举例:
void TestXdata(void) reentrant
{
unsigned char val; //large编译模式 正确, 变量在重入栈中
val = 0XFF;
P2 = val;
}
void TestXdata(void) reentrant
{
unsigned char edata val; //large编译模式 不正确, 变量为固定位置
val = 0XFF;
P2 = val;
}
void TestXdata(void) reentrant
{
unsigned char xdata val; //large编译模式 正确, 变量在重入栈中
val = 0XFF;
P2 = val;
}
void TestXdata(void) reentrant
{
unsigned char val; //xsmall编译模式 正确, 变量在重入栈中
val = 0XFF;
P2 = val;
}
void TestXdata(void) reentrant
{
unsigned char edata val; //xsmall编译模式 正确, 变量在重入栈中
val = 0XFF;
P2 = val;
}
void TestXdata(void) reentrant
{
unsigned char xdata val; //xsmall编译模式 不正确, 变量为固定位置
val = 0XFF;
P2 = val;
}
以上红色两种情况并没有体现出 "可重入优先的原则"
总结来说, 正确的说法应该是:局部变量(含参数)不要强制指定存储类型, 让编译器自己决定. 就不会出错
tzz1983 发表于 2024-7-3 10:15
非常感谢您的关心
不过我这里不是这个问题, 任务初始化时,我一直有对DPXL的处理的
看来，我们的情况是不同的。
那就检查下 所有指向任务控制块的指针，注意指针域。
我曾有过多次经验，同一个功能、同一段代码，在C51、MDK，下测试都没问题，
在C251下，尤其是Large模型，就会出问题。
这通常都与 指针域 或 指针的应用 相关。
我曾碰到的两个问题：
1、两个不同指针域的指针变量，放在一个union中，会出问题，最后改为只定义一个指针变量，需要时再强制转换；
2、数据结构不要用指针直接赋值，改为memcpy。
示例（CosyOS 任务管理器）：
s_tasknode_ts node_temp;
s_tasknode_tsp node_curr = sTaskNode(&u_taskhand_Taskmgr);
node_temp = *node_curr; // 早期的方法，在Large模型时异常
s_memcpy(&node_temp, node_curr, sizeof(s_tasknode_ts)); // 现在的方法，各种情况都正常
tzz1983 发表于 2024-7-3 11:30
回馈一个问题:
这个说法并不严谨.以下6种举例:
研究的很仔细，{:4_250:}
Yang.Lian 发表于 2024-7-3 11:06
我刚刚把之前 CosyOS-II V2.2.2 升级到 V3.0.0
过程很丝滑，比较简单
自动进入省电/休眠/掉电模式 已经增 ...
{:4_250:}