《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》——01-04限制!限制!限制!

简介:

本节书摘来异步社区《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》一书中的第1章,第1.4节,作者:邱毅凌,更多章节内容可以访问云栖社区“异步社区”公众号查看

01-04限制!限制!限制!

嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜
PM:“这个组就是我们的固件组。你可以看到每个人桌上除了个人计算机外,有着各式各样的板子、仪器、文件和一堆不知名的线。前阵子大老板要我要求所有工程师保持桌子的整齐,我马上向他报告此事窒碍难行,不同领域的员工自有其工作模式,身为管理者必须为其创造最能发挥工作力的环境,不应该妄加限制。”

菜鸟:“好像负责固件的人数不是很多,面试时您曾提过除了正在开发的产品外,我们已经开始设计下一代的硬件平台。我以为开发阶段应该会有许多问题等待解决,而新的硬件平台设计应该需要更多的人力,但我们就这四五个人,够吗?”

PM:“确实不够,但这是我目前仅能挤出的人力,况且也不是每个人都适合做固件开发的。这样说吧,若非不得已,不会有任何一个军队指挥官,会把一条一公里的战线交给只剩15人的连队防守,基本上,只有15人的连队根本就是不合理的存在,然而,这是不得不的现实。”

菜鸟:“老板知道这样的事吗?”

PM:“当然,其实老板正是始作俑者之一!哪一位老板不希望用最少的资源创造最大的价值?公司存在的主要目的是什么?不就是营利吗?这就是我这个专业项目经理存在的原因之一。嵌入式系统开发本来就是限制重重的,人力缺乏只是其中之一而已,而我的责任就是妥善统筹资源、人力与时间分配。”

在1-3节中说明了嵌入式系统的多样性,接下来,我们从以下5个方面来说明嵌入式系统的另一个特性—限制。

产品规格设计
人力分配
进度管理
硬件设计
系统设计

1-4-1 产品规格的限制

嵌入式系统和一般软件项目有个显著的不同点,嵌入式系统完全应用于电子产品,而电子产品的开发必然牵涉硬件、结构、外观设计及其制造成本,也就是说,软件并不是某件电子产品是否热销的唯一原因1。

任何电子产品的开发计划都始于需求或创意,而创意的实现却往往被制造成本所限制, 也就是说,制定电子产品规格时必须有所节制,不能天马行空的无限想象。举例来说,要用国产车的造价,设计出奔驰同等级的车款,无异是缘木求鱼。成本会影响规格,而规格则会影响所有与开发有关的工作。生产电子产品必须在成本与规格上取得微妙的平衡,如果规格及制造成本都不愿让步,那就只能考验开发团队的能力了2。

偏偏现实世界是大部分的客户或制定产品规格的人员都高估工程师的能力了。确切地说,应该是高估了目前计算机与管理科学的水平。在PC上某些很简单的事情,要在8位CPU,或少得可怜的内存(可以想象整个系统的内存容量居然是以KB或byte为单位来计算的吗?)的平台上实作时,需要的算法有时都可用来写论文了。

结论是:因为制造成本的考虑,电子产品在制定规格时便限制重重,而产品规格更是直接影响了运行其中的嵌入式系统的开发。

1-4-2 人力分配的限制

嵌入式系统开发并不一定都是复杂的项目,例如“电子宠物机”就是一个技术简单、成本低廉的产品,但其所牵涉的人力或技术种类却肯定比一般软件项目要多。以下简单列出嵌入式系统开发流程不可或缺,但一般软件项目可能不需要的人力资源。

硬件设计工程师
PCB Layout工程师
PCB制作协助厂商
结构工程师
模具制造协助厂商
提供硬件零件的厂商(如CPU、设备IC、内存、LCD模块、电阻电容等)
固件工程师
硬件测试协助厂商
硬件品管及验货人员
工厂
即便只负责软件开发,也无可避免地要和其他单位协调与合作,如果软件工程师能稍具其他领域的知识与技能,对嵌入式系统的开发绝对大有裨益。但现实情况是要找到具备与其他领域人员沟通的热诚、管理协助厂商的能力,并兼具程序设计之外技能的软件工程师确实不多,只能让工程师从工作中学习,等工程师好不容易渐入佳境,却又要担心被其他公司挖角,这是每一位管理嵌入式系统项目的项目经理心中无法抹灭的痛!

嵌入式系统开发在人力资源上的限制不仅仅是项目人数的问题,主要是牵涉单位太多,而各单位各有自己的文化及语言,管理的复杂度自然大增,若想把所有相关单位都纳于同一公司或团队之内,或要求每位员工都必须多才多艺且可同时执行不同领域的工作,却也显得不切实际且成本过高。

