tag 标签: 嵌入式软件

相关帖子
相关博文
  • 热度 4
    2014-7-10 22:01
    868 次阅读|
    0 个评论
    硬件工程师该如何成为软件专家 要想成为某个方面的专家可不是件容易的事,需要付出艰辛的努力,尤其是涉及到嵌入式软件方面。嵌入式技术的变化速度至少可以说是很快的。虽然用来编写软件的编程语言仍然是C和C++,但相关技术、编译器、工具链、支持工艺和技术在无穷无尽的革命浪潮中一直在勇往直前。你只要稍歇一会儿,就只有望洋兴叹了。尽管变化神速,但仍有一些事件是工程师想要与时俱进并成为软件专家可以做的。 专注于某个领域中的一个特定专业 尽管社会或项目经理认为工程师应该是从概念开始一直到生产的每个方面的专家,但每个方面都是专家是不现实的。想成为无所不能的专家不仅没有足够的日常时间,也没有足够的资源。一个很明显的解决方案是在某领域中寻找一个感兴趣而且有需求的小众市场,然后全力以赴加以攻克。只有当工程师完全掌握了这种技术,并且维护它很轻松时,才应分出精力去寻找其它小众市场。另外应该时刻关注对这个专业市场的行业观点,如果开始变得过时或即将失去实用性,工程师就可以在意外变成老古董之前转移到一种新的专业技术。 硬件工程师该如何成为软件专家 【 分页导航 】 • 第1页: 专注于某个领域中的一个特定专业 • 第2页: 每周抽出时间与时俱进 • 第3页: 积极参加社交媒体 • 第4页: 参加会议或网上研讨会 • 第5页: 不要忘了获取经验 延伸阅读: 编程大师的成功秘诀 成功制作工程师简历的十个技巧 《电子设计技术》网站版权所有,谢绝转载 每周抽出时间与时俱进 光阴似箭,日月如梭,稍不注意,时间就会从我们的指头悄悄遛走。对生活、工作和项目负担的追求占据了工程师的大部分时间,并且很容易超出工程师的可控范围。因此有必要每周抽出一定的时间来学习和巩固专业知识。午饭时间或周末早晨是可以充分利用的好时间,否则这些时间很容易就浪费了。分配的时间长短很大程度上取决于感兴趣的领域和变化速度有多快。用于提高这些技能的时间可以少至一周一个小时、长至一周一天。不管怎样,你不用这些时间就白白失去了! 阅读书藉和杂志 阅读书藉和杂志是消磨零碎时间的一种好方法。每个行业都有一份能作为每个工程师知识库基础的媒体资源和著作清单。嵌入式软件行业也不例外。本文作者认为有大量书藉是学习和理解常用嵌入式软件的理想基础。下面是一些例子,包括: 1.David Simon编写的《嵌入式软件初级读本》 2.Jack Ganssle编写的《嵌入式系统设计艺术》 3.Elecia White编写的《嵌入式系统设计》 市面上有许多有关嵌入式软件方面的书藉和杂志可以用来保持工程师不落伍,并且还有助于特定市场中的专业化发展。首先要确定感兴趣的主题,然后搜索出这些资源。一些可供阅读的最佳在线杂志包括《电子技术设计》(EDN),还有《Embedded》。 【 分页导航 】 • 第1页: 专注于某个领域中的一个特定专业 • 第2页: 每周抽出时间与时俱进 • 第3页: 积极参加社交媒体 • 第4页: 参加会议或网上研讨会 • 第5页: 不要忘了获取经验 延伸阅读: 编程大师的成功秘诀 成功制作工程师简历的十个技巧 《电子设计技术》网站版权所有,谢绝转载 积极参加社交媒体 一般来说,社交媒体有时看起来似乎铺天盖地、很无趣也很浪费时间。然而,正确地利用这些渠道被证明是完全值得的。在电脑网络空间中任一时刻都存在着数不清的广博知识等待你去发现和利用。上面有许多文章、技巧和提示、网站链接以及更多永远不会让工程师特别留意到的东西,除非他们能够积极参与社会媒体。一些本来可能被忽略的技术讨论通过简单地寻找相关的散列标签可以被轻松发现。从中流露出的信息可以很容易将职业人员与专家区别开来。 但只是消费媒体永远只能成为一个工程师。为了获得参与社交媒体的全部影响力,你应该发表自己的知识、专业技能和经验。这不仅有助于让学到的经验教训公诸于世,而且能使其他人从这些信息中受益。社交媒体上有数不清的年轻工程师可以从经验丰富的年长工程师那里学到东西。为了试图鼓励这种努力,本文作者经常会在推特上发表一些常用技巧,并赋于散列标签#EmbeddedTips。参与这些讨论时不仅只是阅读这些技巧,而且要发表你自己的见解! 使用时事通讯获得最新的提示与技巧 成为某方面专家的另外一种最佳途径是订阅时事通讯,它能自动向电子邮件直接发送最前沿的技术。这方面最好的一个例子是覆盖《电子技术设计》、《电子工程专辑》、《Embedded》等的UBM时事通讯。每周都会有相关的文章和故事发送出来,因而能节省工程师很多宝贵的互联网漫游搜索的时间。还有像Jack Ganssle和Michael Barr等软件专家专门撰写的定期时事通讯,这些邮件也专注于行业内的一些专业主题。本文作者还每月发表一份嵌入式时事通讯,内容涉及C基本原理、提示与技巧、贸易工具和感兴趣的新闻集锦。(感兴趣的读者可以上http://bit.ly/156NXX8网站注册) 【 分页导航 】 • 第1页: 专注于某个领域中的一个特定专业 • 第2页: 每周抽出时间与时俱进 • 第3页: 积极参加社交媒体 • 第4页: 参加会议或网上研讨会 • 第5页: 不要忘了获取经验 延伸阅读: 编程大师的成功秘诀 成功制作工程师简历的十个技巧 《电子设计技术》网站版权所有,谢绝转载 参加会议或网上研讨会 会议和网上研讨会是获得专业知识的好地方。Design West是嵌入式软件领域中的一个极好例子。那里不仅有覆盖每个可能想到的主题的一周课程和培训,而且参加会议的很多是业内专家。会议是与这些专家面对面交流、咨询问题和获取他们知识和经验的极佳机会。在这些会议上知识膨胀的速度绝对是惊人的!但有时许多公司不允许或者没有时间参加会议。在这些情况下,参加在线培训和网上研讨会同样不错。IEEE Spectrum会定期赞助业内专家主持的网上研讨会,作者认为这都是很好的机会!尝试至少一年参加一次会议,一个月参加一次网上研讨会。 成为IEEE认证的软件开发专家 很少有什么比某人名字后面的头衔和职称更能暗示其专业才能的了。在软件行业内有一些认证项目可供工程师展示其才能。这些项目包括专业技能考试和IEEE认证的软件开发专家(CSDP)。通过这些考试意味着拥有了通过考试所具备的最低限度的理解力和知识。另外,他们还有经验要求。要想通过认证,工程师不仅要有书本上的知识,还必须花时间实际编写软件!这些认证通常能让雇主大概知道他们的雇员能做什么。 【 分页导航 】 • 第1页: 专注于某个领域中的一个特定专业 • 第2页: 每周抽出时间与时俱进 • 第3页: 积极参加社交媒体 • 第4页: 参加会议或网上研讨会 • 第5页: 不要忘了获取经验 延伸阅读: 编程大师的成功秘诀 成功制作工程师简历的十个技巧 《电子设计技术》网站版权所有,谢绝转载 不要忘了获取经验 阅读理解书藉是不错,但没有实际经验工程师也不可能成为专家!他们必须沉下心来编写代码!找到一个便宜的开发套件,然后开始编程。 提出一个项目、一项发明或只是找到一个感兴趣的问题,然后借助软件解决。从中学到的问题和技能是仅靠阅读文章或书本永远学不到的。 在一天结束时,不管工程师成为了专家,还是只是掌握了先进的开发技术,他们都不应忘记享受解决遇到的问题。毕竟这是工程师最乐意和最擅长做的事情之一。 原作者:Jacob Beningo 【 分页导航 】 • 第1页: 专注于某个领域中的一个特定专业 • 第2页: 每周抽出时间与时俱进 • 第3页: 积极参加社交媒体 • 第4页: 参加会议或网上研讨会 • 第5页: 不要忘了获取经验 延伸阅读: 编程大师的成功秘诀 成功制作工程师简历的十个技巧 《电子设计技术》网站版权所有,谢绝转载
  • 热度 2
    2014-3-10 16:39
    514 次阅读|
    0 个评论
    在软件开发过程中没有比获得一个只有很少甚至没有说明文档的代码库而又要求进行维护更具挑战性的事情了。这些文档不只是告诉工程师某个特定函数或变量是做什么的,而且能够展示和传达软件为何以某个特定方式实现。在软件实现过程中会作出成千上万个决策,因此维护工程师甚至未来的你尽可能多地保留这些决策过程至关重要。 注释代码的问题部分原因来自出货压力、不正确的设计以及注释代码是如何工作的事情没有开发来得有趣或兴奋这个事实!许多工程师(包括我自己)憎恨必须注释代码,但这项工作在嵌入式工程师开发过程中是如此重要,以致于我们绝对不能省略或三意二意地去做。然而,可以在软件开发过程中记住一些技巧,它们有助于确保未来开发人员维护好代码开发中的任何细微变动。 技巧1——随时而不是过后进行注释 交付产品的压力经常导致天马行空般的编码风格,为了完成任务以便尽早推出产品,代码是想到哪就编到哪。在疯狂的代码编写过程中,很少想到记录下代码要完成的功能。等产品交货后,设计人员才会回去浏览代码并进行“注释”。这样做的问题是,这时已经距离写完代码几周甚至几个月的时间了!对一些工程师来说记起昨天早餐吃的是什么都很难,更不用说两周前写的一段代码了。最终结果是不准确的注释说明,日后往往会引起误解和缺陷。 这里的技巧当然是在进行决策的同时随时进行注释。形式化的外部文档注释过程无疑会降低开发人员的进度,但向代码库中增加注释真的不会占用更多时间。开发人员能够做的第一件事是先对代码要做什么事写一些注释行,然后再写代码。如果实现发生了变化,开发人员可以立即更新注释。在任何情况下,在编写代码的同时写下注释只会节省时间和增加条理性,从而更少发生错误,产品也能更快的上市。 《电子技术设计》网站版权所有,谢绝转载 技巧2——自动生成注释文档 尽管对代码做了很详细的注释,但总是有生成外部文档的要求,以便任何人不看代码就能明白程序功能。这个要求经常导致双倍的注释工作量。幸运的是,市场上有现成的工具可以自动读取代码注释、然后生成界面和代码的其它文档细节!帮助工程师避免必须做两次相同的工作!一个具有这种功能的免费工具例子是Doxygen。当开发人员在编写他们的代码时,他们以指定方式格式化他们的注释,并提供他们想要在外部文档中展示的细节内容。然后他们就可以运行Doxygen生成真实反映软件内注释的html、rtf或pdf文档。美妙的是如果你更新注释,外部文档也会自动更新!有关如何获得这款工具并运行的教程可以在www.beningo.com网站的Design Articles-Design Cycle专栏中找到。 技巧3——不要写显式的注释 虽然开发人员写了代码注释,但如果注释只是变量或函数名字的重复,会特别令人恼火。注释应该是描述性的文字,需要提供显式意思之外更多的细节!提供尽可能多的信息,而且不要忘了提及相关和关联的变量或函数。开发人员应该能够只通过阅读注释就了解软件的行为。图1给出了一个注释简单映射数组代码的例子。 图1:映射数组。 《电子技术设计》网站版权所有,谢绝转载 技巧4——提供使用例子以便更清楚地了解用途 函数或变量注释中包含如何使用它们的例子是很有用的。说应该如何使用是一回事,但展示如何使用会让人更清楚其用途。除了能够减少错误使用对象的机会外,还能给人一个更清晰的印象。图2显示了一个如何注释函数的例子,它告诉开发人员应该如何使用这个函数,从而避免了容易出错的猜测过程,使人能够更清晰地了解其用途。 图2——使用例子。 技巧5——创建注释标准 就像写代码一样,为代码开发注释和文档也应该有个标准。由于注释标准中不可能有许多条款,因此特别推荐向编写代码标准靠拢。也就是说确保小组中的每个成员以相同的方式进行注释和归档,从而确保开发的易用性。开发人员应该专注于解决手头的设计问题,而不是费劲地去搞懂注释。 《电子技术设计》网站版权所有,谢绝转载 技巧6——使用文档模板 确保注释遵循标准的最容易的方法是为头文件、源文件和支持文件创建模板。当创建一个新模块时,可以从模板入手,然后增加相关的信息。这将有助于确保文件信息块、代码段、函数和变量都用相同的格式注释。这种方法的最大优势是能够节省大量时间,并有助于减少将一个模块拷贝到另一个伪模板时发生的拷贝粘贴错误。为了让生活更加轻松,我特意开发了可以用于定义头文件和源文件的模板。 技巧7——图表的作用 在一个项目的软件实现阶段开始之前,应该有一个软件设计阶段。这个设计阶段无疑会生成许多漂亮的图(如流程图和状态机),并被用于实际实现。虽然这些文档作为软件的开发路线图,但在开发和测试过程中总会出现偏差!遗憾的是,这些变化很少会返回到图表中。结果是设计文档和软件的不匹配!在实现和测试阶段将这些图表放在手边,以便发生上述偏差时这些图表能及时得到更新。将这些图表留到日后更新永远不是正确的做法。虽然我们总是有返回去更新或修复的良好愿望,但这永远不是合适的时机。 技巧8——保持注释框使用的一致性 就像听起来一样奇怪,许多网络争论的内容是何时、哪里使用何种类型的注释框!不过严肃地讲,不管你的信仰是什么,归根到底是一致性问题。如果一个团队决定只使用/*…*/类型的注释,那么就只使用这种类型。如果决定使用//类型,那就只使用//类型。作者个人的观点是倾向于使用/*…*/进行函数和模块级说明,使用//进行函数代码说明。不管选择是什么,确保每次都按同样的方式去做,这样有助于生活更加轻松。 《电子技术设计》网站版权所有,谢绝转载 技巧9——使注释更容易阅读(即格式的美化) 为了确保避免误解并由此产生代码缺陷,使代码保持结构化和容易阅读很重要。注释也一样。偶尔结构化的注释会使眼睛很难捕捉注释,更难捕捉不在合适位置的内容。应该对注释进行格式化处理,这样如果代码打印出来时(虽然现在不常打印,但我偶然仍会打印代码)注释就不会分到好几页上去。在大块注释(如文件头或函数注释)中,如果你使用块指示器,千万不要包含进任何拖尾字符(如#或*),要不只会使文档更新变得更加困难。 技巧10——嵌入图像和图表 借助自动化工具的使用,在注释文档中包含编码标准、缩写词、项目细节、要求和大量其它条款就成了可能。甚至能够包含诸如流程图等设计性图表!使用这类功能允许代码库不仅包含执行代码和逻辑,还包含你想要了解的项目所有内容,并且所有信息都放在同一个地方。 作者:Jacob Beningo 《电子技术设计》网站版权所有,谢绝转载
  • 热度 8
    2010-6-17 09:57
    4189 次阅读|
    5 个评论
    男人征服世界,女人通过征服男人来征服世界;硬件叱咤江湖,软件通过控制硬件来统治江湖。当今世界,放眼江湖,有电子的地方就有嵌入式软件,有电子故障的地方,也就有嵌入式软件设计缺陷的影子。我们今天就把软件所容易犯的错误和规避的方法一一罗列,并给出应对之法。 嵌入式软件的最大特点是以控制为主,软硬结合的较多,功能性的操作较多,模块相互间调用的较多,外部工作环境复杂容易受到干扰或干扰别的设备,且执行错误的后果不仅仅是数据错误而是有可能导致不可估量的灾难,所以总结起来,嵌入式软件可靠性设计需注意的问题有四个方面: 1、软件接口 先说软件接口中容易出问题的地方和编程人员容易犯的错误。 软件接口调用一般会有数据的赋值,赋值变量的数据类型可能会存在强制的数据转换;需加以检查。如果为了防范出问题的话,可以添加对数据范围和数据类型的检查。 赋值数据的数量不对路,多了少了的都不好,会出现意外的赋值结果,不过还好,这项错误比较好检查。 软件编程中,会有对某一功能操作代码的复用,比如对某个端口的数据检查和控制,在整个程序中只会发生两次,为了图省事,可能就直接把该段代码直接插入实际程序模块中去了,这样,在源程序代码中,就出现了两段完全相同,完成相同功能,只是服务于不同模块的代码,按道理来说,这样设计其实也没啥问题,是的,你没错,但你的行为会使别人无意中犯错。就像青年男女相处,女孩子纯粹是想和男孩子充分享受温馨的气氛和心情,并不想更深入的发生什么,但女孩子邀请男生去的是她的家,在家里换上了家居的睡衣,窗户紧闭,放着的还是暧昧的音乐,被男孩子半强迫发生后,无限哀怨地说“我没想到结果会是这样的”,那怪得谁来呢?在代码方面,您的这种做法与貌似引诱男孩上钩的少女无异。 有人会说了,我这样写代码怎么就算引诱呢?原因是程序可能会升级,您这几行代码在实际应用过程中也不能保证是尽善尽美的,发现不完善的地方后,势必会修改,如果你还能想得起来,可能不会遗漏,如果修改此代码的是别的人,改了一个地方,别的地方没改,是不是还留着隐患?那如何做呢?方法不难,把这段功能单独做成一个模块即可,对此端口的读取和控制赋值均由此独立模块完成,如果数据的正确性影响大的话,还需要对端口数据的正确性进行检查和判断。嵌入式软件可靠性编程方法的四个目的是防错、判错、纠错、容错。对端口数据的判断属于判错的内容,如果数据有错的话,纠错和容错的设计方法应该不用我深入讲解了吧? 2、软硬件接口 硬件如男人,对外的执行都靠它来实现,一旦出现问题,执行后的后果就不可控了,周总理说过“外交无小事”。但如何注意呢? 对读进来的硬件接口的数据要判断其真伪; 对输出的数据的执行效果要检测; 对输出的数据的可能后果要进行预防性设计,数据输出的过程,我们从设计上要做一个分析,分析的思路是一般容易局限在稳态过程,忽视了过渡过程。举例说明,比如我们控制一个支路的供电,从软件控制来说,直接给继电器一个启动信号,让开状态的触点闭合就可以了,非“关”即“开”,是受控继电器的两个稳态状态,但事实上,在从开到闭合的过程中,支路供电的电压并不是一个简单0V—24V(24V为示例而已)的跳变状态,而是一个抖动,有冲击信号的过程,这种情况在硬件上的防护是必不可少的,但在软件上也不是可以事不关己、高高挂起的。 另外在逻辑上,宜将容易被干扰和容易产生的干扰控制动作从时序上控制好,予以分开隔离。比如,控制继电器的过程是容易产生抖动尖峰脉冲而干扰数据总线和控制信号总线的,这时候从控制上,不宜同时实施数据的发送和接收工作,不宜作出其他的控制动作,惹不起咱躲得起,躲过这一阵干扰的时候总可以了吧? 3、软件代码 软件的可靠性是随着时间的推移,可靠性逐渐增加的,这一点区别于电子可靠性、机械可靠性。电子可靠性服从指数分布,在整个生命周期内,其失效率为一个常数;机械可靠性因为磨损、腐蚀、运动等因素的存在,随时间推移可靠度会下降。因此也就有了软件可靠性设计的一个特定规律和注意事项。(待续) 继续阅读: 《嵌入式软件可靠性设计要注意的问题》(下) http://forum.eet-cn.com/BLOG_ARTICLE_4478.HTM
  • 热度 15
    2010-6-17 09:56
    4142 次阅读|
    12 个评论
    3、软件代码 软件的可靠性是随着时间的推移,可靠性逐渐增加的,这一点区别于电子可靠性、机械可靠性。电子可靠性服从指数分布,在整个生命周期内,其失效率为一个常数;机械可靠性因为磨损、腐蚀、运动等因素的存在,随时间推移可靠度会下降。因此也就有了软件可靠性设计的一个特定规律和注意事项。 既然需要通过时间推移,通过不断改进,软件可靠性得到提升。那么软件的可维护性就是一个大问题了。这也是为什么软件工程管理方面特别关注软件文档、注释的原因了。但做这些要求的人只是人云亦云,并不理解如此做法的真正动机。至于注释如何去做、变量如何命名、软件配置管理如何操作,这里面既有很常规的方法,也有一些我们司空见惯然而是错误的做法。信手举上几个值得注意的细节供参考。 变量定义时宜将变量类型的变量名程中体现于其中;如AD_result_int、Cal_result_float等。这样为的好检查,防止数据类型的强制转换或强制赋值时出现数据类型的错误; 注释要充分; 代码的布局风格宜统一,便于阅读查找; 不可出现非受控的default流程,所有数值和变量,不论是调用函数时赋予的、读取接口读进来的、还是中间变量计算出来的,在应用前都宜作数据有效性的判断,并对判定的所有可能结果均做受控的对应处理。 … … 关于软件可维护性编程方法方面的文章资料在网上是铺天盖地,不予赘述,综合采用之即可。很多文章把软件可维护性编程规范推荐做成企业的嵌入式软件可靠性设计规范,实在是有点以偏概全,有失偏颇的,用一句娱乐圈的话来说,“爱情是生活的重要内容,但它不是生活的全部”,软件可维护性编程方法亦然。 软件代码在执行中容易出现的下一个问题是跑飞,程序指针受到干扰,跳转到了一个非受控位置,执行了不该执行的代码。如果执行了不该执行的代码,如果在程序中加入了足够的变量判断、读值判断、状态检测判断等,那倒还好了,后果也不会太严重,甚至最终还是可能自己跑回来的。但有一种跑飞是比较可怕的,一般我们在ROM中存放的程序目标代码是1-3字节的指令,就是最多3条字段的目标码组成了执行动作,如果程序指针跑飞到了某个3字节指令的第2个字节上的时候,执行的后果是什么,可就真的没人知道了,即使在程序上作了足够的数据判错、逻辑跳转的防范措施,结果也不会好。而且ROM一般是不可能全部都被程序代码填满的,总有富余空间,富余空间中的默认内容是啥,这些默认字节是否也会导致一些操作呢?单片机中的默认空间是0FFH,DSP的我没查过,大家有兴趣查一下,跳到这些字段里,也是容易出麻烦的。 好了,不再罗嗦,直接给出解决方法吧,就是每隔一段程序代码或控制区域,就人为放置上几个NOP指令,在NOP指令后放置一个长跳转的ERR处理程序。注意NOP最少放置3个,这样任何的跑飞最多只能占用2个NOP,第三个NOP一样还是能把程序代码揪回来,揪回来后就执行ERR处理程序。 如果碰到安全性、可靠性等级要求比较高的程序,推荐的处理方法可以采用热备份的处理方法,即用两段代码同时执行同一个功能,执行的结果进行对比,如果一致则放行通过,如果结果不一致,咋处理就看您的喽。但是… …国人有的是办法,为了图省事,你领导不是要求我编热备份程序吗,那好,我就把原来的代码复制一遍,重新插入到某个地方,您这和明朝时代冯保太监(还是严嵩、张居正阿?拿不准了,大家有兴趣的翻看《明朝那些事儿》查阅下)玩的没啥两样,自己写奏章,自己给自己审批奏章。既然是备份就是为了防止一个人出问题,那最好的办法自然是不同的人来编这段,如果原理计算方法上也不同,数据采集通道也不同,那就过年带娶媳妇的,好上加好了。 安全性和可靠性的编程细节注意事项还有很多,窥一斑难见全豹呵,诸位仁兄一起努力钻研了。 4、数据、变量 变量的定义是为的避免各种混淆,同一程序内数据和数据的混淆、不同人读程序时对变量理解上出现的二义性、视觉效果上容易出现的错误(字母的“o”和数字的“0”,字母的“l”和数字的“1”)。这里要遵循一个“要么相同,要么迥异”的基本规则,这条规则在很多的领域都有应用,用的最绝的是朱元璋,对待贪官,要么不理你,自觉点您贪差不多了就收手吧,您自己不收手的话,做的过了直接就杀,株连几族,所以在明朝,朱元璋是杀人最多的皇帝;在结构的防呆性设计上,接插件的选型也是如此,如果一个乳白色和一个浅灰色的同类接插件,最好的选择是有很直观的视觉差异或结构的差异,或者干脆就是相同的,相同须基于一个前提,互换性要好。 用显意的符号来命名变量和语句标号。标识符的命名有明确含义,且是完整单词或易理解的缩写。短单词通过去掉“元音”形成缩写;长单词取头几个字母形成缩写;一些单词有公认的缩写。如: Temp — tmp; Flag — f.l.g;(*注:请去年中间的.号) Statistic — stat; Increment — inc; Message — msg。 特殊约定或缩写,要有注释说明。在源文件开始处,对使用的缩写或约定注释说明。自己特有的命名风格,要自始至终保持一致。对于变量命名,禁止取单个字符(如i、j、k...);含义+变量类型、数据类型等,i、j、k作局部循环变量是允许的,但容易混淆的字母慎用。如int Liv_Width,L代表局部变量(Local)(g全局变量Global)、i代表数据类型(Interger)、 v代表 变量(Variable)(c常量Const)、Width代表变量的含义,这种命名方式可防止局部变量与全局变量重名。 禁用易混淆的标识符(R1和Rl,DO和D0等)来表示不同的变量、文件名和语句标号。 除了编译开关/头文件等特殊应用,避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义。 全局变量是战略性资源,它决定了模块和模块间的耦合度,需在项目上提升到一个足够高的高度,慎用全局变量,不得不用的时候,要单独为每一个全局变量编写独立的操作模块或函数,在修改全局变量的时候,要检查是否有别的函数在调用它并且需要此数值保持稳定。 对变量代表某个特定含义的时候,尽量不要仅仅用位来代表什么,比如用某变量的第零位代表某个状态(0000 0001,其中仅用1代表某个内容,这样01H、03H、05H… 会有很多个组合都能代表这个状态);位容易受干扰被修改,信息出现错误的几率大很多。 也不要用00H、FFH等数据代表,就像我们面试一群人一样,第一个被面试人和最后一个被面试人容易被记住,00H和FFH亦然,系统默认状态是00和FF的时候较多,他们容易被复位或置位成这类数值。推荐以四位的二进制码的某个中间值为状态变量,如1001。 变量数据在应用之前宜作数据类型和数值范围的判断; 数据在存储过程中也容易出现问题,EEPROM、RAM等都有过类似的案例。数据出错时避免不了的,解决的办法是学花旗银行等美国金融企业,之所以在9.11后他们能很快恢复业务,基本没有数据方面的损失,原因何在?因为他们有异地容灾数据备份系统,知里面有两个关键词,异地、备份。我们的信息也同样,首先选择存在不同的介质中、或相同的介质但迥异的存放环境和位置下,双重备份的结局是两边不一致的时候,数据被怀疑并拒绝反映执行,但嵌入式软件很多时候是要靠数据来推动执行机构的,即使发现数据有问题也不允许行政不作为,这种情况下,作为我们也很难办,2个不同的数据,有明显问题的还好排除,都在有限范围内可如何判定哈?这种时候没办法只好三备份,少数服从多数是唯一的选择了。石头剪刀布的方式不好用,葛优的分歧终端机也不适用,就只好选择这种最原始最有效的办法了,唯一需要注意的是数据宜存放于三种不同的备份环境下,不然岂不成了你家哥俩儿,咋表决都占便宜啊。 以上仅就嵌入式软件可靠性的关注方面分了几大类,进行了基本的描述,实际应用中,需要关注的点还有很多很多,如果是准备自行制定设计规范的话,以上的思路应该也可以给与一些启迪了。(全文完) 《嵌入式软件可靠性设计要注意的问题》(上) 另外作者本人通过整理,完成了一份《嵌入式软件可靠性设计规范》,doc版本的25 页,也是呕心沥血了,另有一个ppt的培训课程讲义,诸位读者如果有兴趣的话,可以联系400-6800-965或wuyeqing@rdcoo.com,参加培训的话这两部分都可以提供,不过这可是收费的欧。希望读者不要骂我,兄弟闯荡江湖也不容易,也有一帮小弟等着吃饭呢,见谅见谅。
  • 热度 1
    2010-5-18 19:14
    647 次阅读|
    0 个评论
    我最近有个事情,打算在MINI2440基础上做一个简易的CCD采集系统,软件完成的功能是控制IO口的时序读取AD数值,并通过USB发送。我本人对 软件不算太了解,找比较清楚的兄弟帮忙编写一些代码。   报酬可以谈。 点击下载 《CCD软件程序任务书V1.0》 PS:后续的数据处理在电脑上完成希望可以移植至ARM里面处理,然后在自带的触摸屏上做基本的显示。 软件设计任务书(偶自 己写的)  
