Linux (and any other OS) on an MP780?

Are there Linux distros or emulators for CE2.11? I seem to recall one of the problems being storage space and a flash drive getting flogged to the point where one worries about it's lifetime.. Would one of those little PCMCIA hard drives help? I know that it has to execute as an app under CE2.11 in the case of an MP780 due to it's non-flash ROM, so it will have to be an emulation. That being the case, what emulators are available for that platform? I'm thinking of trying out some arcade games and see if they can be loaded on my nieces' MP780s.

Alright, alright, I admit it! I wouldn't mind some of those old Atari console games for myself either!

There are ports of Linux or *nix for ce 2.11 (HPCPro) devices.

There's Jlime for the 680s/720s (SH3/ARM), NetBSDs ports for the MIPs HPCs such as NEC MP770/780 (HPCPro), MP790 (HPC2000), opensimpad for SIMpad SLC/SL4/t-sinus, OpenZaurus for iPaq (ok, that's a PPC! ) ...

Search this column or look around, there are multiple threads on this.

For the MP780, as I mentioned, there is hpcmips port. Goto netbsd.org and http://netbsd.org/Ports/hpcmips/ for info on it.

As for how it works, the bootloader for hpcmips basically starts off as a wince app. It then wipes out the whole SDRAM with a boot image you select. You usually start off with the installboot image (netbsd.gz or netbsd) and after doing so, the bootloader (I presume) resets the program counter (PC or something) to point to the start of the boot image. On the MP780, it takes say under 1 minute after the loading sequence in wince ends, and you will be greeted with a console screen showing Netbsd booting up.

It autodetects all the hardware including any network card (prism in particular is well supported) and storage CF card. Oh, did I mention that you will need to have the installboot image on a small (say 16MB) partition on the CF card, with the remaining space ready for netbsd to partition?

You should arrive at a text-based install menu where you select your choice of partitioning, the PacKaGes you wish to install, the install method (FTP, LAN, local, remote etc) and the location to find the source/bins.

If you get through smoothly and selected X11, you will be greeted with the standard grey-checked X11 background and a terminal window. From there you can go on to do what you will with netbsd.

Installing netbsd *will* wipe out all SDRAM memory data, so backup your PIMs or data before proceeding. If you want to revert back to wince later, just do a reset (or hard reset) and your device will restore to factory condition.

Thanks for the info, Snappy!

Which would you recommend for the purpose of teenybopper gaming?

And which would you recommend for the purpose of realtime automation controller?

The former is self-explanatory, and the latter is for automating a mini-lathe. Turning it from manual into computer controlled. Below are before and after photos of the mechanicals. Now just need something to handle the optical encoder inputs, and the stepper command outputs, in realtime.

EDIT: Additional info.

Currently using an old PC running DOS. I figure it's simple enough to read an M-Code or G-Code file and translate that to closed loop automation control. So it should be do-able with an MP780...

Edited by Zapper 2005-07-27 12:45 AM








Attachments
----------------
Red_lathe_y.jpg (12KB - 23 downloads)
CNC_ml02.jpg (50KB - 22 downloads)

well ... if you ask me, coding in CE2.11 would be real-time enough for the application you mentioned, but the K response time might need to be tested to make sure any lag due to less than realtime performance do not result in a oscillation or under-damp condition.

For teeny bopper gaming ... actually, CE2.11 would also be pretty good as it means no messing around with CF-boot up, setup or installation. Besides there is quite a bundle of games (commercial and freeware) for CE2.11. Don't expect highend highspeed gaming though, given the older OS (CE2.11), processor (MIPS 168MHz) and mostly unsupported platform (HPCPro).

EDIT:

Regarding the machine tooling equipment, since its already controlled by a DOS app, it should imply that it has existing DAC controllers where the DOS app controls the machine via PC->Serial/Parallel port->DAC->servos etc ...

If the current interface is using serial port, then you can use the serial port of the MP780 and rig with a female-female adapter and basically have a one to one replacement for the DOS app. You just need to port over the app to either eVC or eVB. eVC recommended.

