mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ausführungsgeschwindigkeit ARM M0


Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich versuche gerade mit einem XMC 2Go Board einen 
Inkrementalgeber mit 5000 Inkrementen mittels diesen Codes auszuwerten:

https://www.mikrocontroller.net/articles/Drehgeber

Durch die hohe Auflösung des Inkrementalgebers und der zu erwartenden 
Drehzahl von 300 UpM wollte ich den Timer mit 500kHz takten lassen.
Der Timer löst alle 2us einen Interrupt aus. Wenn ich nur das Pintoggeln 
in die ISR packe messe ich mit dem Oszi die gewünschten 2us, sobald 
jedoch der Auswertecode für den Inkrementalgeber dazu kommt wächst die 
gemessene Zeit auf 9.5us an. Der Mikrocontroller taktet mit 32MHz, ich 
dachte das sollte reichen um diesen kleinen Code in den 2us 
auszuführen...

void TimerISR (void)
{

  XMC_GPIO_PORT0->OMR = 0x10001U << 0U;


    int8_t neu, diff;


    neu = 0;
    if ( PHASE_A_Enc )
      neu = 3;
    if ( PHASE_B_Enc )
      neu ^= 1;                   // convert gray to binary
    diff = last - neu;                // difference last - new
    if ( diff & 1 ) {             // bit 0 = value (1)
      last = neu;                 // store new as next last
      enc_delta += (diff & 2) - 1;        // bit 1 = direction (+/-)
    }


}

