嵌入式软件主程序结构的问题

[mjs00]

小弟在写一个发动机控制器的软件，设计需求是实现对发动机的速度控制，再加上对操作台上几个按钮进行响应。开发平台是一款 ARM 芯片，开发语言是 C 。

整个程序的结构非常简单。没有用操作系统，只用了一个超级循环。程序里唯一用到的中断源是片内测速模块的中断，中断始终打开。整个程序的执行过程就是初始化后在循环里反复读取输入(操作台命令、环境温度、压力等)、运行控制逻辑、执行输出，并且时不时进入测速中断读一下速度。

之前写这样的程序时没考虑过时间概念，执行到哪算哪。最近看到 Simulink 生成的代码的样例程序里有一个步长的概念，比如说每多少毫秒执行一次主循环。想问的是：

1. 这种定频率执行是不是一种好的设计，和不计时埋头执行的程序相比优点在哪？在没到设定周期的等待时间里程序做点什么呢？
2. 怎么实现按频率运行？是使用芯片内部的定时器模块(多少时间触发一次)，还是使用计数器(累加器加到多少运行一次)？前者对时间把控准确，但定时器模块故障时直接停机，不够安全。后者虽然安全，但计数器计时并不准确。

顺便，很想请教下嵌入式软件领域有哪些比较好的架构、安全 /可靠性方面的书籍或材料？求大佬指点。

[summer20100514]

嵌入式系统的实时性是，在规定的 deadline 之前一定能完成某个任务。可以顺着这个去查资料。

[zjqzxc]

问题 2：如果使用计数器累加，在累加计数期间 cpu 只能做一件事：累加，别的啥也干不了了。
应对简单的需求比如闪烁一颗 led 灯这没问题，但是实际的多任务工作场景中这就很局限了。
此外，使用定时器，可以启动定时器后把 cpu 进入到低功耗模式，使用累加计时的时候 cpu 需要持续工作，费电且发热大。不过你是控制发动机的，这点电和热量倒是无所谓。

另外，定时器模块故障的这种情况绝大多数时候可以不用考虑，而且现代 MCU 里很多都有不止一个定时器。不过没研究过他们是不是完全独立的。

至于问题 1：只执行一个任务的时候感觉不到有啥区别。如果有多个时间间隔不同的任务交替执行的时候就能感觉出来差别的

[shayuvpn0001]

定时触发任务是由中断来实现的，不会一直占用 CPU 资源。