Should I use x86 and Puppy for a control application?

[ScottMayo]

Don't know if this is the right place to ask, but...

I've got a project (unrelated to the one I've been writing about elsewhere) that involves using a small embedded x86 processor to control the automation of a room. The way I've been thinking of doing this is installing DOS, hooking interrupts (I need to handle 4k interrupts a second), and doing my in and out instructions as needed. I also need TCP, UDP and serial port access. DOS can do all that, but it's a pain.

I bet Puppy could do all this too, and it would give me 32 bit addressing, reliable TCP/UDP, and a bunch of shoulders to cry on when I messed things up.

But I'm not a linux internals guru. In DOS, if you want to hook an interrupt, you hook it. One system call, done. You're now taking live interrupts. Linux requires device drivers. I don't know how to write that and I don't know how hard it is. If it's hard, I'll take my chances with DOS...

So, two questions. First, is it possible to hack linux to allow apps to directly hook interrupts and do privledged instrucions like IN and OUT. Yes, I know that violates every level of security known to man, but it seems to match the puppy philosophy of "root is good".

Second, if apps simply cannot be allowed to hook interupts, what's a good way to learn how to code up device drivers under Puppy? Maybe it's really simple: I don't need much. Access to the timer tick, and the ability to get at IN and OUT for the TTL I/O pins on the processor in question. (An AMD Elan Pentium-like thing.)

Feasible? Insane? I don't relish trying to go back and remember how to get extended memory and TCP working under DOS. And Puppy is cool - I've never burned a CD and just had Linux boot before, no muss, no fuss. If I can strip it down to just the OS (for TCP and serial port handling) and my one little application...

[rkevans]

This book has been updated but the older version is still available for free online: http://www.xml.com/ldd/chapter/book/index.html

Obviously, some of the details may be obsolete now, but the book was written for the 2.4.XX kernel series, so it'll probably be fine for you... You can browse the book and see if writing a device driver is something you really want to try it. It's more complex than DOS, but probably not as bad as you expect.

Good luck,

Rick

[Flash]

I believe what you describe is known as a "Real Time" OS. I think there are several variants of Linux which were optimized for such use, but Puppy may be adaptable enough to do the job for you.

I've never written a device driver, but I get the impression that the biggest hurdle is getting from the device manufacturer a complete and accurate specification for the software interface. If the manufacturer won't tell you then you have to reverse engineer by trial and success. Good luck.

[ScottMayo]

This book has been updated but the older version is still available for free online: http://www.xml.com/ldd/chapter/book/index.html

Obviously, some of the details may be obsolete now, but the book was written for the 2.4.XX kernel series, so it'll probably be fine for you... You can browse the book and see if writing a device driver is something you really want to try it. It's more complex than DOS, but probably not as bad as you expect.

Good luck,

Rick

