I have a real-time industry control device, running Linux. The control device currently has a firmware written in C.
Is Island good for writing firmware for real-time applications?
My primary concerns are:
Island seems still undergoing frequent improvements and bug fixes.That is, it is still not perfectly stable
The size of the executable generated by Island is non-trivia, or termed otherwise, sometimes clumsy for embedded applications
The GC might have “unpredictable” run-time behavior which may violate the constraint of real time system to have “deterministic” executions (but, of course Linux is not a real time OS either)
Any advice, heads-up or warnings (for any foreseeable pitfalls)?
I guess I can stick to C, but I really enjoy the Oxygene language, and would like to know if it suits the job!
It is actually a standard NEMA-TS Controller.
CPU:PowerQUICC II 233MHz
128MB DDR2 RAM
64MB Flash storage for OS software and applications (can NOT take large files!)
2MB SRAM memory for non-volatile parameter storage
Operating System: Linux 3.12 (minimum Linux 2.6.3 kernel or higher) with real-time extension of POSIX 1003.1b
As we can see, the run-time resource is quite limited.
Island of course does have bug fixes, and some improvements. But there haven’t been gigantic changes since we introduced multiple class model support (ie com, cocoa and island classes in 1 project).
Agreed there. Our compiler includes a GC in the project which has a base size. Though we constantly work on improve the situation with the file size, it has a base size that’s already quite large for embedded work.
Oh yeah - I understand your points. But - as I explicitly noted in my original post - Linux is not a real-time OS (RTOS) like OS9 or Greenhills RTOS. I also noted in my original post that GC renders executions “in-deterministic”.
But the control device I had in mind - does include some sort of “real-time extension of POSIX 1003.1b” on top of Linux. Also I have a feeling that Island can be running in a “stripped” mode close to C without GC (not tested yet, just a wild guess based on my feelings!).
Hence I was just asking to explore potential of Island/Oxygene before getting my hands dirty since I like the language so much!
Tha should be achievable, yes. By which I mean, it probably will not work with current Island (the GC is abstracted, but not that easily switch-mutable for a non-GC solution), but it’s certainly something we could and should look at,. Ideally, I’d like configurable lifetime strategies (beyond just different GCs), much like Swift has planned, where a project cpiuld code to use ARC (which right now would not be hot-swappable because it does not solve retain cycles the same GC does) or even Manual RC.
That said, this is not. priority for is right now, as requests for that have been low, but it would be doable if the demand is there.
ANy backend LLVM supports we can support, in theory — but it requires work, testing, maintenance and test hardware, so it can really only be justified if there’s sufficient demand for it. This one for example, I personally have never heard if before. So would directing resources to support it be worth it? How many additional Elements licenses would it sell? If the answer is one or two, it probably won’t be…
Marc, one supported platform is ARM and many embedded projects are based on it. Even using C, the developer must avoid calls to malloc() if they want a deterministic application, suitable for hard real-time requirements. Could we do the same with Oxygen? C is too low level for most of the current real-time applications. Right now Microsoft provides a powerful architecture (Azure IoT Central) for modern embedded applications, but most of the developers still use C. It is a shame.