关于单片机软件框架的一点思考

软件产品的文档很重要,其实我想说,任何东西都要有说明书,不然别人是很难使用的。最近一段时间有在看OSAL这个为操作系统,看了很就也不会用,其原因嘛,我实例有限,另外就是TI自己的文档不够全面,仅仅是zigbee好蓝牙的芯片中使用,其他mcu的平台基本上没有现成比较好的,有的网友移植了,也没有好好说明,导致osal的这个使用率没有rtos的高。

其实我个人认为,小项目使用裸机(定时器+状态机),稍稍大一点项目就使用RTOS。

还有一种是时间片的框架,我反而认为不太好,适合玩玩,因为这个框架,说实在的,用一个硬件定时器来模拟多个软件定时器,这样硬件定时器的资源其实是过度利用了,而且每一个软件定时器的回调函数要十分精简,否则,定时器就会不准,而且我觉得定时器的定时中断太频繁了,对很多系统来说反而不好。目前至少我是这么认为的。如果有网友可以有一个比较好的实际项目使用了这个软件定时器,可以分享一下。

原文地址:https://www.cnblogs.com/CodeWorkerLiMing/p/12241603.html

时间: 2025-01-02 23:38:11

关于单片机软件框架的一点思考的相关文章

《SICP》读后感:关于软件本质的一点思考

摘要:软件本身不是目的,人类的需求才是目的,而软件只是达到目的的手段. 软件的本质在于控制复杂性,这个复杂性并非来自于计算机,也并非来自于现实世界,而是来自于人类的思维和知识体系. 软件被使用的广泛性,在于它所满足的人类需求的广泛性. 什么是软件? 从一个简单的例子说起,比如我想计算两个数的和,于是写下这样的python代码 print a + b 但是,这段代码是我的最终目的吗?显然不是,我需要把它在计算机上实际运行,并赋予a和b实际的数值.也许我是在水果,买了5块钱的苹果和10块钱的香蕉,然

如何实现一个TCC分布式事务框架的一点思考

一个TCC事务框架需要解决的当然是分布式事务的管理.关于TCC事务机制的介绍,可以参考TCC事务机制简介.http://www.bytesoft.org/tcc-intro TCC事务模型虽然说起来简单,然而要基于TCC实现一个通用的分布式事务框架,却比它看上去要复杂的多,不只是简单的调用一下Confirm/Cancel业务就可以了的. 本文将以Spring容器为例,试图分析一下,实现一个通用的TCC分布式事务框架需要注意的一些问题. 一.TCC全局事务必须基于RM本地事务来实现全局事务 TCC

关于前端的一点思考

关于前端的一点思考 Author:tkorays 最近写前端代码,写着写着就突然开始惆怅.忧伤.愤怒.发狂,我TMD到底在干什么啊! 很多东西写了n遍了,但是还是在不停地写着.自己写过的代码也不想再修改完善.重新利用,只是觉得,可能重新写一遍可能要好点.面对这很多库以及框架,虽然喜爱,但是也是有所顾忌,我只要使用其中的一个功能,根本不需要引入这么大的整个库. 事实上,我们可能在动手写任何代码之前,先要思考下,我们到底要的是什么! 0x00 界面真的需要这么炫酷么 在使用某个界面库之前,我们可能先

软件框架

软件框架 最近做了一个软件,这个软件不是网站,但是与HTML,AJAX等技术密切相关,也不是只有单纯的数据库增删改查,还涉及到线程协调,比较复杂的文本处理…… 这样的软件,用OA,ERP的框架显然是不合适的,因为这种软件用不上权限管理,工作流这些技术.但是软件又要操作数据库. 介于这些的特殊性,想来想去,还是自己搭建一个轻量级的软件框架是比较好的. 一:C/S与B/S的选择 1,我做的是一个购物网站的刷单软件,有如下几个方面的原因,我选择了C/S程序 a,刷单软件需要长时间的运行,不定时,不间断

关于模板方法和策略模式的一点思考

该随笔的思想原点,应该算是在两三年前了.当时和一前同事聊天.不知怎得就聊到了Http访问. 一.我记得他和我说过的第一句话,大概是:有没有已经封装好的.比较强大的HttpUtil.也可能是受业务的影响(接口对内).我当时接触到的Http访问,大多比较“规范”,至少有一个接口约束在约定着某些东西,不至于一会传递json,返回json, 一会又要传递xml,返回xml,甚至更奇葩的是,上传个文件.返回0或者1.如果真出现这样的状态,HttpUtil依然能够方便.灵活的适应着各种情况.我想这个Util

服务框架和软件框架

一.服务框架 服务框架基于业务对应用SaaS分发模式的服务进行整合,以产生新的应用,其具有如下的特点: ü 它是面向特定领域的可复用软件集成平台: ü 反映了该领域应用的一般需求和结构: ü 具有部分实现的特性,包括一组与业务功能的整合密切相关.相互协作的组件: ü 服务框架中,与业务相关,但与业务功能的整合无关的组件以外部服务形式引入. ü 基于服务框架开发应用是通过扩展和复用外部服务实现的. 分布式服务框架是面向服务架构的基石,是解耦子系统的利刃.核心实现是RPC(远程过程调用),但又不仅限

关于后台系统自动生成的一点思考

大量实践发现后台管理程序,其实90%的代码都是相同的,当然是在抛弃复杂逻辑业务的情况下,那么如何能高效的节约这些时间呢,那就是接下来我要说的,对于后台系统自动生成的一些思考. 适用情景: 1.表编号id为自增(基于现在大部分表编号都是自增的情况): 2.没有太复杂业务关联关系,比如表的某一个字段,存储了一个json对象,为了平衡后台用户使用,需要友好的分段展示给用户的定制ui界面:还比如表中存储了外键的多个id,但为了方便用户使用,只能已标签name的方式,给用户展示,等等这些超强业务黏合逻辑的

[Alljoyn] 1、物联网开源软件框架alljoyn研究(一)——初步了解

What is AllJoyn?[是一个合作的开源软件框架目的在于连接万物] An Open Source API Framework For the Internet of EverythingA way devices and applications publish APIs over a network in a standard wayWhy APIs?– Because this is what software developers understand and work with

TI BLE协议栈软件框架分析

看源代码的时候,一般都是从整个代码的入口处开始,TI  BLE 协议栈源码也不例外.它的入口main()函数就是整个程序的入口,由系统上电时自动调用. 它主要做了以下几件事情: (一)底层硬件初始化配置 (二)创建任务并初始化任务配置 (三)检测并执行有效的任务事件 Main() 函数源码如下: 一:底层硬件初始化设置 75行,设置系统时钟,使能内存缓冲功能. 78行,关中断,刚启动时,系统运行不稳定,一般会首先关中断. 81行,硬件相关的I/O 口配置. 84行,初始化mcu 内部的flash