作为一名理工科技男，我要说的就是我大学期间的社死事情。在大三的时候我们学校的传统就是会请许多的培训机构来讲课，扩充我们的实际操作经验，书上的知识还是比较单一老套的。
在培训机构来讲课的时候和上课不同，他们主要以一个项目为切入点，提供设备与讲师，首先让我们学习基础的知识，比如linux的操作，如何编译硬件文件，还有使用到的一些硬件知识等等，我们一开始并不会做这些东西，非常的费事费时，后面四天都是辨学边做，实际上听懂的不是特别多只是大概了解了开发流程。
到了做后一天要我们做一个上课期间学习的作品，并且要用PPT来讲述过程，而我是非常不善于做这个工作的，但是又没有技术，我们就一直进行代码修改等工作，把一些好玩的图片加在里面，比如说小猪佩琪，这样做PPT就更加尴尬了，最后只能保证自己不笑场讲完整个PPT，做完的项目，想想都挺社死外加抠脚趾了

大佬大佬！

第一次接触安信可还是在工作中需要用到无线远程控制相关的项目中，那也是第一次学习物联网，本来是想通过433或315的遥控方式来处理，后来看到报道有带wifi的模块，价格也很便宜，于是就买来模块开始研究，我记得那时还是使用AT命令来控制，后面在深入，可以把模块当成单片机进行编程，确实对于物联网来说上手简单得多，希望后续能用到更强大的安信可模块。
后期通过在安信各种学习，花巨资组装一台3D打印机，为技术路添砖加瓦………………

登录/注册后可看大图

登录/注册后可看大图

登录/注册后可看大图

登录/注册后可看大图

学习，开发，一起跑起来

在烧录单片机时遇到问题无法成功的情况下，首先需要确认串口与单片机板子连接是否正确。然后，确保选对了正确的芯片型号，并装载了程序。接下来，拔掉VCC（电源）并按下烧录按钮，然后再将VCC重新接上。有些较旧的单片机需要进行冷启动，否则无法成功烧录程序。

对于初学者来说，经常会遇到这些问题。耐心地检查并查找解决方法，可能会有其他人告诉你需要进行冷启动。虽然他们没有具体说明如何操作，但你可以通过百度等搜索引擎来寻找相关的操作方法，这样问题就能很快解决了。

我热衷于电子技术和编程，并希望通过自己的努力创建一个可以控制家庭设备的智能系统。

我开始从头学习各种电子元件的原理，并购买了所需的组件和开发板。我还研究了各种传感器和通信协议，并用心编写了一些程序代码。

一切看起来进展顺利，我准备开始组装和测试系统。但是，在测试阶段，他遇到了一系列问题。

首先，我安装了一个温度传感器，这个传感器应该能够读取室内温度并发送数据到控制中心。然而，当我接线完成后，传感器并没有正确工作，我无法得到正确的温度读数。我检查了所有的连接，并重新焊接了一些连接，但问题依然存在。

接下来，我尝试连接家庭灯光系统。我编写了一个程序，打算通过智能手机应用控制灯光的开关和亮度。然而，当我尝试连接系统时，我的应用程序无法与灯光系统通信。我再次检查了所有的连接和程序代码，但问题仍然无法解决。

我感到非常沮丧，但并没有放弃。我继续查阅资料，尝试不同的解决方案。然而，我的努力没有取得显著进展，问题仍然困扰着我

最后，我决定向一些经验丰富的电子爱好者寻求帮助。他在一个电子论坛上发布了我的问题，并详细描述了我所做的一切。很多人给予了我建议和指导，提供了一些可能的解决方案。

在经过进一步的尝试和错误后，我最终找到了问题的根源。原来我在连接传感器和灯光系统时犯了一些简单的接线错误，导致系统无法正常工作。

通过重新布线和一些简单的调整，我终于得以修复我的智能家居系统。虽然我经历了许多困难和挫折，但最终我成功地实现了自己的目标。

焊接电路板不可缺少的就是电烙铁加热台和热风枪，电烙铁与加热台是在立创开源平台都有，我选择了小q的加热台进行焊接，一开始是拿我八块钱的电烙铁进行焊接，虽然不是很雅观，但勉强算是焊接上去了，但是没想到电脑弹出了超过最大电压进行了usb口保护，让我备受打击，然后我明白了想要拥有一个加热台就必须先买一个加热台，买了鹿仙子的加热台进行了焊接，这一次十分成功一次点亮，后又焊接了5块加热台电路板，但是不知道为什么3块正常俩块电压从50v开始下降，询问了许多人，最终得出结论是电路板的锅，焊接的过程中虽然遇到了种种困难但也学习到了许多知识，十分快乐。

