解决Ti CC1310上I2C驱动能力不足(稳定性)问题

在使用Ti CC1310的硬件I2C与外部设备进行通信的时候,无法长时间稳定运行,尤其是平时的测试开发板,使用杜邦线连接的情况下。

同等情况下的SPI总线,一般不会发生此类问题,因此怀疑是GPIO管脚的驱动能力不足导致的。

我们的工程是使用的Code Composer Studio 8.2.0.00007创建的项目。

我们研究I2C初始化GPIO管脚的代码在simplelink_cc13x0_sdk_2_30_00_20/source/ti/drivers/i2c/I2CCC26XX.c,相关的代码如下:

从上面的代码中,我们发现GPIO管脚的驱动能力没有设置,根据CC13x0, CC26x0 SimpleLink ™ Wireless MCU Technical Reference Manual中的介绍,我们发现,如果不设置,默认情况下是PIN_DRVSTR_MIN(< (*) Lowest drive strength)。这个驱动模式下,最省电,但是当有干扰存在的情况下,最容易导致出现错误。

查找Ti CC1310提供的I2C驱动程序,没有找到可以设置管脚驱动能力的接口。

网上有人通过直接修改Ti CC1310提供的I2C驱动程序,也就是simplelink_cc13x0_sdk_2_30_00_20/source/ti/drivers/i2c/I2CCC26XX.c里的初始化代码(见上面的代码段)增加驱动能力属性来实现这个功能。

但是这种修改方式不推荐,修改的侵入太强。

GPIO的操作函数中,我们找到如下函数:

我们尝试从上层找到I2C驱动使用的GPIO管脚,然后调整其驱动能力。

从上面我们看到I2C句柄的.object指针指向了I2CCC26XX_Object类型的结构体,这个结构体在simplelink_cc13x0_sdk_2_30_00_20/source/ti/drivers/i2c/I2CCC26XX.c里的static int I2CCC26XX_initIO(I2C_Handle handle, void *pinCfg)函数中被初始化,这个结构体记录了详细的GPIO操作句柄。

因此我们可以使用如下的代码对GPIO管脚的驱动能力进行调整:

参考链接


Raspberry Pi Zero W解决调试信息不足的问题(以libzmq-dev为例)

最近在参照 树莓派实时系统下脚本语言的选择(应当使用Lua而不是Python) 调用调试lua-zmq的时候,发现使用PAIR模式进行线程之间通信,长时间运行后会出现死锁的情况。

当我们需要跟踪问题的时候,使用apt-get安装的版本缺乏必要的调试信息。

我们可以手工安装调试信息包,如下:


我们也可以从源代码重新编译一份,如下:

以上是针对Debian安装包来进行的处理,然而对于luarocks安装的插件来说,默认luarocks是不能编译调试版本的,此时就需要我们手工编译了。我们以lua-zmq为例子,参考如下:

ubuntu 16.04安装以及使用PCB设计软件KiCAD EDA

继续阅读ubuntu 16.04安装以及使用PCB设计软件KiCAD EDA

macOS High Sierra(10.13.6)使用HL-340(CH340/CH341)芯片的USB转串口设备

最近开发需要,购买了一堆的USB转串口设备,在Linux下面都是免驱动的,但是到了macOS High Sierra(10.13.6)上,无法正常识别。在Linux上通过lsusb可以看到如下信息:

继续阅读macOS High Sierra(10.13.6)使用HL-340(CH340/CH341)芯片的USB转串口设备

Ti Code Composer Studio 8.1.0使用SEGGER J-Link Emulator插件代码完整性校验

最近在使用Ti Code Composer Studio 8.1.0编译调试代码,当通过网上购买的SEGGER J-Link Emulator来烧写固件的时候,发现在某些情况下会出现固件烧录不正确,导致各种莫名其妙的问题。可以通过下图所示的方式,要求SEGGER J-Link Emulator在烧录完成固件后,对固件进行完整性校验,规避上面的问题。
继续阅读Ti Code Composer Studio 8.1.0使用SEGGER J-Link Emulator插件代码完整性校验

ubuntu 16.04(x64)编译并烧录NodeMCU固件

最近在捣鼓NodeMCU,中间各种折腾,下面记录一下编译固件的过程。

首先参考 ubuntu 16.04(x64)构建NodeMCU编译工具链 来构建工具链,然后把工具链加入到环境变量。

然后就是下载固件代码并进行编译了

如果存在下载问题,可以本站下载一份代码拷贝。点击此处下载

只要NodeMCU开发板通电或重置,就会执行init.lua脚本。因此,我们把自己的代码写在这个脚本里面即可。然后用luatool更新到NodeMCU设备里面即可。

注意上面的代码中,--port参数需要根据实际情况进行修改,--src参数也是一样需要根据我们实际的文件名来调整,最后的-b指定波特率,上面固件编译后默认的波特率是115200,淘宝上卖的设备,很多是默认9600的,这个要注意。

如果上面的代码下载存在问题,可以本站下载一份拷贝 点击这里下载luatool
继续阅读ubuntu 16.04(x64)编译并烧录NodeMCU固件

ubuntu 16.04(x64)构建NodeMCU编译工具链

最近在捣鼓NodeMCU,中间各种折腾,下面记录一下编译工具链的过程。

官方推荐的操作过程如下:

上面操作中最慢的依旧是下载依赖的工具链的源代码部分,可以从本站下载一份已经下载完全部依赖项目的编译环境。点击此处下载

本站下载的文件,直接执行make命令即可,不要执行make clean,make clean会删除ESP8266_NONOS_SDK文件夹,导致编译不通过。这种情况,可以还原Makefile,再次去服务器上拉取文件即可。

编译完成后,注意以下几个路径

  • esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/include/为头文件的所在目录
  • esp-open-sdk/xtensa-lx106-elf/bin为工具链所在目录
  • esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/lib为链接库目录

上面的几个路径在编译源代码的时候会用到。

以下的操作过程可以通过,但是已经过时,在实际编译新项目的时候,可能会出现异常,已经不推荐了。

对于上面的命令执行过程中,往往卡住在ct-ng build这个位置,观察目录下的build.log会发现总是卡住在文件下载的位置,大量的链接无法正确下载,都是国情导致的。

如果出现下载问题,一般建议从本站下载一份已经下载好的文件,当然,也可以手工从其他镜像站点逐个手工下载依赖的源代码压缩包。

参考操作如下:

然后重新执行ct-ng build命令即可。

如果上面的代码下载存在问题,可以从本站下载一份拷贝,点击下载crosstool-NG

已经编译好的工具链,可以从本站下载,点击这里下载 xtensa-lx106-elf

参考链接


esp8266/esp8266-wiki/Toolchain