嵌入式系统不一定比一般软件项目复杂(其实有些电子产品的软件简单的出奇),也不一定需要更多或更高素质的人力,但“人”的管理,绝对是嵌入式系统项目能否顺利结项最重要的因素之一。

1-4-3 进度管理的限制:测不准原理

嵌入式系统的进度计划(Schedule)管理与人力管理面对同样的问题与限制,即参与开发的单位通常很多。项目主管一方面要花时间精力协调各单位,以便精准控制进度;另一方面,某项任务的延误,往往会影响其他单位的开发,尤其当这个单位隶属于别家公司,甚至这家公司不在国内时,不理性的争执、责任的推诿以及语言与文化的隔阂,必然让进度延误的状况雪上加霜。

图1-15所示是个典型的嵌入式系统的进度计划表,你可以发现很多任务是有前后关系的,而这些任务之间又往往属于不同领域、牵涉到不同公司。实际上,因为不确定性因素太多,进度计划表几乎都是边做边修正的。

项目中的任务之间必然会有一些相依性。举例来说,硬件的延误会影响软件的开发,而驱动程序的开发延误也可能影响硬件设计的验证,产品规格迟迟无法确定,则会打乱其他开发单位的步调,零件供货商供货出问题,则会直接影响生产,若到开发中后期,某零件无法供应,则直接受冲击的将是硬件设计以及固件工程师,整体项目进度势必推迟。

以图1-15所示为例,最常发生的悲剧是所有时间表都是由预计量产时间点往前推导得来。举例来说,营销部门希望12月底产品可以上架贩卖,所以往前推12月5日必须开始量产,再往前推一个月必须做小量试产,也就是说,在11月5日前硬件所有问题都要解决并完成备料。再继续推演。假设公司规定试产后软硬件设计就不该再更动,那么,既然11月5日要小量试产,软件应该要在半个月前就绪,而根据经验,软件要经过3轮QC测试才能将所有问题解决完,所以推导出软件整合必须在10月初就完成,于是管理人员拍拍脑袋就把进度计划画出来了。

ca4473b2fb2e42d20430573e9735bb89c520424c

注意到了吗?上述推演是以销售时间推导量产时间,用量产时间推导硬件开发时间,再用硬件开发时间推导软件开发时间,其中完全没考虑到人力与规格复杂度,主事者的说法必然是:“如果软件没办法照我的计划完成,这个产品就无法如期上架销售,则项目视同失败,所以请大家尽量配合加班……”其中逻辑看似合理,其实相当荒谬,一个摆明无法执行的进度规划行同废纸一张。

而且嵌入式系统是软硬件整合,调试较为困难,测试负载量也较大。在产品应用日渐复杂的情况下,偏偏电子产品的生命周期越来越短,为求尽快将产品推到市场,开发时间往往被迫压缩。然而产品质量和上市时机(Time to Market)孰重孰轻没有一定的答案,要视情况而定,所以嵌入式系统开发的进度管理需要考虑的事情非常多,要订出合理且可满足质量与上市时间的开发进度,几乎是件不可能的任务。

身为项目经理,制定进度计划时只能秉持经验、知识与职业道德勉力为之。原则上,项目进入执行阶段就不该大幅度修改进度计划,但实际上,频繁的更改进度计划却是业界的常事。其实项目进度并不是测不准,主要是嵌入式系统项目牵涉的变量太多,偏偏预定上市时间又太赶,往往没做好完整的风险评估就贸然进入执行阶段,任何一件小事若发生推迟的状况,就可能对整个项目进度造成出乎意料的影响。

1-4-4 硬件设计的限制

嵌入式系统的硬件设计也是限制重重,成本考虑是造成这些限制的主因,其他会影响硬件设计的原因还包括:

