Så kopplar JBlanked Flipper Zero, Cardputer och PicoCalc till lokal AI med ZimaBoard 2

Tack till JBlanked för att ha dokumenterat ett annorlunda sätt att föra in lokal AI i utvecklingen av inbyggda enheter. I hans fullständiga video förvandlar han ZimaBoard 2 till en lokal Ollama-server och ansluter handhållna enheter, bland annat Cardputer-ADV, PicoCalc och Flipper Zero, till den gemensamma AI-miljön.

I stället för att försöka köra en stor språkmodell direkt på varje liten enhet delar experimentet upp arbetsbelastningen: ZimaBoard 2 hanterar den lokala AI-tjänsten, medan de handhållna enheterna fungerar som lättviktiga utvecklingsgränssnitt. JBlanked använder sedan sin öppen källkod-baserade Picoware Agent för att skapa applikationer, granska enhetsinformation och hantera maskinvara via den lokala AI-anslutningen.

Samarbetsinformation: Den här artikeln bygger på den konfiguration som demonstrerats av JBlanked samt den offentliga dokumentationen för Picoware och FlipperHTTP. Programvaruversioner, tillgängliga AI-modeller, maskinvarukompatibilitet och prestanda för lokal inferens kan förändras över tid.

Resultatet: en kompakt hemmaserver kan tillhandahålla AI-lagret för flera maker-enheter med begränsade resurser. Den handhållna hårdvaran kör fortfarande sin egen firmware och sitt eget gränssnitt, medan beräkningsmässigt tyngre språkmodelluppgifter kan hanteras av Ollama på den lokala servern.

Den lokala AI-konfigurationen i korthet

Projektet kombinerar en kompakt x86-server med flera inbyggda plattformar. I stället för att tvinga samma programvarustack på varje enhet använder JBlanked olika anslutningslager beroende på vad varje enhet stöder.

Varför använda ZimaBoard 2 som AI-server?

Det intressanta med detta projekt är inte bara att ZimaBoard 2 kan köra en AI-applikation. Det är hur kortet förändrar arkitekturen för små inbyggda projekt.

Enheter som Cardputer, PicoCalc och Flipper Zero är utformade med fokus på portabilitet och specialiserad inbyggd hårdvara. De är användbara för gränssnitt, skript, firmwareexperiment, nätverksverktyg och portabla applikationer, men deras inbyggda resurser är betydligt mer begränsade än hos en vanlig AI-arbetsstation.

ZimaBoard 2 Mini Home Server tillhandahåller en separat x86-värd med trådbundet nätverk, lagringsanslutning och PCIe-expansion. Det gör det möjligt att hålla de handhållna enheterna små genom att flytta den mer krävande serverbelastningen någon annanstans.

I JBlankeds arbetsflöde kör ZimaBoard 2 ZimaOS, medan Ollama tillhandahåller den lokala språkmodellstjänsten. När tjänsten är tillgänglig i det lokala nätverket kan kompatibla enheter kommunicera med den utan att varje handhållen enhet behöver tillräckligt med beräkningskapacitet och minne för att själv vara värd för modellen.

Videon visar också en viktig detalj om den demonstrerade serverkonfigurationen: medan Ollama körs rapporterar ZimaOS systempanel ett NVIDIA GeForce RTX 3060 med 12 GB VRAM. Det innebär att prestandan som visas i demonstrationen bör förstås i kontexten av en GPU-utrustad lokal server, snarare än som ett CPU-enbart test av ZimaBoard 2.

Ollama körs i ZimaOS-miljön. Systempanelen som visas bakom rapporterar ett NVIDIA GeForce RTX 3060 och 12 GB VRAM, vilket visar att den demonstrerade lokala AI-servern har GPU-acceleration tillgänglig.

Så fungerar den lokala AI-anslutningen

Grunddesignen kan förstås som tre lager:

• Serverlager: ZimaBoard 2 kör ZimaOS och är värd för Ollama.
• Agent- eller nätverkslager: Picoware eller Flippers nätverksstack skickar begäranden mellan den inbyggda enheten och den lokala servern.
• Enhetslager: Cardputer-ADV, PicoCalc eller Flipper Zero tillhandahåller det fysiska gränssnittet och utför enhetsspecifika åtgärder.

Den här uppdelningen är användbar eftersom språkmodellen inte behöver köras direkt på varje maskinvaruenhet. Den inbyggda programvaran på varje enhet kan exponera de funktioner den stöder, medan servern tillhandahåller den modellkapacitet som används för att tolka begäranden eller hjälpa till med utvecklingsuppgifter.

Cardputer-ADV och PicoCalc använder Picoware Agent

JBlankeds Picoware-projekt är en miljö med öppen källkod för fast programvara som stöder Cardputer-ADV, PicoCalc, Flipper Zero och andra enheter baserade på ESP32 eller Raspberry Pi Pico.

För det här experimentet är Picoware Agent den viktiga komponenten. Agent erbjuder ett LLM-drivet gränssnitt med olika användningskontexter i stället för att endast fungera som ett generiskt chattfönster.

