Industriële fabricage
Industrieel internet der dingen | Industriële materialen | Onderhoud en reparatie van apparatuur | Industriële programmering |
home  MfgRobots >> Industriële fabricage >  >> Industrial Internet of Things >> Internet of Things-technologie

Ontwikkeling van stuurprogramma's voor Linux-apparaten:het subsysteem voor pincontrole

Noot van de redactie:de embedded Linux-kernel speelt al een cruciale rol in embedded systemen en zal nog belangrijker worden om te voldoen aan de uiteenlopende vereisten van het Internet of Things (IoT). Op hun beurt vormen apparaatstuurprogramma's de cruciale link tussen applicaties en IoT-apparaten zelf. In Linux Device Drivers Development biedt auteur John Madieu een uitgebreid overzicht van de ontwikkeling van deze stuurprogramma's, waarbij een gedetailleerde uitleg wordt gecombineerd met tal van codevoorbeelden.

Dit fragment, hoofdstuk 14 uit het boek, richt zich op pincontrole en GPIO's — een gebied dat van bijzonder belang is voor ontwikkelaars van embedded systemen die interactie willen hebben met aangepaste hardwareapparaten. Deze eerste aflevering van dit fragment introduceert het pincontrole-subsysteem.

Aangepast van Linux Device Drivers Development, door John Madieu.


Hoofdstuk 14. Pincontrole en GPIO-subsysteem
Door John Madieu

De meeste embedded Linux-stuurprogramma's en kernelingenieurs schrijven met GPIO's of spelen met pins-multiplexing. Met pinnen bedoel ik uitgaande lijn van component. SoC maakt gebruik van multiplex-pinnen, wat betekent dat een pin verschillende functies kan hebben, bijvoorbeeld MX6QDL_PAD_SD3_DAT1 in arch/arm/boot/dts/imx6dl-pinfunc.h kan ofwel een SD3-datalijn 1, UART1's cts/rts, Flexcan2's Rx of normale GPIO.

Het mechanisme waarmee men de modus kiest waarop een pin moet werken, wordt pin-muxing genoemd. Het systeem dat hiervoor verantwoordelijk is, wordt de pincontroller genoemd. In het tweede deel van het hoofdstuk bespreken we de Algemene Invoer Uitvoer (GPIO ), wat een speciale functie (modus) is waarin een pin kan werken.

In dit hoofdstuk zullen we:

  • Loop door het pincontrole-subsysteem en kijk hoe men hun knooppunten in DT kan declareren

  • Ontdek zowel legacy op integers gebaseerde GPIO-interfaces als de nieuwe op descriptor gebaseerde interface-API

  • Omgaan met GPIO toegewezen aan IRQ

  • Behandel sysfs-interfaces speciaal voor GPIO's

Subsysteem voor pincontrole

De Pin-bediening (pinctrl ) subsysteem maakt het beheer van pin-muxing mogelijk. In de DT moeten apparaten die pinnen nodig hebben om op een bepaalde manier te worden gemultiplext, de configuratie van de pinbesturing aangeven die ze nodig hebben.

Het pinctrl-subsysteem biedt:

  • Pin-multiplexing, waarmee dezelfde pin opnieuw kan worden gebruikt voor verschillende doeleinden, zoals een UART TX-pin, GPIO-lijn of HSI datalijn. Multiplexen kan groepen pinnen of individuele pinnen beïnvloeden.

  • Pinconfiguratie, toepassen van elektronische eigenschappen van pinnen zoals pull-up, pull-down, driversterkte, debounce-periode, enzovoort.

Het doel van dit boek is beperkt tot het gebruik van functies die door de pincontroller-driver zijn geëxporteerd, en niet hoe een pincontroller-driver moet worden geschreven.

Pinctrl en de apparaatstructuur

De pinctrl is niets anders dan een manier om pinnen (niet alleen GPIO) te verzamelen en door te geven aan de bestuurder. Het stuurprogramma van de pincontroller is verantwoordelijk voor het ontleden van pinbeschrijvingen in de DT en het toepassen van hun configuratie in de chip. Het stuurprogramma heeft meestal een set van twee geneste knooppunten nodig om de groep pinnenconfiguraties te beschrijven. Het eerste knooppunt beschrijft de functie van de groep (waarvoor de groep zal worden gebruikt), het tweede knooppunt bevat de pinnenconfiguratie.

