Spørsmål:
SPI Arduino På grunn av konflikt med pinMode (), feil?
newandlost
2014-11-06 22:01:37 UTC
view on stackexchange narkive permalink

Tenk på følgende minimale eksempel, der jeg setter pinMode før jeg ringer SPI-funksjoner: 

  #include <SPI.h>void setup () {pinMode (10, OUTPUT) ; SPI.begin (10); SPI.setDataMode (10, SPI_MODE1);} ugyldig sløyfe () {forsinkelse (1000); SPI.transfer (10,1);}

Nå når SPI.transfer (10,1) kalles i loop () , Jeg ser alltid at den slave valgte pinnen går ned til 1,65V, men ikke 0 som den skal! (se bildet nedenfor)

pin mode set before calling SPI functions

Hvis vi ikke kaller pinMode () , slik: 

  # inkluderer <SPI.h>void setup () {SPI.begin (10); SPI.setDataMode (10, SPI_MODE1);} ugyldig sløyfe () {forsinkelse (1000); SPI.transfer (10,1);}

Vi får det vi forventer når vi ringer SPI.transfer:

pin Mode not set

Er det en feil, eller har du en forklaring på den oppførselen?

Tusen takk på forhånd for din tid og interesse!

Bør det ikke være `SPI.setDataMode (10, SPI_MODE1);`? Også bare den andre er nyttig, da `start ()` kaller setDataMode. Ser vi på [kildekoden] (https://github.com/arduino/Arduino/blob/ide-1.5.x/hardware/arduino/sam/libraries/SPI/SPI.cpp#L34-L38) ser det ut som SPI-biblioteket endrer ikke pinnen du spesifiserte (selv om jeg ikke kjenner ARM).
Ja du har rett, ved et uhell ringer jeg setDataMode () to ganger. I morgen skal jeg teste effekten av SPI.setDataMode (10, SPI_MODE1); Men hvorfor det å ringe til pinMode () har denne effekten, er fortsatt ikke klart eller? @Gerben
@Gerben Jeg endret innlegget mitt
En svar:
CharlieHanson
2015-06-01 10:24:58 UTC
view on stackexchange narkive permalink

Det kan ha noe å gjøre med den interne trekkmotstanden. I følge SAM3X / A-databladet er

Kontroll av opptrekksmotstanden mulig uavhengig av konfigurasjonen av I / O-linjen.

Etter tilbakestilling er alle pull-ups er aktivert.

Hvis du graver gjennom alle inkluderingsfilene du finner: 

  ../Arduino/hardware/arduino/samd/cores /arduino/wiring_digtal.c

Line 124 definerer pinMode (uint32_t ulPin, uint32_t ulMode) -funksjonen. Når du undersøker bryter / saksuttalelse for INPUT vs INPUT_PULLUP vs OUTPUT, ser du følgende:

  1. INPUT setter et register til reg = PORT_PINCFG_INEN .
  2. INPUT_PULLUP setter et register til reg = (PORT_PINCFG_INEN | PORT_PINCFG_PULLEN)
  3. OUTPUT setter et register til reg & = ~ PORT_PINCFG_INEN .
    4. ol>

    'Registret' i hvert tilfelle er det samme. Jeg kan ikke i løpet av livet finne hvilken verdi PORT_PINCFG_INEN eller PORT_PINCFG_PULLEN er definert som, men de er uten tvil bare 8-biters masker (de blir kastet til uint8_t når de er tilordnet 'registeret'). Dermed kan vi anta at hvilken bit som styrer inngang / utgang er aktiv når det hevdes, og det samme er pullup-biten. For eksempel: 

      PORT_PINCFG_INEN = b'00000001 '; PORT_PINCFG_PULLEN = b'00000010 '; ~ PORT_PINCFG_INEN = b'11111110';

    Hvis pull-ups er aktivert etter tilbakestilling, kan vi si det ved tilbakestilling: 

      reg = b'xxxxxx1x ';

    Punkt (3) ovenfor innebærer sterkt at instruksjonen er: 

      reg = b'xxxxxx1x' & ' b11111110 '; så reg = b'xxxxxx10 '; // pull-up er aktivert!

    Derfor, hvis du ringer pinMode (X, OUTPUT) før noe annet vil du ende opp med pullup-motstand aktivert. Hvis du setter pinnen til en inngang, tømmes aktiveringsbit for pullup, hvoretter du kan sette pinnen til en utgang, og biten forblir klar.

    Hele argumentasjonen faller imidlertid ned med det enkle faktum at hvis du ikke kaller pinMode () i det hele tatt , oppstår ikke problemet ...



ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...