Rechenzeitbedarf beim Zahlenausgabe

[Klebwax]

Danke für den Tip, ich habe manchmal so meine Schwierigkeiten mit dem Messen von Zeiten - mit nem simplen, analogen Oskar - ohne Speicher, nicht triggerbar auf ein bestimmtes Vorkommnis - da bleibt mir halt in einigen Fällen nur das Messen wie hier gezeigt.

Da gibts ein paar Möglichkeiten. Wenn das, was man messen will wiederholt vorkommt, kann man es auch auf einem analogen Scope darstellen. Wenn es sich schlecht triggern läßt, kann man ein Triggersignal auf einem freien Portpin programmieren und das auf den zweiten Scopekanal (oder falls vorhanden auf den externen Trigger) geben und damit triggern.

Ist das Ereignis nicht periodisch genug, hab ich ab und an schon mal zum Messen das Program umgeschrieben.

Inzwischen benutze ich dafür eigentlich immer den saleae.

Ja, so sehe ich das auch - und das ist ja das Erschreckende. Gefühlt ist so eine kleine Meldung schnell draussen.

Schnittstellen, insbesondere die asynchrone serielle, sind schon eine ziemliche Bremse. Sie können das Echtzeitverhalten eines Systems empfindlich stören. Ich benutze die serielle daher sehr selten. Leider ist der UART via USB die einfachste Schnittstelle und daher das Mittel der Wahl zum Datenaustausch. Ethernet wäre wesentlich besser, ist aber leider aufwendig auf einem µC und hat seine eigenen Zeitanforderungen. SPI mit einigen 10MHz wäre ganz gut, kann aber ein PC nicht wirklich.

Ein größerer Buffer oder ein UART mit FIFO sind schon mal gut, aber wenn mehr Daten gesendet werden sollen, als Zeit vorhanden ist, hilft auch kein größerer Buffer. Was bleibt, ist die serielle gezielt und sparsam einsetzen.

Ein LCD, am besten im 8 Bit Mode an einem kompletten Port, ist auch hilreich. Man darf dann nur nicht auf die gängigen Ratschläge hören und den Code mit Delays vollpflastern, sondern geschickt das Ready-Signal auswerten. Dann kann man ein Zeichen so in 2 µs ausgeben. Da kann man dann schon im PWM Interrupt den PWM-Wert Live ausgeben.

Wenn man die Leistung moderner µCs wirklich ausnuzt, ist eine Datenausgabe schon problematisch. Leider

MfG Klebwax

[malthy]

Schnittstellen, insbesondere die asynchrone serielle, sind schon eine ziemliche Bremse.

Naja, in welchem Sinne? Klar, bei einer gegebenen Übertragungsrate kann man eben nur eine dementsprechende Datenmenge drüberblasen. Aber das ist doch völlig deterministisch, oder? Und das reine Schreiben in das UART Register geht ja dann wieder recht schnell, das meinte ich oben, als ich schrieb, dass man während des Sendens dann ja durchaus wieder andere Dinge tun kann. Oder übersehe ich etwas?

Gruß
Malte

[Klebwax]

Naja, in welchem Sinne? Klar, bei einer gegebenen Übertragungsrate kann man eben nur eine dementsprechende Datenmenge drüberblasen. Aber das ist doch völlig deterministisch, oder? Und das reine Schreiben in das UART Register geht ja dann wieder recht schnell, das meinte ich oben, als ich schrieb, dass man während des Sendens dann ja durchaus wieder andere Dinge tun kann. Oder übersehe ich etwas?

Das reine Laden eines Registers ist schnell, das Warten, bis das Register wieder frei ist, eine andere Sache.

Was ich aber meinte ist, daß leicht viel mehr Daten entstehen als die serielle transportieren kann. So ein ADC liefert schon mal 10k bis 100k Daten pro Sekunde, andere Sensoren leicht ebensoviel. Jetzt mal eine komplexe Rechnung, Sensorfusion oder Filterung durch ein paar serielle Ausgaben live zu Debuggen oder Darzustellen kann leicht dazu führen, daß das Zeitverhalten mehr von der seriellen Schnittstelle als von den Sensoren abhängt.

Wenn man jetzt vom PC gewöhnt ist, daß so ein paar printf() mit einigen 10kB oder auch MB (auch mal in eine Datei umgeleitet) ohne ein paar PWMs oder Schrittmotoren im Hintergrund und mit einigen Gigabyte als Speicher kein Problem sind, kann einen das schon "Erschrecken".

MfG Klebwax