产品规格与客户要求:产品规格当然会直接影响硬件设计,而负责制定产品规格的客户常常有些特殊的要求。例如,指定使用该集团子公司生产的零件,或要求硬件设计必须符合其旧有产品的结构。尤其是某些传统的国际大厂自有一堆内部标准,从键盘的反应时间、系统的耗电流、音频输出的质量、必须通过环境测试的种类,一直到零件采购公司的限制等。举例来说,通常这些大公司内部都有一份可采购零件的厂商清单,如果硬件设计者忽略了这个限制,到后期才发现可就麻烦了。若一开始不弄清楚客户的要求,等到产品试产之后才发现问题一堆,除了影响进度,势必影响工程师的士气以及公司之间的合作气氛。
CPU特性:CPU是电子产品的心脏,当CPU选定后,硬件设计才可随之展开,嵌入式系统使用的CPU往往不为人所熟知。举例来说,EPSON可不是只作打印机而已,他们的半导体部门根据特定的应用领域设计了一系列的嵌入式CPU。该CPU内部集成了许多外围芯片,如SDRAM、LCD Controller等,广泛地应用在诸如电子辞典或电子书等产品上。除此之外,许多硬件产商为特定应用自行设计的ASIC或SoC更是不胜枚举。
CPU的特性与功能直接影响其他部分的硬件设计,举例来说,若CPU的GPI/O(General Purpose I/O;CPU中可用于一般用途的输出或输入脚位)不够,则势必要外加扩展I/O电路或芯片,假若CPU有提供诸如I2C或I2S等通信接口,硬件设计者就可以选用支持此接口的外围芯片,因为这些接口可以把多个芯片串在同一个bus上,不但控制简单,还可节省I/O脚位。此外,嵌入式系统领域里的CPU通常集成了许多其他外围IC,如此可减轻硬件设计的复杂度与工作量。

CPU的选择对产品开发有着决定性影响,选择CPU时必须在性能、单价以及可用资源上取得平衡。基本上,工程师不必奢望会有性能远超过产品应用需求的CPU可用,这是嵌入式系统工程师的宿命!

耗电流:开发PC或Web应用程序时几乎不需考虑系统耗电的问题,但在许多产品应用上,尽量延长使用时间却是重要的规格或功能之一,手机是最容易明了的例子。要延长产品的使用时间,软硬件都要配合,硬件设计上除了使用更长效的充电电池之外,还必须花时间选用较省电的零件。为了在待机时可以尽可能的把没在动作的零件电源关闭,硬件设计时必须考虑到软件的需求,如选用CPU某根I/O脚来当作某个零件的电源开关。
产品Size大小及外观:结构设计也可能影响硬件设计。同样功能的硬件零件要“摆”在开发初期用的大板子(Target Board)与最终产品的小板子(Real Size Board),在硬件设计的困难度并不是在同一个等级上的!其中牵涉到Layout走线以及为了抗干扰所增加的硬件设计。
图1-16所示有两张比较图,其机器具有完全相同的电路设计,但因为最终产品外观结构不同,其中一台机器必须分为两块板子,就硬件设计而言,其复杂度自然较高。

e536472a634d6ce0317aedf8c6dbc239e76805e6

销售国家或地区:每个国家或区域对电子产品上市前要通过的检查标准都不同,简单地说,同样类型的产品,销售某些非洲国家和销售美国、欧洲、日本等已开发国家就可能采用不同的硬件设计(这样说并没有任何轻视非洲国家的意思)。往往硬件设计为了提升一点性能必须付出极大的代价,例如,CA认证标准要求产品的抗静电能力必须达到某个等级,但有些廉价的芯片抗静电能力就很差,要解决这个问题,要不就得加抗静电电路、修改结构或加铜箔保护,否则就只能更换主控芯片,除了成本增加外,也可能影响其他部分的硬件设计。
工厂制造与备料能力:这是一个常被项目经理或工程师忽略的因素,硬件工程师设计出来的东西,最终当然希望顺利大量生产,但选中的工厂却不见得有生产这些产品的能力。工厂并不是只有组装而已,同样以手机的例子来说,要验证生产在线手机半成品的通信功能需要昂贵的仪器,并非每间工厂都负担得起。此外,有时选择零件还必须考虑工厂的库存与备料的能力,所以硬件设计初期,最好就能和工厂人员确认设计是否可行。例如,这个产品要用到某个型号的Flash Memory(闪存),在设计定案之前,应该先了解工厂是否有烧录该Flash的能力(如支持该Flash的烧录器)。

1-4-5 软件系统设计的限制

嵌入式系统开发在软件上的限制显而易见,许多工作项目在一般软件开发项目上都是没有的,而本书大半的篇幅便是试图说明面对这个现实的因应之道,在此我们先列举如下。

不熟悉的CPU与硬件平台
不熟悉的开发环境
不易调试
CPU计算能力限制
内存容量限制
在不稳定的硬件平台上进行驱动程序开发
电源管理程序
工厂验证专用软件开发
嵌入式操作系统开发
仿真器开发
软硬件整合测试
稳定度与性能调整
Code Size调整
细节会在之后的章节陆续提到,本节仅用一个例子来说明嵌入式系统软件开发的“艰苦卓绝”。

在个人计算机CPU已迈入64位的时代,工作频率超过3 GHz,还可以多核心,内存容量从GB等级起跳,请想想,你可以用8 bit、2 MHz的CPU来做什么?

