Förslag på hur jag ska få två Java program att tala med varandra - Raspberry Pi

Varför inte bara köra appen rätt på pajen, så slipper du hela problemet?

Är det inte möjligt att köra Eclipse på din PC och konfigurera den så allt byggs, körs och debuggas på RPi?

Kör själv uteslutande Visual Studio Code + Rust på min RPi4, där går det utmärkt att redigera koden från min (Intel baserade) laptop. Koden ligger däremot på RPi4, är också där det hela byggs och körs. VS Code kan automatiskt installera små "agenter" på RPi4 som utför det som behöver utföras lokalt, det blir rätt mycket som om man sitter direkt på RPi fast man har kraften från en "normal" PC för att driva VS Code.

Så här kan det se ut när man debuggar, uppkopplad mot RPi4 visa SSH

Sedan har nämnts tidigare när du frågat om Java+RPi: du gör det väldigt komplicerat för dig själv när du envisas att köra Java ihop med en RPi. Framförallt om du kör Rasbian eller något annat som kör 32-bitars ARM, Java-stödet är inte superbra där.

Om du absolut måste använda Java, kör i alla fall 64-bit ARM (t.ex. Ubuntu Server för RPi) då Java fungerar betydligt bättre på ARM64. Allt verkar fungera lysande under 64-bit Ubuntu ihop med RPi4, problemet du får här är att vissa RPi-specifika projekt (som t.ex. WiringPI) fungerar inte, fast det är egentligen en fördel då det numera finns standardiserade metoder för att jobba med GPIO, I²C, SPI etc som är mer effektiva än de RPi-specifika äldre metoderna + det man skriver fungerar på andra kort som har motsvarande HW!

Ah, då är det ju inte helt hopplöst
Som du kanske redan märkt är det ändå en rätt udda kombination, så antagligen inte jättelätt att få några bra svar på frågor relaterade till den setup:en.

Vet att jag tittat på PiGPIO. Det har som du skriver fördelen att fortfarande utvecklas aktivt, men det är ännu ett i raden av bibliotek som envisas att koda specifikt mot RPi i stället för att använda de standardfunktioner som finns i Linux så att det fungerar på alla system som har drivrutiner för GPIO, SPI, etc. Men om det fungerar och det är ett privat projekt: go for it!

Det du kan kika på i något läge är chardev GPIO (standard Linux finess för att hantera GPIO) samt libgpiod (hanteras av kernel.org). Möjligen saknas det Java-bindings för detta, borde faktiskt gå att använda detta helt utan att involvera C-kod via /dev/gpiochip0.

Tillbaka till ditt problem. Är helt med på varför du måste köra på RPi i detta läge, du behöver ju tillgång till HW som typiskt saknas på "vanliga" PC-system. Kan inte hjälpa dig med Eclipse och min Java-fu är rejält ringrostig i det här läget (över ett decennium sedan jag jobbade professionellt med Java).

Men fick igång ett enklare Java-projekt via Visual Studio Code på samma sätt jag kör Rust, C++ och Python: via tillägg som möjliggör styrning från en VSCode på din PC av program som kör på RPi. Även debuggern fungerar!

Det jag använda är ett tillägg med namnet Java Extension Pack. Installera detta på din PC, öppna ett "remote directory" över SSH och välj katalogen för ditt RPi projekt. Det ska nu vara möjligt att öppna, editera och spara filer via VS Code på din PC. Installera nu också Java Extension Pack på din RPi, bara göra på samma sätt som innan fast nu i den VS Code instans som är uppkopplad mot RPi.

Tryck på debugger-symbolen, välj den föreslagna konfiguration. Det borde nu gå att debugga från din PC direkt på RPi. Ser ut så här för mig (kör OpenJDK 11 på min RPi4 med ARM64 Ubuntu server här, men borde fungera oavsett Java-version). "Normala" saker som single-step med F10, "tool-tip" för att se värden i variabler etc fungerar.

Det som debuggas här körs alltså på en RPi4, men VS Code själv körs på min Ubuntu laptop (x86-baserad).

Har ingen aning om det är möjligt att göra motsvarande i Eclipse. Om det är det får du hoppas någon annan vet hur...

Ursprungsfrågan om två mjukvaror på separata datorer så är det ju ett nätverks-api som behövs, sen om det är blåtand, rest eller binärt spelar mindre roll.

När apiet är definerat kan båda delar utvecklas oberoende av den andra, och går att simulera/testa enkelt med slumpad data.

Har du hittat någon bra guide? Har inte lyckats få till remote debugging, hade varit sjukt nice, har visual studio professional och en app är skriven i C och en annan i Python. Båda körs på en Raspberry Pi, nu sitter jag och kopierar filer fram och tillbaka, pythondelen har jag fått till att bli plattformsoberoende men C-programmet styr specifik hårvara på pajen. En guide började med att man måste ha en lösenordsfri ssh-inloggning... Känns inte helt coolt, tänkte sätta den i sommarhuset med portforwarding. Nu blandar jag ihop lite olika pajer och projekt... Nu är det väl inte långt kvar till .Net 5 och jag kanske kan merga mina program till ett enda C#-program.

