Auswahl Einplatinencomputer

Bitte detaillierte Angaben über deinen Geber!

Schnittstelle, Interface, Typ, Hersteller...

750000 Zählungen/ Events pro Sekunde?!

Plus Auswertung, Verarbeitung, Speicherung.....


Ich bin raus!

Nennt mich doof, aber ich finde in der Produktbeschreibung des Sensors 
keinerlei Hinweis, wie die Daten übermittelt werden.

Der liefert also tatsächlich nackte Impulse, nicht irgendwie als Daten 
aufbereitet.

Mirko: Willst du die Flanken der Impulse mit Zeitangabe speichern oder 
wie hast du dir das gedacht?

Ich würde dir den PSOC 5LP (oder ähnliches) empfehlen.

http://www.cypress.com/products/32-bit-arm-cortex-m3-psoc-5lp

Damit kannst du die Impulsmessung per programmierbarer HW machen. Damit 
ist die SW aus dem kritischen Timing raus.

Deine "Messwerte" sind also Zeitpunkte, und zwar reichlich viele. Du 
wirst dazu einen verdammt schnellen Mikrocontroller benötigen, mit 
verdammt viel Speicher.

Die üblichen Bastlerprodukte (Arduino, STM32, Raspberyy Pi), die hier 
diskutiert werden, sind nach meiner Einschätzung allesamt nicht 
geeignet.

Und für 10$ gibt es schon ein Prototype-Board...

http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and

> Und für 10$ gibt es schon ein Prototype-Board...

Mit einem ARM Cortex-M3, ich lach mich tot.

Vielleicht ist hier eine eine Logikschaltung angesagt, als ein 
klassisches Programm das von einer CPU abgearbeitet wird.

Goldmedaille schrieb:
> 750000 Zählungen/ Events pro Sekunde?!

Das ist doch nicht schwierig?

Da nimmt man passende Hardware, oder einen µC, dessen Timer AB-Signale 
verstehen. STM32 können das.
Da zählt die Hardware. Das dürfte problemlos bis in den MHz-Bereich 
gehen.

Siehe auch:
http://www.micromouseonline.com/2013/02/16/quadrature-encoders-with-the-stm32f4/

Stefanus F. schrieb:
> Mit einem ARM Cortex-M3, ich lach mich tot.

Schade, würdest du noch leben würde ich dir sagen, dass der µC eine 
programmierbare Logic auf dem Chip hat.

Als Nachtrag vielleicht noch:
Es gibt spezialisierte IC, die die Zählarbeit übernehmen können.
Zum Beispiel jenen:
https://ichaus.de/upload/pdf/MD_factsheet_rev1en.pdf

Damit ist JEDER µC tauglich.

750k Inkremente pro Sekunde sind im Übrigen Standardkram. Da braucht man 
nicht in Ogottogott-Starre verfallen.

soso... schrieb:
> STM32 können das.
Aber locker, man nimmt einfach einen 32Bit Timer und lässt diesen 
Incrementieren. Man zählt während der 15s die Überläufe, die ~alle 6s 
kommen und wertet nach 15s den Zählerstand + Überläufe aus. Wenn man 
will kann man sogar den internen Prescaler noch davor ballern. 
Anschließend das Ergebnis an den PC, evtl. sogar gleich mit 
Auswertung...

Adam P. schrieb:
> Wenn er aber jedes Inkrement mitbekommen möchte um es mit Zeitstempel zu
> versehen?
Dann habe ich auch keine Lösung, ich denke man sollte dann lieber mit 
Überlegen weiter machen statt mir "brute-force" bzw. unbegrenzter 
Rechenleistung

Mirko S. schrieb:
> Ich brauche den Winkel , die Drehrichtung und die Zeit. Wenn ich nur die
> aufsteigende Flanke benutze , kann ich zwar Winkel und Zeit bestimmen
> aber die Richtung nicht. Deswegen dachte ich , ich müsste beide
> benutzen.

Die Richtung ergibt sich aus den Zählerständen.
Denn AB geht ja Aufwärts und Abwärts.

Dann gibts zwei Möglichkeiten:
Du liest den Timer in einem bestimmten Raster aus (1ms zum Beispiel), 
und speicherst das im SRAM.
Bei 32Bit Auflösung für die Position benötigt das etwa 60kBytes - kein 
Problem soweit.

Oder du speicherst dir die Zeitstempel für eine bestimmte 
Inkrementenzahl. Nimmt man an, alle 400 Inkremente speicherst du einen 
Zeitstempel mit 32 Bit, wären das 112kBytes (wenn ich richtig gerechnet 
habe).

D.h. du wirst schon die Auflösung vorgeben müssen, wenn man dir ein 
solches Board empfehlen soll.
Ich vermute, jedes einzelne Inkrement genau zu erfassen, wird Overkill 
sein.

