DSP

我对嵌入式底层开发学习的一点看法

2019-07-13 19:11发布

站内文章 / DSP
16553 0 1282
不知不觉中，学习嵌入式已经有差不多两年的时间了，从大二的时候开始学习 DSP ，现到开始接触 ARM9 ，有很大的感触，所以写出来，让大家进行指正，首先说明，这些只是个人学习中的看法，如果你，我亲爱的读者，我的看法与你的不同，那么请把你的看法分享出来。让本人也进行一下学习。       在老师的要求下。把 51 单片机着为入门嵌入式的接触 MCU ，现在想起来，老师做得很对，因为他当时要求我在两个月的时间内把 51 开发板板上的接口驱动都写出来，但是，不要求我把 51 搞太长的时间。只要知道怎么进行控制外设，但是有一点。 UART ， IIC ， SPI 等常见的驱动程序设计必须了解其真正的原理。这为后来的学习打下了强有力的基础。      在大二的暑假，由于项目的关系，开始接触 TMS320F2812 DSP ，老师没有说什么，给我一本 2812 芯片手册，再给一个仿真器，一个开发板，就让我在一天之内完成一个 LED 点阵进行显示汉字。还好，看了一天的芯片手册，在晚上的时候把 GPIO 看了一下，加上在 51 的时候也写过数码管的实验，所以，不一会儿就写出来。之后的所有的接口驱动都是一边看手册一边写驱动。由于 DSP 更偏重于算法。对 LCD 的支持不太好，所以不得不又得了解一下 ARM 。      在学习 ARM 的过程中，我个人认为最重要几章应该是前 10 章，加上后面的中断控制这一章，这几章才是 ARM 体系结构的重点，看一下开发板的起动程序，特别对 MMU 的重定向不是那么简单，小弟不才，到现在还不敢自己动手写起启动程序。后面的接口驱动程序与其它的 MCU 的差不多，就只是寄存器的配置不同罢了。      眼下 Linux 与 WCE 这两个操作系统在嵌入比较热，所以有很多初学者都只去进行学习基于操作系统的驱动程序开发，其实，以其说那叫驱动程序开发，还不如是调用驱动程序模块功能函数开发。因为操作系统中已经对很多的接口驱动进行了模块化，所以，只需进行相应的调用与注册，管理就可以实现对硬件的控制，可是，各位有没有想过，你真正的操作硬件还是别人给你屏蔽了硬件。      所以，个人认为，如果想真正的了解驱动程序的实现过程。还是基于裸机的驱动程序更加好，因为这样可以让你真正的知道某个接口是怎么进行驱动的，这样对个人的能力的修行应该更加为重要，因为学嘛，总得自己的能力提高。不要搞到最后没有操作系统就不知道怎么写一个驱动程序。这意味着什么呢。在论坛上经常见到寻找 Linux 内核 API 的问题，如果真正的动手开发过裸机的驱动程序，直接到内核里的相应位置去看 .H ，或者 .C 文件，这样不就知道操作系统提供给我们的接口函数了嘛。还能更加清楚各个参数的约束条件。      当然，如果是产品化的驱动程序，还是基于操作系的驱动更好，因为操作系统模块化的驱动程序都是经过严格的测试的，经典的程序，这样对产品的开发周期与产品的稳定性可以得到保证。      不管什么方向，牛人都是从基础一步一步的走出来的，因为他们对每一个接口驱动都了解，所以，他们写出来的基于操作系统的驱动程序，那是一件艺术品，是经过效率考虑后的成品。不真正了解接口驱动实现的人写出来的基于操作系统的驱动程序，那是代码的堆砌，形似而神非。对于嵌入式这一个特殊行业，需要的是神真而非形似，这就是底层驱动程序的特别之处。      所以，对于初学者来说，特别向我这样的初学者，在实验过程中最好先写基于裸机的驱动程序，再去看看别人写的，对照一下，这样对个人的能力提高有很大的帮助。当裸机驱动程序达到令自己满意后，再去写基于操作系统的驱动程序，这样你会对这一接口驱动有一个质的提高而非好像懂了，其实什么也不懂。         其实 ,uC/OS-II 是一个最不错的学习系统，因为其只提供我们内核的调度，所以，要想真正的了解内核调度，多任务的实现过程等， uC/OS-II 是一个不错的选择，虽然 ARM9 以上的 CPU 跑 uC/OS-II 有点浪费资源，但是对学习来说，这是一个很好的操作系统，因为每一个接口的驱动程序都得自己动手一个字节一个字节的写入，同时信号量的控制，多任务的创建，同步异步机制，死锁等问题都得自己去思考。        好了，说了这么多，也不知道自己说得对不对，对与不对，请给予指正。  

热门文章