Betreffende de afbeelding in uw bericht over 'SPI Read Data', die eenvoudigweg zegt dat de eerste byte die wordt ontvangen via MISO wordt weggegooid, wat wordt gedaan in PCD_ReadRegister()
vlak voor de voor
loop en vervolgens worden n
bytes gelezen, waarbij 0 de laatste keer wordt overgedragen om te stoppen met lezen.
Een snelle blik op de bibliotheek en datasheet laat zien dat het argument rxAlign
wordt gebruikt om het eerste geldige bit in de eerste ontvangen byte te identificeren. txLastBits
heeft een soortgelijk doel, alleen voor verzending van de laatste byte. Beide zijn geschreven naar BitFramingReg
van de MFRC522 en zijn noodzakelijk voor bitgeoriënteerde frames tussen de MFRC522 en een kaart/tag.
In de functie die u hierboven heeft, bijvoorbeeld, als rxAlign = 3
, betekent dit dat alleen bits 7 tot 3 geldig zijn in de eerste ontvangen byte , uitgepakt met bitmasker 11111000
. Dus de eerste geldige 'byte' omvat bits 7 tot 3 van de eerste ontvangen byte aaneengeschakeld met bits 2 - 0 van de volgende ontvangen byte. Op dezelfde manier geeft txLastBits
tijdens de verzending het aantal bits van de laatste byte aan dat naar de kaart/tag moet worden verzonden. In beide gevallen is wat wordt verzonden of ontvangen via het RF-veld mogelijk geen veelvoud van 8, vandaar de noodzaak van deze argumenten en BitFramingReg
.
In elk geval zou dit niet moeten interfereren met het porten van de bibliotheek. Vervang gewoon de Arduino-specifieke functies/interfaces en laat de bestaande logica van de bibliotheek ongewijzigd blijven.
Bewerken
Ik zal proberen je vragen te beantwoorden:
- In deze context verwijst 106kBd naar de gegevenssnelheid tussen de RC522 en een kaart, en niet tussen de RC522 en de MCU. Het maximum is ongeveer 848kBd, denk ik. Raadpleeg de datasheet voor meer informatie.
- Bitgeoriënteerde frames zijn noodzakelijk voor het anti-collisionproces. Boven elkaar geplaatste bits in de Manchester-codering, wanneer meerdere kaarten tegelijk proberen te communiceren met de RC522, vereisen dat individuele bits worden verwerkt in tegenstelling tot de eenheden van de gebruikelijke bytegrootte. Antibotsingtechnieken opzoeken.
- Anticollisie is nodig als dezelfde lezer mogelijk meerdere tags binnen zijn bereik heeft. Uit een IEEE-artikel:
Tagbotsingen kunnen een grote inefficiëntie in RFID-systemen met zich meebrengen, wat resulteert in lage herkenningspercentages, een kort leesbereik en ineffectief gebruik van middelen. Ze zijn problematischer in passieve tags vanwege beperkingen van het vermogen en de functionaliteit.
Dus als u slechts één kaart tegelijkertijd presenteert, moet u veilig zijn zonder de anticollisie in uw code te implementeren. Anders ben ik bang dat je geen keus hebt tenzij je de lezer in de war wilt brengen.
Als u alleen UID's wilt lezen en blokken van/naar blokken op een kaart wilt lezen (een voor een), probeert u dit rechttoe rechtaan MFRC522 UART-bibliotheek , die trouwens geen anitcollision implementeert.
Als je de SPI-gebaseerde bibliotheek nog steeds wilt porten, dan zijn er een paar suggesties:
U wilt de SPI-interface vervangen door UART. Dit zijn dingen op een laag niveau, allemaal in een paar functies zoals PCD_ReadRegister()
, PCD_WriteRegister()
en een paar andere. Deze functies dienen functies op een hoger niveau, die geen idee hebben van hun interne implementatie, maar van hen bepaald gedrag verwachten. Verwissel de SPI-functies voor hun UART-equivalenten, zodra u begrijpt hoe u met de lezer kunt praten via UART. Zodra uw ARM UART-functies zich precies gedragen zoals de SPI-functies, is uw werk bijna voltooid; het is niet nodig om de reden voor alles in de functies op een hoger niveau te leren, omdat ze niet gerelateerd zijn aan interface-specifiek. Dit omvat alles met betrekking tot rxAlign
en wat dan ook. Succes :).