如何看待HAL层

[硬件拾遗]

例如，有个设备是IIC通讯，需要IO模拟IIC，可以定义hal_iic_init()，hal_iic_start()，然后设备驱动调用这些接口，如果这样，驱动层在HAL层之上，应用层不会调用HAL层，只会调用驱动层。
可如果设备是片上外设，比如ADC，如果定义hal_adc_init()，这时应用层直接调用HAL层，还是把ADC初始化放在驱动层，可如果放在驱动层，它就是一个初始化函数，感觉没什么意义。

[硬件拾遗]

软件框架设计中，又遇到个问题：设备层和应用层如何数据交互？

[硬件拾遗]

就在此记录一下对软件分层的思考吧。
采用面向对象的思想，不管是片上外设还是其他设备，每一个都看作是独立的设备，比如片上ADC1，ADC2这是两个设备，每个设备都有自己的驱动程序，因为这里以设备为中心，故将驱动层改为设备层，有的设备需要片上外设支持，比如IO操作，所以设备层里有个HAL层，对于片上外设，就没有HAL层。
强调一下，这里HAL层属于设备层，是设备驱动程序的一部分，移植的时候，修改HAL层即可。

[硬件拾遗]

虽然数据来源于设备，但需要什么样的数据，如何处理数据却取决于应用层，不同的应用可能需要不同的数据，所以将所有的数据定义放在应用层。
数据交互以函数返回值方式或者形参的方式进行，形参可以是值传递或地址传递，具体选择哪一种，实践中再考虑。
主要原则：只在应用层定义数据。

[fuchouzhe]

嵌入式系统的软件分层是有针对性的，基于裸机的编程和调度器（freertos，ucos等）还有专用的VxWorks、linux、wince的分层不会完全一致 一般来说，像控制软件大部分无界面，没有太多移植性要求，不要过度封装，例如将电压采集拆分成adc操作和输出电压计算两部分。 也许你会说，可以有片上ADC和SPI/IIC的ADC，但此时可以直接重写电压采集对应的文件。因为通常嵌入式系统软件规模不大，否则干脆像VxWorks或linux等系统直接写个驱动程序，还能实现动态加载。

[硬件拾遗]

首先感谢楼上的评论，希望大家多多提点意见，个人总有想不到的地方，众人拾柴火焰高。 楼上说分层基于操作系统，这符合传统的操作系统原理，因为最基本的原则，操作系统管理硬件，提供接口。不过我这里不打算以操作系统为核心，而是打算以设备为核心，原因有二，一是因为嵌入式主要还是要和各种硬件打交道，二是设备相对独立，天生可裁剪。而操作系统的功能，只保留任务调度和管理，而且是以服务的方式提供，还有信号量、消息队列、定时器等，以及各类软件功能，比如FIFO、CRC、PID等都以独立的服务方式提供。 关于重写这一点，说说我的真实经验吧，因为就像楼上说的，基本上不同的项目，程序我都是重新写过，说实话，是不大，写起来也不难。可这样每个程序都各具特色，就算相同的功能，实现也不一样，当然复制粘贴的除外，如果真的重写，今年和去年的想法还是会有点区别的。这也是我想设计一个程序框架的主要原因，因为如果都用一个框架，就算想法变了，可以算作框架的升级，这是一个持续的过程，不像在每个程序里的变动，杂乱无法延续。