当我回顾我的电子工程师生涯时，有一次特别让我感到成就满满的经历，那是我处理一个古怪的问题的故事。

在某个项目中，我们的设备一直遇到不明原因的崩溃问题。这些崩溃似乎是无规律的，让我们感到非常头疼。我们检查了电源、焊接、芯片，但问题依然存在，简直像是捉鬼一样。

在数周的努力后，我和我的团队决定尝试一种不同的方法。我们开始使用高级的调试工具，监视设备的各个部分，并记录崩溃时的数据。经过一段时间的监测，我们发现了一个有趣的现象：每次崩溃都伴随着电源电压的微小波动。

这个发现让我们怀疑电源可能存在问题。我们深入研究了电源电路，最终发现了一个微小但致命的设计缺陷。一个电容器的数值选得不当，导致电源电压在某些情况下波动，触发了设备的崩溃。

我们更换了电容器，重新测试设备，而这次却没有再出现崩溃问题。这一时刻让我感到极度的满足和成就，因为我们通过耐心的调试和坚持解决了一个看似无解的问题，而这个问题一度威胁着整个项目的进展。

这个经历教会了我一个宝贵的教训：在电子工程领域，解决问题往往需要创造性的思维和坚持不懈的努力。当我们终于看到设备稳定运行时，那种成就感是无法言表的。这正如莫泊桑所说，生活中有挑战，但克服困难后的成就感是无与伦比的。

电子工程每天过得都很固定。
焊板子，盯示波器，捶桌子。
现在是在一家开发半导体设备的公司上班。半导体生产属于一个比较老的行业，从上世纪50年代左右的仙童公司开始，到如今的因特尔，三星，台积电等，这些公司也是我们的客户。当然单位时间内的芯片生产数量也可以通过增加生产设备的"运行速度"来提高。
所以，缩小工艺尺寸、提高设备的"运行速度"就变成了每一个半导体人所共同追求的目标，不管是做工艺的还是设计设备的。
不像搞互联网的，产品迭代的速度很快。为了让这些小单位的电流电压的电路稳定运行，通常需要大量的实验和多次的改版。所以我们的工作很磨人，简单的一个采样电路可能就要调试一年，电阻的温飘和热燥声等影响也不再可以忽略。
经常会因为莫名其妙的电路噪声变得躁动不安，所以日常的工作就是右手拿电烙铁，盯着示波器显示屏，并用左手捶桌子。
早上八点到公司找停车位，停好车上楼，到工位放下包，捅开电脑，然后去茶水间打一杯咖啡，然后回自己的工位，打开一包消化饼咖啡兑三元特品(一定得是保质期四天的那种巴氏奶)喝完，电脑就启动的差不多了。
打开ol，把未读邮件全部设置为已读，找出那些直接to我的，点开随便看看，心情好的话回复一下，心情不好的话直接转给一个小弟处理。等到九点半，第一个项目每日站会开始（对的，没错，就是敏捷开发的那种每日站会），戴上耳机，挂上会大概听一下项目进度，然后是项目经理m工程师，工程师嘬牙花子。

提交四五次，一直说我有不良信息，实在不知道怎么回事，只能删减篇幅了。

