(inspired by David Bagby's post): We (Charles, PeterW, me) looked into the question of running HAL/RTAPI instances on a non-Linux kernel a while ago, in the context of the ub work, and while considering multiple HAL instances. This was assuming a fast-forward (NML gone, UI/RT separation achieved, new middleware), and userland threads becoming the preferred way of running RT threads. We discussed how the newfangled FPGA/SoC combos could be brought to bear. In particular I looked FreeRTOS and similar kernels.
Under these assumptions porting HAL/RTAPI to a non-Linux kernel - while non-trivial - is definitely doable. The key parts - thread management, and shared memory support, are pretty well isolated by now (into rather short source files in the case of RT threads, and behind a common shared memory API which might be implemented on a different base if needed). Those dont really frighten me - any RT kernel will have support for threads and shared memory one way or the other. The showstopper requirement for such an effort actually comes from the HAL component architecture: loading modules at runtime. Assuming userland RT threads, this requires the equivalent of dlopen(3) ff, i.e. dynamic loading of modules. And that is where the RT kernels I looked at failed miserably - many of those assume one links kernel plus application and that is the image one boots. It really is a parallel of shared library support: if the RT kernel dont support shared libraries, one might forget a HAL port. There goes your Arduino HAL instance. Beyond RT - in terms of 'new middleware' (zeroMQ, protobuf, websockets), this means: Posix threads, and a bullet-proof poll(2) or equivalent system call, the latter being the steep part (this assumes a decent underlying file descriptor abstraction, which for instance usually goes haywire if TCP is added as a userland library). The data-massaging library parts - protobuf + jansson for JSON - are rather harmless. zeroMQ actually does run on Windows, so this is doable on unfriendly environments. Once the RT part is wrapped behind zeroMQ/protobuf messaging it shouldnt really matter where a UI, or task, or interpreter runs, and which UI technology is used. I'm working on the assumption that zeroMQ/protobuf will be the preferred method if the UI toolkit supports this one way or the other, and websockets/JSON if not (i.e. if a Web UI is used). Of course, running on the same host as RT will still be possible, in case somebody would want to do that. - Michael ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
