- 博客(226)
- 资源 (13)
- 收藏
- 关注
RSS订阅
原创 软件架构及几种典型框架
什么是软件架构？什么是软件框架？很多时候，我们常常会混用架构和框架这两个词。实际上，广义上的架构和框架在概念上有很大的不同，架构给人的感觉，包容上更大，所以实际上架构是包含了框架的概念的。广义的架构应为一个系统的架构，不仅仅涉及软件中的技巧，更有系统的观念与视角在其中；不仅要考虑代码的因素，更要布局非代码的因素；不仅仅有技术的内容，更有管理的内容在其中。而为了便于讨论，这里的架构很多时候是指狭义上的纯技术上的架构，我们根据表达需要，将其与框架混用。就单纯的框架而言，其核心是抽象。抽象就是统......
2021-08-11 21:44:51
17323
9
原创 基于多进程架构的嵌入式软件框架研究与实现
摘要：本文针对中高端嵌入式软件产品的开发，提出了一种多进程的开发框架。使用该框架，可以实现多人并行开发，加快产品开发周期，提供产品稳定性，是一种有益的尝试。关键字：框架 多进程 嵌入式软件0 引言伴随着计算机软件技术的发展，嵌入式软件开发也在不断的变化更新。软件的发展离不开硬件的进阶。从早期的51单片机到高性能的dsp芯片再到当今基于ARM的高性能soc芯片遍地开花，嵌入式硬件的发展经历了快速化高性能化低功耗化，普适化，多核化发展，甚至当今部分soc芯片的性能已远远高于早..
2021-08-05 22:04:22
1021
2
原创 嵌入式开发可以这样学 之--总体目录
新年开新篇！准备出个嵌入式开发相关的系列博文，在这里立一个FLAG。打算通过这一系列文章，整理一下这几年开发过程中思考的东西，对自己是个总结；对相关领域的开发者，希望也能有所帮助。先来看一个全局图，该图展示了一个嵌入式产品的全貌，从硬件到系统到库到上层架构。本系列博文的内容也就依此图结构而展开讨论。这幅图中的内容细节并不重要，主要是展现嵌入式开发中涉及的方方面面。本来是想整理个Android系统的，但是过于庞大复杂，不见得能提炼出来，而且最终效果可能也不见得比上面这幅图好多少，所以决定还.
2021-02-12 11:10:20
768
4
原创 一文将大数据、云计算、物联网、5G（移动网）、人工智能等最新技术串起来
可以看见，上述概念都是随着技术的发展而不断创造的。技术的发展与需求的发展相伴相生，新的需求促进新的技术，新的技术解决新的问题，问题的解决又催生新的需求，如此往复。那么，新的问题有什么特点呢？或者说与旧的问题有什么本质区别？显然，新的问题总是比旧的问题更复杂，更难以解决。技术的演进，就是随着这些问题的不断解决而更新、发展的。这些技术虽然涉及不同领域，但是我们还是会发现共同点，即它们都属于ICT（即信息通信）范围。为了更好的将它们串起来，我们看看ICT的架构本质。个人认为，无论涉及范围多么庞大、...
2021-02-05 19:36:04
3552
原创 Makefile中如何使用echo输出$符号
简单总结一下，makefile中可以使用两个$来表示$本身，而shell中需要使用反斜杠/来转义$符号。
2024-02-29 22:54:07
600
原创 解算人生--写于2023跨年之夜
跨年之夜，数学中的用抽象解释抽象，让我对人生也有了类似的感悟。其次呢，没有故事，没有细节，那么只剩干巴巴的枝干，就刻画不了丰富的层次感、立体感，难以展开想象的空间，无法带来探索的满足感，自然也是容纳不了大美的。回到刚说的这本书上，书中就有很多类似的描述，比如将数学的历史进行高度提炼，然后从全局的俯视的角度给出说明，抛开常规数学教材的公式罗列，带有故事性（像数与形的关系），这是我喜欢的数学书，但是还是不够轻松，这也许是书的问题，比如还不够生动，也许是我的问题，比如不愿转脑子，幻想着用看小说的心态看数学。
2023-12-31 23:15:19
1567
6
原创 一个C++ string使用问题的分析及解决
想的很简单，不断接收串口的字符，每收到一个就append到一个string中，遇到\n，就将当前string放到queue中，对string执行clear，然后继续接收下一个字符。因为当前这个使用方式，之前在其他模块代码中也是有类似的应用的，从来没出问题，因此就感觉更加奇怪了，也开始各种怀疑，甚至怀疑是不是编译时没有clean，怀疑\n是不是会截断，怀疑string对象是不是过早释放了，为此还加入了多个临时对象来验证。按说很简单，但是实现中，发现日志总是不全，更加奇怪的是本地打印是好的。
2023-11-27 19:18:13
515
原创 rsyslog出现Unit rsyslog.service is masked不可用问题解决
博主在测试将日志发送到日志服务器的功能时遇到了rsyslog服务不可用的问题，具体来说，就是执行systemctl restart rsyslog或者 service rsyslog restart命令时，出现了标题中所述的Unit rsyslog.service is masked问题。但博主的需求是如何将日志发送到日志服务器，而不是让Ubuntu做日志服务器，所以这些资料大都略过，然后从最简单的命令来尝试。于是按照网上的资料，修改/etc/rsyslog.conf及相关配置文件后，重启该服务，测试。
2023-11-26 13:01:44
906
原创 小命令，大世界
对初学者而言，它可以让你了解系统都有哪些命令，也是每日一练的好题材（书中每个命令的例子都比较简练，而且只介绍比较实用的参数，篇幅也保持在一两页，不像有的书籍，一个命令可以介绍几十个参数，每一个展开显示，让人产生畏难退缩的情绪。而进一步的，学而不用，时间一长，容易忘记，这会导致挫败感增强，成就感减弱，最终让大家难以坚持，产生命令行难学的假象。最后，给一点点小建议，希望下次再版时，能够按大的功能模块（比如CPU相关的，内存相关的，磁盘相关的，网络相关的，显示相关的等等）做个分类查找索引表就更好了。
2023-11-18 16:07:24
181
原创 关于二阶低通滤波的C代码及入门测试
低通滤波器在许多领域都有广泛的应用。博主也因为需要，最近看了看这方面的资料。因为一方面主要需求是二级低通滤波的实现，另一方面该需求只是功能中引入的一个小点，不是做这方面研究用，所以在资料的挑选上就比较苛刻，那些讲一大堆原理公式的就不太适合，有点头重脚轻。反而那些直达目标，讲如何代码实现的，是博主比较关注的。也正因为如此，感觉网上资料比较少。而且好多资料虽然有代码，但也穿插了比较多的理论和概念，有的还需要二次转换，这种资料，很多时候就放弃了。
2023-09-24 17:24:03
2088
原创 学内核之二十一：系统调用栈结构分析
主要是内核栈占用两个页面，共8KB，一头上threadinfo，一头是内核栈栈底。关于汇编里的伪代码 标记 头文件引入 指令集选择 新旧ABI兼容处理 等等，就不记录了，可以结合最终汇编代码，确定一些条件编译的情况。r4 和 r5之后，使用r8保存系统调用表，使用7中的中断号，右移两位，每个调用占用4字节，修改pc寄存器，直接跳转到系统调用中。这个反汇编中，虚拟地址开始位置调整为c0000000了，且上述表的内容也有具体内容了。这个函数里，入栈7个位置，并预留9个位置，这也跟上述栈标记及栈回溯对应上了。
2023-09-17 17:45:40
378
原创 系统架构主题之七：基于架构的软件设计方法及应用
为此，团队对需求的变动进行了二次系统梳理，对相关变更的必要性进行了仔细的校对，对技术实现的约束限制进行了全面仔细的验证测试，在这些信息的基础上，反推到需求层，对需求进行调整，改变了最初过于苛刻的性能要求和体验目标，在大家达成共识的基础上，进行了二次演进处理，并增加了更为全面的测试，收集了系统化的测试数据，为业务的调整提供了更为合理的边界。平台层，可以构建对业务层其关键支撑的技术框架，包括多媒体的采集渲染，数据的编解码支持，网络通信的支持，异步事件的支持，开发框架的支持等。这个过程是不断迭代的过程。
2023-08-27 21:47:31
2044
原创 系统架构主题之六：软件系统架构风格
当然实际中，整个链条的处理不是这么单一的，编码压缩涉及不同的格式标准，解码解压缩也是一样，数据还可能存在融合要求，比如音频的混音，视频的多画面融合等。但是，无论如何变动，整个处理过程仍然是数据进入处理模块，流出后再进入下一个处理模块，这个结构关系、组织关系是不变的，因此管道过滤器的适用性是没有问题的，而且按这种方式实现，便于理解，便于代码维护，便于修改应对新的需求。当然，金无足赤，人无完人。比如，对于数据流的抽象，虽然统一了代码处理风格、方式，复用了代码，简化了处理，但也在一定程度上影藏了差异。
2023-08-27 10:37:26
1493
原创 系统架构主题之五：软件系统建模方法及其应用
前面我们梳理了需求分析的相关内容。完成需求分析后，会输出指导软件开发的需求规格说明书。有了该文档的支持，下一步就是系统设计阶段，用于将软件需求的内容转换为可指导软件开发的概要设计和详细设计文档。下面我们从理论和实践上看看如果做系统设计。1 信息系统建模常见方法及相关概念通常，系统设计的主要工作就是系统建模。系统建模的主要方法分结构化建模方法和面向对象建模方法，分别与结构化分析和面向对象分析对应。首先，我们看结构化建模方法。这一方法的切入点是数据设计，指导思想是程序=算法+数据结构。在结构化分
2023-08-20 11:25:54
3112
原创 系统架构主题之四：软件系统需求管理技术及其应用
更进一步的，实际中采用了中心圆模式进行度量分析，中心为核心需求，体现系统的核心价值，外围为关键需求、安全管理需求、会议需求、智能检修需求等业务相关需求，将变更映射到度量模型上，集中有限资源，优先处理影响核心价值的需求。从理论上和工程实践上来看，总是有不受控的因素导致需求发生变更，但是需求的变更最终是要传导到设计、编码、测试、维护的后续链节的，且越往后，变更的实现成本就越大。如果需求挖掘不充分，获取存在明显的遗漏疏忽，那么后续的变更就不可避免，因此，越是做足了需求获取的工作，越是能够减少后期的变更。
2023-08-13 22:33:57
454
原创 系统架构主题之三：软件系统需求获取技术及应用
需求获取是一个反复的过程，不是一次成型的。在需求获取过程中，就发现有些数据是内部网络的，有些数据是外部网络的，比如电力设备的相关信息，必须在内网隔离情况下，才能传输，而向视频会议业务，则可以使用外网构建。但是，内外网之间又有一些数据传递需求，这些需求重要的不是技术方面问题，而且规范安全防护方面的问题，是合规的问题。JRP，联合需求计划，应该跟需求专题讨论会是一个意思，是一个通过高度组织的群体会议来分析企业内的问题，并获取需求的过程，是联合应用开发的一部分。注意，不同规模不同类型的项目，需求获取的技术不同。
2023-08-13 18:17:37
511
原创 系统架构主题之二：软件系统需求分析方法及其应用
首先构建用例模型，识别参与者，合并需求，获得用例，细化用例描述，其次构建领域模型，包括发现领域对象，定义领域概念，识别对象属性，识别对象关系，为类添加职责，建立交互图。结构化分析方法，进行业务流程分析，包括数据流图，DFD图确定关键的平衡关系，数据字典（包括数据项、数据结构、数据流、数据存储、数据处理），通过判定树、判定表及结构化语言对数据加工。最终生成软件系统需求规格说明书，包括功能性需求，描述主要功能用例，也要包括非功能性需求，描述性能、可用性、安全、可修改性、可靠性等相关需求。
2023-07-30 21:30:08
994
原创 关于EJB，这两文把热闹和门道都说清楚了
关于技术的很多概念，如果你是小白，不建议看官网。原因就在于官网描述太抽象，就像八股文，看完感觉好像说了很多，但回过头又感觉似乎啥都没说。其实这些官网的打太极式的表述，在你对这个东西有个直观感受的前停下，还想提升自己的理解面，这时候再来看就比较合适。最近深入SOA架构时，遇到了EJB这个JAVA领域早年的流行词，且总在各个地方蹦出来，影响理解新的东西，索性就停下来，专门研究了一下。结果，还真找到了好资料，一看就清楚了。神神秘秘的东西，扒开看，其实都没啥稀奇的，只是被包装的玄玄乎乎。
2023-07-30 19:39:45
153
原创 串2：云计算架构思考
开始之前，先给出串1：一文将大数据、云计算、物联网、5G（移动网）、人工智能等最新技术串起来_龙赤子的博客-CSDN博客承上事物的复杂性一般有两个方面，一个是本身结构的复杂，一个是运行机制的复杂。因为这两者会相互影响，所以边界不会那么的清晰。运行机制的复杂，会催生结构的复杂，而结构的复杂往往也会导致内部运行机制的复杂。一般来讲，理学多体现机制的复杂，而工学问题多体现结构的复杂。举个例子，物理问题，首先研究的是原理，即如何找到一个数学模型来表达内部的机制。经典的牛顿力学，就是通过几个数学公式，被完美的
2023-07-24 21:24:55
285
原创 Jenkins极简体验
也许本意是想避免口语化的描述，把功能说的更加概括，更加严谨，更加通用，也可能仅仅是想把稀松平常的东西说的高大上。在计算机运维中，Jenkins提供了一个流水线，你可以告诉它，当我们的代码提交后，它从哪里把代码下载下来或者更新，也告诉它，怎么将代码进行编译，还告诉它如何进行模块测试，如何进行集成，如何进行打包，如何将安装包安装到测试或者目标系统，如何进行系统测试，如何…你总结提炼的时候，脑海里是有具象的东西辅助的，我学习的时候，是需要填充这个具体的东西的，否则读来就会感觉空、感觉虚，感觉飘，感觉迷，感觉茫。
2023-07-16 22:35:13
310
原创 Windows下特定应用卡顿问题的分析与解决
当然，打开也可能导致。其次，这个软件看着还是比较复杂，性能表现不凡的，一看就是经验丰富的人员开发的，不应该出现访问网络导致阻塞界面的这种常见设计缺陷。所以，问题的根因，与操作系统有关，也不是没有可能。打开注册表，搜索软件，数量也不少，但是还好，一条一条过，也就是十分钟的事。另外，为了进一步的验证软件的影响，关闭开机自启动的几个软件，然后在不起其他软件的情况下，使用该软件。0 此类问题，想都不用想的顺手动作，就是查看任务管理，看看系统或者程序是否CPU占用过高，内存专用过高，磁盘读写是否在疯狂进行。
2023-07-16 15:12:58
1328
原创 系统架构师主题整理之一：软件系统开发模型及其应用
瀑布模型：传统模型，从需求开始，按照需求分析、概要设计、详细设计、单元测试、集成测试、系统测试这个流程实践软件工程。增量模型：该模型有模块的概念，强调在核心模块基础上，不断实现、整合新的模块，基于此向最终目标系统行进的一种软件工程方法。面向对象模型，使用对象建模，结合用例图、类图、对象图、时序图、状态图、顺序图、构件图、部署图、活动图等指导开发。螺旋模型：在传统流程的基础上，每一个阶段都需要进行目标设定，风险分析，开发和有效性验证，评审几个过程。迭代模型：简单而言就是小步快跑，稳中求进，不断演化整个系统。
2023-07-02 20:55:08
429
原创 不可盲目优化，否则不是缘木求鱼就是南辕北辙
说难，是因为同所有的行业一样，从良好到优秀，是一个量变到质变的过程，难度就会递增，而从优秀到卓越，更是一种突破，不是努努力就可以达到的。我估算了一下，周期为20纳秒的时钟，一个存储地址的访问，很容易到百纳秒级别，这样1K的空间，少说就需要几十微妙，CPU把时间耗在这里，自然没时间干别的事情。通过查资料，分析代码，包括分析汇编验证，确定CPU支持浮点协处理器，也就是指令级别支持浮点运算的，编译选项中也支持了浮点的相关选项，所以，转整形其实没有什么必要（这一点，大家在实际中可以查看生成的汇编代码来确认）。
2023-06-18 21:46:06
212
原创 锤子眼里全是钉？谈如何对现有系统进行微服务改造
整个系统部署风险也很大，需要停用现有系统，无法做到无缝对接，无缝过渡，不利于业务产品的迭代，系统本身升级成本和风险也比较大，如此，带来的是整体运维成本增加。其次，当服务多了后，通信链条自然就变多了，极端情况，每一个服务都需要同其他所有服务通信，这使得通信链条的调试，问题点的定位，功能的验证变得复杂了；（1）微服务，微表示小，细粒度，这点从名称上直接体现出来。作为一个微服务架构师，系统改造专家，既需要全面通透的理解原系统，从而可以庖丁解牛式的分解原系统，也需要吃透微服务的精髓，以便高瞻远瞩的布局新系统。
2023-06-11 09:57:52
798
原创 技术回锅：从起点到起点
从技术的方向来看，其实其他领域也是类似的，很多人进入好大学，找到好工作，沉淀很多年，最终 可能 或 甚至才有机会 在某些大型系统中充当拧螺丝的角色。技术人员突破一个个瓶颈的过程，不得不让人感叹，科技世界没有灵丹妙药，有的只是有心人的坚持，怕的也是有心人的坚持。最近也有机会看了很多国外的一些产品研发介绍，再加上小时候了解的那些科学家的故事，更加坚定了上面的看法。这是疫情后的第一个高考和第一个毕业季。每当一个个新成果点燃内心的火热激情后，我们需要更加清醒的认识到：坚持初心，脚踏实地，才能走的更稳，走的更远。
2023-06-10 22:31:00
64
原创 当你怀疑电脑的时候，就是该换个方法的时候了
做软件开发的朋友们，干的时间长了，相信都会有过类似的体验：一个问题查了很久很久，代码检查了很多遍很多遍，到最后都要怀疑电脑了，突然发现是一个特别隐蔽的错误导致的，而这种错误通常不涉及逻辑流程，却特别容易瞒天过海。比如可能是掺杂了一个中文字符，可能是少写了一个分号，可能是变量重名了，可能是类型强转了，可能是变量未初始化，可能是指针指错了等等等等。其实这个问题的原因很简单，我们在编写代码过程中，出现了拼写错误，丢失了函数的括弧，编译器将函数名当做函数指针，用一个指针值参与运算了。可以看到，符合我们的预期。
2023-06-03 11:42:53
198
转载 Google I/O 2023 新的变化，今年流行AI
随着 AI 不断的快速升级，我们专注于为用户带来更有用的功能。从今天开始，我们为用户提供了一种新的方式，来预览 Workspace 和其他产品中的部分体验。这就是 Labs。虽然我说这是一种新方式，但是 Google 使用 Labs 作为一种早期访问和获得反馈的方式已经有很长的历史了，用户可以在今天晚些时候开始注册。除了你们刚才看到的 Workspace 功能外，能够在 Labs 测试的首批体验之一是我们的创始产品——Google Search。
2023-05-21 11:05:16
320
原创 学内核之十八：纸上得来终觉浅，绝知此事要躬行
大家都知道，内核开发跟应用开发，体验是完全不同的，尤其是驱动。一方面要掌握扎实的语言基础，另一方面还要对操作系统的基本概念深入理解。然后配合软硬件的一些知识，才能做好驱动的开发任务。博主最近做一个虚拟设备驱动，再次体验到了什么叫纸上得来终觉浅，绝知此事要躬行。现实中，大部分开发人员（包括博主本人）都是应用开发者，无论是做产品还是项目，主要都是面向特定的业务。而内核，毕竟是一个通用系统，很多情况下是拿来就用，开箱就用。专门做内核开发的人员还是少数。这其中的大部分，也都是主要做驱动开发的。
2023-04-09 13:37:16
662
原创 文件小注意
文件操作在软件开发中是很常见的一件事。虽然与它相关的工作看起来不怎么起眼，无非就是通过通过open、read、write、close几个调用搞定的事情，但也正是这种看似简单的工作，在稍加变化需求的场景中，会给你带来意想不到的麻烦。这里就记录本人最近关注到的几个点，做为小例子，分享给大家。多说一句，往往简单的事情会给人带来大麻烦，就是因为人的大脑会对简单或者认为简单的事情过于麻痹大意，先入为主，不加重视，导致往往只看到冰山一角。该怎么做，不用多说了，直接看实例。（本文都是基于Ubuntu系统）
2023-04-09 11:08:08
743
嵌入式领域：基于NIOS II 和 uCOS II的音频数据采集和网络传输技术
2023-02-28
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人