Johan,
I'm fairly interested in the language and learning more about ARM. I could help with porting/general improvements to Timber, however I would not want the porting work I do to be useless for the future development (so doing porting in my private branch which will never see the light of day because the main branch is headed elsewhere or becomes too incompatible is the thing I'd like to avoid). I know Haskell and have some experience in developing real-time applications, so adding improvements should not be a problem.
I understand that there always be some hooks to specific hardware, even after code reorganization, and that's why I'd like to see the “minimum hardware requirements” and “target platform specifications” — so that it was clear what are hard requirements and what could be worked around to make the results work on a different, but close platform.
I'm not in an extreme hurry to make my project happen, however I want to decide on a language/toolchain for it to start prototyping various things using available hardware and/or ARM emulator.
On the other note, do you know any other practical research real-time languages which I should look at (not as a matter of choosing one over another, but to learn the new concepts which may be lacking from the mainstream)?
Ivan
Hi Ivan,
The only platform that is officially supported by the current release is POSIX, but an ARM port is indeed on its way. However, as you have observed, the problem with our ARM prototype is that is is heavily linked to a very specific board with a very specific programming environment. It would be so much better if an rts port could be made generic enough to work with any board matching some chosen architecture.
Fortunately, our next compiler release will contain a slight code reorganization that makes an rts independent of the external environment one wishes to support. For the ARM port this means that the interrupt vector table, the IO ports and the TFT driver will all be separate modules that one may choose to use on an individual basis, probably also combined with some form of parameterization regarding base addresses etc. This will make adaption to a specific board like your ARM9 hardware much easier.
However, even with such a reorganization there will still be some hardware dependencies left inside an rts like the ARM port: the timer interface being one, board and memory initialization being another. Ideally such dependencies should also be singled out as separate modules for the benefit of easy rts adaption, although this time we're talking about C files, not Timber modules. We're currently investigating how to do this the best way.
All this is for the next release, though; sometime this fall. So if you want to start your project today you'll probably have to do an adaption yourself, with a risk that the work will be overridden by the next release. It shouldn't be too complicated, though, if you know your way with your hardware. And we'll be interested in hearing about the results!
Otherwise, stay tuned!
-- Johan
_______________________________________________Hello,
is there some kind of description of Timber supported platforms? I can see the ARM and POSIX platforms, and I can see that ARM is actually not just for any ARM device, but the one with some kind of TFT (and probably other hardware). What is exactly meant by ARM there?
I have a hobby project in mind, for which I'm likely to use ARM9 hardware — does that mean that I'd need to create my own RTS (just like rtsARM and rtsPOSIX in current sources)? Or should current ARM RTS be made more general instead?
Ivan
Timber mailing list
Timber@haskell.org
http://www.haskell.org/mailman/listinfo/timber
_______________________________________________
Timber mailing list
Timber@haskell.org
http://www.haskell.org/mailman/listinfo/timber