Akselerere utviklingen av installasjoner som inneholder børsteløse likestrømsmotorer (BLDC – brushless direct current) for bilindustrien og IoT med A4964KJPTR-T-motordriveren

Børsteløse likestrømsmotorer (BLDC – brushless direct current) brukes i økende grad for mange og varierte bruksområder, fra fjernstyrte tingenes Internett (IoT)-garasjeåpnere og -bilvinduer, til styringer for drivsystemene i satellitter. Problemet konstruktører står ovenfor med BLDC-motorer er at styringsalgoritmene som er nødvendige for å drive dem, er kompliserte og ofte spesialiserte. Dette gjør det vanskelig for den gjennomsnittlige teknikeren å komme i gang i løpet av rimelig tid.

Utviklere er vanligvis nødt til å velge mellom en programvarebasert løsning som kjører på en mikrokontroller – som tilbyr en fleksibel programvareløsning, men som også er en ekstra byrde for mikrokontrolleren – eller bruke en dedikert IC (integrert krets). Sistnevnte sammenfatter hele BLDC-motorstyringsfunksjonen og avlaster BLDC-styring fra verten.

Denne artikkelen omhandler forskjellene mellom en mikrokontrollerbasert programvareløsning og en dedikert maskinvarebrikkeløsning. Deretter tar den grundig for seg hvordan man bruker Allegro MicroSystems A4964KJPTR-T, som er en motordriver konstruert for å forenkle BLDC-motorstyring spesielt for kjøretøyutrustning. Artikkelen vil vise hvordan man samhandler med A4964KJPTR-T, samt noen anbefalte fremgangsmåter for hvordan man unngår uventet oppførsel.

En (svært) kort innføring i BLDC-motorer

BLDC-motorer gir dreiemoment med høy virkningsgrad over et bredt spekter av hastigheter, de er stillegående og de rammes ikke av mekanisk friksjon fra børstemotorer. BLDC-motorer styres av strøm, ikke spenning, noe som gjør at de kan brukes i et bredt spekter av konstruksjoner, og de har et bredt utvalg av former, størrelser og kostnadspunkter.

For eksempel er TRINAMIC Motion Controls QBL4208-41-04-006 en 24-volts motor med 4000 omdreininger per minutt (RPM), som leverer et dreiemoment på opptil 0,06 newtonmeter (Nm) (figur 1). Motoren veier bare 0,300 kg (0,662 pund (lb)) og gir utviklere flere alternativer for å styre motoren, for eksempel gjennom sensorfri drift ved å bruke motelektromotorisk kraft (BEMF – back electromotive force), eller ved å bruke innebygde sensorer som rapporterer posisjonen.

Figur 1: QBL4208-41-04-006, en 24-volts BLDC-motor med 4000 o/min (RPM) som kan levere litt over 0,06 Nm dreiemoment ved maksimal hastighet. (Bildekilde: TRINAMIC Motion Control GmbH)

For å oppnå mer dreiemoment, kan konstruktører bruke QBL4208-41-04-025, som også er fra TRINAMIC Motion Control (figur 2). Dette er en 24-volts BLDC-motor med 4000 o/min (RPM) som kan levere litt over 0,25 Nm dreiemoment.

Figur 2: TRINAMIC Motion Control QBL4208-41-04-025, en 24-volts BLDC-motor med 4000 o/min (RPM) som kan levere litt over 0,25 Nm dreiemoment ved maksimal hastighet. (Bildekilde: TRINAMIC Motion Control GmbH)

BLDC-motorer drives gjennom trefaseledninger som genererer et magnetfelt som så skyver mot permanente magneter for å bevege statoren og spinne motoren.

I teorien høres dette enkelt ut, men i praksis er det ganske komplisert å drive en BLDC-motor. Konstruktører må velge mellom å bruke et programvarerammeverk til å drive motoren eller velge en dedikert brikkeløsning.

Programvare kontra dedikerte brikkeløsninger

Det er flere faktorer som utviklere bør ta hensyn når de skal løse hvordan de skal spinne opp BLDC-motoren. Disse faktorene dreier seg i bunn og grunn om:

• Materialkostnader kontra arbeidskostnader
• Kretskortkompleksitet kontra programvarekompleksitet
• Vedlikeholdstid og -kostnader

Fra et maskinvareperspektiv kan det være svært fristende å velge programvareruten, fordi en dedikert brikkeløsning øker materialkostnadene noe. I stedet for en dedikert brikke, kan du fjerne denne kostnaden, bruke en brøkdel mer på en mikrokontroller, og programmere alle styringsalgoritmene i mikrokontrolleren. Dette kan virke som en vinn-vinn-situasjon, men team tar ofte ikke hensyn til alle konsekvensene som følge av denne beslutningen.

