1. 项目介绍
![](https://img-blog.csdn.net/20140819094541296)
![](https://img-blog.csdn.net/20140819094554078)
![](https://img-blog.csdn.net/20140819094818973)
在NINJA设备上支持RTM-ISDN卡
RTM-ISDN卡硬件组成
主要组成单元
C6415: DSP
PEB383(上图中的PEX8112改为PEB383,由于后者具有NT功能): PCIE2PCI bridge
PEF22554: FALC E1/T1 framer
LC4256V: CPLD
2. 完毕情况及时间
number | item | class | status | date | used |
1 | RTM-ISDN study | design | finished | 9 | 9 |
2 | RTM-ISDN card platform software design | design | finished | 5 | 5 |
3 | RTM-ISDN setup development environment | coding | finished | 1.5 | 1.5 |
4 | RTM-ISDN card PCIE bridge setting | coding | finished | 2 | 2 |
5 | RTM-ISDN card RTM-DSP loading coding | coding | finished | 4 | 4 |
6 | RTM-ISDN card PCIE bridge bring up | debug | finished | 2.5 | 2.5 |
7 | RTM-ISDN card RTM-DSP loading bring up | debug | finished | 2 | 2 |
8 | RTM-ISDN card host communicate coding | coding | finished | 5.5 | 5.5 |
9 | RTM-ISDN card host communicate debug | debug | finished | 8 | 8 |
10 | RTM-ISDN card new feature for HQA | coding | finished | 2 | 2 |
11 | RTM-ISDN setup DSP Debug environment | debug | finished | 2 | 2 |
12 | RTM-ISDN QuadFALC HQA PRBS test support | support | finished | 6 | 6 |
13 | RTM-ISDN diag and monitor | coding | finished | 12 | 12 |
14 | RTM-ISDN diag and monitor debug support | support | ongoing | 5 | 0 |
15 | RTM-ISDN code rebase | support | finished | 3 | 3 |
16 | RTM-ISDN FCT | coding | finished | 12 | 12 |
17 | NINJA FCT V3.5 debug | debug | ongoing | 3 | 0 |
18 | RTM-ISDN hardware debugging support | support | suspend | 10 | 6 |
19 | RTM-ISDN software debugging support | support | ongoing | 10 | 8 |
3. 项目总结
3.1 统计
Row Labels | Sum of date |
coding | 39 |
debug | 17.5 |
design | 14 |
support | 34 |
Grand Total | 104.5 |
3.2 项目中做的好的地方
3.2.1 design部分
前期design工作非常有效果,后期工作都採用design的预设方案。
coding部分和debug部分工作量对照37:17说明了预设方案的成熟与可靠。
架构设计採用五视图方法
系统架构设计中五视图的功能
逻辑架构:关注功能。不仅包含用户可见的功能。也包含一些基础模块以及辅助模块。
开发架构:关注程序包,不仅包含要编写的程序,还包含能够直接使用的第三方SDK或者现成的框架、类库以及开发的系统将执行于其上的系统软件或者中间件。
执行架构:关注进程、线程、对象等执行时概念。以及相关的并发、同步、通信等问题。
物理架构:关注‘目标程序及其依赖的执行库和系统软件’终于怎样安装或部署到物理机器,以及怎样部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。
数据架构:关注持久化数据的存储方案。不仅包含实体及事实上体关系的数据存储格式,还包含数据传递、数据复制和数据同步等策略。
平台软件架构中五视图的功能
逻辑架构:关注功能。
从需求提炼出平台软件功能,注重功能的逻辑性和完整性。
开发架构:关注模块。分解组合平台软件功能到各个功能模块。注重功能模块间关系,确定开发顺序。
执行架构:关注平台层机制执行时逻辑。
物理架构:关注功能模块和功能模块组成程序包的部署。
数据架构:关注数据的存储方案。
物理架构图,体现功能模块在各个子系统中的部署情况。
RTM-DSP时钟同步机制执行架构
RTM-DSP stream 通信数据架构
RTM-DSP系统的bootup,recover和upgrade逻辑架构
RTM-DSP平台软件开发架构
3.2.2 需求部分
对硬件project师提出需求
提供硬件信息,包含芯片所需电源,时钟,控制总线和数据总线信息
避免软件和硬件设计不匹配,方便排查低级错误。
对于FCT需求
帮助MFGproject师确定FCT需求。
提供FCT设计草案。并提供每一个測试环节数据流图,使MFGproject师在了解系统的情况下合理确定FCT需求。
3.3 项目中做的不好的地方
3.3.1 support部分
support花费时间较多,眼下已占33%。
个人觉得原因是架构设计时将RTM-DSP定位为黑盒系统,导致没有安排DSPproject师负责。
尽管,以色列执行RTM-DSP系统7年时间,说明其足够稳定和可靠。
可是。硬件和APP都有修改。硬件和APP对自己的部分也不是非常熟。出问题后都想从RTM-DSP系统获取信息。
还有,RTM-DSP缺乏对应的測试工具证明自己工作正常。
不应该将RTM-DSP定位为黑盒系统。应该安排DSPproject师负责,降低对RTM-DSP系统猜疑。节省时间和精力
,加快进度
。
3.3.2 设计部分
尽管和硬件相关项目不太适合使用敏捷开发,可是需求不会100%完整,也不会没有需求变更。
须要借鉴敏捷开发。灵活应对需求变化。
3.3.3 debug部分
缺乏各层通信验证工具
此次因为底层通信涉及L3 L4。验证工具开发平台project师无法独立完毕。
假设可以尽早开发出合适的验证工具,一旦验证通过,一方面能排除平台软件问题,
给予APP信心。定位问题时不走错方向
,
还有一方面平台软件project师可
尽早抽出精力做其它部分工作。