EMC should run on different platforms, but the 486s have
some other way to address the shared memory used by the software.
It is some time since I configured this, so I can't tell all
the details I did find concerning this.
The machine used is a 486DX2 ( Dell 466/MX).
I started out with RH5.0 and a lot of patches, and had
all sorts of trouble. There were errors in EMC, in RTLinux,
and Linux as well. So, at this moment it is very difficult
to write all there is to the subject, and I didn't keep
all the notes. I just can't recall the different memory
details the 486 versus other platforms. But the good news
is that you don't need this information to get it running.
One of the papers I will recommend to anybody is "Using
Shared Memory in Real-Time Linux" by Frederick
M. Proctor.
By reworking some of the examples, you may find out a lot
on how the shared memory works, and possible problems. It is also
easier than to try to test with the much larger EMC software.
But the program examples is not correct for the 486 !
(see shared memory examples below )
In the end I used:
Linux 2.0.36 kernel
release9J.tgz RT patch
emc-15-Apr-1999.tgz
*Note -I may have used a newer emc release, but a least none after august 1999.
Just install and follow the instructions, and do a normal build.
The problem with the 486, is that it uses a few different memory call functions, and for some time this was not done correctly. For the RT-kernal releases like the above, this is corrected, and also the emc. So after a lot of tests, the problems turned out to be simple: How to set aside the right amount of memory.
First a few basics:
The notations like kilo, mega, giga, - is missleading when it comes to computers. Kilo, means a thousand, but a 1Kbytes is not 1000 bytes, - but 1024 bytes. 1 Mbytes is not 1000kbytes, but 1024Kbytes.
image=/boot/zImage
label=RTLinux
root=/dev/hda5
append="mem=0x1640000"
read-only
I do have 24Mb of ram on this machine, and you would think
that I should enter something like 24M-1M= 23Mb.
In other words append="mem=23m", but this is wrong!
Virtual memory:
On the 486, the memory model is a bit different. On the original PC-XT/AT - there was an upper memory limit at 1Mb, of conventional memory. So, linux uses the above memory as a virtuell memory pool. If you should use: append="mem=23m", you would point to a wrong location.
The EMC uses only about 0.5Mb for the shared memory. Because I only have 24Mb total, I don't want to waste too much memory. What I want is to set aside 768Kb ( 512Kb + 256Kb= 768Kb) - this should be plenty, but note that you have to have some even 8bit number - 128,256,512,768, 1024 etc.
Okay, here is the calculation: 24Mb * 1024 * 1024
= 25165824 bytes in decimal.
Then I remove the bottum:
1Mb * 1024 * 1024 = 1048576 bytes
--------------------------------------------------------------------
This gives: = 24117248 bytes
Set aside the shared memory:
768K * 1024 = 786432 bytes
--------------------------------------------------------------------
This gives
= 23330816 bytes
====================================================================
This is in decimal and when converted to hexadecimal we
get: 1640000
The notation "0x" is "C's" way to say
it is a hexadecimal number. In other words: append="mem=0x1640000"
I could have done the calculations a little simpler, but
I think that this would be better understood by most, and
I think you may have different amount of memory, so I did
this in detail. Also, it is worth to note how you can choose to
set aside less or more shared memory. ( Why set aside more than
will be used )
The Memory calls:
Instead of the calls mmap and munmap, you
have to use vremap and vfree.
How to do this in the shared memory examples, see below. For
the EMC, the necesarry code is added,
so you don't have to do anything to it.
In common.h:
#define BASE_ADDRESS (0x1640000) /* change this */
In rt_process.c:
#include <linux/mm.h> /*ARNE: vremap(),vfree()*/
/*
* Note the use of vremap in the init_module
*/
int init_module(void)
{
my_struct_ptr = (MY_STRUCT *) vremap(BASE_ADDRESS,sizeof(MY_STRUCT));
.
.
.
/*
* and the vfree call in the cleanup_module
*/
void cleanup_module(void)
{
.
.
.
vfree(my_struct_ptr);
}
Final Notes:
The use of the shared memory example programs and papers provided by F.Proctor, is nice to use as a test vehicle. You can use printk, and output kernel values from the inserted module, and was the key program to find out what was wrong. For some time I had a RT_Kernel module that had errors, ( not a NIST module ) and this was also verified by F.Proctor, so these examples turned out to be very nice.
To insert modules, you can overide the BASE_ADDRESS in the .inifiles until you get them right. ( I see I had several files with the Base address set to 0x170000 ? ) I have not runned the 486 for a long time, and could not verify why I had this, - I might have overriden the values, and could have been from some earlier tests.
But when I did run this setup, all worked well. In fact I think the 486 may work very well. Just don't use to many applications and uneeded processes. The ISA boards and IO run at the same speed as pentiums, so I don't see why this should not be a usable platform.
Many tend to think that CPU speed, memory and tens of gigabyte disk is needed. I have seen many systems run on a small 8 bit cpu, and used steppers on 8088 and other small microprocessors, and I have used Linux on several 386 computers, so I don't see any reason not to try.
//ARNE
Current status: The
software seems to run okay, but has not been tested on a real
machine doing work.
Any corrections and notes on this paper, are highly welcomed.
Parallel port inactive
From: "Wallace Koopmans" wkoopmans@home.com
To: Multiple
recipients of list emc@nist.gov
Date: Thu, 29 Mar 2001 02:23:02 -0500
(EST)
Hello, I have just set up EMC on a 486Dx33 with Redhat 5.2 and the associated RTlinux patch. I have also been able to get it to run using the steppermod.o and minimillio. The problem that I am having is that although I can get it out of estop and jog the axis I cannot get any activity on the parallel port. I have an oscilloscope set up to read the port pins and they just stay at +5V. The port is set up at 0x378. Any suggestions would be helpful.
I also wouldn't recommend this slow of a processor for more than getting set up experience, it can just run xemc but is not even usable with tkemc (well unless you can wait 30 sec for the mouse to move)
This is a preliminary copy of a chapter to be included in the part programming section of the EMC cookbook. This page is maintained by Dan Falck. Comments, criticism, additions, subtractions, and editing are welcomed.