Ja, det reduserer materialkostnadene, men det legger også en ekstra byrde på mikrokontrolleren som må behandle BLDC-tilstandsdata og kontinuerlig drive motoren. Hvis mikrokontrolleren også prøver å ta samplinger av andre sensorer, kommunisere med en radio og styre andre enheter, kan kostnader relatert til programvareutvikling og vedlikehold eksplodere hvis man ikke er forsiktig.

Når det er sagt, kan en programvarebasert løsning i en mikrokontroller tilby fleksibilitet, siden team kan finjustere motorstyringsalgoritmene. Bruk av programvare betyr heller ikke at ting alltid er nødt til å være altfor komplisert.

For eksempel vil det vanligvis være slik at flytting av motorstyringsalgoritmen inn i mikrokontrolleren kan bruke mer RAM og kreve mye flashminne. Hvis et team derimot bruker en mikrokontroller som er utviklet for motorstyring, for eksempel Texas Instruments F280049CRSHSR-mikrokontrolleren for motorstyring, er algoritmene innebygd i et bibliotek som befinner seg i ROM-en til mikrokontrolleren. Dette betyr at den eneste tilleggskoden som legges til i programmet er funksjonskallene for å få tilgang til biblioteket som utfører alle de tunge oppgavene.

Å spinne opp en BLDC-motor handler ikke bare om programvaren, men krever også maskinvare. Figur 3 viser et eksempelprogram som bruker en C2000-mikrokontroller, der F280049CRSHSR er et familiemedlem, som illustrerer alt som er nødvendig og valgfritt for å drive en BLDC-motor. I tillegg til en mikrokontroller, må det også være et trefaset effekttrinn som kan drive de tre fasene på BLDC-motoren slik at motoren kan spinne rundt.

Figur 3: Texas Instruments sine C2000-mikrokontrollere er utviklet for motorstyringskonstruksjoner. Dette bildet viser en eksempelløsning med mikrokontrolleren i midten og de nødvendige og valgfrie kretsene som trengs for å drive en BLDC-motor. (Bildekilde: Texas Instruments)

Å bruke en mikrokontroller til å drive motoren er definitivt en interessant løsning, men hvordan ser en dedikert maskinvareløsning ut? La oss ta en titt på Allegro MicroSystems sin A4964KJPTR-T-motordriverbrikke.

Allegro MicroSystems A4964KJPTR-T-motordriver

Allegro MicroSystems A4964KJPTR-T-motordriverbrikken er en dedikert BLDC-motordriver som inneholder all de nødvendige funksjonene som trengs for å drive en motor (figur 4). Brikken er spesielt utviklet for kjøretøyutrustninger og bruk med N-kanal MOSFET-er, og den har sensorfri oppstart og kommutering (strømvending), så den krever minimalt med ekstern maskinvare. A4964KJPTR-T fungerer også over et bredt spekter av spenninger, fra 5,5 til 50 volt, som dekker nesten alle standard bruksområder, deriblant kjøretøysystemer.

Kanskje den mest interessante funksjonen til A4964KJPTR-T, er at den kan kobles til en mikrokontroller eller sentral elektronisk styringsenhet (ECU) over det serielle periferigrensesnittet (SPI) slik at den kan konfigurere de forskjellige registrene for motordrift. Mikrokontrolleren trenger selvsagt ikke være like kraftig som en som driver selve motorstyringsalgoritmene.

Figur 4: A4964KJPTR-T BLDC-motordriveren kan fungere fra 5,5 til 50 volt og gir sensorfri oppstart og kommutering. Motorhastighet kan konfigureres gjennom SPI eller gjennom et dedikert PWM-signal. (Bildekilde: Allegro MicroSystems)

Alternativt, og dette er den interessante delen, kan A4964KJPTR-T-motorhastigheten drives uten SPI ved å rett og slett gi et pulsbreddemodulasjonssignal (PWM-signal). Ikke-flyktig minne finnes der innstillingene for motoren kan lagres, som lastes inn ved påslåing, slik at alt som trengs som å styre motoren er et PWM-signal.

Fra et konfigurasjonsperspektiv, har A4964KJPTR-T 32 adresserbare 16-bits registre, pluss et statusregister. Statusregisteret er unikt ved at de første 5 bitene overføres under hver lese-/skriveoperasjon på SPI-en, noe som gir programvaren mulighet til å sjekke en generell status for å se om det er noen feil eller problemer. Alle statusregistrene kan leses ut under skriveoperasjoner til brikken, siden ingen data overføres tilbake fra A4964KJPTR-T.

