RTT_逍遥
RTT_逍遥 - 认证专家
我欲乘风

注册于 1 year ago

回答
131
文章
5
关注者
7

rt-thread可以在docker上开发,在RT-THREAD上安装docker有些困难。RT-THREAD是RTOS,已经是操作系统内核了。

楼主这个是不是GCC环境遇到的问题,MDK没有问题吧?
通常这个问题和栈的地址有关系,可能在rt_object_get_information 函数中某个地方出现异常的进入,可以考虑检查下bss段或者RAM是否有正常初始化。因为MDK在执行main之前会做很多前期动作,GCC没有这些动作。

@NCJN_9736 楼主可以试下#include "error.h"是否可以,也可以试下最新的github上面的该bsp是否ok。

@chenyingchun
帮楼主试了以下几个软件包,这些软件包里面都有submodule,且都是在github上面,在menuconfig中选中之后,执行命令pkgs --update
log如下所示:

image.png

下载起来也是很快的,而且submodule都是从镜像里面下载的。速度也是相对来说比较快的,因为是从gitee上面下载的,

带有submodule的软件包有:
https://github.com/RT-Thread-packages/jerryscript
https://github.com/RT-Thread-packages/CMSIS
https://github.com/RT-Thread-packages/trusted-firmware-m

所以经过我的测试,结论是:gitee镜像同步软件包其实是有对submodule进行同步的。楼主可以验证下我的结论。所以大胆的在软件包中使用submodule,没问题的,虽然可能镜像同步有些延迟,不过一般过个几天就能在gitee镜像中找到submodule。

支持的。用命令

scons --target=vs

即可。不过可能年久失修,有些功能待完善。

@大话西游2018 看来楼主的好奇心还是挺大的。那我们就来看看究竟到底怎么回事吧。
你写代码的地方经过反汇编得知,nice_day其实是由于编译器对其进行优化,认为const变量不会变,那就直接用常量定义吧。0x63 =99
image.png

实际上不是map里面没有,是由于编译器对其进行优化,让这个常量直接作为一个十六进制的数字放到汇编里面。

比如你如果做如下修改,把const的int改为char[]类型,你会发现nice_day变量在map的地址很清楚。
image.png

当然这边说的优化并不是优化等级,当前我用的等级是-O0. 也就是说可以算作编译器默认认为cosnt int可以作为常量直接存储。

IIC消息的结构体:

struct rt_i2c_msg
{
    rt_uint16_t addr;
    rt_uint16_t flags;
    rt_uint16_t len;
    rt_uint8_t  *buf;
};

addr预留了16bit的数据,可以存放16bit的地址,传下来之后,由flags里面的ADDR_10BIT这个标志位来区分16bit还是8bit。

#define RT_I2C_WR                0x0000
#define RT_I2C_RD               (1u << 0)
#define RT_I2C_ADDR_10BIT       (1u << 2)  /* this is a ten bit chip address */
#define RT_I2C_NO_START         (1u << 4)
#define RT_I2C_IGNORE_NACK      (1u << 5)
#define RT_I2C_NO_READ_ACK      (1u << 6)  /* when I2C reading, we do not ACK */
#define RT_I2C_NO_STOP          (1u << 7)

由底层驱动决定如何分辨,之后通过调用HAL层传下去。

hi:
hdac1 这个是一个指针:
DAC_HandleTypeDef *hdac1;
没有进行初始化就使用了:

    hdac1->Instance = DAC1;
    HAL_DAC_Init(hdac1);

    hdacch1_cfg->DAC_Trigger = DAC_TRIGGER_T6_TRGO;
    hdacch1_cfg->DAC_OutputBuffer = DAC_OUTPUTBUFFER_DISABLE;
    HAL_DAC_ConfigChannel(hdac1, hdacch1_cfg, DAC_CHANNEL_1);

Hi 最近libc做了一些调整。比如error.h
可能会导致你在master分支上做的一些libc相关的东西有些问题。
官方肯定也没法测太多软件包,不过你可以稍微修改一下提交PR,大家一起来维护。
因为studio里面的不经常会变动,github上的代码经常会变动的,所以推荐使用studio来做长期coding

解决方案:
找到编译ok的studio里面的SIGALARM 这个宏定义,再去判断一下bsp里面出错的原因,找到rootcause。修改PR即可。

人无完人,代码也没有完全没有问题的。欢迎PR.

hi:
这里的On-chip Peripheral Driver是需要每家芯片自行整理添加的,之前整理的bsp/l496zg-st-nucleo 可能小伙伴只整理了UART和GPIO。 欢迎整理出对应的USB DRIVER,具体可以参考pandora相关的USB的配置。
只要在board/Kconfig
中添加这些USB相关的配置,然后测试一下就可以PR了。

目前配合的比较好的是蓝牙nrf52840,有nimble协议栈以及softdevice协议栈可以提供使用。可以查找相关软件包

回到
顶部

发布
问题

投诉
建议