答案是任天堂电视游戏机(红白机),虽然这已是老古董了,且效果当然比不上PS23、PS3、Wii、Xbox 360等,但当你知道它的CPU是8 bit、1.77 MHz时,是否也对开发这个系统以及许多爱不释手游戏的软件工程师怀有钦佩之意?这是个20多年前的产品,当时许多软件技术都不如今日发达,他们是怎么做到的?即便其下一代主机“超级任天堂”的CPU也仅仅是16 Bit、3.68 MHz!

千万不要以为8 bit CPU的时代已经过去了,据统计,微控制器厂商(MCU)在产品布局是以8位微控制器为主力,其次为16位,主要锁定消费性应用市场。目前仍以8位微控制器的市场最大,就最典型的8位8051架构微控制器而言,全球一年的出货量就高达33亿个。这个数量已经明显大过个人计算机CPU的需求!

2001年嵌入式系统国际会议年会Jim Turley的报告中提到:根据统计报告,PC的数量只占CPU总销售量的0.1%,而且直到可预见的未来,这个悬殊的比例都不会有太大的改变。这就是嵌入式系统开发的业界生态—绝大部分的电子产品制造商,正使用着不为人所熟知的CPU,开发围绕你我生活的各种电子产品。

这也是嵌入式系统软件工程师的宿命之一,他们的价值不在于用过许多CPU,写过很多驱动程序,或开发过很多产品,而在于处处限制的情况下把产品开发出来,这意味着清晰的计算机系统概念、高效能的算法、良好的程序写作习惯以及有效率的资源管理。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
11天前
|
小程序 前端开发 API
微信小程序全栈开发中的异常处理与日志记录
【4月更文挑战第12天】本文探讨了微信小程序全栈开发中的异常处理和日志记录,强调其对确保应用稳定性和用户体验的重要性。异常处理涵盖前端(网络、页面跳转、用户输入、逻辑异常)和后端(数据库、API、业务逻辑)方面;日志记录则关注关键操作和异常情况的追踪。实践中,前端可利用try-catch处理异常,后端借助日志框架记录异常,同时采用集中式日志管理工具提升分析效率。开发者应注意安全性、性能和团队协作,以优化异常处理与日志记录流程。
|
2月前
|
数据库
什么是计算机软件开发领域的 verbose 代码和日志
什么是计算机软件开发领域的 verbose 代码和日志
31 0
|
3月前
|
调度
kettle开发篇-写日志
kettle开发篇-写日志
87 0
|
2月前
|
供应链 Java 测试技术
开发Java应用时如何用好Log
开发Java应用时如何用好Log
72 3
|
5月前
|
监控 Java
Springboot开发系统记录操作日志
Springboot开发系统记录操作日志
94 3
|
7月前
|
人工智能 运维 监控
在日常开发工作中,日志数据该如何利用?
在日常开发工作中,日志数据是一个宝贵的资源,它可以提供关于应用程序运行状态、错误报告、性能指标和用户行为等方面的重要信息。正确地利用和分析日志数据可以帮助开发人员更好地理解应用程序的运行情况,快速定位和解决问题,改进应用程序的性能,并为业务决策提供有力支持。尤其是在现代科技发展的背景下,日志数据作为一种重要的信息资源,对于运维工作具有极大的价值。然而,如何充分利用日志数据,并将其应用于运维和开发工作中,仍然是许多企业和运维和开发人员关注的问题。那么本文就来分享一下在日常开发中关于日志数据的利用方面的探讨。
130 1
在日常开发工作中,日志数据该如何利用?
|
9月前
|
XML SQL Java
Spring Boot + vue-element 开发个人博客项目实战教程(二十、登录日志、用户、分类管理页面开发)2
Spring Boot + vue-element 开发个人博客项目实战教程(二十、登录日志、用户、分类管理页面开发)2
68 0
|
9月前
|
前端开发 NoSQL Java
Spring Boot + vue-element 开发个人博客项目实战教程(二十、登录日志、用户、分类管理页面开发)1
Spring Boot + vue-element 开发个人博客项目实战教程(二十、登录日志、用户、分类管理页面开发)1
113 0
|
9月前
|
JSON 前端开发 NoSQL
Spring Boot + vue-element 开发个人博客项目实战教程(十九、日志中心页面接口对接)2
Spring Boot + vue-element 开发个人博客项目实战教程(十九、日志中心页面接口对接)2
53 0
Spring Boot + vue-element 开发个人博客项目实战教程(十九、日志中心页面接口对接)2
|
9月前
|
前端开发 JavaScript Java
Spring Boot + vue-element 开发个人博客项目实战教程(十九、日志中心页面接口对接)1
Spring Boot + vue-element 开发个人博客项目实战教程(十九、日志中心页面接口对接)1
130 0

热门文章

最新文章