Det er også to spesialregistre i de 32 adresserbare registrene. Register 30 er skrivbart, men ikke lesbart (write-only), og register 31 er skrivebeskyttet (read-only). Det skrivbare/ikke-lesbare registeret gjør det mulig for en utvikler å angi etterspørselsinndata (demand input), eller driftssyklushastigheten motoren vil bli drevet med for en verdi mellom 0–1023. De skrivebeskyttede registerdataene endres basert på de forespurte dataene som er skrevet til register 29, som er registeret for tilbakeleveringsutvalg (readback select register). Dette registeret gjør det mulig å hente et bredt spekter av telemetriinformasjon, for eksempel:

• Diagnostikk
• Motorhastighet
• Gjennomsnittlig forsyningsstrøm
• Forsyningsspenning
• Brikketemperatur
• Etterspørselsinndata
• Påført topp for broens driftssyklus
• Påført faseforsprang

Utover disse spesialregistrene, gjør de gjenværende 30 det mulig for den bestemte motorkonstruksjonen å justeres og feil kan aktiveres eller deaktiveres, for eksempel strømbegrensning og gate-driver-feil.

Dedikerte motordrivere er interessante fordi de oppsummerer alt som må konfigureres for å kunne kjøre motoren til noen få titalls konfigurasjonsregistre. Dette fjerner dramatisk all programvare som ellers ville ha eksistert på en mikrokontroller, og kanskje enda viktigere, kan dramatisk redusere kostnader relatert til programvareutvikling og vedlikehold. Det å drive BLDC-en er da så enkelt som å sende en pulsbreddemodulator (PWM) som ikke kan ha noen overhead (responstid før utførelse av instruksjon) i en mikrokontroller, eller aktivere motorbiten og tilveiebringe en SPI-basert etterspørselsinngang for å spinne BLDC-en.

Tips og triks for å bruke A4964KJPTR-T

A4964KJPTR-T er relativt ukomplisert å koble seg opp mot, men det er flere «tips og triks» som utviklere bør være oppmerksomme på slik at utviklingen kan forenkles og fremskyndes, for eksempel:

• Statusregisteret returneres på SPI-grensesnittet under hver skriving til brikken, og er ikke tilgjengelig som et dedikert, adresserbart register. Dette betyr at driverkoden må overvåke SPI-bussens SDO-linje og samtidig skrive til brikken for å få statusinformasjon.
• Feilinformasjon er inkludert i statusregisteret, men en oversikt over brikkens status er tilgjengelig i hver SPI-transaksjon i de første fem bitene når mikrokontrolleren tilveiebringer adressetilgangsinformasjonen. Disse dataene kan brukes til å finne ut om det har oppstått problemer.
• Det er to unike registre i minnekartet som er skrivebeskyttet og skrivbare/ikke-lesbare. Dette er ukomplisert, men vær forsiktig så du ikke prøver å lese fra det skrivbare/ikke-lesbare registeret, da dette vil skrive de kunstige dataene som måtte befinne seg i lesesekvensen til registeret.
• Brikken har noe ikke-flyktig minne som kan brukes til å lagre standardparametere. Disse parametrene lastes inn i RAM-en og brukes under oppstart. For å sikre at brikken starter opp i klartilstand på en effektiv måtet, kan «sikre» oppstartsverdier programmeres inn i brikken.
• Hvis sluttenheten kjører i støyende eller strålingsrike omgivelser, kan det være en god ide å lage programkoden på en slik måte at den bekrefter konfigurasjonsdataene med jevne mellomrom. Brikkekonfigurasjonen lagres i RAM-en, noe som betyr at den er sårbar for kosmiske stråler, bit-vippinger (bit-flips) og andre «morsomme», sjeldne hendelser som kan oppstå med elektronikk.

Konklusjon

BLDC-motorimplementasjoner for bilindustrien, IoT eller andre bruksområder er ganske vanlig, men det kan være komplisert å drive dem. For å håndtere programvarekompleksiteten, kan utviklere bruke en dedikert BLDC-motordriver, for eksempel A4964KJPTR-T, som innkapsler all funksjonaliteten for motorstyring.

Selv om programvare fortsatt er nødvendig for å samhandle med brikken, er mikrokontrolleren som kjører programvaren kun nødt til å stille inn konfigurasjonsinnstillingene, og A4964KJPTR-T tar seg av å drive motoren. Utviklere som følger de medfølgende «tipsene og triksene» vil oppdage at de kan spare ganske mye tid og stress når de forsøker å bruke A4964KJPTR-T.