Autor: Ingo Less (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. H. schrieb:
> ich
> dachte das sollte reichen um diesen kleinen Code in den 2us
> auszuführen...
In 2us macht der Controller mit 32MHz 64 Takte, das ist nicht viel...

Autor: Ingo Less (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allerdings scheinen mir 304 Takte (9,5µs) auch etwas viel für diesen 
Popelkram. Zeig mal das ASM listing.

> int8_t neu, diff;
Versuch mal uint32_t, das geht schneller.

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Ändern der Variablen in uint32_t brachte keine Besserung. Ich habe 
aber jetzt anstatt der von der DAVE IDE bereitgestellten Funktionen zum 
Pinauslesen nun den Code so umgeschrieben das ich die Register direkt 
auslese mit:
(((XMC_GPIO_PORT0->IN) >> 8U) & 0x1U)

vorher:
DIGITAL_IO_GetInput(&Spur_A)

jetzt komme ich auf 3.3us, nahe dran aber immer noch zu langsam...

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was mich verwundert: wenn ich keine Interrupts habe und in der 
Hauptschleife nur den Pin toggeln lasse komme ich auf nur 500ns. Ist 
doch etwas zu langsam bei 32Mhz Systemtakt oder?

Autor: Ingo L. (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. H. schrieb:
> auf nur 500ns
Das sind dann 16 Takte. Zeig mal das Programm zum "nur toggeln".

: Bearbeitet durch User
Autor: Alexander B. (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

was soll dieser Spielkram? Warum nimmst du nicht die CCU40 und lässt die 
deine Impulse zählen. Dann sind auch 2MHz Pulstakt kein Problem. Wenn 
der Controller die Peripherie hat nutze sie.

Siehe: 
http://www.infineon.com/dgdl/Infineon-CCU4-XMC1000...

Gruß

Tec

: Bearbeitet durch User
Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. H. schrieb:
> neu = 0;
>     if ( PHASE_A_Enc )
>       neu = 3;
>     if ( PHASE_B_Enc )
>       neu ^= 1;

Das ist doch recht umständlich. Wie wäre es mit:
if ( PHASE_A_Enc )
{
  if ( PHASE_B_Enc )
    neu = (3 ^ 1);
  else
    neu = 3;
}
else
{
  if ( PHASE_B_Enc )
    neu = (0 ^ 1);
  else
    neu = 0;
}

Die xor-Ausdrücke für die Nachvollziehbarkeit; da es konstante Ausdrücke 
sind, wird der Compiler die ohnehin schon zur Compilezeit auswerten, so 
daß sie keine Rechenzeit kosten.

Autor: Stefan K. (stefan64)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du Dir schon mal den "Encoder interface mode" der Timer angeschaut? 
Damit brauchst Du keinen einzigen CPU-cycle.

B.d.w.: welchen Optimierungslevel hast Du bei Deinem Compiler (welcher?) 
eingestellt?


Gruß, Stefan

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tec Nologic, Stefan K.

danke für den Einwand, ist mir beim Datenblattüberfliegen nicht 
aufgefallen das der Controller anscheinend Encoder in Hardware auslesen 
kann. Das ist ntürlich die wesentlich angenehmere Methode. Dann werde 
ich mich mal ans Studieren der Unterlagen machen...

Autor: Alexander B. (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

sieh die die Appnote an die ich gepostet habe, falls der Link nicht geht 
such mal nach XMC CCU40 dann findest das Dokument auch. Da ist die CCU40 
beschrieben. Unter anderem auch wie man sie zum Impulse Zählen verwenden 
kann. Das richtige POSIF haben nur die XMC1300 und XMC1400 und die 
XMC4xxx aber das ist nur ein Fortend für die Timer der CCU40 oder CCU80.

EDIT: OK nur mit der CCU40 wird das schwierig. Die kann zwar zählen aber 
die Drehrichtung müsstest du mit einer externen Logik machen. Ohne POSIF 
geht hier leider nix voll automatisch. Da habe ich mich getäuscht.


Gruß

Tec

: Bearbeitet durch User
Autor: aSma>> (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. H. schrieb:
> Hallo, ich versuche gerade mit einem XMC 2Go Board einen
> Inkrementalgeber mit 5000 Inkrementen mittels diesen Codes auszuwerten:

> Durch die hohe Auflösung des Inkrementalgebers und der zu erwartenden
> Drehzahl von 300 UpM wollte ich den Timer mit 500kHz takten lassen.

Brauchst du einen Absolutwert Position?

Dann erweitere den 16bit timer mithilfe einer 32bit var. Hier muss man 
aber ein wenig Gehirmschmalz investieren. Dazu müsste man den update 
flag (überlauf) nehmen. Dann pollst du jede ms und speicherst die neue 
Position.

Anders wird es nicht ohne Zählfahler gehen. Oder dein µC ist nur damit 
beschäftigt. Bei 300 rmp musst du, 1/(5* 5000*4)s  das sind 10µs + 
Nyquist das sind dann 5µs (160 Takte), eine Änderung des Encoders um 1 
zu garantieren.

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aSma>> schrieb:
> Dann erweitere den 16bit timer mithilfe einer 32bit var. Hier muss man
> aber ein wenig Gehirmschmalz investieren. Dazu müsste man den update
> flag (überlauf) nehmen. Dann pollst du jede ms und speicherst die neue
> Position.

Ok, das verstehe ich jetzt nicht ganz. Die frage ist ja wie ich mittels 
der Counter die Drehrichtung erkennen kann. Ich denke hier bleibt doch 
nur die anfangs erwähnte Softwarelösung. Der Mikrocontroller soll als 
SPI-Slave arbeiten und bis auf das Zählen nichts weiter machen.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. H. schrieb:
> Der Mikrocontroller soll als SPI-Slave arbeiten und bis auf das Zählen
> nichts weiter machen.

Was hast du denn als Master? Nimm doch für den Master einen 
Mikrocontroller der Encoder in Hardware nebenher auswerten kann; viele 
STM32 können das zB.

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, der Master kann das auch nicht, ist ein MSP430 von TI. Vielleicht 
wäre noch eine Möglichkeit ein Quadratur Decoder IC, hat da jemand nen 
Tipp für mich?

Autor: Alexander B. (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du nicht auf das XMC2Go festgelegt bist nimm doch einen größeren 
Controller con Infineon den XMC1300 oder so. Oder einen STM32 vllt auch 
dort nicht unbedingt den kleinsten M0. Dann geht das auch.

Oder du machst die 2 XOR in Hardware und hast ein Zählimpuls und eine 
Drehrichtung dann kann das auch der XMC1100 auf dem XMC2Go.

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ich für den vorgesehenen Einsatzzweck etwas kompaktes benötige mit 
wenig Batelarbeit habe ich mich für dieses kleine Board entschieden. 
Also ich sehe jetzt nur noch zwei Möglichkeiten: langsamer Samplen 
(200Khz sollte klappen) oder ein Decoder IC verwenden...

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. H. schrieb:
> (((XMC_GPIO_PORT0->IN) >> 8U) & 0x1U)

Habe mir mal das XMC1100 Manual angesehen und wie es aussieht hat der 
keine Bit-adressierbaren Ports. Bei anderen M0 wie z.B. LPC800 ginge das 
direkt:

(P0_8) bzw. LDRB bitval, [PORT0BASE, #8]

Und wie gesagt:

Ingo Less schrieb:
> Zeig mal das ASM listing

Wahrscheinlich werden da mehrere unnötige type casts durchgeführt. 
Abgesehen davon wäre ein M3 statt M0 auch nicht teurer und hätte 
bedingte Codeausführung, was alles deutlich schneller macht.

Autor: aSma>> (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. H. schrieb:
> Da ich für den vorgesehenen Einsatzzweck etwas kompaktes benötige mit
> wenig Batelarbeit habe ich mich für dieses kleine Board entschieden.
> Also ich sehe jetzt nur noch zwei Möglichkeiten: langsamer Samplen
> (200Khz sollte klappen) oder ein Decoder IC verwenden...

Du suchst nach etwas kompakten, aber zwei IC´s erhöhen nur die 
Fehlerwahrscheinlichkeit. Das ist einfach der falsche Weg.

Wenn dir die Pins vom XMC2Go reichen, dann nehme den 16bit timer + 32bit 
hilfsvariable. Das kostet keine Rechenleistung!

Die Drehrichtung zu bestimmen ist voll low bob:
if(new_abs_pos >= old_abs_pos)
  dir = NORMAL;
else
  dir = REVERSE;

Aber du musst zum Schluß entscheiden.

Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
aSma>> schrieb:
> Du suchst nach etwas kompakten, aber zwei IC´s erhöhen nur die
> Fehlerwahrscheinlichkeit.

Ostern ist weit weg - Angsthasen gibt es zu jeder Jahreszeit.
Konsequenterweise darf man max. auch nur einen Abblockkondensator 
verwenden?

Ein separater, autonom arbeitender µC reduziert m.E. die 
Fehlerwahrscheinlichkeit.
Ob nun ein einzelner Dekoder, oder gleich fünf oder zehn davon - alles 
kein Problem.

Autor: aSma>> (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
@m.n.

Ein sinnfreier Beitrag von dir mit einer sinnfreien Rhetorik. Die 
Fehlerwahrscheinlichkeit kann auch durch die Software kommen...

Man kann hier alles mit nur einen µC lösen. Aber es gibt viele Wege nach 
Moskau.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aSma>> schrieb:
> Fehlerwahrscheinlichkeit kann auch durch die Software kommen...

... und noch viel schlimmer, wenn die Versorgungsspannung ausfällt. 
Daher immer zwei Stromversorgungen vorsehen.
Diese blöde Schwarzmalerei geht mir schlicht auf den Keks!

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aSma>> schrieb:
> Wenn dir die Pins vom XMC2Go reichen, dann nehme den 16bit timer + 32bit
> hilfsvariable. Das kostet keine Rechenleistung!
>
> Die Drehrichtung zu bestimmen ist voll low bob:
> if(new_abs_pos >= old_abs_pos)
>   dir = NORMAL;
> else
>   dir = REVERSE;
>
> Aber du musst zum Schluß entscheiden.

@ aSma

Ich kann dir nicht ganz folgen, wie soll ich deinen Vorschlag jetzt 
verstehen? In Hardware zählen mit den Countereingängen? Die Frage ist 
doch wie ich aus der A und B Spur des Encoders mit den Countereingängen 
die absolute Position erhalten kann???

: Bearbeitet durch User
Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das ein echter Quadrature-Zähler ist, dann wertet der 
automatisch(hardwaremäßig) A und B aus. Damit muss man nur z. B. alle 
100us den 16bit Timer auslesen um die aktuelle Position jede 100us zu 
bekommen. Benötigt man einen 32bit Quadrature-Zähler, dann muss man die 
Überläufe des 16bit Zählers softwaremaßig zur 32bit Variable 
addieren/subtrahieren. Diese Behandlung der Überläufe macht man in der 
100us Interrupt-Routine.
Wenn du nur jede 1ms die Zahlen benötigst, dann halt jede 1ms einen 
Interrupt auslösen.

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der XMC1100 hat nur normale Counter, im Datasheet steht nichts von 
Quadratur-Eingängen. Also bleibt doch nur das softwaremäßige Polling mit 
der Hoffnung das die 200kHz Abtastung reichen...

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der XMC1100 das nicht kann, dann gibt es nur eine Lösung - weg 
damit. Nimm einen ARM Cortex Mx der das kann.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Nimm einen ARM Cortex Mx der das kann.

Da würde ich doch eher einen popeligen 8-Pin ATtiny ergänzen als den 
Hauptprozessor zu wechseln.

Noch einmal gerechnet: 5 Umdrehungen/s mit 5000 Impulsen/Drehung und 
4-fach-Auswertung erfordert eine minimale Abtastfrequenz von 100 kHz. 
Der oben verlinkte ATtiny25 taktet mit 350 kHz und hat damit hinreichend 
Reserve für diesen Geber.

Autor: R. H. (breezer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Habe mir mal das XMC1100 Manual angesehen und wie es aussieht hat der
> keine Bit-adressierbaren Ports. Bei anderen M0 wie z.B. LPC800 ginge das
> direkt:
>
> (P0_8) bzw. LDRB bitval, [PORT0BASE, #8]
>
> Und wie gesagt:
>
> Ingo Less schrieb:
>> Zeig mal das ASM listing
>
> Wahrscheinlich werden da mehrere unnötige type casts durchgeführt.
> Abgesehen davon wäre ein M3 statt M0 auch nicht teurer und hätte
> bedingte Codeausführung, was alles deutlich schneller macht.

@Lothar, Ingo Less

Ich hab hier nochmal das Asm Listing aus dem Debugger Disassembly-View 
kopiert:
43            XMC_GPIO_PORT0->OMR = 0x10001U << 0U;
10001976:   ldr r3, [pc, #8]        ; (0x10001980 <main+36>)
10001978:   ldr r2, [pc, #8]        ; (0x10001984 <main+40>)
1000197a:   str r2, [r3, #4]
44          }
1000197c:   b.n 0x10001976 <main+26>    }

hier der C-Code dazu...
  while(1U)
  {
    XMC_GPIO_PORT0->OMR = 0x10001U << 0U;
  }

Viel steckt nicht drin, benötigt er dafür tatsächlich 16 Taktzyklen?

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.