Wie mit STM32F0 DMX Empfangen

[Peter (Gast)]

Hallo,
ich versuche gerade einen DMX Empfänger mit einem STM32f072 zu bauen.

Hatte das zuvor mit einem AVR gemacht und hatte eigentlich nicht mit 
Problemen gerechnet. So kann man sich irren.

Der AVR reagiert auf Overflow, Frameerror und normalem Empfang.
Also das normale vorgehen beim DMX Empfang.

Jetzt wollte ich genau diese Interrupts auch beim STM einschalten.
Aber nach den ersten INT ist der Tot und macht nichts mehr.

Im Netz stolpere ich immer über 2 Projekte die aber total anders 
arbeiten und absolut ungeeignet sind.

Hat jemand das schon mal gemacht?
Gibt es beispiele die so arbeiten?

MFG, Peter

[Jim M. (turboj)]

Peter schrieb:
> Jetzt wollte ich genau diese Interrupts auch beim STM einschalten.
> Aber nach den ersten INT ist der Tot und macht nichts mehr.

Wenn man die entsprechenden Flags nicht löscht, wird der Interrupt 
Handler endlos zyklisch aufgerufren. Anders als bei AVR findet dann auch 
keine Codeausführung in main() statt.

Übrigens sollte man sich einen eigenen Handler für Hardfault schreiben,
sonst sucht man u.U. endlos nach Fehlern. Die Cortex M0 sind z.B. 
empfindlich bei Alingment Problemen, die man auf 8-Bittern so gar nicht 
kennt.

Anders als AVR kann man Cortex M IMHO ziemlich gut debuggen...

[Peter (Gast)]

Der Serial Int ist Tot nicht der Prozessor, Main läuft noch ohne 
Probleme.

Die Flags lösche ich, habe es auch schon mal ohne löschen probiert, 
gleiche Resultat.
In einem Anderen Projekt habe ich mit der SIO schon gearbeitet, aber da 
ohne die Fehlerbehandlung.

Ich packe nachher mal die paar Testzeilen hier rein, habe das Projekt 
gerade nicht dabei.

Den Umgang mit den ARM Prozessoren kenne ich inzwischen recht gut.
Aber das man den viel besser debuggen kann konnte ich bis jetzt nicht 
merken.
Weder ein M0, M4 noch ein M7 war da besonders besser als ein AVR.

MfG Peter

[Falk B. (falk)]

@  Peter (Gast)

>Der Serial Int ist Tot nicht der Prozessor, Main läuft noch ohne
>Probleme.

Dann hast du einen Bug in deiner ISR-Behandlung. Wo auch immer.

>Den Umgang mit den ARM Prozessoren kenne ich inzwischen recht gut.

Aber kriegst nicht mal einen einfachen UART mit Interrupt zum laufen?
Noch einer, der glaubt zu wissen.

>Aber das man den viel besser debuggen kann konnte ich bis jetzt nicht
>merken.
>Weder ein M0, M4 noch ein M7 war da besonders besser als ein AVR.

Man muss schon die Methodik kennen und richtig anwenden. printf() ist es 
nicht.

[Peter (Gast)]

Ich glaube Printf ist kein geeignetes Mittel um ein Programm zu 
debuggen, da ist ein ICE doch um klassen besser.
Besonders beim ARM werden einem die Dinger ja für wenig Geld nach 
geworfen.


Eine normale SIO bekomme ich hin, nur hier ist eine Eigenart der SIO bei 
den Fehler Quellen gefragt und da klappt halt was nicht.

[Falk B. (falk)]

@ Peter (Gast)

>Ich glaube Printf ist kein geeignetes Mittel um ein Programm zu
>debuggen, da ist ein ICE doch um klassen besser.
>Besonders beim ARM werden einem die Dinger ja für wenig Geld nach
>geworfen.

Und wie kommst du dann zu der Aussage, dass ARM nicht besser zu debuggen 
ist als ein AVR?

[Peter (Gast)]

Weil es für den AVR auch solche Tools gibt und die sind nicht besser 
oder schlechter.
Aber lass es einfach, ist nicht das Thema hier!

Wenn Du was über DMX mit dem STM32f072 sagen kannst dann bitte.

Peter

[Altes Lötzinn stinkt (Gast)]

Hatte das gleiche Problem beim STM32F072
Ich vermute mal Du nutzt die HAL Lib?
Aber warten wir mal ab bis Du Deinen Code postest.