### 说一下最无语的一个开发经历吧，之前开发一个智能家居的WiFi模组，具体哪家的就不说了，用到的主要功能就是`UART,WIFI,MQTT,BLE`等功能，大体流程是是手机通过蓝牙将配网信息发送给WiFi模组，WiFi模组连接上网络后将串口数据通过MQTT发送到平台，同时还可以将平台的数据通过`UART`发给设备，实现远程控制的目的，开发过程中简直就是一步一个坑啊： ## UART： ### `UART`部分初始化代码如下（省略一些配置）： ``` int uart_getchar(char *inbuf, int *len) { if (inbuf == NULL) { os_printf("inbuf_null\r\n"); return 0; } while (bk_uart_recv(UART_DEMO_POART1, &inbuf[*len], 1, BEKEN_WAIT_FOREVER) == 0) { if (*len >= IN_SIZE)//每次中断读取最大量为19字节，长数据会多次触发 连续读取，以下为数据长度判断 { *len = 0; overflow = 1; return -1; } if (overflow == 1 && inbuf[*len] == '\r') { os_printf("Error: input buffer overflow\r\n"); *len = 0; overflow = 0; return -1; } if (inbuf[*len] == '\n')//以回车判断数据结尾 continue; if (inbuf[*len] == '\r') { inbuf[*len] = '\0'; *len = 0; return 1; } (*len)++; } return 0; } ``` ``` static void uart_recv_sema_callback(int uport, void *param) { uint32_t cont = bk_uart_get_length_in_buffer(UART_DEMO_POART1); os_printf("bk_uart_get_length_in_buffer:%d\r\n", cont); rtos_set_semaphore(&rx_sema); } void uart_dome_init(void) { int ret = -1, cont = 0; char rbuff[IN_SIZE] = {0}; bk_uart_initialize(UART_DEMO_POART1, &demo_uart1_config[0], NULL); rtos_init_semaphore(&rx_sema, 32); bk_uart_set_rx_callback(UART_DEMO_POART1, uart_recv_sema_callback, NULL); while (1) { if (rtos_get_semaphore(&rx_sema, BEKEN_WAIT_FOREVER) == kNoErr); { ret = uart_getchar(rbuff, &cont); if (ret == 1) { ret = 0; demo_uart_test_send(rbuff, cont); cont = 0; } } } } ``` ### 从demo上看初始化了一个回调函数`uart_recv_sema_callback`，以为时串口接收完成一段数据会进入回调，其实不然。长度小于21的数据进一次回调，超过21的会进回调多次，也许就是初始化信号量数量为32的原因。由于串口协议没最后的回车换行，所以用这个demo无法判断数据结束，使用串口发给模组发一组数据日志如下： ``` bk_uart_get_length_in_buffer:21 bk_uart_get_length_in_buffer:41 bk_uart_get_length_in_buffer:61 bk_uart_get_length_in_buffer:81 bk_uart_get_length_in_buffer:101 bk_uart_get_length_in_buffer:121 uart rx fifo full bk_uart_get_length_in_buffer:128 ``` ### 由于发送数据超过了128字节（RX FIFO最大128字节），日志里面有底层输出`uart rx fifo full`，最大就只能接收128字节。这样子主循环里面会多次收到信号量，进行多次循环，与开发需求不符，稍作修改如下： ``` int uart_getchar(char *inbuf, int timeout) { uint8_t length = 0, length_1 = 0; for(int i = 0; i <= timeout; i ++) { length_1 = bk_uart_get_length_in_buffer(UART_DEMO_POART1); if (length_1 == length) { i ++; } else { i = 0; length = length_1; } rtos_delay_milliseconds(1); } bk_uart_recv(UART_DEMO_POART1, inbuf, length, BEKEN_NO_WAIT); return length; } ``` ``` void uart_dome_init(void) { int cont = 0, timeout = 3; char rbuff[128] = {0}; rtos_init_semaphore(&au_rx_sema, 9); bk_uart_initialize(UART_DEMO_POART1, &au_uart_config[0], NULL); bk_uart_set_rx_callback( UART_DEMO_POART1, au_rx_callback, NULL); bk_uart_send(UART_DEMO_POART1, "1234567890ABCDEFGHIJKLMNOPQRSTUVWSYZ", 36); while(true) { if (rtos_get_semaphore(&au_rx_sema, BEKEN_WAIT_FOREVER) == kNoErr) { cont = uart_getchar(rbuff, timeout); os_printf("uart cont:%d\r\n", cont); if(0 != cont) { print_hex_dump("UART:", rbuff, cont); } } } } ``` ### 给模组发数据日志如下： ``` bk_uart_get_length_in_buffer:21 bk_uart_get_length_in_buffer:41 bk_uart_get_length_in_buffer:61 bk_uart_get_length_in_buffer:81 bk_uart_get_length_in_buffer:101 bk_uart_get_length_in_buffer:121 bk_uart_get_length_in_buffer:121 uart cont:121 UART:31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 uart cont:0 uart cont:0 uart cont:0 uart cont:0 uart cont:0 uart cont:0 ``` ### 现象：还是会进中断多次，可以自动判断数据结束，一次发送数据不能超过128字节，遵循`能用就行`的原则，暂且先这么用，屏蔽掉回调里面的日志就可以了。后面如果有发送是数据量比较大的情况可以更改一下``uart_getchar``的逻辑。中间也做过一些其他的尝试，例如使用``OSStatus bk_uart_recv( bk_uart_t uart, void *data, uint32_t size, uint32_t timeout );``超时机制，无论`timeout`设置为多少，现象都是一样，查看源码才发现该参数直接没有用，没有用，没有用。还有就是API手册和SDK根本对不上，对不上，对不上。 ## WIFI: ### WiFi连接过程中有时候带汉字的WiFi名称连接不上，查看demo发现在连接之前有个UTF-8的转换：  ### 就是这个函数，通过蓝牙发过来的数据编码格式就是`UTF-8`，这里再转换一下反而出错了。将蓝牙发过来的数据格式改成`GB-2312`或者将此处的转换删除即可。 ### 简直了，以后选型模组还是需要先看下资料是否齐全，省的全网都找不到资料，只有一个多年没有维护的API手册还与SDK对应不上，开发过程极其不爽。