Inbyggt universellt gränssnittskort - USB/Bluetooth/WIFI -kontroll: 6 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:45

Jag tycker ofta att jag skapar bibliotek för nya inbäddade moduler från grunden baserat på enhetsdatabladet. När jag skapar biblioteket kommer jag att fastna i en kodcykel, kompilera, programmera och testa när saker och ting fungerar och är felfria. Ofta kan kompilerings- och programtiderna vara mycket längre än den tid det tar att redigera koden och så ett sätt att stänga av dessa steg vid utveckling skulle vara mycket praktiskt.

Jag tycker också ofta att jag vill ansluta en inbäddad modul till en dator. Om modulen inte specifikt har en USB -anslutning, vilket ofta är fallet, måste du i allmänhet köpa en dyr USB -omvandlare som gör ett enda jobb, till exempel bara SPI eller bara I2C.

Det är av dessa skäl jag bestämde mig för att skapa det universella gränssnittskortet. Den är utformad för att möjliggöra enkel PC -baserad kommunikation med inbäddade moduler.

De inbäddade gränssnittsfunktionerna i styrelsen som jag bestämde mig för inkluderar.

• Digital I/O
• I2C
• SPI
• UART
• PWM
• Servomotor
• ADC -ingång
• DAC -utgång

Alla kan användas helt oberoende.

Gränssnittskortet kan styras via en USB -anslutning till datorn, men har också valfria WIFI- eller Bluetooth -modulanslutningar så att kortet kan användas på distans eller i ett IoT -typscenario.

Genom att använda standard 2,54 mm SIL -sidhuvuden är det möjligt att direkt ansluta honkontaktkablar mellan kortet och den inbäddade modulen som möjliggör snabba, pålitliga och lödfria anslutningar.

Jag funderade också på att lägga till saker som CAN, LIN, H-bridge etc men dessa kan kanske komma senare med en v2-revision.

Steg 1: Designa kretskortet

När jag designar kretskortet gillar jag att försöka hålla saker så enkla som möjligt. När du ska bygga brädor för hand är det viktigt att bara lägga till komponenter när de har ett specifikt syfte och använda så många interna funktioner i mikrokontrollen som möjligt.

När jag tittade på min föredragna elektronikleverantör hittade jag ett chip jag var bekväm med som hade de funktioner jag letade efter och som var en rimlig kostnad. Chippet jag landade på var PIC18F24K50.

Med de tillgängliga 23 I/O -stiften tillät detta mig dessa funktioner

• Digtal I/O
• I2C
• SPI
• UART
• PWM x 2
• Servomotor x 6
• ADC -ingång x 3
• DAC -utgång x 1
• I/O drivs från 5V eller 3V3
• Status -LED

En nackdel med IC: n som jag valde är att den bara har en UART -kringutrustning och att använda Bluetooth- eller Wifi -kontrollmetoden hindrar dig från att kunna använda UART -anslutningen.

Visas i bilderna ovan är det färdiga schemat och PCB.

Steg 2: Utforma protokollet

Det första steget i utformningen av protokollet är att bestämma vad du specifikt kommer att behöva styrelsen för att kunna göra. Bryt upp saker ger en bättre kontrollnivå medan kammning av saker förenklar gränssnittet och minskar kommunikationstrafiken mellan kortet och datorn. Det är ett balansspel och svårt att göra perfekt.

För varje funktion på tavlan bör du ange alla parametrar och avkastning. Till exempel kan en funktion för att läsa en ADC -ingång ha en parameter för att ange vilken ingång som ska samplas och ett returvärde som innehåller resultatet.

I min design här är listan över funktioner jag ville inkludera:

• Digital I/O

  • SetPin (PinNumber, State)
  • State = GetPin (PinNumber)

• SPI

  • Initiera (SPI -läge)
  • DataIn = Överföring (DataOut)
  • ControlChipSelect (kanal, stat)
  • SetPrescaler (Rate)

• I2C

  • Initiera ()
  • Start ()
  • Omstart ()
  • Sluta ()
  • SlaveAck = Skicka (DataOut)
  • DataIn = Ta emot (senaste)

• UART

  • Initiera ()
  • TX Byte (DataOut)
  • BytesAvailable = RX Count ()
  • DataIn = RX Byte ()
  • SetBaud (Baud)

• PWM

  • Aktivera (kanal)
  • Inaktivera (kanal)
  • SetFrequency (kanal, frekvens)
  • GetMaxDuty (Duty)
  • SetDuty (Duty)

• Servo

  • Aktivera (kanal)
  • Inaktivera (kanal)
  • SetPosition (kanal, position)

• ADC

  ADCsample = Prov (kanal)

• DAC

  • Gör det möjligt
  • Inaktivera
  • SetOutput (spänning)

• WIFI

  • SetSSID (SSID)
  • Ange lösenord (lösenord)
  • Status = CheckConnectionStatus ()
  • IP = GetIPAddress ()

Parametrar visas inom parentes och returer visas före likvärdighetssymbolen.

Innan jag börjar koda tilldelar jag varje funktion en kommandokod från 128 (binär 0b10000000) och arbetar uppåt. Jag dokumenterar protokollet fullständigt för att se till att när mitt huvud är i koden har jag ett trevligt dokument att hänvisa till. Hela protokollet för detta projekt bifogas och innehåller inkommande kommandokoder och bitbredder.

Steg 3: Designa firmware

