Pewnie, da się. Robiłem tak żeby ładniej kable ogarnąć. Oczywiście trzeba:
- wyłączyć w Linuksie ten serial port żeby nie walił konsolą na nim
- użyć jakiekolwiek konwertera poziomów logicznych przynajmniej na linii odbierającej
Sam RAMPS ma wyprowadzone TX i RX na pinach z Megi, to samo co idzie po USB.

Dam głowę że jak by rozdzielić drukowanie i obsługę WWW na osobne wątki to nawet na małej malince nie byłby absolutnie żadnego problemu .

Nie do końca, problem występuje ale raczej nie jest widoczny z względu na wydajność pojedynczego rdzenia w Pi 3.

sp6vgx pisze: A ja się odniosę po części do podobnej sprawy... i teraz tak dlaczego nie ESP32 który może jest ciut droższy, a ma fajną sprawę jaką są dwa rdzenie.
Spokojnie można rozdzielić obsługę WiFi czyli stos tcp/ip itd. puszczając na jednym rdzeniu i drugi mamy pełen do dyspozycji. Jakiekolwiek problemy z dużym obciążeniem WiFi itp. nie odbiją się na sofcie pracującym sobie osobno na drugim core (i vice versa).

Pomijam już większą wydajność ESP32 oraz kupę innych ciekawych funkcjonalności w tym np. BT...

Oczywiście że tak , zrób soft to chętnie skorzystamy .

Kopytko pisze:Octoprint prawie wogole nie uzywa procesora raspberry przy pracy. Chyba ze macie wlaczony podglad na zywo w fhd to wowczas proces rosnie a tak to jest to ok 2-3%.

Niestety Octoprint ma jedną wadę - wysyłanie g-code oraz obsługa WWW jest w tym samym wątku. Zazwyczaj się to nie objawia ale jak spróbujemy załadować stronę z kompa który jest mocno obciążony i w trakcie ładowania strony 'przytnie' to potrafi to również przyciąć wydruk. A z drukowanie z USB i gorszą jakością chodzi o szybkość przesyłania danych przez połączenie szeregowo która jest dużo niższa niż odczyt przez SD - przez co przy bardziej skomplikowanych modelach i dużych szybkościach wydruku może dojść do tego że drukarka będzie się zacinać czekają na komendy z Octoprint.