Hoe pingroepen in de DT worden toegewezen, hangt sterk af van het platform en dus van de pincontroller-driver. Elke pincontrolestatus krijgt een geheel getal-ID beginnend bij 0 en aaneengesloten. Men kan een naameigenschap gebruiken, die bovenop ID's wordt toegewezen, zodat dezelfde naam altijd naar dezelfde ID verwijst.

De eigen binding van elk clientapparaat bepaalt de set statussen die moet worden gedefinieerd in zijn DT-knooppunt, en of de set status-ID's moet worden gedefinieerd die moet worden opgegeven, of dat de set statusnamen moet worden gedefinieerd die moet worden opgegeven. Een pinconfiguratieknooppunt kan in ieder geval door middel van twee eigenschappen aan een apparaat worden toegewezen:

  • pinctrl- :Dit maakt het mogelijk om de lijst met pinctrl-configuraties te geven die nodig zijn voor een bepaalde toestand van het apparaat. Het is een lijst met phandles, die elk verwijzen naar een pinconfiguratieknooppunt. Deze pinconfiguratieknooppunten waarnaar wordt verwezen, moeten onderliggende knooppunten zijn van de pincontroller die ze configureren. Er kunnen meerdere vermeldingen in deze lijst voorkomen, zodat meerdere pincontrollers kunnen worden geconfigureerd, of zodat een status kan worden opgebouwd uit meerdere knooppunten voor een enkele pincontroller, die elk een bijdrage leveren aan de algehele configuratie.

  • pinctrl-name :Dit maakt het mogelijk om elke staat in een lijst een naam te geven. Lijstitem 0 definieert de naam voor integer status-ID 0, lijstitem 1 voor status-ID 1, enzovoort. De status-ID 0 krijgt gewoonlijk de naam default . De lijst met gestandaardiseerde statussen is te vinden in include/linux/pinctrl/pinctrl-state.h .

Het volgende is een uittreksel van DT, waarin enkele apparaatknooppunten worden weergegeven, samen met hun pinbesturingsknooppunten:

In het voorgaande voorbeeld wordt een pinconfiguratie gegeven in de vorm . Bijvoorbeeld:

MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x80000000

MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 staat voor de pin-functie, in dit geval GPIO, en 0x80000000 staat voor de pin-instellingen. Voor deze regel,

MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1

MX6QDL_PAD_EIM_D25__UART3_RX_DATA vertegenwoordigt de pin-functie, de RX-lijn van UART3, en 0x1b0b1 vertegenwoordigt de instellingen.

De pin-functie is een macro waarvan de waarde alleen van belang is voor de pincontroller-driver. Deze worden over het algemeen gedefinieerd in header-bestanden die zich in arch//boot/dts/ bevinden. Als men bijvoorbeeld een UDOO quad gebruikt, die een i.MX6 quad core (ARM) heeft, zou de header van de pinfunctie arch/arm/boot/dts/imx6q-pinfunc.h zijn. Het volgende is de macro die overeenkomt met de vijfde regel van de GPIO5-controller:

#define MX6QDL_PAD_DISP0_DAT11__GPIO5_IO05 0x19c 0x4b0 0x000 0x5 0x0

kan worden gebruikt om dingen in te stellen zoals pull-ups, pull-downs, keepers, aandrijfkracht, enzovoort. Hoe het moet worden gespecificeerd, hangt af van de binding van de pincontroller en de betekenis van de waarde hangt af van het SoC-gegevensblad, meestal in de IOMUX-sectie. Op i.MX6 IOMUXC worden hiervoor alleen minder dan 17 bits gebruikt.

Deze voorgaande knooppunten worden aangeroepen vanaf het corresponderende stuurprogrammaspecifieke knooppunt. Bovendien worden deze pinnen geconfigureerd tijdens de bijbehorende driverinitialisatie. Voordat u een pingroepstatus selecteert, moet u eerst de pincontrole verkrijgen met behulp van de pinctrl_get() functie, pinctrl_lookup_state() aanroepen om te controleren of de gevraagde status bestaat of niet, en ten slotte pinctrl_select_state() om de status toe te passen.

