Blog's Home

越努力,越幸运!

RS-232, RS-422, RS-485 Serial Communication General Concepts(转载)

原文地址:http://www.ni.com/white-paper/11390/en/

合并BIN文件的两种方法(转载)

原文链接:https://www.cnblogs.com/we-hjb/archive/2011/01/06/1929147.html

在单片机的开发过程中,经常需要将两个单独的BIN文件合并成一个文件,方便烧写和生产。下面结合STM32的IAP Bootloader Code和Application Code的合并,介绍两种合并BIN文件的方法。

广州长沙就业定居环境对比分析

本文主要分析下软件开发行业广州长沙的就业环境,以及相关的定居环境。

嵌入式软件开发人员其实也是程序员中的一个群体,故此,根据上图中的程序员工资图,2019年长沙程序员工资平均为 11K,广州程序员工资平均为 14K,比值为 1:1.27

利用.bat(批处理)来删除KEIL编译生成的无用文件(转)

本文第转载,原地址为:http://home.eeworld.com.cn/my/space-uid-238351-blogid-649660.html

Bootloader&USB问题记录

一、从bootloader跳转到应用层时产生hardfault

这个问题在上一家公司上班时就遇到过了,虽然问题的表现不太一样,但源头基本是一样的,就是Systick中断引起的。之前的是从boot跳转到应用层时,没有关闭Systick中断,导致在跳转过程中产生了中断,而此时系统还没有正常初始化,导致系统出错。这一次的问题也是因为Systick中断没有关,跳转到应用层后产生了Systick中断,但是这里并非是由于中断导致系统出错,而是因为应用层里面没有定义Systick的中断服务函数,所以在应用层产生了Systick中断后,系统找不到该中断的入口,从而导致没法正常进入,于是就出错了。

内存未对齐导致的hardfault分析

今天写代码时,碰到了一个问题,就是我在某个函数里面新增了一个成员变量,然后在该函数结束并返回调用函数时,进入了hardfault。然后我将该变量前面添加static修饰符,使其不再使用堆栈中分配的内存,错误就没有了。这让我感觉很不解,于是又进行了后续的验证。

初步怀疑问题原因就是内存未对齐,导致访问时出错而引起hardfault。当我将static修饰符去掉,然后对该函数内的局部变量的位置进行了一番调整,问题也没有再出现。于是我仍然使用原来出问题的那种变量定义顺序,这里面有一个二维数组,定义的形式是uint8 ch_name[][10],第一维的大小是没有显示定义的,于是我将第1维的大小给定一个固定值,再调试发现,也没有出现hardfault,这时我就想,难道是因为这个数组所占用的内存空间前后没有对齐,于是我又将第1维的固定值去掉,调整变量的定义顺序,使得在这个数组前面的内存为4字节对齐,然后再调试,发现又出现hardfault,既然这样,我就又把这个数组之后的内存调整为4字节对齐,仍然产生hardfault。很奇怪的是,此时我再将第1维的大小给定,再调试,发现仍然有问题,这就很令人费解了。虽然很大程度上我判定就是内存未对齐导致的hardfault,但是这么一测试,却发现结果表现的很奇怪。

论单片机编程中数据类型的应用

刚刚在《C专家编程》一书中看到这么一段话:

尽量不要在你的代码中使用无符号类型,以免增加不必要的复杂性。尤其是,不要仅仅因为无符号数不存在负值(如年龄,国债)而用它来表示数量。

STM32引脚JTDO、JNTRST与JTDI作为普通IO口使用配置(转载)

转载本文是因为,最近在用STM32F103RCT6的MCU时,硬件人员设计电路用了SPI3的几个引脚,我也没太在意,结果编码时发现这几个脚上电复位后的默认功能是JTDO、JTDI和JNTRST,想做普通IO使用还必须进行重映射操作。于是我就进行了重映射,结果发现控制还是不起效,后来看到这篇文章写的,如果配置了重映射后,又配置了其他的引脚,那么配置就不起作用了,以后每次对这几个脚进行拉高拉低操作时,前面都必须附带一条重映射配置的代码。于是我照着试了下,果然可以,故此转载以记录。


问题记录——堆栈问题、strcmp()比较问题

1、堆栈太小导致图片数据接收异常

如上图示,查看编译输出的信息可知,程序执行过程中使用的堆栈大小为:1592 bytes + Unknown,也就是说,按这个数值来看,最少的堆栈大小起码也要给定2KB的空间才够用,一般来说,我们是根据这个已知的字节数,给出它的两倍大小做为堆栈空间,即1592*2=3184 bytes,而实际在程序中查看,堆栈只分配了 0x400的大小,即1024字节,很明显,这个大小是不够用的,所以导致在图片数据传输过程中,即涉及到比较大的堆栈空间操作时,数据发生了紊乱,从而使得MCU接收到的数据就不正确了。

论协议数据解析

本来没想要写这篇文章,但是协议数据解析实在是太过重要,应该算是驱动级别的功能,而且这两天又碰到个因为协议数据解析代码考虑的不够完善,而导致连续发送命令时出现解析失败的情况,花了比较多的时间才想明白了逻辑漏洞出在哪里(是分析出来的,因为很难通过观测来判定出错原因)。故此总结,希望以后碰到此类问题不再犯同样的错误。

«12345678910»
欢迎来到黄建雄的博客,本站点不定期进行博文更新,敬请期待!
  [查看权限]

站内搜索
友情链接
  • 订阅本站的 RSS 2.0 新闻聚合

Powered By Z-Blog 2.2 Prism Build 140101

Copyright © 2015 by 黄建雄. 本站文章除特别声明系转载外,均保留所有权利.
知识共享许可协议本作品采用知识共享署名 2.5 中国大陆许可协议进行许可,欢迎转载,但请注明来自Blog's home,并保持转载后文章内容的完整。        
湘ICP备15003615号 工业和信息化部

  • 您的鼓励是对我最大的认可