Let me know how we can help. Sounds like a fun project!

http://www.jlime.com ports to CE2.11, but when asked the big guy said that the MP780 would probably work, but he has to port it to the mp780 chip architecture. He does not have a MP780 unit so he is going slow. right now they support jornada 680s etc with CE2.11.

Gee ... that's extremely good news for the MP users! ... since the jlime distro is live right now, if it can be ported to the MIPs processor, even the Vadem CLIO, intermec 6651 users can all benefit too!

Then maybe we can have the HPC-LINUX CD installer project started off ...

Thanks for the info, Snappy!

Now I have to port the motion control libraries and the app.. It's more complex than a simple data logging program, but the basics should be the same.. Is there the equivalent of the realtime multimedia timer that a bloke could subclass under CE2.11?

I'm not exactly sure of your app's requirements, but here's my shot at the API I think you need.

You can use OnTimer message handler for any dialog or CWnd window. Your app can call SetTimer and KillTimer to create a polling sequence for your app.

UINT SetTimer(
UINT nIDEvent,
UINT nElapse,
void (CALLBACK EXPORT* lpfnTimer)(
HWND, UINT, UINT, DWORD) );

BOOL KillTimer(
int nIDEvent );

In the function OnTimer(), you do what you want and you exit.

Let me know if you need any thing.

when you mention real time, do you really mean real time (ie absolute time critical)?

if so, you will need to look into thread prioritisation: with WinCE 2.11, you can ask the OS to make your thread time critical with the API call:
BOOL SetThreadPriority (HANDLE hThread, int nPriority);

Pass THREAD_PRIORITY_TIME_CRITICAL as the nPriority parameter and your thread will be as realtime as it can be - at the expense of the rest of the system's usability.

A good compariton of real time aspects of WinCE 2.12, 3 and .net is here:
http://www.windowsfordevices.com/articles/AT6761039286.html

Thanks Chiark, Snappy! This is pretty valuable info.

Yes, by realtime, I mean 'HARD' realtime. It is controlling a machining operation, afterall. I can get away with running it slow to keep it within the maximum latency period, but of course we want it to be precise AND fast.

I figure there are two basic ways of doing this: Either use two smart hardware stepper controllers, or a dumb signal translator using optocouplers and a tristate buffer. The former is expensive, the latter is cheap, in terms of hardware. The standard is of course the former. But being a Cheap Stingy Bastard, I will be experimenting with a pure software direct signalling and encoder readback controller. The inherent limitation of course being the maximum bidirectional serial port communications capability of the device. The X-axis for the little lathe is roughly 12 inches or about 0.3 meters. At a 0.1mm resolution, that gives 3000 discrete steps. The Y-axis can be taken as roughly 4 inches or about 100mm, giving 1000 steps. So a single status message must be able to encode the position of both axes, plus spindle rotations per second, plus 7 digital input signals.
X-axis 12 bits
Y-axis 10 bits
Spindle RPS 7 bits
Digital signals 7 bits
Using bit mapping, we can get away with a single message word length of 5 bytes.
At 57600bps/10 bits per word = 5760 bytes per second / 5 bytes per update message = ~1000 updates per second or a hardware status readback resolution of 1ms.

Send-command is easier:
X-axis 2 bits (step and direction)
Y-axis 2 bits (ditto)
Spindle RPS 7 bits
This fits comfortably in 2 bytes, giving us 2880 send-commands per second. At 0.1mm per step, this translates to 288mm/s travel. Over 11 inches. Meaning we can do an almost full homing on the longest axis in just 1 second. Assuming of course we are willing to drive it with blind faith.

Practically, commands and status updates should be lockstepped, and we should halve the throughput for a nice conservative safety margin. That drops it to 500 discrete events per second, and a 50mm/s slide speed. About 2 inches per second.

That is adequate speed for a prototyping lathe.

Looks like we have a go. Much obliged, mates!

Sounds like fun

I await pictures of your first turned masterpiece

Now if you can get your hands on one of those 3D prototyping thingies... Wow! Would I have some use for one of those