The 'C' language does access hardware directly, and is the most common
language for doing so. (I'm a professional real-time software engineer; been
enjoying this discussion from the sideline ;/)  In 15+ years, I've never
used anything but 'C' or variants (or assembler) to program hardware.

#define  SOME_PERIPHERAL_ADDRESS  0xBADBADBA

//now shove some bits into that peripheral
*(SOME_PERIPHERAL_ADDRESS)= 0x03;

// or read from it...
volatile uint* peripheral_address= SOME_PERIPHERAL_ADDRESS;

uint8_t peripheral_read= *peripheral_address; // assuming an 8-bit data
size, 32 bit address size

This works assuming your operating system allows you to address memory
directly- most OS's usually restrict that to kernel drivers. Don't remember
if DOS does, never used it for anything.

For a project like this I would consider 'ucos', read 'micro-cos'. It's an
open source deterministic real-time OS ported to a wide variety of intel
systems. If your DOS variant isn't intended for real-time work, it is likely
not deterministic, and will also likely have an imprecise scheduler.

--Kenny A.

http://websites.expercraft.com/kennya/


Thanks for the tips Kenny. I'll research RT Linux for direct access to
memory.
I am not against using a different OS so I will also take a look.
micro cos.

----------------------------------------------------------

As far as I can tell micro cos does not run on PC mother
boards. Probably due to the dynamic ram requiring refresh.
I am not sure if that is done by the processor or the BIOS.
If it is the BIOS one might be able to find a BIOS
that supported static ram. Static ram is available
for PC mother boards.

Paul Lamar


On a normal motherboard Dynamic RAM refresh is often (always) handled
by the chipset..  The parameters for running the DRAM are usually
saved in the BIOS.  At boot time, the chipset gets these parameters.
I believe the upkeep of the DRAM is essentially completely hidden from
the processor.  The processor asks for the (block of) data (starting)
at a particular address and then either waits for it (not likely
because of the relatively huge latency of DRAM) or goes off to do
other things until the chipset tells the processor that the data is
available.  There's more to it than that on a modern processor (cache,
pipeline, etc), but that's the basic idea.


Matt-

Thanks Matt. That actually sounds encouraging as the parameters
for static ram are more favorable for real time so the
ship set won't make the processor wait.

Paul Lamnar


Paul,

On uC-OS, that is fine to use for non-commercial use.  If you make a commercial
product using uC-OS, you need to talk with Jean Labrosse (the author uC-OS).

Flashlight 186 is a very simple board, which is ideal for embedded applications.
http://www.jkmicro.com/products/flashlite186.html

uC-OS is support on this.

Remember with x86 -- find an industrial board rated for -40C to +85C.  COTS = Commercial
off the shelf, yep used in military hardware (often folks will do their own burn in and qual
from -55C to +125C, but starting with a -40C to +85C board makes life easier).

Just realized I have a couple of bookshelves full of programming books. Like flying the only way to get real experience is just to do it. Alas, also like flying, you need to keep on doing it to keep
the skills polished!  These days I get about 10 minutes between interrupts... impossible to
write code, but have become a jack of all trades, master of none. :)

The Embedded PC's ISA bus is a decent book by Ed Nisley. Only problem is you don't find ISA boards anymore, other than some embedded legacy products (still used in production). Book is OOP, but Paul if you find it cheap >$20 it has a wealth of information you would enjoy.

Tom W

Thanks Tom.  Here is some stuff on the new super I/O chips. Common on a lot
of mother boards these days.

Paul Lamar