STM32 Software Interrupt auf Variable

Sascha P. schrieb:
> In einer USART ISR schreibe ich in ein Array, sobald die Daten (eine
> definierte Zeichekette variabler Länge (<$>...<CR><LF>)) fertig sind
> müssen diese verarbeitet werden.

1. Das klingt, als ob das nicht in einer Schleife gemacht wird, sondern 
die Daten irgendwoher kommen.
2. 'Irgendjemand' muss doch das <CR><LF> anhängen, kann 'der' nicht die 
Sende-ISR freischalten?

Kannst du nicht einfach in der USART-ISR ein Flag setzen, sobald ein 
CR/LF erkannt wird?
Die Verarbeitungsfunktion wird dann aus dem Mainloop aufgerufen falls 
das Flag gesetzt ist. Dabei muss aber sichergestellt werden, dass der 
nächste USART-Interrupt nicht Teile des Arrays überschreibt, bevor die 
nicht fertig verarbeitet sind.

Irgendwie scheint das Konzept Murks zu sein.
Hänge zwischen ISR und AppCode einen SW-Ringpuffer. Wenn diene ISR <LF> 
erkennt, kann sie ja ein Flag setzen. Zwischendurch kommt ja immer dein 
AppCode dran, der dann auf das Flag pollt und es u.U. zurücksetzt.

Arne schrieb:
> Irgendwie scheint das Konzept Murks zu sein.

Ich wollt's so nicht sagen...

Es muss nicht unbedingt ein Ringpuffer sein.
Daten in 'Daten-Sammel-ISR' in Eingabepuffer schreiben. Wenn fertig, 
Fähnchen hissen. Im Mainloop Flagge auswerten. Interrupts sperren, Daten 
in Ausgabepuffer kopieren, 'USART-OUT-Interrupt freigeben, Interrupts 
freischalten.

Sascha P. schrieb:
> Jetzt müssen diese Daten aber auch ausgewertet werden

Ja, und das ist das Hauptprogramm.
Man muss das ja nicht in die mainloop schreiben. Ich würde das auch 
nicht machen. Da kommt nur ein Funktionsaufruf rein, der abgearbeitet 
wird, wenn Daten angekommen sind, und das ganze bleibt schön 
übersichtlich.

Ok, ich habe keine Erfahrung mit einem RTOS.
Trotzdem verstehe ich nicht, wieso die Datenverarbeitung in einer ISR 
laufen soll. Die müsste ja dann mit sehr Priorität laufen, damit sie von 
zeitkritischen Interrupts unterbrochen werden kann. Und für die 
Modularität ist es auch egal, ob der Code in einer ISR oder einer 
normalen Funktion steht.

Flo G schrieb:
> Trotzdem verstehe ich nicht, wieso die Datenverarbeitung in einer ISR
> laufen soll. Die müsste ja dann mit sehr Priorität laufen, damit sie von
> zeitkritischen Interrupts unterbrochen werden kann.

Ich glaube, Interrupts sollte man möglichst überhaupt nicht 
unterbrechen.
In einer ISR setzt man am besten immer nur ein Flag. Höchstens mal ein 
Byte empfangen und in einen Puffer schreiben bzw. lesen und dann senden.

> Und für die
> Modularität ist es auch egal, ob der Code in einer ISR oder einer
> normalen Funktion steht.

Das meinte ich. Einfach Zeiger auf die Daten übergeben. Fertig. Läuft 
dann völlig für sich. Was sonst noch in der main() gearbeitet wird, 
stört die Funktion überhaupt nicht.

David R. schrieb:
> Anderer Vorschlag: Wie wäre es wenn du die Daten im Hintergrund per DMA
> direkt vom USART in den RAM scheffeln lässt?
scheffeln (mit welcher Methode auch immer) und wenn fertig ...
> Dann muss nur noch in unregelmäßigen abständen der STM über die Daten
> drüber schauen und nach dem bestimmten Zeichen suchen.
... lieber Bescheid sagen. Das ist nicht so anstrengend ;-)

Flo G schrieb:
> Trotzdem verstehe ich nicht, wieso die Datenverarbeitung in einer ISR
> laufen soll.
Ich auch nicht!
ISRs sollen nicht ohne Grund so kurz wie möglich sein. So einen Quark 
mit ISRs, die O(n^2) Code ausführen, habe ich allerdings schon sehen 
müssen. Entsprechend holprig lief das System.

> Die müsste ja dann mit sehr Priorität laufen, damit sie von
> zeitkritischen Interrupts unterbrochen werden kann.
Und sie muss mit niedrigerer Priorität laufen als die UART ISR, sonst 
gehen Zeichen verloren.

@Udo
> Ich wollt's so nicht sagen...
manchmal muss man die Dinge beim Namen nennen ;)

@Sascha
Wenn dir Ringpuffer zu kompliziert ist, dann lege zwei Puffer 
identischer Große an, die jeweils so groß sind, dass eine auszuwertende 
Nachricht komplett rein passt. Die ISR empfängt dann in die eine oder 
andere. Damit umgehst du die Ringpufferverwaltung.