嘉立创社区
发动态
综合 最新发布 最新回复
图文
列表
立创·地阔星-STM32F103C8T6开发板 拼单
立创·地阔星-STM32F103C8T6开发板 拼单缺1 https://activity.szlcsc.com/group/purchase/product.html?groupPurchaseOrderCode=sve8m9gk7kf79zjxxzf6fz #立创超级会员日#
立创开发板
立创开发板
8件套 立创·泰山派开发板RK3566 2G+16G版本 8人团拼单
https://activity.szlcsc.com/group/purchase/product.html?groupPurchaseOrderCode=fll1b9gk7kf99eMxx9c1ne
立创开发板
庐山派k230运行程序有时候突然卡住一会,然后又恢复
庐山派k230运行程序有时候突然卡住一会,然后又恢复，我复制网页教程的一开始的摄像头显示程序也会出现这种情况，这是为什么[撇嘴]
立创开发板
这几天在跟着学梁山派，B站视频下的评论好少哇[发呆]
立创开发板
衡山派TCP
最近在研究衡山派的无线功能，看到luban-lite里面的kernel-rtthread-examples-network下面有TCPSERVER和TCPCLIENT的代码，但是这个应该如何启用、如何设置不知道，有没有大佬给指点下，谢谢
立创开发板
一谈到编译器的优化等级，很多人都会潜意识的认为:"一定不要开优化，否则会产生意想不到的问题~"，于是就这样口口相传，使得很多后来的学习爱好者都会有意的去回避掉优化等级这个问题。优化其实是多个方面的，就像我们平时不同的人写一个功能模块的代码，有些人写出来的代码运行效率高、可是代码量大；而有些人写出来的代码效率一般，但是比较简洁有效等等。如何选择优化选项也是类似的，编译器会根据你的优化选项内容，按照一定的规则和策略来优化你的代码，比如代码中存在较多无效的逻辑语句，如果不进行优化，那么编译器几乎会根据你所写的语句一步一步进行“翻译”成汇编来执行，这样的运行效率是很慢的，好在现在大部分编译器即使你不开优化等级，也会对你的代码进行或多或少的优化处理。设置了对应的优化等级，编译器会根据你所选择的优化等级，对你的代码进行不同程度的分析，最终从不同的维度来进行优化处理(如代码大小、资源的占用、执行性能等)。那么很多掉过坑的朋友该说了，“有一次编译器开启了优化，不是按照我所编写的逻辑来运行的，于是从那以后我就习惯了不开优化”。其实通常编译器相对我们而言，更加的了解处理器，对于前面那位朋友的问题，更多的还是因为对所用的编译器不够熟悉，编写的代码让编译器"误解"了你的意思，不能完全赖在优化上。还是那句话:"存在即合理"，编译器也仅仅只是一个工具，不要因为驾驭不了，就持否定的态度。反而你所编写的代码如果经不住各种优化等级的考验，是不是可以从侧面反映出当前代码的设计不合理？不够规范？考虑得不够全面呢？实际项目中让程序代码在所有优化等级下都可以正常运行来检查各种奇葩问题，也是一种检验代码健壮性的有效手段。GCC毕竟是嵌入式领域广泛应用的编译器，下面便以GCC编译器为例讲解一下相关优化选项：(其他编译器略有差异，注意区分)1、GCC的优化选项通常我们使用到-Ox选项，其中x有:0、1、2、3等，随着数值的增加，优化的程度也是逐步增加。-O0通常是不对代码进行优化，或者是最简单的一些优化，跟源码执行顺序基本是一致的，也比较方便单步调试，所以其不需要过多的分析代码，编译速度也是相当快的，debug阶段通常用该优化项，等代码稳定以后，再考虑其他的优化项。-O1主要是一些基础类的优化，比如删除一些无效的代码、展开内联函数等，能够在一定程度上提高运行效率。-O2在O1基础上进一步优化，比如循环优化、函数跳转优化等，编译相对较长，且代码的大小也会有一定增加。-O3在O2基础上更进一步优化，比如循环展开、向量化等。通常使用-O3优化较少，因为其优化程度较高，带来的逻辑风险也相应的提高，而-O2是一种比较折中的选项，基本满足要求，且比较安全可靠。除了上面常见的集中，当然你也可以使用其他更加精细化的选项，来自己控制优化的内容，具体就要参考GCC的相关手册来了解使用了。2、GCC部分代码设置编译选项有时候一套代码中有部分代码需要进行不一样的优化策略处理，那么通常编译器可以设置某些函数进行优化、或者某些文件进行优化的设置等。下是GCC部分代码使用固定的-O0进行优化#pragma GCC push_options #pragma GCC optimize ("O0") void foo(void) {     /* Do something, but don't optimize this function */ } #pragma GCC pop_options 当然，如果当你怀疑相关问题与优化等级的选择相关，可以采用这种方式，把部分可以代码进行非优化状态来运行，从而缩小问题的排查范围。3、优化等级越高越不好调试特别是玩单片机的同志们，习惯了使用调试器来进行单步调试，如果你想让代码编译以后易于调试，那么编译后的执行逻辑与源码所编写的执行逻辑基本上要吻合，此时代码就不能有优化处理了。所以如果你是为了获得更高的性能、更小的代码空间、甚至是编译时间，我们会选择进行优化，必然就会牺牲易于调试这一点。这也是很多朋友开了优化等级以后，单步调试断点到处乱跳的原因。所以通常我们在前期调试的时候不使用任务优化选项，而到了需要进一步优化代码大小、效率等以后再考虑开启优化等级。4、两个C关键字特别重要1. volatile 关键字volatile 关键字能够阻止编译器的过度优化，可以做到如下两件事情： · 阻止编译器为了提高速度将一个变量缓存到寄存器而不写回； · 阻止编译器调整操作 volatile 变量的指令顺序；2. register 关键字将代码放在寄存器的方式是使用 register 修饰变量，适用于频繁调用的变量。
单片机程序开发把优化等级直接拉满吧~~
立创开发板
MPU6050复位过不去
#TI#， #MPU6050# 我在将mpu6050移植到TI的mspm0g3507的时候，一直没办法复位，我是根据立创的https://wiki.lckfb.com/zh-hans/dmx/module/sensor/mpu6050-six-axis-sensor.html进行修改的。
立创开发板
#ESP32-S3# 谁有这个立创开发板的小智扩展电池的那个开源项目链接呢 找了好久都没有找到[大哭]
立创开发板
大家好，我是bug菌～对于一些需要动态存储数据的嵌入式系统往往我们需要考虑系统在各种状态的数据可靠性问题。当然也不仅仅这些数据敏感的协议，最常见的就是你向存储系统写入数据的过程中给断电了，系统下一次上电跑飞了~掉电过程是最为敏感的情景，也是一般在系统设计前期要重点考虑的，那么今天bug菌就跟大家重点聊聊一般的嵌入式系统如何尽可能的避免重要存储数据的丢失与损坏。1、掉电检测  前面也提到了，掉电过程是数据丢失和损坏比较高发的状态，一方面离不开硬件上掉电备电电源的相对稳定性和持久性，另一方面也需要软件部分最好掉电过程系统完整的收尾工作，最常见的问题就是正在掉电，你还在使劲的写文件或者其他改变存储介质的操作，运气好可能只是文件写少了；运气不好直接文件系统就崩溃了～那么快速的掉电检可以帮助系统在断电前尽早将这些数据进行保存，以确保系统重新上电后能够恢复到正常工作状态，而不会因为掉电导致数据丢失或损坏。2、存储器件的寿命与稳定性电子产品都有使用寿命，在嵌入式设备里面常用闪存存储器，即Flash，而闪存通常以擦除/写入循环次数（P/E cycles）来衡量其寿命。常见的闪存产品如NAND和NOR闪存都有固定的P/E周期数量，一般在几千到几十万次之间，所以如果频繁擦写就会导致损坏，最终也会使得数据丢失，另外，闪存的寿命还受到温度、电压以及擦除/写入操作的影响。所以为了减少存储介质上的数据丢失要么选择高品质且可靠的存储介质，要么根据介质的特点优化存储算法，延长使用寿命。那么通常在软件层面有如下几种软件处理方法和策略：磨损均衡在闪存中，频繁写入相同的块会导致这些块的寿命提前耗尽，从而降低整个存储器的寿命。磨损均衡算法旨在平衡闪存中不同块的使用次数，避免某些块过早失效。可以通过选择写入次数最少的块来进行新数据的写入，或者通过重新映射块来实现。垃圾回收当删除或更新数据时，闪存中会产生垃圾数据，占用空间而无法直接写入。垃圾回收算法会定期检查闪存中的垃圾数据，并将其重新组织以释放可用空间。有效的垃圾回收算法可以减少擦除操作的频率，从而延长闪存的寿命，当然如果你没有用文件系统，只是裸写，基本上都是按顺序去写了。坏块管理坏块管理指的是处理闪存存储器中出现的无法正常读取或写入数据的坏块的过程。通过坏块检测、标记和替换，系统可以有效地识别和处理坏块，确保数据的完整性和可靠性。坏块管理还包括维护坏块映射表，以记录坏块的位置和替代块的使用情况。有效的坏块管理可以延长闪存存储器的寿命，提高系统的可靠性，并确保数据安全。写入放大减少写入放大指的是实际写入闪存的数据量与应用程序请求的数据量之间的差异。减少写入放大可以减少对闪存的写入操作，从而延长其寿命。这可以通过合并小的写入请求、延迟写入、以及数据压缩等技术来实现。静态和动态数据分离将静态数据（很少修改的数据）与动态数据（频繁修改的数据）分开存储在不同的闪存块中。这样可以避免频繁写入对静态数据块的影响，延长其寿命。温度和电压管理通过一些辅助的采样。来调节读写负荷，维持在合适的工作温度和电压可以减少对闪存的损坏和老化，从而延长其寿命。3、数据备份对于数据动态存储非常严格的应用需求场合，保证嵌入式设备的实时数据存储稳定性是非常重要的，特别是对于需要高可靠性和实时性的应用场景。以下是一些办法来确保嵌入式设备的实时数据存储稳定性：实时数据备份实时将数据备份到多个分区或者其他位置，例如本地存储和远程服务器，即是一块区域物理上遭到破坏，也能从其他区域进行恢复，极大的降低了数据丢失或损坏的概率。使用事务性存储机制采用具有事务性支持的存储机制，确保数据的原子性操作，即要么全部写入成功，要么全部失败，以避免数据不一致性，以免存在第三种状态完成系统的混乱与破坏。实时监控和错误处理建立实时监控系统来检测存储设备的健康状况，及时发现并处理存储设备的故障或错误，以前bug菌就接手到一些项目，写数据出了问题，好几天系统也没有提示，客户也没有及时查看，等发现问题已经好几周的数据异常了。采用更加成熟的文件系统一些支持掉电保护的实务型文件系统基本都支持日志功能或者文件系统级的保护机制。数据完整性校验实施数据完整性校验机制，例如循环冗余校验（CRC）或者哈希校验，来检测存储数据的完整性，及时发现和纠正数据损坏。
嵌入式系统如何尽可能避免存储数据丢失与损坏？
立创开发板
大部分开发工具或者IDE中都为你创建的工程配置为debug和release两个版本，字面上很好理解，一个用于调试debug，一个用于发布release，那么是不是很多伙计都是debug版本用到老？那么今天聊聊release的必要性吧。1、两个版本的通用解读在大型嵌入式应用软件开发中，如linux应用程序，这两个版本类型主要针对软件开发在不同阶段的构建过程的一些优化和设置，当然这些优化设置也是可以更改的。Debug版本主要是于开发和调试阶段，你所编写的软件通常被编译为未经优化的代码，以便于调试和排查。编译器会保留大量的符号信息、调试信息和原始代码结构，以便于在调试器中查看变量、函数调用栈等详细信息，有助于开发人员快速定位和解决问题。而对于release版本，经过了各种优化，以提高代码的执行效率和减小代码体积，比如去除未使用的代码、内联函数、循环展开、常量传播等，这样会使得程序具有较高的性能和较小的内存占用，适合于在实际运行环境中使用，但这也会大大削减一些调试信息和辅助检查。在大型OS上运行的应用程序所使用的两个版本均有如上特点，但对于单片机固件却有所差异，但也非常相似。2、单片机两种版本的特殊对于单片机软件系统中，这两个版本上的配置相对比较单纯点，主要是如下三个方面:1、优化级别：Debug版本通常使用较低的优化级别，例如-Og（优化以便调试），以便在调试过程中能够更好地观察变量的值和程序的执行流程。这种优化级别保留了较多的符号信息和原始代码结构，有利于开发人员进行实时调试和故障排除。Release版本则会使用更高的优化级别，例如-O2或者-O3（最大优化级别），以提升代码的运行效率和固件的性能。高优化级别会进行函数内联、循环展开、删除未使用的代码路径等操作，当然你也可以更细粒度的进行优化项目的设置，从而最大程度地优化代码的执行速度和资源利用率，但也会在一定程度上干扰开发软件对于程序与执行过程的对应分析。2、调试信息输出Debug版本通常会让程序中较多的debug_printf生效，这些打印调试信息不仅仅有第三方组件，还有一些自定义的调试信息，这样可以在一定程度上让开发人员更加直观的了解程序运行流程和结果，但也同时会导致程序执行负荷较高，体积变大。3、安全检查和错误处理：基本上也就是我们说的断言了，其实它就是在程序运行时检查程序中的某个条件是否满足预期，如果条件不满足，则程序会进入一个错误处理流程，通常是通过打印错误信息并可能进行一些清理工作后停止运行，如下代码示例:#include stdio.h#ifdef NDEBUG #define ASSERT(expr) ((void)0) #else#define ASSERT(expr) ((expr) ? (void)0 : assert_fail( __FILE__, __LINE__ )) #endif void assert_fail(const char* file, int line) {     printf("Assert failed at %s, line %d ", file, line);     while (1); // 可以添加清理代码，例如锁定资源，然后停止执行 } int main() {     int x = -1;     ASSERT(x > 0); // 这里的断言会失败，会调用assert_fail函数     return 0; } 所以当断言较多的时候，每个函数基本上都会对输入进行检查，执行效率可想而知。3、两个版本的必要性一般的公司基本上都只有一个debug版本，特别是单片机固件开发的项目更为突出。当然为了减少开发周期、又想保证产品功能的稳定性，处理器相对裕量较大，一直使用debug版本也不是不行，毕竟很多公司这些年就这么过来的，总比有些工程代码编译出来的release直接就飞了，还不知道怎么飞的好太多了，公司产品又急着上线，客户又要求快速解决，确实不容易；debug版本丢到现场，出了问题有日志，日复一日，终可修护稳定。不过从开发角度两个版本还是非常有必要的~release执行效率的提高、代码固件的压缩能够进一步降低核心主控的成本，同样对于执行效率敏感和内存资源受限的平台还是非常有用的，而且专业软件公司都会有单元测试与集成测试的开发与使用过程，release软件的稳定性能够得到较好的测试保障。同时debug版本通常比release版本更容易被反向工程，debug版本保留了大量的符号信息、调试信息以及原始代码结构，这些信息对于逆向工程者来说提供了更多的线索和可操作性。而且你打印了较多的调试信息，对于友商开发工程师而言也是很好的参考资料，相关功能也推敲个七七八八。当然话说回来，如果所开发的产品都是定制的话，并不需要去市场上争蛋糕，其实这块优势也会弱化。所以在软件稳定并且即将部署到目标设备时，尽量切换到Release版本，值得注意的是这里的release不是你测都没测，直接切换选项卡生成的版本，而是稳定发布版。正确选择和管理Debug版本和Release版本，能够有效地支持整个嵌入式软件开发生命周期的各个阶段。
大部分公司的嵌入式软件只有debug版本
立创开发板
#立创开发板# 泰山派2+16版本, 到手之后直接刷了ubuntu固件[ubuntu20.04_hdmi_20231130_update.img], 开机直接安装软件就报错, 提示是依赖有问题, 但是无法安装依赖, 已经尝试 sudo apt update 和 upgrade
立创开发板
今天主要是大家聊聊设备唯一标识符：1、聊聊唯一标识符早期大部分芯片都没有唯一设备标识符UID，英文叫Unique ID，现在去查查其实很多芯片现在也没有唯一标识，然而随着芯片成本降低，功能上大家基本都对齐了，新推出的芯片都会有一个唯一标识码，通常这个编码在芯片制造的过程中就生成了，用户通常读取固定地址或者调用相关API即可轻松获取。当然了这些UID通常不是随机的，都有一定的规律，比如标识制造商、批次、芯片型号等等，所以通常厂商会根据UID的部分字段做一些功能的区分。有一点一定要注意:对于相同型号的芯片，其UID通常是唯一的，但不同型号的芯片，尽管是同一家公司，其UID也有可能不是唯一的。因为之前遇到过这个问题，所以特意提示下，这一点一些人容易有惯性思维。2、UID有那些应用？那么唯一标识符到底有啥用处呢？字面上那肯定是为硬件设备提供唯一性，以便区分罢了，但具体涉及到哪些方面会要用到唯一标识区分呢？下面我总结了几个方面:1、产品唯一标识许多不同的设备可能会共享同一种硬件平台，每个设备都分配一个唯一标识符，系统可以确保每个设备在全球范围内都是唯一的，避免了设备间的冲突。像现在许多的IoT设备，其中的每个传感器或控制器可以通过唯一标识符进行识别和管理，这对于设备的监控、配置以及后续维护是非常重要的。2. 设备身份认证在一些需要身份验证的应用场景中，唯一标识符可以作为设备认证的一部分。在系统初始化或进行安全通信时，通过标识符验证设备的合法性，从而提高安全性。现在有很多的智能家居的产品，所有设备（如智能门锁、摄像头等）在联网时可以使用唯一标识符来进行身份认证，这些标识符提前录入了系统，确保只有经过授权的设备能够接入系统。3. 版本控制和固件更新通过设备的唯一标识符，厂商可以为特定设备提供定制化的固件更新或配置管理。这样一来，即使是相同型号的多个设备，也可以根据其唯一标识符来执行不同的操作或更新。4. 系统完整性绑定多个设备的唯一标识符可以进行捆绑，当检测到标识符不匹配可以进行报警提示，防止系统被拆解，从而带来的一系列混乱、不匹配问题。5. 软件许可和防盗唯一标识符可以作为本地软件运行的一种许可管理和防盗机制。设备唯一标识符可以与授权许可绑定，也就是相当于一种密钥，防止不法商家盗版软件的使用或设备被非法复制。通过唯一标识符与授权信息绑定，厂商可以确保只有授权的设备才能使用特定功能，防止盗版设备影响正常运行。
芯片的唯一标识符有什么作用？
立创开发板
大家好，我是bug菌，又见面了~最近在做设计评审时，下面工程师在对用UDP和TCP中展开了激烈的讨论，而一个同事发表了这样的观点:"能用TCP绝不用UDP，UDP实在是太不靠谱了~"说实在的我也很理解，但是对于这样的言论也容易误导人，导致很多初学者在尝试使用UDP设计的时候，只要出现一些埋得比较深的问题就会一棍子把UDP给拍死，这是我觉得不应该的。其实UDP并没有那么不靠谱。1、UDP数据包首先我们看看UDP的数据包格式，数据内容本身的正确性是由UDP的**校验和（Checksum）**机制保证的：如果数据包在传输中发生比特错误（如电磁干扰），接收端会直接丢弃该包，不会将错误数据传递给应用层。然而UDP的“不可靠”主要是如下三点：不保证数据包到达（可能丢包）不保证顺序性（可能乱序）不主动控制发送速率（可能拥塞丢包）所以有些数据错乱问题的过，真不该让UDP来背，往往有时候就是自己设计的应用层逻辑设计不当。比如下面常见的一些场景：场景1：乱序未处理• 问题：接收端先收到后发送的包（如视频流的第2帧早于第1帧到达）。• 根因：应用层未实现乱序重组逻辑，直接按接收顺序处理数据。• 改进：在数据包头部添加序列号（Sequence Number），由应用层缓存并排序。场景2：分包/合包逻辑缺失• 问题：发送端传输了超过MTU的大数据包，IP层自动分片，但接收端未正确处理。• 根因：应用层未实现手动分包/合包逻辑，依赖IP分片（可靠性差）。• 改进：在应用层主动将大数据拆分为≤1472字节的块，并为每个块添加序号和偏移量。场景3：未区分丢包与延迟• 问题：误将延迟较高的包视为丢失，导致逻辑错误。• 根因：未设置合理的超时重传机制。• 改进：为关键数据添加ACK确认与重传，非关键数据允许丢弃（如实时音视频）。2、丢包原因其实UDP的丢包主要还是与网络环境有关，网络拥塞：路由器缓冲区溢出时，UDP包被优先丢弃（TCP会主动降速，UDP不会）。链路质量差：无线网络（如Wi-Fi、4G）易受干扰，物理层丢包率上升。IP分片丢失：若数据包超过MTU被分片，任一碎片丢失会导致整个UDP包不可用。虽然会丢包，但丢包 ≠ 数据错乱， 丢包只会导致部分数据缺失（如视频卡顿、语音中断），不会破坏已接收数据的正确性，数据内容错误，已被UDP校验和过滤。3、可靠的UDP协议设计从前面UDP的结构大家就知道，其实它挺简洁的，UDP既然不解决这些问题，那就应用层去弥补，说实在有更多的灵活度。UDP应用层需解决乱序、完整性、丢包三个问题就本上就比较靠谱了。比如传输协议中增加一些字段:| 序列号 (4B) | 时间戳 (4B) | 载荷长度 (2B) | 载荷数据 (N B) | 为了处理乱序、重复、丢包检测等问题。对于一些关键数据添加ACK确认与重传，一些实时数据丢包了也没关系，就不需要应答了~最好是避免IP分片，控制数据包大小≤1472字节（假设MTU=1500），大数据传输时，主动在应用层分包并添加序号。如果你加快异常时的收发效率，可以采用前向纠错（FEC），通过发送冗余数据包，允许接收端通过算法恢复部分丢失数据（如RTP协议中的FEC机制）。
UDP通信哪有那么不靠谱呀~
立创开发板
我刚刚按照嘉立创天猛星入门手册配置了一下，配置界面可以出来但是编译的时候报错了。这是怎么回事？
立创开发板
安装的下单助手 ，从下单助手打开的EDA专业版，请问助手里的EDA是最新版本还是？没有单独安装EDA
立创开发板
跟大家介绍一下C编程十诫，这10条建议是作者Henry Spencer提出来的，bug菌也是在不经意间看到了这10条建议的英文文档《The Ten Commandments for C Programmers》，今天翻译了一下，并做了批注，供大家学习参考:1、你应该经常运行 lint 并仔细研究它的声明，因为它的感知和判断确实经常超过你的判断力。（bug菌:尽量能够使用一些静态检测工具，这样通过自动化测试代码能够发现非常多潜在的错误，并且能极大地减轻测试人员的压力，减少软件项目的出错成本，重要的是这些工具的能力可能是我们平常达不到的。）2、你不能跟随 NULL 指针，因为混乱和疯狂在它的尽头等待着你。（bug菌:不要使用空指针NULL，他会使得比较混乱。）3、你应该将所有函数参数转换为预期的类型，即使它们已经不是那种类型，即使你确信这是不必要的，以免它们在你最不期望的时候对你进行残酷的报复。（bug菌:函数传参有时候一些编译器并不要求完全匹配仍然可以编译通过，不过最好是养成传递给函数的实参与形参保持一致，以免出现移植等问题。）4、如果你的头文件没有声明你的库函数的返回类型，你应该非常小心地自己声明它们，以免严重的伤害降临到你的程序上。（bug菌:注意函数声明的返回类型，以免引入bug。）5、你应该检查所有字符串（实际上是所有数组）的数组边界，因为肯定在你键入的地方，“foo”有一天有人会键入“supercalifragilisticexpialidocious”。（bug菌:数组越界一定要注意一下，C语言编程比较容易犯错，特别是初学者，加上一些编程中的防御性设计。）6、如果一个函数被声明为在遇到困难时返回错误代码，你应该检查那个代码，是的，即使检查是你的代码大小的三倍并且会让你的打字手指疼痛，因为如果你认为“这不可能发生在我身上”，众神一定会惩罚你的傲慢。（bug菌:函数异常返回需要认真对待，并且对于异常需要进行相应的处理，比如动态内存的释放等等。）7、你应该研究你的库，努力不无缘无故地重新发明它们，这样你的代码就可以简短易读，让你的日子愉快而富有成效。（bug菌:最好是自己整理一些可移植的库代码，以后直接拿来用提高效率。）8、即使你不喜欢，你也应该通过使用 One True, Brace Style 让你的同伴清楚你的程序的目的和结构，因为你的创造力更好地用于解决问题，而不是创造美丽的新障碍来理解。（bug菌:代码的结构和风格比较建议大家遵循 One True, Brace Style，通常也叫(1TBS)，以免由于风格和代码结构混乱引入一些问题。）9、你的外部标识符在前六个字符中应该是独一无二的，尽管这种严厉的纪律会让一些人感到厌烦，而且它的必要性在你面前似乎永无止境地延伸，以免在你希望让你的程序在旧系统上运行的那个决定性的日子里撕破你的头发并发疯。（bug菌:代码的结构和风格，比较建议大家遵循 One True, Brace Style，通常也叫(1TBS)，以免由于风格和代码结构带来一些混乱。）10、你应摒弃、放弃声称“整个世界都是虚无缥缈”的邪恶异端，并与坚持这种野蛮信仰的愚昧异教徒没有任何往来，你写程序的日子可能会很长，即使你当前机器的日子很短。
嵌入式C语言编程十诫
立创开发板
立创开发板
去官网查看
立创开发板不靠卖板赚钱，以培养中国工程师为己任
推荐话题 换一批
#嘉立创PCB#
#DIY设计#
#嘉立创3D打印#
#畅聊专区#
#嘉立创免费3D打印#
#创享2025#
#618金豆嗨购节#
#高校动态#
查看更多热门话题
打赏记录
激励规则
粤公网安备44030002004666号 · 粤ICP备2023121300号 · 用户协议 · 隐私政策 · 侵权举报 · ISO/IEC · Copyright © 2024 嘉立创社区版权所有
服务时间：周一至周六 9::00-18:00 · 联系地址：中国·深圳（福田区商报路奥林匹克大厦27楼） · 媒体沟通：pr@jlc.com · 集团介绍
移动社区
联系我们