【早该这样做】之 调试口用一个串口真的不过分

辛昕

【早该这样做】之 调试口用一个串口真的不过分 [复制链接]

 

这个标题听着可能有点可笑。
不过，这里面，有故事。

身为一个经常纠结很多 大多数人通常都不会纠结的问题 的我，这个问题，就算不足以 冠之以 啊哈~
用 “早该这样做” 的感慨一番也绝对是必然的。

在流水账以前，先简单解释一下这个事情。

写代码，免不了调试，不管是在PC上，用printf,还是在单片机上，都一样。
问题在于，你怎么调试。
调试其实至少有两大类方法：
1.debug--breakpoint--watch
这个方法的好处是，不需要任何代码上的额外支持。
不好的地方是，假如你是写单片机的你就会知道，即使不是调一些需要比较长时间运行的代码，这种方法在很多场合也是无法完成的。
举个最简单的例子：测试某段代码的运行时间。
2.通过printf,或者串口（单片机的最爱），实质上是通过 标准输出流，在程序中打印出一些自己想看的东西。
这两个的优缺点基本是互换的。

会有人支持进而反对另一种方法，其实我想说的依然是，这两种方法一样是各有不同场合。
以我个人的长期（下意识经验来说），我用串口打印的时间会多得多得多，但是，在调试和“运行时间”无关的东西上时，比如写一个算法，我通常会喜欢用debug方式。
因为真的很方便查看一些中间数值，而根本不需要写一大堆printf,然后还要考虑调试完后怎么清除，更不需要考虑什么 断言宏一类的鬼东西。
但不得不说，我通常使用串口多得多。

我想这也许是因为我是在PC上学C的原因，我真的很喜欢 printf。

而这个标题里说的，给调试口留一个串口，实际说到底，就是在单片机上，怎么想办法实现这个  printf而已。
当然实现上是个很简单的重定向，这里说的 过分不过分，其实是 “应不应该”的考量。

一点半了，抛出个问题先，明晚接着写故事。

所有的纠结虽然到最后可能会发现完全不值得，但是却并未毫无原因。只是——早该这样做。

nmg

期待下篇

eric_wang

需要通过不断地积累经验再遇到同类的问题才能想到“早该这样做”

ddllxxrr

楼主的方法也不要说绝对。我调程序用一个LED就可以，楼主还得用串口。还得初使化串口。

cruelfox

自带库的 printf 太耗资源了。
我是用 uart_wstr() 来输出字符串，uart_whex(), uart_wdec() 来输出整数，uart_hexdump() 来输出一串字节.
并且USART用DMA传输，调用时几乎不等待。

皈依

我和楼主大大一样的 我调试也是喜欢用printf，只有遇到一些IDE本身或者C本身的问题的时候才用debug 逻辑层一律printf

辛昕

ddllxxrr 发表于 2017-2-16 08:29
楼主的方法也不要说绝对。我调程序用一个LED就可以，楼主还得用串口。还得初使化串口。

别急啊， 好歹我也是从51开始的，LED调试这种事我也不是没干过

辛昕

cruelfox 发表于 2017-2-16 10:19
自带库的 printf 太耗资源了。
我是用 uart_wstr() 来输出字符串，uart_whex(), uart_wdec() 来输出整数， ...

你这几个函数都是哪里来的？
c库的printf耗资源，是因为它带了标准流的功能，实际上stdio中有很多版本的 printf，可以选择的

人民币的幻想

嫌弃printf的话，自己实现一个mcu版的变参调试函数。打断点和加printf二者有时候联合使用会更容易找问题。

辛昕

人民币的幻想 发表于 2017-2-17 11:05
嫌弃printf的话，自己实现一个mcu版的变参调试函数。打断点和加printf二者有时候联合使用会更容易找问题。

有机会试试，但我相信，我不太可能写的比C标准库还好。
printf至少有
sprintf fprint等版本，好好选择应该会有合适的。

long521

这个贴子好,我需要,学习楼主和下面各位回贴高手,

辛昕

nmg 发表于 2017-2-16 07:06
期待下篇

我就是那个下篇

辛昕

ddllxxrr 发表于 2017-2-16 08:29
楼主的方法也不要说绝对。我调程序用一个LED就可以，楼主还得用串口。还得初使化串口。

用LED这种事我也干过，尤其早期还不懂得什么重定向串口，又因为用51，没有在线ISP工具的时候，我真的是毫无办法，全靠断点或者 LED。
当时不是有流水灯呢，刚好8位，不多不少，还刚好连在P0上，坦白说，当时我真的就是拿它当一个字节寄存器在用的。

我就想问你，那种日子蛋疼不？

辛昕

cruelfox 发表于 2017-2-16 10:19
自带库的 printf 太耗资源了。
我是用 uart_wstr() 来输出字符串，uart_whex(), uart_wdec() 来输出整数， ...

