Crossbar function #5
Volksolive
started this conversation in
Ideas
Replies: 1 comment
-
The code added to the core is just some initial dabbling in structures and functions declarations. My idea is to have the core handling the settings and the driver the actual implementation. Also the crossbar should only be for optional pins such as safety door, motor fault, flow detectors, extra coolants, optional stop and what not. And perhaps the crossbar should be a layer above the io-port API... |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@terjeio, I have noticed you have added a draft of crossbar code. it seems you make it so that the core can manage a pin.
Wouldn't it be more easier to create callback functions for the core that are attributed to pins in the driver during a setting_change, the same way the pull_up and invert are managed.
For example you would have a control_reset_assert_callback function that you can attribute to a pin function in the driver. pin function could be polling, IRQ, Debounce, SR Latch, etc.
So when doing the runtime configuration it would be something like:
Sending $xx=1 would attribute a core function to the pin represented by xx (f.ex function control_reset_assert_callback) and $xx+1=1 would select the driver function irq for the pin represented by xx where 0=polling, 1=IRQ, etc.. $xx+2 could be invert and pull up disable.
and if $xx=0 the pin is de-activated.
The driver could add the $xx to the setting depending on how many pins for that driver are crossbar-able and a crossbar_mapping.h could explain all the available $xx and description for that driver?
Maybe it would be better that core function like reset Feed_hold, etc are not crossbar-able ?? but I think you get the idea of how this
the core could have specified number of core callback function and each plugin as well which all combine into an array so that the driver can ensure the callback attributed to a pin exist and can generate an alarm otherwise.
This could work the same way for output function but in that case it is the pin output callback function that is attributed to the core/ plugin function
Beta Was this translation helpful? Give feedback.
All reactions