[Peter (Gast)]

So ich habe gestern Abend noch etwas Probiert und jetzt geht es auf 
einmal.
Bin aber noch nicht so sicher ob das alles so richtig ist, ich meine den 
Empfang nicht was mit den Daten passiert.

Hier der Code (Auszug):

void USART1_IRQHandler(void)
{
   uint16_t rx;

   if (USART_GetITStatus(USART1, USART_IT_ORE) != RESET) // Data Overrun?
   {
      rx = USART_ReceiveData(USART1); // Lese das Zeichen
      USART_ClearITPendingBit(USART1,USART_IT_ORE);
      DmxInStatus = IN_BREAK; // Warte auf Reset (BREAK)
   }
   else
   {
      if (USART_GetITStatus(USART1, USART_IT_FE) != RESET) //BREAK or FramingError?
      {
         rx = USART_ReceiveData(USART1); // Lese das Zeichen
         USART_ClearITPendingBit(USART1,USART_IT_FE);
         if (rx == 0)
         {
            DmxInStatus = IN_STARTB; // FE WAS a BREAK -> Warte auf Start Byte!
         } else {
            DmxInStatus = IN_BREAK; // Warte einfach auf Reset (BREAK) 
         }
      }
      else
      {
         if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) // Empfangsinterrupt?
         {
            rx = USART_ReceiveData(USART1); // Lese das Zeichen
            switch (DmxInStatus)
            {
            case IN_STARTB:
               if (rx == 0)
               {
                  DmxInStatus = IN_DMX_DATA; // gehe in den Daten einlese Zustand
                  DmxInDataCounter = 0; // Reset vom Daten Counter
               } else {
                  DmxInStatus = IN_BREAK; // Warte einfach auf Reset                                    
               }
               break;
            case IN_DMX_DATA: // Daten ablegen
               DmxPc_In_DmxUniverse[DmxInDataCounter] = rx;

               DmxInDataCounter++; // Datum weiter zaehlen
               if (DmxInDataCounter >= sizeof (DmxPc_In_DmxUniverse))
               {
                  DmxInStatus = IN_BREAK; // ALL CHANNELS RECEIVED
               }
               break;
            default :
               break;
            }
         }
         else
         {
            USART_ClearITPendingBit(USART1,USART_IT_ERR);
            USART_ClearITPendingBit(USART1,USART_IT_FE);
            USART_ClearITPendingBit(USART1,USART_IT_IDLE);
            USART_ClearITPendingBit(USART1,USART_IT_ORE);
         }
      }
   }
}


//  DMX IN auf UART 1   Pin A9 & A10 (30&31)
void Uart1_Init(void)
{
   USART_InitTypeDef USART_InitStructure;
   GPIO_InitTypeDef GPIO_InitStructure;
   NVIC_InitTypeDef NVIC_InitStructure;

   RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);
   RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1,ENABLE);

   GPIO_PinAFConfig(GPIOA, GPIO_PinSource9, GPIO_AF_1);
   GPIO_PinAFConfig(GPIOA, GPIO_PinSource10, GPIO_AF_1);

   /* Configure USART1 pins:  Rx and Tx ----------------------------*/
   GPIO_InitStructure.GPIO_Pin =  GPIO_Pin_9 | GPIO_Pin_10;
   GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
   GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
   GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
   GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
   GPIO_Init(GPIOA, &GPIO_InitStructure);

   /* Enable USART1 IRQ */
   NVIC_InitStructure.NVIC_IRQChannel = USART1_IRQn;
   NVIC_InitStructure.NVIC_IRQChannelPriority = 0;
   NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
   NVIC_Init(&NVIC_InitStructure);

   USART_InitStructure.USART_BaudRate = 250000;
   USART_InitStructure.USART_WordLength = USART_WordLength_8b;
   USART_InitStructure.USART_StopBits = USART_StopBits_2;
   USART_InitStructure.USART_Parity = USART_Parity_No;
   USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
   USART_InitStructure.USART_Mode = USART_Mode_Rx;
   USART_Init(USART1, &USART_InitStructure);

   USART_Cmd(USART1,ENABLE);
   USART_ITConfig(USART1, USART_IT_RXNE, ENABLE); // Enable always
   USART_ITConfig(USART1, USART_IT_ERR, ENABLE); // Enable always
}

Wer sich damit auskennt könnte mir mal sagen was ich noch falsch mache,
oder was man besser anders machen sollte.

