Vraag:
Hoe snel beweging (cycli / s) kan ik betrouwbaar lezen met de PSoC4-kwadratuurdecoder?
SF.
2015-07-29 15:38:09 UTC
view on stackexchange narkive permalink

PSOC4 biedt een kwadratuurdecoderfunctionaliteit, maar ik kon geen details over de prestaties ervan vinden in de datasheets. Natuurlijk weet ik dat ik de telling moet lezen en gebruiken totdat de 16 bits van de teller overlopen, maar dat is ongeveer 32k per iteratie van de hoofdlus van mijn programma. Als een precieze encoder is aangesloten op een snelle motor, produceert dat heel veel pulsen in een zeer korte tijd, en ik ben bang dat de decodermodule het niet kan bijhouden.

Dus, weet iemand wat de maximale prestatie is van het decoderblok - de minimale timing van zijn invoer?

Twee antwoorden:
Mark Booth
2015-07-30 15:39:37 UTC
view on stackexchange narkive permalink

Kwadratuurdecoder

Als we kijken naar het PSoC 4 TCPWM-gegevensblad, is de maximale werkfrequentie van het telblok 48 MHz, met een tellerresolutie van 21 ns.

Ervan uitgaande dat u een incrementele roterende encoder met hoge resolutie hebt met 10.000 tellingen per omwenteling, en de rotor draait met 15.000 tpm, is dat 2.500.000 tellingen per seconde (2,5 MHz), comfortabel minder dan de max. 48 MHz. bemonsteringssnelheid.

Helaas is het niet duidelijk of de PSoC 4 TCPWM aan dezelfde 10x bemonsteringsvereiste lijdt als de PSoC QuadDec die wordt genoemd in Simon Jenkins 'antwoord. Ik vermoed van niet, aangezien de datasheet niet de kloksignalen op de timingdiagrammen bevat. Dit houdt in dat PSoC 4 TCPWM flankgestuurd is (beperkt door de tellerklok), terwijl PSoC QuadDec wordt aangestuurd door het niveau bij elke klokflank en dus wordt beperkt door de bemonstering aan de klokfrequentie.

Zelfs als de PSoC 4 TCPWM oversampling vereist, is de max. 2,5 MHz pulstrein nog steeds minder dan beide 10x bij 48 MHz voor de PSoC 4 TCPWM en 28 MHz voor de PSoC QuadDec .

Als je slechts 2000 PPR bij 6000 RPM nodig hebt (zoals voorgesteld in je opmerking), dan hoef je slechts 200 KHz (2000 * 6000/60), dus een 2MHz-klok zou voldoende moeten zijn.

Interruptiebehandeling

Een andere zorg is of de CPU in staat zal zijn om te gaan met de interrupts die dit zou kunnen genereren .

Als we aannemen dat je de kwadratuur precies op de limiet van het decoderblok laat draaien, dat wil zeggen 48 MHz met een 16-bits teller, krijg je 1465 overflow-interrupts per seconde, dus tenzij je je interrupt ( inclusief eventuele vereiste contextomschakeling) in minder dan 68 2 microseconden, dan ga je worstelen.

Gelukkig lijkt het erop dat de Cortex-M0-processors een zeer efficiënte ISR-verwerking hebben (zie A Beginner's Guide on Interrupt Latency - and Interrupt Latency of the ARM® Cortex®-M processors ) dus tenzij je ISR erg inefficiënt is, zou het dit moeten kunnen verwerken.

Resolutie

Overigens lijkt het erop dat je de X4-modus moet gebruiken als je individuele kwadratuurovergangen willen tellen. Als je X1 gebruikt, zie je alleen hele kwadratuurcycli (4 toestanden), terwijl als je X2 gebruikt, je slechts de helft van de toestanden ziet.

Ik ben het ermee eens, het lijkt erop dat dit anders is dan het gegevensblad dat ik heb gevonden, het is niet bemonsterd en heeft daarom niet de vereiste 10x bemonstering. Geen klok op timingdiagrammen zoals je zegt, ze laten alleen zien welke randen de teller activeren. Ook de de-glitching (die was gebaseerd op het bemonsteren van de inputs) is niet aanwezig.
De afhandeling van interrupts kan behoorlijk efficiënt zijn; het enige dat nodig is, is de telling te ontlasten door deze (met teken) toe te voegen aan een 32-bits of 64-bits variabele. Dus één 32- of 64-bits optelling, één schrijven (nul) en de onderbreking kan eindigen.
Simon Jenkins
2015-07-30 02:07:16 UTC
view on stackexchange narkive permalink

Dit wordt niet vermeld in sommige documentatie voor de PSoC-kwadratuurdecodercomponent, maar in andere versies (bijv. hier) staat het volgende:

De klok ingangsfrequentie moet groter zijn dan of gelijk zijn aan 10x de maximale A- of B-ingangsfrequentie.

Gezien het feit dat AFAICT je de decoder op multi-MHz-frequenties kunt klokken, denk ik dat het waarschijnlijk kan bijhouden met de meest plausibele motoren.

BEWERK: Het lijkt erop dat het onderdeel waarvoor ik de gegevens vond niet helemaal het onderdeel is waar de vraag over ging, hoewel dit antwoord voor iemand nuttig kan zijn ooit zou het hier waarschijnlijk niet de hoogst gestemde of de geaccepteerde moeten zijn.

2000 PPR bij 6000 RPM is al 12 KHz van het signaal, dus de klok moet 120 KHz zijn om dat te verwerken. Toch geloof ik dat er zelfs 1 MHz beschikbaar was.
Hallo @SF. als dat deel uitmaakt van uw systeemspecificatie, zou het goed zijn om uw vraag aan te passen. Ik moest gisteravond veel te veel aannames doen toen ik [mijn antwoord] (http://embedded.stackexchange.com/a/99/186) schreef zonder deze informatie.
@MarkBooth: Dat zou het antwoord erg specifiek maken. Ik heb liever eentje die de beste beoordelingen geeft in plaats van een stukje gegevens "je bent binnen / buiten de toleranties". Het systeem kan zonder veel verlies worden gesmoord om binnen de specificaties te passen.
Op stack exchange is het over het algemeen beter om meer specifieke vragen te stellen en er vervolgens meer algemene antwoorden uit te laten vloeien. Dat is hoe we omgaan met duplicaten. We sluiten een vraag niet dubbel als de vraag een duplicaat is van een andere vraag, maar als een vraag al is beantwoord door een andere vraag.


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...