📄 alert_overview.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage Express 2.0">
<title>Basic Embedded Real-Time (Operating System) for micro-controller applications - freeware</title>
</head>
<body bgcolor="#FFFFFF">
<p align="center"><font color="#800000" size="4" face="Tahoma">ALERT:
"A Light Embedded Real-Time" operating system for micro-controllers</font></p>
<hr>
<p><font color="#000040" size="4" face="Tahoma">ALERT features...</font></p>
<p><font color="#000040" size="2" face="Tahoma">The kernel module
(rtos.c) contains support code and device interface functions for</font><font
color="#000040" size="1" face="Tahoma">:</font></p>
<ul>
<li><font color="#000040" size="2" face="Tahoma">Foreground
tasks: RTI "tick" handler and real-time clock/calendar</font></li>
<li><font color="#000040" size="2" face="Tahoma">Background
task scheduler & dispatcher; periodic and "ad-hoc"
task control</font></li>
<li><font color="#000040" size="2" face="Tahoma">SCI (UART)
serial I/O handlers (interrupt-driven, with FIFO buffer
for received data)</font></li>
<li><font color="#000040" size="2" face="Tahoma">LED
indicators; preset flash modes (rate & duty cycle) </font></li>
<li><font color="#000040" size="2" face="Tahoma">USB slave
controller drivers ("Virtual UART", AT89C5131
target)</font></li>
<li><font color="#000040" size="2" face="Tahoma">EEPROM
support functions and background task (AT89C5131 target)</font></li>
</ul>
<p><font color="#000040" size="2" face="Tahoma">The kernel is
easily scalable to include required features and to exclude
unwanted features.</font></p>
<p><font color="#000040" size="2" face="Tahoma">ALERT provides
additional code to support these options...</font></p>
<ul>
<li><font color="#000040" size="2" face="Tahoma"><strong>Command-line
user interface (CLI)</strong> for service/debug port
facility -- in module "cmnd.c"</font></li>
<li><font color="#000040" size="2" face="Tahoma"><strong>Resident
"debug monitor"</strong> with (optional) 8051
disassembler -- also in module "cmnd.c"</font></li>
</ul>
<p><font color="#000040" size="2" face="Tahoma">The application
firmware only needs to include required RTOS support modules. </font></p>
<p><font color="#800000" size="2" face="Tahoma"><strong>ALERT
will allow you to implement small embedded applications with many
of the benefits of a more sophisticated RTOS, e.g. robustness and
reliability of execution, ease of code maintenance and extension,
but with minimal overheads on processor and memory.</strong></font></p>
<hr>
<p><font color="#000040" size="4" face="Tahoma">Characteristics
of ALERT</font></p>
<p><font color="#000040" size="2" face="Tahoma"><strong>ALERT
supports simple "Foreground/Background" processing</strong>,
where background tasks may be interrupted by foreground tasks. (A
"foreground" task is any interrupting task.) The kernel
provides a task scheduler for periodic background tasks.
Simplicity is achieved by compromise... of course.</font></p>
<p><font color="#000040" size="2" face="Tahoma"><strong>The
overall philosophy is to put as much as possible of the
application code into background processes</strong>, i.e.
scheduled tasks and the (optional) Command Line Interface (CLI).
Background tasks are best implemented using a "state machine"
model of some sort, because they are not permitted to cause
delays. In this minimal RTOS design, background tasks have only
two possible "status" values: ACTIVE and SUSPENDED.
Active tasks are executed in a round-robin sequence. When a task
is complete, it sets its own status to Suspended.</font></p>
<p><font color="#000040" size="2" face="Tahoma"><strong>Background
tasks are not time-critical, but must have short execution times
on each call</strong>, so that the sum of all B/G tasks execution
times is normally less than the minimum B/G task period.
Occasional overruns can be tolerated, as long as not excessive in
duration or frequency. (The definitions of "occasional"
and "excessive" depend on the application and the
watchdog time-out interval!) Background task overruns are
monitored by the kernel, for diagnostic purposes.</font></p>
<p><font color="#000040" size="2" face="Tahoma"><strong>Background
tasks may be scheduled periodically by the Task Scheduler, or
they may be invoked on an 'ad hoc' basis, as required, e.g. by a
CLI command function or by another task.</strong> </font></p>
<p><font color="#000040" size="2" face="Tahoma"><strong>Tasks are
not permitted to contain "wait loops".</strong> If a
process involves waiting for some external event to happen, e.g.
a delay timer to expire, or another task to complete, or whatever,
the process should be implemented as a "state machine".
While a task is "stuck" in the same state, waiting for
an event to occur before it can advance to a subsequent state, it
should return immediately but remain in the ACTIVE state. This
has the effect of allowing all other Active tasks to execute
without disruption.</font></p>
<p><font color="#000040" size="2" face="Tahoma"><strong>In any
RTOS, care must be taken to prevent data corruption during data
transfers between tasks. </strong>More sophisticated RTOS's use
semaphores, message queues, etc, to control inter-task data
communications. ALERT uses a simpler, more efficient approach...</font></p>
<p><font color="#000040" size="2" face="Tahoma">There is no
difficulty with data transfers between background tasks, since
they are inherently prevented from "interrupting" each
other at inconvenient times. As the majority of processing occurs
in background, inter-task communications will rarely require
special handling. Similarly, assuming the application disallows
nesting of interrupts (with possible exemptions), there is no
need to control data transfers among foreground tasks. In a
nutshell, while a task (foreground or background) is processing
data that another task needs to read, the data is never available
for reading until the update is complete. Shared data simply
cannot be modified by one task while it is being read by another.</font></p>
<p><font color="#000040" size="2" face="Tahoma">ALERT does not
provide generic mechanisms for synchronisation of inter-task data
communications. There are two reasons for this: 1) Such
mechanisms can add significant overheads to processor load and
memory requirements; 2) Mechanisms developed specifically to suit
the application are likely to be more efficient and less obscure
than a generalised set of system calls.</font></p>
<p><font color="#000040" size="2" face="Tahoma">Data transfers
between background and foreground need to be carefully controlled
to prevent errors due to one ground reading data while the same
data is being modified by another. Background tasks must disable
interrupts during multi-word data transfers and then restore the
interrupt status afterwards. Double-buffering is a reliable
technique for managing data transfers. (For example, see
ReadRTCdateTime(). )</font></p>
<p><font color="#000040" size="2" face="Tahoma">Nesting of
foreground tasks which share multi-word data structures with
other F/G tasks is prohibited, i.e. such tasks must be prevented
from interrupting each other. F/G tasks that do not share multi-word
data structures with other F/G tasks may interrupt freely.</font></p>
<p><font color="#000040" size="2" face="Tahoma"><strong>Applying
these guidelines to firmware based on ALERT will help you to
implement reliable error-free applications.</strong></font></p>
<hr>
<p align="left"><font color="#000040" size="4" face="Tahoma">How
to incorporate ALERT into a firmware application</font></p>
<p><font color="#000040" size="2" face="Tahoma"><strong>The best
approach is to design the application around ALERT from the
beginning. Incorporate the application into ALERT, not the other
way around. Attempting to adapt an existing application to ALERT
or any other 3rd-party RTOS, with minimal restructuring, is going
to give you headaches.</strong></font></p>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -