2016-6-30 工作总结
姓名 |
王奈 |
时间 |
2016年6月30日 |
学习内容 |
与课设有关: 依照小组成员发现的数据获取模块中的问题,我对数据获取模块的各种图结构进行了一些修改。 自己学习: 继续昨天的学习,今天我又对在嵌入式开发中的空间复杂度的问题做了一些研究。关于嵌入式芯片的存储结构,之前我们在各种体系结构,系统结构,微机接口课程中多少有些涉及。现在市面上常用的芯片数据宽度多为8位或者16位。这样设计的原因我认为是出于应用角度与计算角度的综合考虑所得出的折衷方案。比如,一个电冰箱的控制系统,自然用不到64位或者更高位数的数字来表示一些参数,成本高,而且没有必要。因此,一个嵌入式系统的存储结构宽度也就可以确定下来。宽度小,所能表示的数字范围也不大,导致寻址空间减小,使得在嵌入式系统中,几百kb的存储体大小十分常见,并不能提供如同日常使用的计算机动辄几个G几个T的存储空间。因此,类似于之前提到的代码复杂度一样,在嵌入式系统的开发中,保留的数据也应当是最有用的数据,并且那些最频繁使用的数据应放在最易获得的位置上面。这些工作,有些可以被编译器发现并且优化,而更多的需要编程人员的注意以及编程习惯。比如,在传统程序编写中,在一个循环体中声明新的变量是很正常的事情,但是在嵌入式开发中,这种做法极容易占据有限的动态内存,因此需要考虑数据的作用域,以决定是否将变量的声明放在循环体的外边,当然还是要以正确性为前提。 除此之外,像一些高级的数据结构,比如链表,以及各种类型的索引表,树,图,我想都不适用于嵌入式系统的开发,因为这些结构注重的可能不是存储而是查找的效率或者别的侧重点上,由此而引入的额外代价更需要去考虑是否值得这样去做。 在今天的开发中,我使用的是数组存储数据并且采用间接寻址的方法获取数据,这样做可以提供比较低的时间复杂度与空间复杂度。 |
所遇问题 |
空间有限,存储体利用率不高 |
解决方案 |
不断地发现可优化之处并改正之。 |
posted on 2016-06-30 22:14 13070006王奈 阅读(188) 评论(1) 编辑 收藏 举报