衔接软硬的HAL
近日特权同学对系统架构思考得很多,虽然工作中还多是在做模块化的半成品,但是越来越感觉到构建一个软硬件协同开发平台的必要性。无论从个人偏好还是开发灵活性上来说,Altera的NIOS2都是一个很好的选择。
晚上专门看了几篇阐述HAL概念的application note,我想我是受益匪浅,对一些过去不曾深入思索过的东西有了一个更清晰的看见,也很是惊叹软硬件设计衔接上的微妙关系。不禁要发出 “人类太有才了” 的赞叹,当然了,归根结底,是要感谢那位说“我们要按着我们的形象和样式造人”的宇宙主宰者了。
首先,很推荐各位有心的看官去瞅瞅下面几篇不错的文章,也许写得比我精彩,说得比我有深度。
《NIOS整体开发结构基础》、《Nios ii设备管理分析》。
如果单从逻辑角度来看,一个NIOS2系统可以归结为如图1所示的简单示意。在最底层,也就是Nios II Processor System Hardware,基本上是一些最基本的逻辑门电路,它用于实现整个系统的外设协议,也可以理解为这个层之间和FPGA外部的各种芯片或接口打交道,比如简单的你可以在这个层实现一个GPIO控制流水灯或是做一些脉冲采集和中断沿触发的功能;复杂一点可以在这个层实现一个SD卡控制器、USB控制器、CAN总线控制器等等;再复杂一些恐怕你也可以去做一些压缩算法或是图像识别算法;总之,用户尽可以在这个层发挥FPGA的灵活性、实时性。而向上的Device Driver层,实际上在前面提Nios II Processor System Hardware层时应该提到它,他们是协同工作来完成各种各样的控制器设计的。Nios II Processor System Hardware层趋向于直接和硬件接口的实现,而Device Driver往往是利用一串串又长又臭的状态机来实现更复杂一些的控制,同时也在这里实现一些上层可访问的总线从接口,以及一些用于控制他们本身的寄存器访问接口。
再往上,暂且不说HAL API这个层,我们先讨论User Program这个层,也就是用户程序执行的层,它就是系统的软件开发部分。用户在这个层通常不需要傻乎乎的写程序用GPIO再去模拟SPI协议、IIC协议或是FLASH的读写时序(在单片机上我们经常干这种傻事的)。在NIOS2中,看到最多的可能也就是调用诸如printf();IOWR (BASE,0x0); IORD (BASE,0x0);之类的函数而已。实际上很多的外设接口就是通过这些简单函数的调用,从而读写一些相关的寄存器,这些寄存器都是在Device Driver中设计好的。
图1
最后来说HAL API,在NIOS2系统中,它其实从某种意义上可以理解为就是Alalone总线,总线在一个处理器系统中的重要性毋庸置疑,Device Driver层需要实现和这个系统总线相连的从接口。而处理器在软件编程时只要一个简单的IOWR或IORD函数就能够发起一次总线主接口的时序,这个时序通过不同的片选或是地址来区别访问不同的外设。从软件实现上看,只要用户添加好一些定义着相应地址的.h头文件,正确的访问这些外设的地址即可。
图2
有了这个HAL,实际上能够给整个系统开发带来很多的便利,如用户可以直接利用newlib ANSI C标准库函数来开发软件;可以在硬件底层就做好了整个系统外设的初始化(软件开发者根本不需要关心这些底层硬件的任何细节);另一个很大的好处是让硬件驱动开发者和软件设计者各司其责,更加专注于自己分内的工作,只一个总线就完成了相互之间的衔接。
如图3所示,从一个简单的SPI外设的系统集成可以看出,软硬件的衔接不过就是avalone总线的主从机的结合而已。
图3
文章评论(0条评论)
登录后参与讨论