Re: Embedded and Real-time systems
At 15:00 7/10/99 +0100, you wrote:
>I would therefore like some pointers to texts that would give me an answer
>to the following questions:
>
>What type of API is the application code going to use? Is the UNIX system
>API any use at all?
What about POSIX 1003.1b and 1003.1c ? It's supposed to be useful for real
time systems. There is a POSIX draft, POSIX 1003.13 draft 9,(AFIK is still
a draft) where four profiles for real-time systems are defined:
PSE51 - Minimal real-time system profile
PSE52 - Real-time cntroller system profile
PSE53 - Dedicated real-time system profile
PSE54 - Multi-purpose real-time system profile
This is a brief summary of features of these profiles:
file-system multiple-proceses multiple-threads
PSE51 No NoYes
PSE52 Yes NoYes
PSE53 No Yes Yes
PSE54 Yes Yes Yes
I think that embedded world and Real Time world are very closed (fecuently
mixed), so you can find more information and "inspiration" if you read docs
from RT OSes, eg QNX is a good one to start from (very small and with
POSIX features). RTLinux (http://www.rtlinux.org/~rtlinux/) and RTAI are
the Linux approaches to RT and they are trying to be POSIX compliant
(http://www.fsmlabs.com/beta).
Minix world has some RT experiences. There is a porting FSU pthreads
library called Champollion
(http://atc.unex.es/jdiaz/anatome/contrib/champollion/champollion.html) and
a scheduler ("Implementing Real-Time services in MINIX" Wagner, G.; ACM
Operating Systems Review. July 1995).
I hope this helps you,
Juanjo
Re: Embedded and Real-time systems
Al: My product (a fiber-optic multiplexer) uses a 10 MHz 80186 with 1 MB RAM and 1 MB EPROM (half disabled). There are a few other system components -- 3 SCCs (Zilog's 2-channel "Serial Communications Controllers" -- a few ports have RS-232), one 8256 multifunction chip (which also has an async port), 3 banks of DIP switches, a very few LEDs, a bus interface (buffers a subset of the 80186 bus) and lots of parallel I/O (96 lines plus watchdog timer on proprietary chips). The RAM is capacitor-backed-up (holds data for about 2 weeks!), and there's a real-time clock -- the MC14618, but there may be a problem, because I don't think the software team ever used it. Size: about 12"x15", runs on +5 Volts at about 5 Amps, 100% "through-hole" technology. Anyway, this product's getting to be pretty old, and if you're (very) interested, I could qualify a couple of these and send them to you with enough documentation to keep you busy for a long, long time. I think it's still a reasonable embedded-implementation representation (except for the proprietary parallel I/O and 8256). Of course, you'd use the AMD chips these days, because they're faster, cooler, and probably have a few more features, and it would all shrink down to one-tenth the size and power. Certainly my whole interest in your project is applications like this. > What sort of features are required for this type of system? It seems to me > that a filesystem is not all that important with no storage. Are device > drivers, interrupt handling and memory management the types of features > required? Anything that can help with debug is great. So, if an IBM PC could be rigged up to emulate this system, and then be replaced with the real thing later, that's a fabulous plus. Otherwise, I'd think the whole filesystem issue is less important. But these days, I think in terms of embedding real linux... > What sort of real-time features to such operating systems generally have? (scared I'm going to sound pre-schoolish with this one) You of course need to be able to time events -- to set a timer, suspend and have good expectation that you'll get control back when you ask for it. > What type of API is the application code going to use? Is the UNIX system > API any use at all? Probably fine. I'm sure interested in others' answers. > Are embedded applications run as stand-alone binaries, or do they get > linked into the kernel and run as kernel threads? I think of kernel threads as a hassle to debug -- it's nice to have OS protection. But in this case, perhaps there is no protection to offer. It still seems like there should be a clear delineation between the kernel (and drivers) and the application... --Bill Ewing
RE: Embedded and Real-time systems
On 07-Oct-99 Alistair Riddoch wrote: > I would therefore like some pointers to texts that would give me an answer > to the following questions: I can tell what we use in our own propietary OS. > What sort of features are required for this type of system? It seems to me > that a filesystem is not all that important with no storage. We use a FLASH based file system to store data bases in. > Are device drivers Oh yes, for all kind of devices. From 2x40 LCDs to high pressure pumps. > interrupt handling Very important > and memory management the types of features required? No > What sort of real-time features to such operating systems generally have? Some processses/threads are to be run at exact intervals. The rest are to be run when the system feels for it (in ordinary Unix way). > What type of API is the application code going to use? Is the UNIX system > API any use at all? No opinion > Are embedded applications run as stand-alone binaries, or do they get > linked into the kernel and run as kernel threads? Both > Can anyone tell me where I can get hold of a cheap SBC with an x86 CPU, > EPROM, RAM and a serial interface at least on? No, but with a Z80 :-) In addition: EPROM XIP is important. There is no point in copying EPROM data to RAM just to execute it. This is what counts in my world. -- Stefan Pettersson Voice +46-70-5933800 Kanard AB [EMAIL PROTECTED] ([EMAIL PROTECTED]) Fax +46-221-50180 Vretberga finger [EMAIL PROTECTED] for my public key S-732 96 ARBOGA "What a scary world it must be, for those with no UID:GID" /OZ9ABN
RE: Embedded and Real-time systems
I'm no expert here, but following are my $.02: : What sort of features are required for this type of system? It seems to me : that a filesystem is not all that important with no storage. Are device : drivers, interrupt handling and memory management the types of features : required? Having a kernel that can be shared with the std source would of course be nice. So I think we need device drivers. The filesystem stuff should be linkable just like the device drivers are. In regards to interrupt handling, most of that should reside in it's own arch-dependent file (much like it is now). If the interrupt controller changes, we don't want to hack much more than one file. : What type of API is the application code going to use? Is the UNIX system : API any use at all? : Of course we'll want to be able to use the same development tools, I would think. So it's quite convenient to have the libc code and the sys vectors that are already built in the dev86 stuff. That also allows the applications programmer to test stuff on linux as well as on the SBC board. : Are embedded applications run as stand-alone binaries, or do they get : linked into the kernel and run as kernel threads? With no filesystem, it's hard to "run" programs without writing a "null" driver (kinda like the one you hacked a while back) but seeing kernel threads would be nice. Then the std ELKS system could also use them Greg
Re: Embedded and Real-time systems
Alistair Riddoch wrote: > > Hi, > > Recently I have become much more interested in the possibility of running > ELKS on actual embedded systems, rather than a Linux for old PCs. I have > no plans for cutting down development of Linux-8086, but would like to add > options to the kernel config to make it possible to build a system which > can do something that is useful to people buidling single board embedded > 80x86 systems. > > Unfortunatly I have little grounding in this field, so I am not sure what > is required. > > I would therefore like some pointers to texts that would give me an answer > to the following questions: > > What sort of features are required for this type of system? It seems to me > that a filesystem is not all that important with no storage. IMHO, a file system is rarely required. > Are device > drivers, interrupt handling and memory management the types of features > required? Yes. > What sort of real-time features to such operating systems generally have? > > What type of API is the application code going to use? Is the UNIX system > API any use at all? > > Are embedded applications run as stand-alone binaries, or do they get > linked into the kernel and run as kernel threads? Stand-alone binaries would often be sufficient. > Can anyone tell me where I can get hold of a cheap SBC with an x86 CPU, > EPROM, RAM and a serial interface at least on? > > Al The cheapest boards I've seen advertised are at http://www.jkmicro.com, but I haven't tried one myself yet. -- --- John K. Chester email [EMAIL PROTECTED] phone 212-792-2036fax 212-253-4290 ---
RE: Embedded and Real-time systems
> Can anyone tell me where I can get hold of a cheap SBC with > an x86 CPU, > EPROM, RAM and a serial interface at least on? Cheap is relative. I think cheap would be like $50 for an SBC, but I can't find any that cheap. Currently, I'm teaching myself some of the grounding for creating my own SBC, and anything anyone else can contribute, or directions to point me in are greatly appreciated.
