Replies: 1 comment
-
Yes, if you wrote relevant drivers there is nothing in the HAL that would preclude any of what you suggest. |
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
-
Two hardware sources for extending the grblHAL Pico IO count that might be considered are:
the Raspberry Pi GPIO, for those systems which have a Pi acting as the GUI or GCodeSender. One could have a process running in parallel on the Pi, interacting with the Pico. If the UART were the chosen interaction pipeline, that would decrease the Pico and Pi IO count by 2 each, resulting in a net increase of 26 IO. Seems like enough for even some blinky lights.
Time critical interrupts would need to stay on the Pico, but infrequent and slower response actions could migrate to the Pi. Things like, vacuum systems, coolant, motor enables, perhaps door alarms (even a 0.5 second delay would not allow a fingers width of door opening).
Board implementation could be a 2x20 pin socket array as a pluggable Pi connection (like the connectors on an arduino) to limit the exposure to noise from any ribbon cable connector.
For non Pi driven systems, how about a second Pico?
For $4.00 and 2 square inches of board space, you get two more processors, more of those nifty PIO and a goodly quantity of GPIO.
Those willing to abide boards with components on two sides (like the PICOBOB ) would need only a slight offset of the Pico on one side of the board, vs the location of the Pico on the other side of the board.
The upstream Pico (the one running grblHal and interacting with the GUI) would be relatively unchanged from current standalone
code. No more IO than are currently being considered for the several cross-bar applications, could be the pathway and bandwidth to the second, downstream Pico. The downstream Pico would have a less demanding life, acting largely as an IO distribution mux.
Is the current implementation of the HAL able to designate that IO tasks or responsibilities
should be handled by current-unit vs upstream vs downstream
interactive capable hardware?
Beta Was this translation helpful? Give feedback.
All reactions