Du willst also wirklich jede Änderung um 0,1° mit Zeitstempel und 
Richtung speichern? Dann solltest du wirklich erwägen, eine spezielle 
Hardware-Logik dazu entwickeln zu lassen (eventuell in VHDL).

Hi
M3 macht ja "nur" das SW Interface, den Rest macht der cpld vom PSoC - 
so der Plan. So weit mir bewusst hat der cpld Teil aber kein Bus master 
Interface, so dass die Daten nicht ohne CPU geschaufelt werden können. 
Aber die Flanke mit dem richtigen Zeitstempel zu synchronisieren könnte 
es doch gehen. Die CPU hat dann ein paar Zyklen Zeit die. Buffer zu 
lesen.

Wenn's noch ein bisschen mehr sein darf, Ultra96 von Avnet hat gleich 
einen richtigen FPGA mit drin.

Grüße
 Thorsten

Wie präzise müssen eigentlich die Zeitpunkte erfasst werden?

> Er sagte ja, Genauigkeit 0.1°

Das bezieht sich auf den Winkel. Ich frage nach der Auflösung der Zeit. 
Mit einer RTC, die Sekunden liefert käme man hier z.B. nicht weiter.

Jetzt magst du die Augen verdrehen, aber der Teufel steckt oft im 
Detail.

Die Diskussion von Genauigkeit versus Auflösung habe ich bewusst noch 
nicht begonnen.

Adam P. schrieb:

> Alles klar, denn sonst könnte man es sehr weit runterbrechen:
[...]

Wenn man's richtig durchdenkt, kann man's noch sehr viel 
"runterbrechen".
Und erkennt: Es reichen zwei AVR8 für die Aufgabe aus, weil:

1) "Zeitstempel" braucht man keinen. Wenn der Code BEWEISBAR schnell 
genug Daten sammelt und wegschreibt, braucht man keinen Zeitstempel zur 
Kontrolle, dass er es auch wirklich tut.

2) Alles, was man tatsächlich speichern muss, ist jede Änderung eines 
der beiden Encoder-Kanäle, also im Kern: zwei Bit pro Encoder-Schritt. 
Oder besser: zwei Bit pro Sample einer hinreichend hohen Samplefrequenz, 
denn dann hat man auch das Timing mit drin (durch temporal äquidistante 
Samples) und damit letztlich sogar auch die Kontrollfunktion des unter 
1) als Schwachsinn verworfenen Zeitstempels. Man zählt statt dessen 
einfach die Zahl der aufgezeichneten Samples und vergleicht mit dem 
Erwartungswert für den Messzeitraum.

3) Nun muss man nur noch die Samplefrequenz passend wählen, also, wenn 
man den alten toten Säcken Shannon und Nyquist glauben darf (und ich 
glaube ihnen), dann genügt dafür etwas mehr als das Doppelte der 
maximalen Schrittrate von 3600*9000/60=540.000Hz, also sagen wir mal 
großzügig: ~1,2MHz Samplerate.

4) Gespeichert werden müssen, wie gesagt, zwei Bit/Sample, nämlich der 
Zustand der Kanäle A und B des Encoders, es passen also vier Samples in 
ein Byte. Damit beträgt die zu bewältigende Datenrate für's Wegschreiben 
der Daten 300kByte/s. Das ist für einen AVR8@20MHz keine besondere 
Herausforderung. Wenn da nicht noch die konkurrierende Aufgabe der 
Datengewinnung wäre...

5) Man erkennt das Problem und trennt den Job in zwei Teile für zwei 
AVR8. Einen kleinen, der die Daten timinggenau einsammelt, zu Bytes 
zusammenpackt und per SPI oder parallel an einen weiteren, größeren AVR 
sendet. Der hat dann den schon deutlich entspannteren Job, den Kram im 
RAM zu puffern und irgendwohin zu schreiben, z.B. auf eine SD-Card. 
Natürlich mit einem double-buffering-Mechanismus zur Entkopplung von 
Lesen und Schreiben.

6) Der Code für den kleinen AVR8 (irgendein Tiny) besteht aus vielleicht 
30..40 Zeilen Assembler, wovon die meisten nur Initialisierung sind. 
Sehr überschaubarer Entwicklungsaufwand.
Die minimale Anforderung ist: externer Takt bis 20MHz möglich (damit er 
taktmäßig vom großen mitversorgt werden kann). Ein blöder Tiny13 (sonst 
zu fast nix nutze) würde bereits diese Anforderung erfüllen.

7) Den großen AVR (hier kommt es vor allem auf viel RAM an, also z.B. 
1284P) könnte man dann schon in C programmieren, hat dann aber das 
Problem mit der fehlenden Beweisbarkeit, dass der Code tatsächlich 
schnell genug ist. Ich würde also auch dafür Assembler empfehlen.

Insgesamt aber: FPGA? Ich lach' mich tot. Industrie-PC? Ich lach mich 
tot. Kann denn hier niemand mehr wirklich denken, rechnen und 
programmieren?

