有这样一个问题？
在嵌入式开发中，软件是怎样知道硬件行为，硬件又是怎样接受软件操作的。这个问题涉及到硬件和软件相关的知识。为了清楚这个问题，查阅了相关资料，将其总结记录在下，如果有一些开发经历就能更加深入理解了。
一、硬件事件（Event）的通知——硬件告知软件
在设计软件时，需要被告知硬件中发生的事件，事件可以分为两大类：
（1）一是软件引发事件，由嵌入式软件下达给硬件的任务时所引发的事件，例如对外的I/O数据包的传输。
（2）二是外部事件，外部触发的事件，如异步输入I/O数据包。
硬件向软件通知事件，以便采取合适的处理措施。那么具体的通知方法有4中，如下：
（1）无通知：该种情况很糟糕，软件必须猜测什么时候能采取下一步的措施。在嵌入式设计中一般不会采取该种方式。
（2）时间延迟（以时间为触发条件）：对于软件引发的事件，软件可以设定一个定时器，在采取下一步措施之前需要等待一定时间。若延迟很长并且响应也不需要很精确，软件可以使用操作系统的超时支持。若延时很短，没有硬件支持软件就很难知道花费了多长时间了。
（3）状态位：事件发生时硬件会设定一个状态位，软件要检查这一位，如有必要还需要进行轮训，直到事件发生。如果事件是软件触发的并且很快就要发生，那么状态位正常；否则软件必须轮训，占用带宽直到事件发生。该种方式较为常用。
（4）中断位：这是硬件向软件通知事件的最佳方式。因为这允许软件在事件发生处理其他的任务，这对于外部引发的的和由软件引发的要花一些时间才能完成的事件来说效果更好。该种方式较为常用。
综上 ：第一点来说，在开发中不会采用。对于第二点，需要延迟时间来等待事件发生，把握事件发生时刻相当重要。对于第三点，利用软件轮询方式查询事件是否发生，将会占用一定计算资源。对于第四点来说，对多个
中断的处理，意味着对多个中断服务的响应和执行。
硬件最佳实践《嵌入式软件工程》：
对软件需要知道的所有事件或情况提供指示。如果要处理非指示性的硬件事件，尽量处理好事件延迟，但一定要清楚地对代码进行注释，以提醒该程序未来的维护者。
二、软件向硬件下达任务
当软件需要向硬件下达任务时，软件多会向一队列位写1，结束后硬件清0 。在一些设计中，由软件向这一位置1之后又由软件清0，改位R/W是Read/Write的缩写，这样需格外注意，因为：
（1）如果在软件还没检测到这一位之前软件就对他清0了，那么硬件就有可能不知道要运行这一任务。
（2）软件使某一位置1时间太长。硬件处理完任务以后发现这一位是置1的，由于高优先级任务或软件的延迟导致没能及时对这一位清0，使硬件有可能又执行了一次该任务。
综上，由于可能存在以上的一些风险，应该使用队列位而不是读写位给硬件下达任务，队列位提供了硬件和软件之间的良好握手。
1）软件读取队列位
2）如果为0的话可以由软件对这一位置1，通知硬件执行任务
3）置1后，软件可以查询硬件位，直到硬件清0。清0后，软件直到硬件检查到了这一位并执行任务。
4）硬件会偶尔检查这一位
5）硬件检测到这一位被置1后就可以执行任务。
6）硬件开始任务后并使队列位清0.
硬件最佳实践《嵌入式软件工程》：
设置一个由软件置1由硬件清0的队列位来在模块中启动任务。如果一个硬件任务是伴随着R/W位下达的，一定要仔细检查，因为太短或太长都可能出现问题，需记录下软件在做什么以此来解决这些问题。
三、总结
以上内容总结了嵌入式系统设计中，硬件和软件之间的协同关系。在具体的开发工程中，需根据具体硬件芯片，电路设计，芯片开发文档来进行软件设计。硬件与软件之间的协同运行关系的具体逻辑、软件配置方法，都需
要体现在程序代码设计中。所以理解掌握软件和硬件之间协同关系对系统开发较为重要。