Peter

[Peter (Gast)]

Schade das niemand was zum Code zu sagen hat.

Peter

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Man fragt sich halt, was sich seit Deiner ersten Anfrage geändert hat. 
:)
Andere Optimierungsstufe? Welches EWU?

Bei ISR Funktionen schau ich mir gerne mal das Timing an (Latenzzeit, 
Verweildauer).
Falls Debug-Pins zur Verfügung stehen, mit dem Oszi, ansonsten mit den 
eingebauten Zählern in der MCU.


Die Interruptlatenzzeit ist bei Cortex Mx erstaunlich groß, dafür 
sichert Dir die Kiste aber schon den Kontext weg.
Auf F030 reden wir hier über mehr als 500ns, bevor Deine ISR losrennt.
Du hast maximal 44us (11/Baudrate) für Deine ISR. Sieht gut aus.

Zum Thema Effizienz:
- Standardbibliotheken (gut zum Einstieg, lahmes Speicherschwein)
- direkter Zugriff auf die Peripherieregister (da weiß man hat, schon 
recht kompakt)
- Assembler (da war es wieder, das böse Wort)


Konkrete Vorschläge:

- die 50MHz Portpins kannst Du auch noch runterbremsen

- das hier
            USART_ClearITPendingBit(USART1,USART_IT_ERR);
            USART_ClearITPendingBit(USART1,USART_IT_FE);
            USART_ClearITPendingBit(USART1,USART_IT_IDLE);
            USART_ClearITPendingBit(USART1,USART_IT_ORE);
   wird eine Zeile, einfach Bits verodern. Tipp öfter mal F3 auf den 
Funktionsnamen und Defines und schau Dir an, wie die Dinger beschrieben 
werden. Nebendran hast Du die RM0360 offen.

- vor dem Enablen von Interrupts, DMA-Requests etc. alle dazugehörigen 
Flags löschen. Der Mechanismus ist bei STM32 manchmal nicht sofort zu 
sehen, ggf. in den Foren suchen. Lösch mal einen pending 
Timer-DMA-Request. ;)

- Hardfault-Handler wurde schon erwähnt -> wenn Du da einen Breakpoint 
reinsetzt, siehst Du gleich, wenn und was schiefgelaufen ist. Komplett 
mit Call-History.

- wenn Dir noch was fischig vorkommt: Breakpoints setzen und die 
Peripherieregister gegen die RM0360 vergleichen, Bit für Bit. Wenn's mit 
den Standardbibliotheken nicht so wird, wie Du es haben willst, dann 
setz die Register von Hand.

[Peter (Gast)]

Danke für Deine umfangreiche und zutreffende gute Antwort.
Leider geht es hier aber nicht um Timming, Debuggen oder wie arbeitet 
man.

Klar kann man später die CMSIS Sachen noch mal ersetzten, mache ich 
normalerweise wenn es läuft auch. Lasse dann als Kommentar die CMSIS 
Zeile immer drin.
Das macht immer Sinn wenn man mal den Prozessor wechselt, was mit Teilen 
meiner Software auch oft passiert.
Heute ist der Code in einem M0 und vielleicht in 8 Wochen in einem M4 
oder M7, wer kann das heute schon sagen.

Geändert haben sich nur 3 Sachen:
- Die Spannung ist nun im DMX Bereich sauberer (war 4,3V sollte 5,0V 
sein)
- Ich fische mit USART_ReceiveData(USART1) bei den Overrun die UART ab.
- Ich habe alles auf if .. else umgebaut und frage somit nicht mehr 
alles ab.

Also an den CMSIS Kram hat es nicht gelegen.
Aber ist das jetzt auch alles so richtig?
Was muss man technisch verbessern (ausser Timming)?

Peter

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Peter schrieb:
> Danke für Deine umfangreiche und zutreffende gute Antwort.
Danke für die Blumen.

> Leider geht es hier aber nicht um Timming, Debuggen oder wie arbeitet
> man.
Ich dachte, dass es genau darum ging. Du bist mit dem Ergebnis 
unzufrieden und wolltest Kommentare zum Code. Solange niemand außer Dir 
hat die passende Hardware, Deinen gesamten Code und Zeit hat, bleibt Dir 
nur die RM0360.

[Peter (Gast)]

