Innebygd universelt grensesnittkort - USB/Bluetooth/WIFI -kontroll: 6 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:23

Jeg finner ofte at jeg oppretter biblioteker for nye innebygde moduler fra bunnen av basert på enhetsdatabladet. Ved å generere biblioteket finner jeg ut at jeg blir sittende fast i en syklus med kode, kompilere, programmere og teste når tingene fungerer og er feilfrie. Ofte kan kompilerings- og programtidene være mye lengre enn tiden det tar å redigere koden, og en måte å kutte ut disse trinnene når du utvikler vil være veldig nyttig.

Jeg finner også ofte ut at jeg vil koble en innebygd modul til en PC. Hvis modulen ikke spesifikt har en USB -tilkobling, noe som ofte er tilfelle, må du vanligvis kjøpe en overpriset USB -omformer som vil gjøre en enkelt jobb, for eksempel bare SPI eller bare I2C.

Det var av disse grunnene jeg bestemte meg for å lage det universelle grensesnittkortet. Den er designet for å tillate enkel PC -basert kommunikasjon med innebygde moduler.

De innebygde grensesnittfunksjonene til brettet jeg slo meg ned på inkluderer.

• Digital I/O
• I2C
• SPI
• UART
• PWM
• Servo motor
• ADC -inngang
• DAC -utgang

Alle kan brukes helt uavhengig.

Grensesnittkortet kan styres via en USB -tilkobling til PC -en, men har også valgfrie WIFI- eller Bluetooth -modultilkoblinger slik at kortet kan brukes eksternt eller i et IoT -type scenario.

Ved å bruke standard 2,54 mm stigning SIL -hoder er det mulig å koble hun -dupontkabler direkte mellom kortet og den innebygde modulen, noe som muliggjør raske, pålitelige og loddfrie tilkoblinger.

Jeg tenkte også på å legge til ting som CAN, LIN, H-bridge etc, men disse kan kanskje komme senere med en v2-revisjon.

Trinn 1: Utforming av kretskortet

Når jeg designer PCB -en, liker jeg å prøve å holde tingene så enkle som mulig. Når du skal bygge brett for hånd, er det viktig å bare legge til komponenter når de har et bestemt formål og bruke så mange interne funksjoner i mikrokontrolleren som mulig.

Når jeg så på min foretrukne elektronikkleverandør fant jeg en brikke jeg var komfortabel med som hadde funksjonene jeg lette etter og som var en rimelig pris. Brikken jeg landet på var PIC18F24K50.

Med de tilgjengelige 23 I/O -pinnene tillot dette meg disse funksjonene

• Digtal I/O
• I2C
• SPI
• UART
• PWM x 2
• Servomotor x 6
• ADC -inngang x 3
• DAC -utgang x 1
• I/O drevet fra 5V eller 3V3
• Status LED

En ulempe med IC -en jeg valgte er at den bare har én UART -periferutstyr, så bruk av Bluetooth- eller Wifi -kontrollmetoden vil stoppe deg fra å kunne bruke UART -tilkoblingen.

Vist på bildene ovenfor er det ferdige skjematiske og PCB.

Trinn 2: Utforming av protokollen

Det første trinnet i utformingen av protokollen er å bestemme hva du spesielt vil trenge for at styret skal kunne gjøre. Bryt opp ting gir et bedre kontrollnivå, mens kombinering av ting forenkler grensesnittet og reduserer kommunikasjonstrafikk mellom brettet og PCen. Det er et balanserende spill og vanskelig å perfeksjonere.

For hver funksjon av brettet bør du angi eventuelle parametere og avkastninger. For eksempel kan en funksjon for å lese en ADC -inngang ha en parameter for å spesifisere hvilken inngang som skal prøves og en returverdi som inneholder resultatet.

I mitt design er her listen over funksjoner jeg ønsket å inkludere:

• Digital I/O

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

• SPI

  • Initialiser (SPI -modus)
  • DataIn = Overføring (DataOut)
  • ControlChipSelect (kanal, stat)
  • SetPrescaler (Rate)

• I2C

  • Initialiser ()
  • Start ()
  • Omstart ()
  • Stoppe ()
  • SlaveAck = Send (DataOut)
  • DataIn = Motta (siste)

• UART

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

• PWM

  • Aktiver (kanal)
  • Deaktiver (kanal)
  • SetFrequency (kanal, frekvens)
  • GetMaxDuty (Duty)
  • SetDuty (Duty)

• Servo

  • Aktiver (kanal)
  • Deaktiver (kanal)
  • SetPosition (kanal, posisjon)

• ADC

  ADCsample = Eksempel (kanal)

• DAC

  • Muliggjøre
  • Deaktiver
  • SetOutput (spenning)

• WIFI

  • SetSSID (SSID)
  • Angi passord (passord)
  • Status = CheckConnectionStatus ()
  • IP = GetIPAddress ()

Parametere vises i parentesene, og avkastningen vises før symbolet for lik.

Før jeg begynner å kode, tilordner jeg hver funksjon en kommandokode som starter fra 128 (binær 0b10000000) og jobber oppover. Jeg dokumenterer protokollen fullt ut for å sikre at når hodet mitt er i koden, har jeg et fint dokument å referere tilbake til. Hele protokolldokumentet for dette prosjektet er vedlagt og inkluderer innkommende kommandokoder og bitbredder.

Trinn 3: Designe fastvaren

Når protokollen er etablert, gjelder det å implementere funksjonaliteten på maskinvaren.

