Aktualisierung UART langsam?

Daniel L. schrieb:

Die Aktualisierungsrate ist jedoch für meine Begriffe extrem lang

Ein Programm ist deterministisch, man könnte auf die Nanosekunde genau berechnen, wie lange welche Anweisung benötigt.

Welche Rate hast du denn erwartet und wie begründest du deine Annahme? Du hast hast Programm geschrieben, also finde ich es merkwürdig, dass du jetzt vom Ergebnis deiner Arbeit überrascht bist.

Läuft alles etwa 8x so langsam, wie erwartet? Ist das CKDIV8-Fusebit gesetzt?

1MHz Takt, 9600 Baud und dann schön komplexe Strings formatieren lassen....

Es kommen ja eh nur knappe 950 Zeichen pro Sekunde, wenn die Schnittstelle voll ausgelastet wäre, was sie nicht ist. Da ginge also noch was, aber das dürfte vor allem am Code liegen. Die CPU wäre schnell genug nach jedem (!) Galapuls eine neue Berechnung durchzuführen und auch zu übertragen (nicht dass das sinnvoll wäre, Mensch kann das ja so schnell nicht lesen).

Es wäre für die angegebene Verwendung aber m.E. sinnvoller, mittels IMU die Verzögerung zu erkennen und dann zu blinken. Machen Fahrradbremslichter ja auch. Den ganzen Yadda mit Autoelektronik, Zulassung, Versicherung, Sciherheitsbedenken usw, kann man sich ja vorab sparen, hier geht's ja definitiv um Betrieb außerhalb des Straßenverkehrs.

Die Baudrate sollte etwas schneller sein, zB 115200 Baud. Und die Berechnung nebenlaeufig machen. Gewisse vorgegebenen Ereignisse wie Bremslicht kann man auch Abspeichern, und rauslassen, ohne Rechnen

Hi,

Du benutzt Variablen in der ISR und in der main Funktion. Diese Zugriffe hast du nicht gegen konkurrierenden Zugriff abgesichert.

Strukturier das Programm um:

1. Main muss die HW Initialisieren und die Interrupts starten. Danach muss main nur noch die Werte der Zeitmessung auslesen und die entsprechende Verarbeitung durchführen. Die Ausgabe Werte schreibst du in einen von mehreren UART Buffern (besser Ringbuffer).

2. Alle Variablen die in einer oder mehreren ISR und / oder main verwendet werden, müssen gegenüber konkurrierenden Zugriff geschützt werden (Interrupts kurzfristig abschalten). Solche Kodeabschnitte müssen kurz sein!

3. Die UART Transmit Funktion in eine ISR auslagern.

4. Vergiss das mit dem GALA Signal. Zu unzuverlässig. Nimm die CAN Signal für die Geschwindigkeit.

===> Polemik on 5. Wenn das Auto kein CAN hat, ist das so alt, dass es sowieso nicht mehr fährt.

==== Polemik off

Gruß Olaf

===> Polemik 2 on 6. gibts das schon lange, ist nur in D bzw. EU-Land nur eingeschränkt zulässig. Was willst du da neu „erfinden“, und warum?

==== Polemik off

Keine Polemik

Würde mich nicht wundern, wenn das Fummeln im Bereich der Bremsleuchten, die Betriebserlaubnis ungültig macht.

Sebastian R. schrieb:

Du hast hast Programm geschrieben

// Datum : 28.10.2003 />

Na ja...

Ja komm, das kann auch ein Rest eines Grundgerüsts sein.

Daniel L. schrieb:

ist jedoch für meine Begriffe extrem lang

Techniker sollten sich quantitativ ausdrücken. Nicht qualitativ.

Also: welche Zeit (in Sekunden) oder welche Aktualisierungsrate (in Hz, aka "pro Sekunde") ist nötig, welche hast du erwartet und welche kannst du messen?

Lothar M. schrieb:

Daniel L. schrieb:

ist jedoch für meine Begriffe extrem lang

Techniker sollten sich quantitativ ausdrücken. Nicht qualitativ.

Also: welche Zeit (in Sekunden) oder welche Aktualisierungsrate (in Hz, aka "pro Sekunde") ist nötig, welche hast du erwartet und welche kannst du messen?

Du hast Recht. Die Aktualisierungszeit der Frequenz liegt bei ca. 0.25s, die Ergebnisse via Uart werden erst mehrere Sekunden später angezeigt (es dürften so um die 3-5s sein). Ich bin im Bereich der uC-Programmierung kein Profi, aber natürlich will ich mich in diese Richtung verbessern. Ich werde erst einmal die oben genannten Tipps beherzigen.