In diesem Fall verteile ich gerne Blumen, weil es einfach gut ist, was 
Du geschrieben hast. Perfekt für einen Programmieranfänger.
Ich bin aber schon lange im Geschäft, nur die ganzen STM32 Prozessoren 
bringen mich regelmäßig zum verzweifeln. Entweder ich werde Alt oder STM 
sollte sich mal überlegen warum man regelmäßig total unlogische Abläufe 
einhalten muss und diese dann nicht mal sauber beschreibt.

Damit hast Du wiedermal recht, ich habe das gesamte Projekt und noch 
kein anderer. Wird kein Produkt was ich verkaufe! Das ist ein Projekt 
innerhalb eines Vereins und wird später auch nur Vereinsintern genutzt.

Es gibt doch einige die sich mit der SIO beim STM32F072 beschäftigt 
haben und wenn dann jemand hier drauf schaut, sollte derjenige schon gut 
sehen können ob das so richtig ist. Gut es geht jetzt, aber ist das nur 
Glück?
Zu mindestens ist das hier um einiges übersichtlicher und einfacher wie 
manch andere Anfragen hier im Forum (Wenn man sich damit auskennt).

VG, Peter

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Wir werden alle nicht jünger.
Die STM32 sind halt eine andere Kampfklasse als AVR/PIC. Bis man die ca. 
4000 Seiten Doku, verteilt auf ca. 50 Dokumente, für den F0 durch hat, 
das dauert. Aber im Vergleich zum F4 ist das Teil echt übersichtlich.
Allerdings kann man anschließend in den MCUs Dinge abbilden, die vor ein 
paar Jahren nur mit FPGAs bzw. ASICs gingen. Meine Website ist voll mit 
Beispielen dafür.

Dabei ist der Cortex Mx eher der Knecht zum Datenverarbeiten. Das 
Datenschaufeln zwischen Peripherie und Speicher macht bevorzugt DMA.

Das nur als abschließende Idee, viel Erfolg mit dem Projekt.
Ich lese einfach noch ein wenig mit. :)

[Peter (Gast)]

DMA würde ich gerne nehmen, ist hier aber nicht so einfach möglich.
Irgendwie muss ich halt auf die ganzen Errors reagieren, weil darüber 
der Start erkannt wird und die Anzahl der Daten die ankommen ist nicht 
sicher. DMX sagt zwar 512 Byte aber es gibt DMX Sender die nur 60Byte 
senden.
Das ganze lief vorher auf einem AVR und wenn der das packt dann sollte 
der STM darüber lachen können.

Die ARM Typen von NXP und Atmel haben mir nie soviel Ärger gemacht.
Aber bei den letzten Anwendungen die ich gemacht habe war von den Daten 
der STM Typen immer besser. Außerdem wenn sie laufen dann arbeitet auch 
alles perfekt.

Ich werde den Code so lassen, schau in mir aber noch mal im Debugger an.
Wenn ich Probleme bemerke dann werde ich mich wieder melden.

VG, Peter

[Falk B. (falk)]

@Peter (Gast)

>DMA würde ich gerne nehmen, ist hier aber nicht so einfach möglich.
>Irgendwie muss ich halt auf die ganzen Errors reagieren, weil darüber
>der Start erkannt wird und die Anzahl der Daten die ankommen ist nicht
>sicher. DMX sagt zwar 512 Byte aber es gibt DMX Sender die nur 60Byte
>senden.
>Das ganze lief vorher auf einem AVR und wenn der das packt dann sollte
>der STM darüber lachen können.

Eben. DMA nützt nur was bei einem DMX-Sender.

[Peter (Gast)]

Das auch nur wenn man kein interbyte Delay macht.
Also ein paar µs wartet zwischen den einzelnen Bytes.

Bitte nicht lachen, es gibt Geräte die schaffen sonst den Empfang nicht.

[Falk B. (falk)]

@ Peter (Gast)

>Das auch nur wenn man kein interbyte Delay macht.
>Also ein paar µs wartet zwischen den einzelnen Bytes.

Dann geht es immer noch mit DMA, nur dass die dann halt per Timer und 
nicht per UART getriggert wird.

>Bitte nicht lachen, es gibt Geräte die schaffen sonst den Empfang nicht.

Jaja, schlechte Designs und Chinakram.

[Peter (Gast)]

Stimmt diesen Trick gibt es ja.

Wenn ich mal einen Sender baue werde ich das dann auch so vorsehen, aber 
zur Zeit muss ich nur empfangen.