With dialog, I can paste as a quote using > or a custom quote. How does
this look:
%% A static volatile object is an appropriate model for a memory
%% -mapped I/O register. Implementors of C translators should
%% take into account relevant hardware details on the target systems
%% when implementing accesses to volatile objects.
Looks fine to me, and makes it obvious that the quote has come from
somewhere other than Usenet. There are also arguments for sticking
with '>' (providing you keep attributions/citations clear).
If the register is to hold the temperature in the hallway next to my
woodburner, what do "static" and "volatile" do together?
'static' at file scope (and in practice such memory-mapped I/O would
usually be represented by file-scope objects only) affects visibility
only.
A compiler might use 'static volatile' on definitions for variables
representing memory-mapped registers in a non-standard header (along
with some other magic to tie those "variables" to specific addresses),
where the 'static' stops the compiler's parser complaining about
duplicate definitions if the header is pulled in in multiple places
(since all the "definitions" actually refer to the same thing, and the
back end doesn't end up actually allocating space anyway).
You'd probably not explicitly use 'volatile' yourself, but have
something like
#include <compiler's-magic-chip-specific-header>
/* At this point, a number of objects have been declared
that refer to the memory-mapped I/O ports. They probably
have names full of acronyms from data sheets. They also
have been declared with whatever qualifiers are necessary. */
#define HALLWAY_TEMP ADC_DATA_IN_0
#define BEDROOM_TEMP ADC_DATA_IN_1
#define WATER_LEVEL ADC_DATA_IN_2
#define SWAMPCOOLER_FAN DAC_DATA_OUT_0
#define REFILL_SOLENOID RELAY_OUT_0
/* hard-coded parameters for simplicity of sample */
#define HALLWAY_MAX 35
#define BEDROOM_MAX 30
#define FANSPEED_MAX 100
#define LO_WATER 10
#define HI_WATER 40
int main(void)
{
unsigned fanspeed = 0;
while (1) {
if (HALLWAY_TEMP > HALLWAY_MAX ||
BEDROOM_TEMP > BEDROOM_MAX) {
if (fanspeed < FANSPEED_MAX) {
/* some output devices are truly output-only
and it's necessary to keep your own record
of their value, rather than accessing them
_just_ like a real variable */
SWAMPCOOLER_FAN = ++fanspeed;
}
}
if (HALLWAY_TEMP < HALLWAY_MAX &&
BEDROOM_TEMP < BEDROOM_MAX) {
if (fanspeed > 0) {
SWAMPCOOLER_FAN = --fanspeed;
}
}
if (WATER_LEVEL < LO_WATER) {
REFILL_SOLENOID = 1;
}
if (WATER_LEVEL > HI_WATER) {
REFILL_SOLENOID = 0;
}
}
return 0; /* for pedantry's sake */
}
Real code would initialize devices; this sample doesn't. Real code
would also probably need to worry about triggering ADC conversions and
waiting until results were ready before reading the converted value,
and also mapping such values onto some temperature scale that reads
other than 0..1023. Devices other than ADCs would have their own
real-world issues too.
Thanks mlp. I have this fantasy of being able to teach my x86
computer to fire events based on temperature. ....
(If you haven't lived somewhere near Albuqerque, you probably have
never experienced evaporitive cooling.)
Grew up in tropical North Queensland - experienced it plenty,
occasionally even via artificial means. And some Aussies have canvas
waterbags strapped to the front of their 4WDs (you'd call them SUVs)
for cold water in hot weather - same principle.
I'm mudding all the walls, so burying wires to wherever they need to
be is in the cards. Do you have any notion of what
hardware/software I would need to make that a reality?
I do, but discussing it is not appropriate here in comp.lang.c. Talk
to the good folks in comp.arch.embedded for further pointers, or email
me privately for consulting.
mlp