Thanks. That looks like a reasonable approach. One question: I need to interrupt at 4k/second, and I planned to get that by reprogramming the timer0 clock. Of course, linux needs that one for running the time of day clock, and probably a lot of other things. (In DOS, taking it over is not a very big deal; done right, it doesn't even clobber the system time of day.)

Can Linux share the time of day interrupt with me? I didn't see a section on that...

[rkevans]

If you're serious about 4k interrupts/sec, then you really do want to look at an RTOS. You'd be shocked and amazed by the cost of a developer's package for most of them. $10,000 / person is typical. I've written code for three different ones in the last two years. One of my colleagues was pretty impressed by RT_Linux, and my firm has a handful of 'seats' from FSM Labs. We can't use it for _most_ of our delivered projects for a variety of reasons.

If you don't want corporate-level support (with a price tag), you'll probably be pretty happy going to:

http://www.rtlinuxfree.com/

Rick

[ScottMayo]

If you're serious about 4k interrupts/sec, then you really do want to look at an RTOS. You'd be shocked and amazed by the cost of a developer's package for most of them. $10,000 / person is typical.

That's where I started looking, and I ran screaming. I didn't want to mess with DOS, because I know from ancient experience that getting TCP working on DOS is no fun. But a couple of price quotes from RTOS people sent me right back to DOS.

But I stumbled over puppy for a different project, and gave it a try on a whim. I'd never imagined that I could burn a CD, put it in a machine, and boot linux. So now it looks interesting for all sorts of things. Flat memory model, built in TCP/UDP and serial handling, runs on pretty much anything...

If you don't want corporate-level support (with a price tag), you'll probably be pretty happy going to:
http://www.rtlinuxfree.com/

Not sure I want the complexity of mixing 2 "operating system like things" for such a simple application. 4k/sec shouldn't be that bad - I don't have a lot to do on most of those interrupts, the only devices I need to keep working are the serial and ethernet port (no disk, no video, no keyboard), and the app's man loop doesn't do all that much except poll for input, and push output along. I'm still ok if 50% of the machine is used in the interrupt handler, as long as serial and ethernet still works...

With Puppy entirely in memory and nothing else running but my app, I can't see why it wouldn't be possible. If I can't sustain 4k/sec, plan B (for either DOS or Linux) is 64 interrupts a sec, and doing the heavy lifting in dedicated hardware. (But I've priced add-on boards for PC 104 and I think I'll try software approaches first.)

[rkevans]

I think you should look closer at RTLinux -- it's a really good fit for your problem.

Here's how it works: The computer runs a very simple / small operating system that is dedicated to responding to interrupts quickly and can run a few other programs in the background when it has cpu time. This is the RT portion.

So, you write a device driver for this simple section to do your special task. This should be simpler than trying to understand and modify the "do everything and make many people happy, even if that makes things sorta complex" Linux kernel. Here's a sanity check for you -- the full source tree for Linux 2.4 is roughly 40 megabytes... that's text files, not executables.

Then you run the (modified) simple OS with one background task. The background task is a copy of Linux. When the CPU is available, Linux runs and handles all the lower-priority things like serial ports, ethernet, etc.

When an interrupt occurs, the 'core' section of RTLinux looks at it and decides whether to take care of it now (call your special interrupt handler) or pass it along to the full-Linux section, which runs nearly unmodified... and all the mods it needs are done for you already.

So, you break your application into two parts and have them communicate. The high-priority section runs at 4KHz and does quick (50 microseconds or less would be ideal) data collection or direct hardware I/O. The lower-priority task runs at about 50-100 Hz and performs any other (more complex) calculations. This would just be a conventional C program that talks to a special buffer for communications...

It's simpler than it sounds. On the other hand, you could probably just do the whole thing in a quarter-million gate FPGA using Verilog.

Rick

[rkevans]

useless post removed by rkevans.

[dvw86]

I've been working in industrial automation for about 10 years. It sounds like what you need may be better accomplished with a PLC. The only time you should use an X86 based computer with Linux or DOS (never use Windows) is if you need a lot of math processing. For instance, many video inspection devices use Linux because a PLC just can't examine every pixel on a screen and decide if a part is good or defective before the next part is passed in front of the camera. However, basic machine control such as motor on-off, speed control, timing, sequencing, and temperature control is best suited for a PLC. Little "brick" style PLCs are pretty inexpensive ($300 - $1,000), and you can even get some that are based on Linux or can be programmed from Linux. Also it's pretty much standard for PLCs to have serial and TCP support built in.

[Lobster]

Any news on the Puppy submarine - they may have valuable info
http://www.murga.org/~puppy/viewtopic.php?p=9185

[muggins]

cncuser was working on a puppy based realtime cnc thingy, see here:

http://www.murga.org/%7Epuppy/viewtopic ... hlight=cnc

...there was a more up2date post that i've lost track of. is this lrelevant to your project?

[muggins]

actually i just checked the link for emc2puppy.iso & it appears to be dead.

[Lobster]

Does anyone have a copy of emc2puppy.iso or an updated version
that can be hosted and added to list of specialised Pups?

[Auda]

I used to use dos for email icq and browsing um 4 years ago if you have a look here http://bonzo.orcon.net.nz/dloads/ you will find an assortment of tcp/ip bits and pieces. Ptsdos could be worth a look its a Russian dos with built in net working, can't remember itf it was ipx tcp/ip or both.

Auda

[bushybill]

The puppy cnc iso is available here
http://cooltool.he.fdread.org/cncforum/

hope this helps
bushybill

[Lobster]

Thanks bushybill

have passed the message to MU
who I hope will mirror it in one of our depositoreies - others are welcome to mirror

Is it useful?
Updateable?

[MU]

mirror of "a stable release with EMC2 and Axis ":
http://dotpups.de/isos/coolcncb05.iso (54 MB)
http://dotpups.de/isos/coolcncb05.iso.md5.txt

Was anounced here:
http://cooltool.he.fdread.org/cncforum/ ... c.php?t=11
Mark