Aktualisierung UART langsam?

[Daniel L. (dannynrw)]

Hallo zusammen,

ich benötige mal Euren Rat. Und zwar arbeite ich an einem Projekt zur 
Implementierung eines "adaptiven Bremslichts". Das bedeutet, ab einer 
bestimmten Geschwindigkeit sollen die Bremsleuchten bei einer 
Vollbremsung blinken, um die Aufmerksamkeit des Hintermanns zu steigern. 
Die Fahrzeuggeschwindigkeit erfasse ich über das GALA-Signal, welches in 
Form von Rechteckimpulsen ausgegeben wird. Die Erfassung an sich 
funktioniert auch und momentan gebe ich diese via UART aus, um diese 
während der Testphase anzeigen zu können. Die Aktualisierungsrate ist 
jedoch für meine Begriffe extrem lang und nun frage ich mich: Liegt das 
an meiner Programmierung oder muss ich damit leben? Ich bin für jegliche 
Tipps dankbar.

Sonnige Grüße
Daniel

[Sebastian R. (sebastian_r569)]

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?

[Jens M. (schuchkleisser)]

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.

[Pandur S. (jetztnicht)]

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

[Olaf D. (Firma: O.D.I.S.) (dreyero)]

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

[Oliver S. (oliverso)]

===> 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

[Sebastian S. (amateur)]

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

[Schwierig (ruelps)]

Sebastian R. schrieb:
> Du hast hast Programm geschrieben
// Datum       : 28.10.2003
/>

Na ja...

[Jens M. (schuchkleisser)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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?

[Daniel L. (dannynrw)]

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.