Waarom hier bitwise-bewerkingen uitvoeren? (SPI FRAM leesmethode)

Zie: https://github.com/adafruit/Adafruit_FRAM_SPI/blob/master/Adafruit_FRAM_SPI cpp De volgende methode leest en converteert de invoer naar 8 bit. Ik heb verschillende vragen met betrekking tot zijn functie.

Met behulp van addr = 0xFFFF als een voorbeeld, converteert de methode de variabele naar 0xFF. Ik begrijp dat bits van het einde worden verwijderd, maar zeker 65535! = 255. Misschien relatief, tot hun maximale grootte, maar hoe is dit een nuttige conversie? Ik mis hier misschien iets over bitsgewijs ...

uint8_t Adafruit_FRAM_SPI::read8 (uint16_t addr)
{
 digitalWrite(_cs, LOW);
 SPItransfer(OPCODE_READ); //read memory from fram array (2-byte)
 SPItransfer((uint8_t)(addr >> 8));
 SPItransfer((uint8_t)(addr & 0xFF));
 uint8_t x = SPItransfer(0);
 digitalWrite(_cs, HIGH);
 return x;
}

Corrigeer me als ik het mis heb, het gieten is om de tekenuitbreiding te voorkomen.

De maskering die ik in theorie begrijp, maar die de toepassing hier helemaal niet begrijpt.

Uiteindelijk wordt altijd dezelfde waarde x = 0 geretourneerd, waarom?

Ik zie ook dat er een schrijfmethode is maar geen leesmethode. Alleen read8. Redenering?

 1
toegevoegd bewerkt
Bekeken: 44
de bron
De code hierboven stuurt eerst de hoogste 8 bits van het adres ( addr >> 8 ), en vervolgens de laagste 8 bits. Weet niet zeker waarom ze zowel maskeren als casten. Daarna stuurt het 8 nul bits. Tijdens het verzenden van die bits stuurde de FRAM de waarde in het adres naar de pinole van Arduinos MISO. De 8-bits waarde wordt opgeslagen in de variabele `x. Houd er rekening mee dat SPI bidirectioneel is en dat u tegelijkertijd gegevens kunt verzenden en ontvangen.
toegevoegd de auteur Al., de bron
Denk na over wat er met de nummers gebeurt en sluit die vervolgens aan op 4 SPI-transfers en denk na over wat er dan gebeurt op de SPI-bus.
toegevoegd de auteur Majenko, de bron

1 antwoord

Laten we aannemen dat addr is 0xbeef . Als we dan elke operatie afbreken:

expression             │ value
───────────────────────┼───────
addr                   │ 0xbeef
addr >> 8              │ 0x00be
(uint8_t)(addr >> 8)   │   0xbe
addr & 0xFF            │ 0x00ef
(uint8_t)(addr & 0xFF) │   0xef

Dus dit is in wezen het opsplitsen van het adres in twee 8-bit chunks, en deze chunks individueel verzenden. Het is zo gedaan omdat SPI verzendt alleen bytes.

het casten is om de tekenuitbreiding te voorkomen.

Niet, sign extensie kan niet voorkomen, omdat addr een niet-ondertekend nummer is. Het gieten dient echt geen nuttig doel, behalve het documenteren van de code. Het zou impliciet worden gedaan simpelweg omdat SPItransfer() neemt een uint8_t argument. Het casten kan nuttig zijn als SPItransfer() werd overladen met een 16-bits versie.

Uiteindelijk wordt altijd dezelfde waarde x = 0 geretourneerd, waarom?

Nee, het retourneert ongeacht de aanroep van SPItransfer (0); retourneert, d.w.z. de gegevens verzonden door de FRAM-module.

3
toegevoegd
de bron