serial_bridge: Add serial bridge module for communication with UART peripherals

[E4ST2W3ST]

Add functionality that allows communicating and configuring uart ports on the target MCU. Currently supports the STM32 architecture.

Inspired from ete100's pull request for similar functionality.

The feature allows for generic communication with uart peripherals, along with an implementation supporting the Neptune 3Pro/3Plus/3Max screens .

To use, run a make menuconfig for STM32 ,enabling low-level configuration options. A list of available bridge configurations will be presented that don't interfere with the main UART:

[NotAmaan]

Thank you for the hardwork @E4ST2W3ST, look forward to using this on my n3p

[KevinOConnor]

Thanks. As high-level feedback, I think it would be useful to add support for forwarding an mcu serial port back to the host software. I do have a few comments on the implementation here:

1. Would there be any interest in reworking this "neptune screen" implementation into a separate program that communicates with Klipper via Klipper's API server ( https://www.klipper3d.org/API_Server.html )? That is, implement new "serial_bridge/send" and "serial_bridge/subscribe_responses" API calls in Klipper and implement an external program that uses those calls to draw the screen. This PR seems to implement an entirely new screen system in Klipper, and I'm not sure that's a long-term maintenance load that we can take on right now.
2. What is the use case for the "SERIAL_BRIDGE_SEND" and similar commands? How would a user use these commands and what real-world tasks would they accomplish with them?
3. Is there a reason that the serial_bridge.c files have my copyright on them? I see that serial_bridge_irq.c is based on my code (serial_irq.c), so it seems fine to list me as the copyright holder there (if the original author doesn't care). It seems odd though to list me as the copyright holder for serial_bridge.c as it doesn't seem to be related to any of my code.

-Kevin

[Grntrenchman]

I can say (at least for me, as a user) that I'm definitely interested in this, as if I understand properly, I could use this to write a set of macros that could communicate with a stock MMU connected to the printer board serial (how marlin/prusa handles it), and listen for things like the runout trigger from it, which is really the only thing stopping me from switching from marlin at the moment.

This would be much better (IMO) than the current MMU support under klipper, requiring me to change the board of the MMU to something that can also run klipper, and controlling both directly via MCU.

This would be one use case for the SERIAL_BRIDGE commands, to send filament change/retraction commands, listen for confirmation and success/fail responses.

[dim1triy]

Hi. This PR will also be very useful for creality printers, they also have a Nextion (TJC) HMI display. I am looking forward to this code being added.

[BongoEADGC6]

@E4ST2W3ST Any further details on this PR? Seems that this is starting to gain traction with folks and I know I'm patiently waiting to get this added to my printer. Thanks!

[burritosoftware]

Also interested in this too, but since I wanted to use it now and keep things inline with upstream, I used git apply with a .patch of the PR so I can use the functionality and still get the latest updates (unless there is a merge conflict, which there likely wouldn’t be as the commit is mostly additions).

If this is improved upon more and gets merged into Klipper, I’d do a git reset --hard to revert all the manual additions.

[tayanov]

Kevin make it, please)

[Sineos]

Before you now continue spamming this thread with "me too", you did realize that:

1. Kevin has posted some feedback and questions
2. The original author @E4ST2W3ST did not come back so far
3. In the current state and without any answers to the raised questions the chance is close to zero that it gets merged

[klack]

I have appreciated people sharing their use case as I have a similar project in the works. I'll probably be repacking, cleaning up, and expanding compatibility for some choice features in this PR.

[t1ngyu]

@E4ST2W3ST I rewrite the neptune3pro's screen firmware to support klipper. The screen is connected to the klipper host, and a service is running to interact with moonraker and the screen. https://github.com/t1ngyu/neptune-screen

If there is a serial bridge between the MCU and the klipper, it is more interesting.

[github-actions]

It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[tayanov]

Also interested in this too, but since I wanted to use it now and keep things inline with upstream, I used git apply with a .patch of the PR so I can use the functionality and still get the latest updates (unless there is a merge conflict, which there likely wouldn’t be as the commit is mostly additions).

If this is improved upon more and gets merged into Klipper, I’d do a git reset --hard to revert all the manual additions.

do you know why *patch file not found?