今晚老衲只讲故事，这个问题，我已经记在 evernote 上了，排期解决啊~~

辛昕

用一个串口不过分 下篇
      前面扯得有点散，加上放了一段时间没写，今天接着写。

      现在说说，留一个串口不过分是个什么意思。

      不知道大家有没注意，有很多很多外设（我是指带主控那一种），基本都很喜欢用串口，真的是串口，i2c spi都不多来做通信口，而大多数单片机，除了STM32有几款变态的多达四五个串口那种之外，大多数时候有个三两个串口就很给力了，又受限于管脚等资源，其实最后往往一个像样点的项目下来，真正能留着来用的串口不多，如果要占用一个串口用来做调试口，想想有点作孽。

      尤其是我前两年做充电桩的时候，有大量外设，都要用到串口，但串口这东西又不比485，i2c spi等可以同时挂多个节点，于是当时就给我留下了深深的印象，串口还是挺金贵的。

辛昕

但其实更多的原因是，我以前很无知很天真的认为，串口真的是一个落后了很多世代的通信口，速度又慢。
所以，当时我真的不待见串口。

另一个事件是，还记得前几年我在倒腾什么 uS库没？现在想想，我觉得当时自己除了脑袋抽风还有点，其实就是 纯粹为技术而技术，根本不考虑实际需要，就各种倒腾，还什么 i2c转串口了，独立小板卡做测试了，数据收集了——都是多余，自己臆想出来的需求。

但狗日的是，我居然在这些事情上花了几年的业余时间和思考时间.......

我是在什么时候突然想通这件事情的呢？

辛昕

大概是我各种折腾无用之后，大概是在去年，被free叔叔K了几次以后，有一天我拿起吃灰的 arm linux板子开始倒腾，我当时在搞的是uboot,我看到它说，首先可以用串口看打印信息

我当时犹如被惊雷过电一样，突然在想，万能的Linux，这么先遣部队的uboot都用串口打印消息。

那你呢？你为什么会觉得这么多人都选择一个串口来做调试口，基本输入输出接口，你就不选择呢？
还有，GSM模块也是，尤其华为的323模块，特意留了俩，一个正常AT通道，一个debug通道。

这时我回忆平生一样，回忆一次我过去所有想到的使用其他办法替代串口做测试口的想法里，竟然发现，没有一个办法会比串口简单......

这时我突然
哦
了一声，留个串口就留个串口，不会死人的。

不够，就换个大点的CPU呗，再不行，搞个485呗.......

辛昕

AT THE END...

这件事现在回想起来，除了当时是纯粹给自己的破uS找一个虚假的需求之外，还有一点就是，没有理解，在打印信息这件事情上，绝对没有一件事比一个现成的通信口，尤其这么多年，大家都把串口作为标准的调试口的时候.......

不管我想换成什么更富于的或者可以同时挂接多个节点的其他更现代的数字接口，然后因为事实上串口已经是个标准的调试信息口，所以我不管怎么搞，最后还得来一次转串口......

那么，不管我怎么干，都是脱裤子放屁

——多此一举

lzwml

启动过程用LED
启动完用printf
报警，通过【不同频率】的 蜂鸣器，蜂鸣器其实是个黑科技，蜂鸣器有LED无法比拟的优势。蜂鸣器，我们用在24小时的机房设备项目里。


我只要坐在椅子上，听到蜂鸣器叫立马反应很可能出大问题了，而且还知道报警类型。客户打电话来，他把手机凑近设备旁，我也可以听声音远程定位故障。

蜂鸣器不是简单的“滴”一声，可以通过频率控制，从而发出 do re mi fa so la si do

假如你有5种告警，通过LED去描述，恐怕检测时候程序员也不能第一时间反应过来到底表示什么，

LED我可以简单用 3个音的排列组合去描述就简单很多，理由——就凭借do re mi fa so la si 七个音能创作多少儿歌？难道 3 个音还不能表示5种故障？？

要相信，人耳的分辨率远比视觉来得敏瑞。
做个测试：【比较蜂鸣器和LED的信息容量】
大家都会唱《义勇军进行曲》，如果把曲子上的5线谱（或简谱）等同于LED。
1.  我给你听100首曲子，从中找到《义勇军进行曲》
2.  我给你10小节五线谱，每小节来源不同曲目，每小节8个音符，从中找到《义勇军进行曲》

上面两个挑战有谁认为第二项比第一项简单？？？

辛昕

lzwml 发表于 2017-3-17 14:20
启动过程用LED
启动完用printf
报警，通过【不同频率】的 蜂鸣器，蜂鸣器其实是个黑科技，蜂鸣器有LED无 ...

老衲认为，除非在很极端的不知道什么情况下（而且我认为总是应该想办法回避的）

乃的蜂鸣器，还要听音乐，这比起LED是更大的反社会反科学

是一个很好的反面教材