> Damit beträgt die zu bewältigende Datenrate für's Wegschreiben
> der Daten 300kByte/s. Das ist für einen AVR8@20MHz keine
> besondere Herausforderung.

Das ist soweit ich weiß, das Maximum was bisher als erreichbar gemeldet 
wurde - wenn der µC sonst nichts anderes zu tun hat.

Gemein ist aber, dass SD Karten sich zwischendurch mal ganz erhebliche 
"Denkpausen" gönnen, vor allem beim Schreiben. Da könnte das bisschen 
interner RAM knapp werden.

Was willst du denn messen?

Den encoder?

Normale Motorkennlinien? Dann reicht es, ggf nur jeden 100ten Impuls zu 
"stempeln".

Oder mikrovibrationen, also ob innerhalb von 10 Impulsen 2 Nanosekunden 
jitter sind.


Ich glaube, wenn du uns die Aufgabe darlegst, zerfällt die HW zu einer 
BASIC-stamp

Weingut P. schrieb:
> oder pro Sekunde 540000 ... 540kHz Zeitstempel 1,8 Mikrosekunden

Schade nur daß die Schnittstelle des Sensors für maximal 300 kHz 
spezifiziert ist. Kein Wunder daß das zu Problemen führt.

c-hater schrieb:
> 3) Nun muss man nur noch die Samplefrequenz passend wählen, also, wenn
> man den alten toten Säcken Shannon und Nyquist glauben darf (und ich
> glaube ihnen), dann genügt dafür etwas mehr als das Doppelte der
> maximalen Schrittrate von 3600*9000/60=540.000Hz, also sagen wir mal
> großzügig: ~1,2MHz Samplerate.

Naja, wenn man eindeutig Vorwärts und Rückwärtsrichtung des 
Quadratursignals erkennen können möchte sollte das mindestens das 8-10 
fache des Einzeltaktes sein, -> ich würde mit 200ns oder 5 MHz abtasten 
wollen.

Ich würde für eine einmalige Meßaufgabe (offline Auswertung) eher ein 
geeignetes 4-Kanal-Oszi verwenden. (der Sensor hat ja nicht nur A/B 
sondern auch noch mindestens den Index-puls).
Man braucht für 20 Sekunden Aufzeichnungsdauer dann ca 400 MSamples in 
Summe für 4 Kanäle.
z.B. das PicoScope 5444B oder das neue 5444D. Das 3406D ginge auch.

Gruß Anja

Stefanus F. schrieb:

> Das ist soweit ich weiß, das Maximum was bisher als erreichbar gemeldet
> wurde - wenn der µC sonst nichts anderes zu tun hat.

Hat er ja durch die Aufteilung der Aufgaben auch nicht mehr wirklich. 
Das Warten auf die trödelnde SD-Karte muss er ja bei sinnvoller 
Programmierung nicht per busy-wait machen. Er kann währenddessen 
natürlich lustig weiter Daten vom "Kleinen" puffern.

> Gemein ist aber, dass SD Karten sich zwischendurch mal ganz erhebliche
> "Denkpausen" gönnen, vor allem beim Schreiben. Da könnte das bisschen
> interner RAM knapp werden.

Kaum. Du hast im M1284P 16 kByte RAM. Das reicht bei double-buffering 
und 300kByte/s, um selbst die Aussetzer fast der lausigsten SD-Karten 
bewältigen zu können (sofern sie nicht bereits "totgeschrieben" sind, 
also ihr Endziel in ihrer Rolle als "Klopapier-Speicher" erreicht 
haben).
8kByte entspricht bei 300kByte/s ja immerhin 26ms Pufferkapazität. Eine 
kleine Ewigkeit...

Anja schrieb:

> c-hater schrieb:
>> 3) Nun muss man nur noch die Samplefrequenz passend wählen, also, wenn
>> man den alten toten Säcken Shannon und Nyquist glauben darf (und ich
>> glaube ihnen), dann genügt dafür etwas mehr als das Doppelte der
>> maximalen Schrittrate von 3600*9000/60=540.000Hz, also sagen wir mal
>> großzügig: ~1,2MHz Samplerate.
>
> Naja, wenn man eindeutig Vorwärts und Rückwärtsrichtung des
> Quadratursignals erkennen können möchte sollte das mindestens das 8-10
> fache des Einzeltaktes sein, -> ich würde mit 200ns oder 5 MHz abtasten
> wollen.

OMG. Was lernt man heutzutage im Studium?

Das war eine rein rhetorische Frage. Ich weiss natürlich, was ich von 
"Anja" zu halten habe...

> 8kByte entspricht bei 300kByte/s ja immerhin 26ms Pufferkapazität.
> Eine kleine Ewigkeit...

Ich meine mich zu erinnern, dass mehr als 100ms Puffer nötig sind.