Hi Gorgc,
I just realized that maybe we are talking about two different things: the
HAL layer proper and what is setting up the HAL environment - the
HALcmd.
Because the HAL layer is a memory space (where the Pins, Parameters and others live) and threads (where the module's functions are periodically called).
There are programmatic ways how to set the HAL up, the simplest are the .hal files, but then there is the TCL language support or Python support (not currently in LinuxCNC). This is happening all on the non-real-time side of things. I am not sure it would be even possible (very probably yes, but not that simple) to do this on the real-time side.
I have a feeling that this is it when you talk about the ST language.
Then there are the real-time scheduled threads with function callback pointers, which are scheduled cyclically. I have few ideas how to create thread pool with waiting threads on some action, I have personally called it
observability. I think it could have a nice asynchronous use-cases. But so far it is just an idea.
However, from cyclical real-time thread, you cannot call too many functions or have too demanding logic, otherwise you will miss you timeshare and create a real-time exception.
In my idea, the new logic control layer also includes a data area, which stores the data of the instantiated module(means there might be many instance of a module, and you need to handle each by their own name) and global variables. I don’t like using pointers for input and output. I hope that each module will allocate space in the data area after instantiation (including input output inout and local variables).
As cmorley said, Machinekit-HAL has implemented something similar. Maybe you could take a peak and see if you could not get some inspiration from there.
Because the relationship between the control modules is very close, for example, a robot module must be connected to a kinematic module, several Axis module, axis module is connected to one or two servo modules, and each servo is connected to a motor module.
I always like the more general approach to modules which do one thing only and composing them together. Problem is, people like more the focused, all-in-one solution - because it is usually simpler for them.
For module designers, he could use another module’s header to know others variables or functions. I think this should be used for inter-module communication.
Yes, you can have modules exporting public headers and other modules depending on it. However, you will have to still solve the communication between them. For example the current LinuxCNC's HAL does not support multicore, so you cannot have more than one thread accessing HAL shared memory segment.
I think a fixed code area is needed to store functions, mainly for adding compilers in the future.
It's probably translation error, but I don't understand what is meant by this.
The current function call method is ok, if I understand it correctly, it depends on the function chain in a thread.
Yes, you understand it right.
you cant just do operation like robot.x=axis1.pos.
Well, you can connect two functions with input/output by way of HAL Pins. Of course, if the consumer is before producer in the call order, it will see the change only in the next iteration of HAL thread.
I think it is better to add a single main function directly to the thread, which has already been compiled.
Again, maybe we don't understand each other (there is a problem in translation), but each HAL thread already has a
"main" function, it is the infinite loop from which all the HAL functions callbacks are called.
The way i think each function or module should be designed is that they all all functions that returns void, and the parameter has only one pvoid pointing to the parameter structure actually used.
From HAL module function you can call all the (C) functions you want, of course you have to make sure that they will not create a real-time exception (for example syscalls are a no-go operation).
Just some ideas that are just beginning to be realized. Please correct me if there is an error
I think you are getting the hang of things nicely. But you must realize that for the things you want to implement, you will have to do a really deep changes to the current implementation of HAL. Which will (very) probably not fly in LinuxCNC, so be prepared to create your own fork.
