Edward Cherlin wrote. > I also want to see Open Firmware replace proprietary BIOSes everywhere.
I'd like that too, but it won't happen. The market forces that drive the computer business still favor proprietary thinking, notwithstanding the many FOSS arguments to the contrary. Intel calls the shots by controlling a big percentage of the silicon designs, and Intel is pushing UEFI, partially because it allows them to keep their chipset-dependent startup code proprietary. The board manufacturers do what the dominant silicon vendor allows them to do. > In fact, I would like to see OFW-only embedded systems, > since FORTH is designed for that environment. I have built such devices, including a web-interface multi-headed high-speed camera that could capture the dynamics of golf club to ball impact. The product shipped for awhile, then the company tanked in the dot-com bust. A lot of the OFW functionality is targeted toward the task of managing a large collection of possibly-plug-in I/O devices, then booting a general purpose OS. That isn't necessarily useful for your random embedded system. For embedded applications that don't need that level of OFW-ness, I have a small Forth interpreter that provides the same Forth interactive development/execution/debug environment as OFW, omitting all the device tree and booting elaborations. It fits easily on an ARM SOC such as the Atmel AT91-SAM7 family, leaving plenty of space for application code and data. Guess how the OLPC multi-battery-charger is programmed? > (I am assuming that Mitch can add real-time capabilities to OFW, It already has them. The golf camera could time the arrival of a golf club to the ball with microsecond resolution. You can add round-robin multitasking (essentially multithreading) to OFW by loading a file. The core data is all in what is essentially thread-local storage. OFW doesn't have preemptive multitasking, but I've never really needed it. Many real-time problems can be handled rather well with a combination of explicit-yield tasking and judicious use of interrupt routines. The added benefit of avoiding preemption is that synchronization is much easier. > and that a variety of > development environments are available for such systems.) Or perhaps > OFW/Parrot hybrids. I don't know. It's Free Software, folks, what do > you want to implement today? > The usual Free Software answer to that question is "I want to implement yet another version of something for which there already exists a dozen other implementations". Which is exactly the problem. _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