De dokumenterade lägena omfattar allmän chatt, en appskapare utformad för att skapa eller redigera Picoware-applikationer samt enhetshanteringsfunktioner som kan arbeta med information och kommandon. Genom att ansluta dessa funktioner till Ollama-instansen på den lokala servern får den handhållna enheten ett AI-assisterat utvecklingsarbetsflöde, samtidigt som modellbelastningen hålls borta från den lilla enheten.

Flipper Zero skickar begäranden till den lokala AI-servern

Flipper Zero använder ett annat interaktionsmönster. I videon visar JBlanked hur enheten förbereder en strukturerad begärandepayload för den lokala modellen via ett Wi-Fi-kompatibelt utvecklingskort som är anslutet till Flipper.

Payloaden som visas på skärmen innehåller ett modellfält för qwen3.5:9b. Detta illustrerar ansvarsfördelningen tydligt: Flipper förbereder och skickar begäran, medan den valda språkmodellen körs på den mer kapabla lokala servern.

Flipper Zero förbereder en begärandepayload för den lokala AI-tjänsten. Skärmen visar modellfältet inställt på qwen3.5:9b, medan ett utvecklingskort med Wi-Fi är anslutet ovanpå enheten.

Den här skillnaden är viktig. Flipper kör inte hela språkmodellen lokalt. Dess roll är att tillhandahålla det portabla gränssnittet och nätverksanslutningen, medan Ollama och den valda modellen körs på servern.

Vad kan den lokala AI-agenten faktiskt göra?

Att ansluta en handhållen enhet till en LLM blir mer intressant när modellen kan göra mer än att besvara en fråga. JBlanked demonstrerar AI-servern som en del av ett arbetsflöde för inbyggd utveckling.

Skapa Picoware-appar

Picoware innehåller en App Creator-kontext för sin AI-agent. Det gör det möjligt för en utvecklare att beskriva en applikation eller ändring på naturligt språk och använda modellen för att hjälpa till att skapa eller redigera motsvarande Picoware-applikation.

I demonstrationen får App Creator i uppgift att bygga en enkel applikation som visar hälsningen ”hello from youtube” när den startas. Agenten returnerar en strukturerad beskrivning av det efterfrågade beteendet och hur gränssnittet ska fungera.

Picowares App Creator körs på PicoCalc. Agenten arbetar med en begäran om en applikation som visar ”hello from youtube”, medan Flipper Zero och Cardputer-ADV ligger bredvid enheten.

Det kan förkorta avståndet mellan en idé och en prototyp, särskilt på en enhet där det annars skulle vara besvärligt att skriva och redigera stora mängder källkod direkt på den lilla skärmen.

AI-genererad kod behöver fortfarande granskas. Kod som verkar rimlig kan innehålla felaktiga API:er, bristande felhantering, osäkra antaganden eller ett beteende som inte överensstämmer med den avsedda maskinvaran.

Inspektera inbyggd programvara och utvecklingsinformation

Agentens arbetsflöde kan även användas som utvecklingsassistent. I stället för att behandla den handhållna enheten som en vanlig chattklient kan systemet kombinera lokala modellsvar med information som exponeras av enheten och dess inbyggda programvara.

Det här tillvägagångssättet är särskilt användbart på små skärmar, där det kan gå långsammare att manuellt navigera bland loggar, dokumentation eller kommandoutdata än att be Agenten tolka en specifik begäran.

Hantera enheten

Picowares Agent-ramverk innehåller även funktioner för enhetshantering. Modellen kan arbeta med verktyg som exponeras av den inbyggda programvaran i stället för att bara returnera text som användaren måste köra manuellt.

I ett exempel i videon frågar användaren: ”hur många nätverk finns i närheten”. Device Manager svarar att sex närliggande Wi-Fi-nätverk är tillgängliga, vilket visar att Agenten kan använda information på enhetsnivå för att besvara en praktisk fråga i stället för att enbart förlita sig på allmän modellkunskap.

Picoware Device Manager på PicoCalc besvarar frågan ”hur många nätverk finns i närheten?”. Gränssnittet visar sex närliggande Wi-Fi-nätverk och demonstrerar hur agenten kan kombinera lokal AI med information från enheten.

Det är här en AI-agent skiljer sig från en vanlig chatbot. Språkmodellen tillhandahåller tolknings- och instruktionslagret, medan den fasta programvaran avgör vilka enhetsfunktioner och informationskällor som faktiskt är tillgängliga.

Varför en delad lokal AI-server är användbar för små enheter

Arkitekturen hanterar en grundläggande obalans i inbyggda AI-projekt: de mest portabla enheterna har ofta minst beräkningskapacitet för språkmodeller.

Att använda en delad server förändrar den avvägningen. En utvecklare kan behålla det fysiska gränssnittet i en fickstor enhet och samtidigt ge den åtkomst till en kraftfullare lokal dator över nätverket.

En AI-backend, flera maker-enheter