Ingen aning om det fungerar i "vanliga" Visual Studio. Inte alls säkert att det är möjligt, det som används i VS Code är funktioner som Microsoft initialt skapade för att underlätta utveckling mot containers körande både lokalt och i "molnet". Beskrivningen av den funktionen hittar man här (inget behövs längre installeras, SSH-stödet är numera inbyggt i VS Code).

I VS Code är det inte alls något krav att köra SSH utan lösenord. Det kan vara smidigt att köra med RSA-tokens så man kommer in snabbare, men fungerar även med lösenord.

För att ta ett step-by-step-exempel kan vi köra Python (är väldigt enkelt där då man slipper byggsteg).

1. Start VS Code

2. Tryck på "Remote Explorer", välj "Add new", skriv in SSH-adress, t.ex. "ssh kjonsson@192.168.2.92"

3. Om det behövs ett lösenord ska det skrivas in nu

4. Välj "File: Open Folder", gå dit projektet ligger (du är nu på RPi)

5. Välj Python filen du vill debugga

6. Tryck på "Run" iconen, skapa ny 'launch.json' (se nedan)

7. Nu är det bara trycka på "Start Debugging"

Detta är den 'launch,json' jag använder här (den kan automatgenereras av Python extension)

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "internalConsole"
        }
    ]
}

Där ser man bl.a. att strängen blir 'Host name is rpi4 and platform is aarch64' då jag döpt min RPi4 till det kreativa namnet 'rpi4' samt den kör 'aarch64'.

+1 på detta. En SSH-server med lösenordsskydd är ajabaja. Lösenord är i regel en mycket svag form av skydd.

Det är fullt möjligt att styra GPIO-pinnar via terminalen, problemet är att det är ännu en i raden av APIer som är markerat: använd inte, utan kör "rätt" sätt vilket är /dev/gpiochipN där det officiella hjälpbiblioteket är just libgpiod.

Eftersom du ändå delat upp det hela i två program, ett som kör en webbserver och en som kommunicerar med GPIO, varför inte skriva det andra i python3 för det kommer handla om en handfull rader kod?

Känner bara till fyra officiella "bindings" till det rekommenderade sättet att köra GPIO just nu, C, C++ och Python3 är alla implementerade i libgpiod som kommer från kernel.org. Ovanpå det finns också en för Rust (är den jag använt mest själv, dels gillar jag Rust och dels presterar det faktiskt något bättre än C och C++ varianten).

Förutsatt att du kör något Debian-derivat borde detta räcka för att installera den officiella modulen för Python3

$ sudo apt install python3-libgpiod

Här har du ett exempel på hur man konfigurerar en specifik I/O-pinne och läser/skriver dess värde.

sysfs

Om du absolut måste köra Java verkar det nu som det du faktiskt väntar på inte ens är släppt än. Det "gamla" officiella sättet att hantera GPIO i Linux har en stor fördel för dig, det går att använda från Java helt utan något 3:e-parts bibliotek!

Nackdelen med denna metod är att den är långsam. Långsam här betyder: du kan inte göra saker som behöver reagera på sub-millisekundnivå. Att slå av/på någon brytare eller liknande är dock inga problem alls.

Dokumentationen för sysfs hittar du här. Vad man gör är att konfigurera kärnan så den skapar ett gäng filer under /sys/class/gpio/gpioN/..., behövs bara läsa/skriva text för att sätta riktning och tillstånd på pinnen.

Eclipse

Visade sig att Eclipse faktiskt har stöd för remote-debugging, instruktioner hittar du här.

Normalt binder debug-agenten till localhost, så du måste göra detta för att kunna koppla upp dig från din PC till RPi

$ java -Xdebug -Xrunjdwp:transport=dt_socket,address=0:8000,server=y,suspend=y ClassWithMain

i.e. lägg till det rödmarkerade, något som inte är med i länken för remote-debug med Eclipse.

Modellen ovan är ett vanligt sätt att debugga mikrokontrollers och andra typer av inbyggda system. Nackdelen över modellen som VS-Code använder är att det är upp till dig att manuellt säkerställa att det som körs "remote" faktiskt matchar den kod du har lokalt på din PC. Brukar bli rätt "intressant" att riktigt förstå vad som händer när dessa är ur synk, (har hänt ett par gånger då jag jobbat rätt mycket med embdded ).

Fast om du gör det som beskrivs ovan kan du faktiskt lika gärna köra webbservern direkt på din PC under utveckling (bara kopiera över allt när det fungerar som tänkt) och sedan låta det programmet kommunicerar över TCP till RPi där programmet som hanterar pinnarna kör. I den färdiga versionen bör du dock binda GPIO-programmet till localhost i stället för 0.0.0.0.