Het volgende is een voorbeeld dat laat zien hoe u een pincontrole kunt krijgen en de standaardconfiguratie kunt toepassen:

Meestal voert men dergelijke stappen uit tijdens de initialisatie van het stuurprogramma. De geschikte plaats voor deze code zou binnen de functie probe() kunnen zijn.

pinctrl_select_state() roept intern pinmux_enable_setting() aan, die op zijn beurt de pin_request() op elke pin in het pincontroleknooppunt aanroept.

Een pincontrole kan worden vrijgegeven met de functie pinctrl_put(). Men kan de resource-managed versie van de API gebruiken. Dat gezegd hebbende, kan men pinctrl_get_select() gebruiken, gezien de naam van de te selecteren staat, om pinmux te configureren. De functie is als volgt gedefinieerd in include/linux/pinctrl/consumer.h:

static struct pinctrl *pinctrl_get_select(struct device *dev,
                                const char *name)

waarbij *name de staatsnaam is zoals geschreven in de eigenschap pinctrl-name. Als de naam van de staat standaard is, kan men gewoon de functie pinctr_get_select_default() aanroepen, wat een wrapper is rond pinctl_get_select() :

static struct pinctrl * pinctrl_get_select_default(
                                   struct device *dev)
   {
      return pinctrl_get_CTULT_STATE_);
   }

Laten we een echt voorbeeld zien in een board-specifiek dts-bestand (am335x-evm.dts ):

dcan1:d_can@481d0000 {
       status ="oke";
       pinctrl-names =“standaard”;
       pinctrl-0 =<&d_can1_pins>;
   };

En in het bijbehorende stuurprogramma:

pinctrl =devm_pinctrl_get_select_default(&pdev->dev);
   if (IS_ERR(pinctrl))
       dev_warn(&pdev->dev,"pins worden niet geconfigureerd vanuit de driver");

De pinbesturingskern claimt automatisch de standaard pinctrl-status voor ons wanneer het apparaat wordt gesondeerd. Als men een init-status definieert, zal de pinctrl-kern automatisch pinctrl op deze status instellen vóór de functie probe() en vervolgens overschakelen naar de standaardstatus na probe() (tenzij het stuurprogramma expliciet de status al heeft gewijzigd).

De volgende aflevering zal het GPIO-subsysteem bespreken.

Herdrukt met toestemming van Packt Publishing. Copyright © 2017 Packt Publishing


John Madieu is een embedded Linux- en kernel-engineer die in Frankrijk, in Parijs, woont. Zijn voornaamste activiteiten bestaan ​​uit het ontwikkelen van chauffeurs en Board Support Packages (BSP) voor bedrijven in domeinen als automatisering, transport, gezondheidszorg, energie en het leger. John werkt bij EXPEMB, een Frans bedrijf dat een pionier is in het ontwerpen van elektronische kaarten op basis van computer-op-module en in embedded Linux-oplossingen. Hij is een liefhebber van open source en embedded systemen, ervan overtuigd dat je alleen door kennis te delen meer leert.


Internet of Things-technologie

  1. Beveiligingsproblemen van het industriële IoT aanpakken
  2. De ontwikkeling van moderne kunststoffen
  3. Vooruitzichten voor de ontwikkeling van industrieel IoT
  4. Wie beheert de connected car? Vraag het de chauffeur in de lus
  5. Zes stappen voor het beveiligen van embedded systemen in het IoT
  6. Het omslagpunt voor SaaS in productontwikkeling (deel 2)
  7. Het kantelpunt voor SaaS in productontwikkeling:deel 1
  8. Uitdagingen bij het selecteren van de juiste leverancier van IoT-ontwikkeling
  9. De IPC-vereisten van complexe besturing
  10. Wat zijn de belangrijkste drijfveren voor succesvolle zakelijke IoT-ontwikkeling?
  11. Impact van IoT op de toekomst van ontwerp en ontwikkeling van webapps