En av de mer användbara idéerna i JBlankeds experiment är att ZimaBoard 2 inte är bunden till ett enda gränssnitt. PicoCalc och Cardputer-ADV kan delta via Picoware, medan Flipper Zero kan kommunicera med samma lokala AI-miljö genom sitt eget nätverksflöde.

Det gör servern till en återanvändbar del av ett större maker-labb. I stället för att bygga om en AI-miljö för varje ny mikrokontroller eller bärbar dator kan utvecklare behålla inferenstjänsten centraliserad och fokusera på att bygga den klientintegration som passar varje enhet.

Konceptet kan också förenkla experimenterandet. En modell kan bytas ut på servern utan att den handhållna enheten behöver ersättas, samtidigt som den handhållna enhetens fasta programvara kan utvecklas oberoende av AI-körmiljön.

Vad experimentet bevisar – och vad det inte gör

JBlankeds bygge är en användbar demonstration av hur lokal AI kan integreras i inbyggd utveckling, men det är viktigt att skilja arkitekturen från garantier om prestanda eller säkerhet.

Lokalt betyder inte noll konfiguration

Att köra Ollama lokalt innebär att man inte behöver skicka varje inferensförfrågan till en chattbotstjänst i molnet, men hela systemet kräver fortfarande normal server- och nätverksplanering.

De ursprungliga modell- och applikationspaketen måste installeras, de handhållna enheterna behöver nätverksåtkomst till servern och alla exponerade tjänster bör konfigureras med avsedda nätverksgränser i åtanke. Utvecklare bör också kontrollera exakt vilka verktyg en AI-agent får anropa innan de aktiverar funktioner för enhetshantering.

Acceleratorkonfigurationen spelar också roll. RTX 3060 som syns i JBlankeds ZimaOS-instrumentpanel har 12 GB VRAM, så valet av modell måste fortfarande ta hänsyn till tillgängligt grafikminne, stöd för körmiljön och prestandakraven för den avsedda arbetsbelastningen.

För kodgenerering är det särskilt viktigt att ha säkerhetskopior eller versionshantering. Om en AI-assisterad ändring skapar en oanvändbar applikation eller firmwarekonfiguration behöver utvecklaren kunna återgå till ett känt fungerande läge.

Vem bör överväga en sådan här konfiguration?

Den här arkitekturen är särskilt intressant för utvecklare och makers som redan arbetar med inbyggda enheter men vill experimentera med lokala LLM:er utan att göra varje projekt till en integrering med ett moln-API.

Det kan vara användbart för:

• Cardputer- och PicoCalc-utvecklare som bygger Picoware-applikationer.
• Flipper Zero-användare som experimenterar med nätverksanslutna verktyg.
• Inbyggda systemutvecklare som vill ha AI-assistans nära sin testhårdvara.
• Homelab-användare som letar efter ytterligare en praktisk arbetsbelastning för en lokal server.
• Makers som vill att flera strömsnåla enheter delar på samma AI-backend.

En molnbaserad AI-tjänst kan fortfarande vara enklare för användare som bara behöver tillfällig chatt eller kodgenerering och inte vill underhålla en server. En större arbetsstation eller ett kraftfullare system utrustat med GPU kan också vara lämpligare när modellstorlek och inferenshastighet är de viktigaste prioriteringarna.

ZimaBoard 2-metoden blir ännu mer övertygande när målet är att hålla AI-tjänsten i samma homelab och göra tjänsten tillgänglig för flera fristående projekt.

Bygg en lokal AI-hubb för din maker-labbmiljö

JBlankeds projekt visar en användbar riktning för lokal AI: i stället för att fråga om varje liten enhet kan köra en språkmodell bör man fråga om dessa enheter kan använda en delad modell som körs någonstans som är bättre lämpad för uppgiften.

Med ZimaOS som kör Ollama på ZimaBoard 2, Picoware som tillhandahåller ett AI-assisterat gränssnitt för enheter som PicoCalc och Cardputer-ADV samt ett nätverksanslutet arbetsflöde som för in Flipper Zero i samma miljö, blir systemet en flexibel lokal AI-hubb för experiment med inbyggda system.

De fyra demonstrationerna visar också varför servern bör utvärderas som ett komplett system. De handhållna enheterna tillhandahåller gränssnitten och de hårdvaruspecifika funktionerna, Ollama tillhandahåller modellserverlagret och den GPU som är synlig i ZimaOS bidrar med ytterligare beräkningsresurser för den lokala AI-arbetsbelastningen.

Om du vill se ytterligare vad lokala modeller kan göra på samma plattform kan du läsa testet av ZimaBoard 2:s lokala AI-assistent, som undersöker sambandet mellan kompakt serverhårdvara, modellstorlek, lagring och AI-arbetsbelastningar.

Titta på JBlankeds fullständiga video för att se konfigurationen och enhetens arbetsflöde direkt, eller utforska Picoware-projektet på GitHub om du vill förstå hur Agent och de enheter som stöds passar ihop.

Vill du se vad andra byggare gör med kompakta servrar, lokal AI och ovanlig hårdvara? Gå med i ZimaSpace Discord-communityn för att upptäcka fler byggen, jämföra konfigurationer och dela dina egna experiment.