相关资源
  • 所需E币: 2
    时间: 2020-11-16 17:28
    大小: 3.87MB
    上传者: SnailWillow
    本文研究了基于通用无线充电硬件平台的嵌入式软件设计与实现,该嵌入式软件具备电能传输、功率控制,高水平垂直自由度等功能。论文首先研究了无线充电系统的基本原理,分析了半桥逆变、全桥逆变的拓扑结构特点,根据具体的需求制定了项目所遵守的规格书,按照规格书要求对嵌入式软件的平台进行了选型,并形成了通用平台的无线充电系统原理图;论文对嵌入式软件进行了概要设计,研究了系统的通讯架构,确定采用调制解调方式作为通讯链路,并完善了硬件原理图,选定了主控芯片;然后论文对无线充电发射端与接收端之间的协议从流程、编码、时序等方面进行了完整的分析与设计;论文针对当前传输协议的短板进行了补充,提出了新的负载识别方案、参数自升级方案、协议认证方案、功率控制方案等;最后根据完成的设计方案制作了工程样机并完成了嵌入式软件的设计编码,对其进行了测试,验证了通用的低功率无线充电系统嵌入式软件的正确性。
  • 所需E币: 5
    时间: 2019-12-26 10:43
    大小: 1.79MB
    上传者: givh79_163.com
    嵌入式系统及实时软件开发……
  • 所需E币: 3
    时间: 2019-12-26 10:42
    大小: 888.22KB
    上传者: 16245458_qq.com
    嵌入式软件测试讲解及CodeTest测试工具介绍……
  • 所需E币: 5
    时间: 2019-12-26 10:37
    大小: 395.57KB
    上传者: 二不过三
    风河公司的嵌入式软件集成开发环境……
  • 所需E币: 4
    时间: 2019-12-26 10:37
    大小: 322.15KB
    上传者: givh79_163.com
    博硕论文ARM处理器μCOS的嵌入式软件开发……
  • 所需E币: 3
    时间: 2019-12-26 10:20
    大小: 30.5KB
    上传者: 16245458_qq.com
    CodeTEST嵌入式软件在线测试与分析工具在嵌入式系统开发中的应用……
  • 所需E币: 5
    时间: 2019-12-26 01:20
    大小: 112.9KB
    上传者: 二不过三
    实时嵌入式软件的测试技术……
  • 所需E币: 5
    时间: 2019-12-26 01:16
    大小: 54.95KB
    上传者: wsu_w_hotmail.com
    嵌入式软件可靠性仿真测试系统研究……
  • 所需E币: 5
    时间: 2019-12-26 01:13
    大小: 847.08KB
    上传者: rdg1993
    基于模型驱动的嵌入式软件可视化开发Rhapsody5.0……
  • 所需E币: 4
    时间: 2019-12-26 00:56
    大小: 447.68KB
    上传者: 978461154_qq
    vxworkspowerpcbsp与ucos的移植--嵌入式软件的复用……
  • 所需E币: 5
    时间: 2019-12-25 22:48
    大小: 803.88KB
    上传者: 2iot
    本文介绍了DSPTMS320LF2407A和FAT32文件系统结构,分析了基于TMS320LF2407A支持FAT32文件系统结构的嵌入式软件实现……
  • 所需E币: 5
    时间: 2019-12-25 15:35
    大小: 279.47KB
    上传者: rdg1993
    分析了嵌入式软件的特点及测试方法;针对嵌入式软件的特点,提出了嵌入式软件系统测试中具有交互式错误检测定位功能的仿真系统架构设计模型,并结合铁路微机联锁系统的测试实例进行分析.嵌入式软件系统测试中的仿真系统结构设计刘志娟+罔智佳(中国科学院研究生院,北京100039)摘要:分析了嵌入式软件的特点及测试方法;针对嵌入式软件的特点,提出了嵌八式软件系统测试中具有交互式错误检测定位功能的仿真系统架构设计模型,并结合铁路微机联锁系统的测试实侧进行分析。关键谲:潮试方法仿真系统结构设计嵌入式软件1嵌入式系统概述1,2嵌入式鞍饽测试方法嵌入式系统是以计算机技术为基础,以应用为中软件测试是软件开发中的一个重要环节,嵌入式软心,并且软硬件可裁剪,适用于应用系统对功能、可靠件也不例外。图1给出了嵌人式软件测试的~般流程。健、戚本、体积、功耗有严拮要洙的专用计葵机系统。拯揞不同的指檬,软l牛测斌方法…有不同的划分方法。嵌^式软件是蒸于嵌人式系统设计的软件,是计算根据软件开发过程中测试所处的不同阶段可分为模}是机软件的一种,同样由程序及文档组成,可细分成系统测试、集成测试和系统测试;根据是否需要运行目标代软件、支撑软件、应用软件三类。摄人式软件大量波用码势为动态测试和静态测试;根据目标代码的可见性可于家鞠、工虢、商监、通讯……
  • 所需E币: 5
    时间: 2019-12-25 15:27
    大小: 39.47KB
    上传者: wsu_w_hotmail.com
    测试工具专栏……
  • 所需E币: 3
    时间: 2019-12-25 12:39
    大小: 47.35KB
    上传者: 微风DS
    嵌入式系统的发展……
  • 所需E币: 5
    时间: 2019-12-25 11:36
    大小: 210.33KB
    上传者: wsu_w_hotmail.com
    给出在VIM编辑器中实现对嵌入式软件调试功能的集成方法。首先,将VIM源码打上vimgdb补丁,使重新编译出来的VIM编辑器支持在其内部对调试器gdb的调用。然后,建立与安装适合调试嵌入式软件的gdb组件,并对vimgdb脚本进行适当的修改,使VIM可方便地在适合PC与嵌入式软件调试的gdb组件间切换。调试样例过程表明,在VIM中实现了对嵌入式软件的调试,而且,这种调试模式可行、高效。……
  • 所需E币: 3
    时间: 2019-6-7 18:41
    大小: 932.89KB
    上传者: royalark_912907664
    由于在众多的软件测试工具中,能自动检测共享资源冲突的软件非常少,而共享资源冲突问题是嵌入式软件研制中最常犯的、最不易发现、隐藏最深的问题之一,同时该问题一旦发生,带来的影响后果也极为严重,可能导致软件无法正常运行。为了解决这一问题,本文分析了共享资源冲突情况,并提出了一种针对嵌入式软件共享资源冲突问题检测的方案,使用C#语言编程,实现了自动检测系统,并进行了相关验证。
广告