När protokollet är upprättat är det sedan ett fall att implementera funktionaliteten på hårdvaran.

Jag antar ett enkelt tillvägagångssätt för maskintypen när jag utvecklar slavsystem för att försöka maximera den potentiella kommandot och dataflödet samtidigt som firmware är enkel att förstå och felsöka. Ett mer avancerat system som Modbus kan användas istället om du behöver bättre interaktion med andra anslutna enheter men detta lägger till omkostnader som saktar ner saker.

Tillståndsmaskinen består av tre tillstånd:

1) Väntar på kommandon

2) Ta emot parametrar

3) Svara

De tre staterna samverkar enligt följande:

1) Vi går igenom de inkommande bytena i bufferten tills vi har en byte som har den mest betydande bituppsättningen. När vi väl fått en sådan byte kontrollerar vi den mot en lista över kända kommandon. Om vi hittar en matchning tilldelar vi antalet parameterbyte och returnerar byte för att matcha protokollet. Om det inte finns några parameterbyte kan vi utföra kommandot här och antingen hoppa till tillstånd 3 eller starta om tillstånd 1. Om det finns parameterbyte går vi till tillstånd 2.

2) Vi går igenom inkommande byte och sparar dem tills vi har lagrat alla parametrar. När vi har alla parametrar utför vi kommandot. Om det finns returbyte går vi till steg 3. Om det inte finns några returbytes att skicka, återgår vi till steg 1.

3) Vi går igenom de inkommande bytena och för varje byte skriver vi över ekobyten med en giltig returbyte. När vi har skickat alla returbytes återgår vi till steg 1.

Jag använde Flowcode för att designa firmware eftersom det visuellt visar visuellt vad jag gör. Samma sak kan göras lika bra i Arduino eller andra inbäddade programmeringsspråk.

Det första steget är att upprätta kommunikation med datorn. För att göra detta måste mikron konfigureras för att köra med rätt hastighet och vi måste lägga till kod för att driva USB- och UART -kringutrustning. I Flowcode är detta lika enkelt som att dra in i projektet en USB -seriell komponent och en UART -komponent från menyn Comms -komponent.

Vi lägger till ett RX -avbrott och en buffert för att fånga inkommande kommandon på UART och vi pollar regelbundet USB. Vi kan sedan på fritiden bearbeta bufferten.

Flowcode -projektet och genererad C -kod bifogas.

Steg 4: Gränssnitt via flödeskod

Flödeskodssimuleringen är mycket kraftfull och låter oss skapa en komponent för att prata med styrelsen. Vid skapandet av komponenten kan vi nu helt enkelt dra in komponenten i vårt projekt och omedelbart ha styrfunktionerna tillgängliga. Som en extra bonus kan alla befintliga komponenter som har SPI-, I2C- eller UART -kringutrustning användas i simuleringen och kommunikationsdata kan ledas till gränssnittskortet via en injektorkomponent. De bifogade bilderna visar ett enkelt program för att skriva ut ett meddelande till displayen. Kommandodata som skickas via gränssnittskortet till den faktiska skärmhårdvaran och komponentinställningen med I2C Display, I2C Injector och Interface Board -komponenter.

Det nya SCADA -läget för Flowcode 8.1 är en absolut extra bonus genom att vi sedan kan ta ett program som gör något i Flowcode -simulatorn och exportera det så att det körs fristående på vilken dator som helst utan några licensproblem. Detta kan vara bra för projekt som testriggar eller sensorkluster.

Jag använder detta SCADA -läge för att skapa WIFI -konfigurationsverktyget som kan användas för att konfigurera SSID och lösenord samt samla in modulens IP -adress. Detta gör att jag kan konfigurera allt med USB -anslutningen och sedan överföra till en WIFI -nätverksanslutning när saker och ting är igång.

Några exempelprojekt bifogas.

Steg 5: Andra gränssnittsmetoder

Förutom Flowcode kan du i stort sett använda ditt valda programmeringsspråk för att kommunicera med gränssnittskortet. Vi använde Flowcode eftersom det hade ett bibliotek med delar som redan fanns som vi kunde starta omedelbart, men det gäller också många andra språk.

Här är en lista över språk och metoder för att kommunicera med gränssnittskortet.

Python - Använda ett seriellt bibliotek för att strömma data till en COM -port eller IP -adress

Matlab - Använda filkommandon för att strömma data till en COM -port eller IP -adress

C ++ / C# / VB - Använd antingen en förskriven DLL, direkt åtkomst till COM -porten eller Windows TCP / IP API

Labview - Använd antingen en förskriven DLL, VISA Serial -komponenten eller TCP/IP -komponenten

Om någon vill se ovanstående språk implementerade, vänligen meddela mig.

Steg 6: Färdig produkt

Den färdiga produkten kommer sannolikt att vara en framträdande egenskap i mitt inbäddade verktygssats i många år framöver. Det har redan hjälpt mig att utveckla komponenter för olika Grove -skärmar och sensorer. Jag kan nu få koden helt spikad innan jag tar till någon sammanställning eller programmerar shenanigans.

Jag har till och med delat ut några styrelser för kollegor så att de också kan förbättra sitt arbetsflöde och dessa har blivit mycket väl mottagna.

Tack för att du läste min Instructable Jag hoppas att du tyckte att den var användbar och förhoppningsvis kommer den att inspirera dig att skapa dina egna verktyg för att påskynda din produktivitet.