Jeg bruker en enkel tilnærming til maskintype når jeg utvikler slavesystemer for å prøve å maksimere den potensielle kommandoen og datagjennomstrømningen, samtidig som fastvaren er enkel å forstå og feilsøke. Et mer avansert system som Modbus kan brukes i stedet hvis du trenger bedre interaksjon med andre tilkoblede enheter, men dette legger til overhead som vil bremse ting.

Statsmaskinen består av tre stater:

1) Venter på kommandoer

2) Motta parametere

3) Svar

De tre statene samhandler som følger:

1) Vi går gjennom de innkommende byte i bufferen til vi har en byte som har den mest betydelige biten. Når vi mottar en slik byte, sjekker vi den mot en liste over kjente kommandoer. Hvis vi finner en samsvar, tildeler vi antall parameterbyte og returnerer byte for å matche protokollen. Hvis det ikke er noen parameterbyte, kan vi utføre kommandoen her og enten hoppe til tilstand 3 eller starte tilstanden 1. Hvis det er parameterbyte, går vi til tilstand 2.

2) Vi går gjennom innkommende byte og lagrer dem til vi har lagret alle parameterne. Når vi har alle parameterne utfører vi kommandoen. Hvis det er returbyte, går vi til trinn 3. Hvis det ikke er noen returbyte å sende, går vi tilbake til trinn 1.

3) Vi går gjennom de innkommende byte, og for hver byte overskriver vi ekkobyten med en gyldig returbyte. Når vi har sendt alle returbytes, går vi tilbake til trinn 1.

Jeg brukte Flowcode til å designe fastvaren, da den visuelt demonstrerer visuelt hva jeg gjør. Det samme kan gjøres like godt i Arduino eller andre innebygde programmeringsspråk.

Det første trinnet er å etablere kommunikasjon med PC -en. For å gjøre dette må mikroen konfigureres til å kjøre med riktig hastighet, og vi må legge til kode for å drive USB- og UART -eksterne enheter. I Flowcode er dette like enkelt som å dra inn i prosjektet en USB Serial -komponent og en UART -komponent fra Comms -komponentmenyen.

Vi legger til en RX -avbrudd og buffer for å fange innkommende kommandoer på UART, og vi poller regelmessig USB -en. Vi kan da i fritiden behandle bufferen.

Flowcode -prosjektet og generert C -kode er vedlagt.

Trinn 4: Grensesnitt via strømningskode

Flowcode -simuleringen er veldig kraftig og lar oss lage en komponent for å snakke med brettet. Ved å lage komponenten kan vi nå dra komponenten inn i prosjektet vårt og umiddelbart få brettfunksjonene tilgjengelige. Som en ekstra bonus kan enhver eksisterende komponent som har en SPI, I2C eller UART periferiutstyr brukes i simuleringen, og kommunikasjonsdataene kan ledes til grensesnittkortet via en Injektor -komponent. De vedlagte bildene viser et enkelt program for å skrive ut en melding til displayet. Kommandodataene som sendes via grensesnittkortet til selve skjermens maskinvare og komponentoppsettet med I2C Display, I2C Injector og Interface Board -komponenter.

Den nye SCADA -modusen for Flowcode 8.1 er en absolutt tilleggsbonus ved at vi deretter kan ta et program som gjør noe i Flowcode -simulatoren og eksportere det slik at det kan kjøres frittstående på hvilken som helst PC uten lisensproblemer. Dette kan være flott for prosjekter som testrigger eller sensorklynger.

Jeg bruker denne SCADA -modusen til å lage WIFI -konfigurasjonsverktøyet som kan brukes til å konfigurere SSID og passord, samt samle IP -adressen til modulen. Dette lar meg konfigurere alt ved hjelp av USB -tilkoblingen og deretter overføre til en WIFI -nettverkstilkobling når ting er i gang.

Noen eksempler på prosjekter er vedlagt.

Trinn 5: Andre grensesnittmetoder

I tillegg til Flowcode kan du stort sett bruke valgfritt programmeringsspråk til å kommunisere med grensesnittkortet. Vi brukte Flowcode ettersom det hadde et bibliotek med deler som allerede var inkludert som vi kunne komme i gang med en gang, men dette gjelder også mange andre språk.

Her er en liste over språk og metoder for å kommunisere med grensesnittkortet.

Python - Bruke et serielt bibliotek for å streame data til en COM -port eller IP -adresse

Matlab - Bruke filkommandoer til å streame data til en COM -port eller IP -adresse

C ++ / C# / VB - Bruk enten en forhåndsskrevet DLL, direkte tilgang til COM -porten eller Windows TCP / IP API

Labview - Bruk enten en forhåndsskrevet DLL, VISA Serial -komponenten eller TCP/IP -komponenten

Hvis noen vil se språkene ovenfor implementert, vennligst gi meg beskjed.

Trinn 6: Ferdig produkt

Det ferdige produktet vil trolig være en fremtredende funksjon i mitt innebygde verktøysett i årene som kommer. Det har allerede hjulpet meg å utvikle komponenter for forskjellige Grove -skjermer og sensorer. Jeg kan nå få koden fullstendig spikret før jeg tar i bruk noen kompilering eller programmerer shenanigans.

Jeg har til og med delt ut noen styrer til kolleger, slik at de også kan forbedre arbeidsflyten, og disse har blitt veldig godt mottatt.

Takk for at du leste instruksjonsboken min. Jeg håper du fant den nyttig, og forhåpentligvis vil den inspirere deg til å lage dine egne verktøy for å øke produktiviteten.