12-UART-Library (STM32F4)

-mit dieser Library können die 6 UARTs der CPU benutzt werden

-die UARTs die benutzt werden sollen, müssen im H-File deklariert und im C-File müssen in der Struktur “UART[]” alle benötigten Parameter eingetragen werden.
(also Pinzuordnung, Baudrate usw)

-es gibt eine Sende-Funktion um einen String über die UARTs zu senden

-und eine Receive-Funktion um zu testen ob ein String über eine UART empfangen wurde. (der Sender muss an den String ein Endekennungs-Zeichen anhängen z.B. CarriageReturn)

-das eigentliche empfangen der einzelnen Character passiert per Interrupt im Hintergrund.

-die Array-Funktion : “UB_Uart_SendArray” sendet ein beliebiges Daten-Array
mit “cnt” Bytes per UART

-die Array-Funktion : “UB_Uart_ReceiveArray” empfängt ein beliebiges Daten-Array
und übergibt die Anzahl der bis jetzt empfangenen Bytes
(Hinweis : diese Funktion muss u.U. mehrmals aufgerufen werden um alle Daten
einzusammeln)

-im Beispiel wurden zwei UARTs definert :

1
2

COM2 per UART2 [TX=PA2], [RX=PA3] mit 115200 Baud
COM3 per UART3 [TX=PD8], [RX=PD9] mit 115200 Baud

Voraussetzungen :

1
2

Benutzte Module der CooCox-IDE : GPIO, USART, MISC
Benutzte Librarys : keine

Enumerationen :

1
2
3
4
5
6
7

typedef enum {
  NONE = 0,  // keine Endekennung
  LFCR,      // LineFeed + CarriageReturn (0x0A,0x0D)
  CRLF,      // CarriageReturn + LineFeed (0x0D,0x0A)
  LF,        // nur LineFeed (0x0A)
  CR         // nur CarriageReturn (0x0D)
}UART_LASTBYTE_t;

.

1
2
3
4
5

typedef enum {
  RX_EMPTY = 0,  // nichts empfangen
  RX_READY,      // es steht was im Empfangspuffer
  RX_FULL        // RX-Puffer ist voll
}UART_RXSTATUS_t;

Funktionen :

1
2
3
4
5
6

void UB_Uart_Init(void);                                                        // zum init aller UARTs
void UB_Uart_SendByte(UART_NAME_t uart, uint16_t wert);                         // zum senden eines Bytes
void UB_Uart_SendString(UART_NAME_t uart, char *ptr, UART_LASTBYTE_t end_cmd);  // zum senden eine String
UART_RXSTATUS_t UB_Uart_ReceiveString(UART_NAME_t uart, char *ptr);             // zum empfangen eines Strings
void UB_Uart_SendArray(UART_NAME_t uart, uint8_t *data, uint16_t cnt);          // zum senden eines arrays
uint32_t UB_Uart_ReceiveArray(UART_NAME_t uart, uint8_t *data);                 // zum empfang eines arrays

Beispiel :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

//--------------------------------------------------------------
// File     : main.c
// Datum    : 24.02.2013
// Version  : 1.0
// Autor    : UB
// EMail    : mc-4u(@)t-online.de
// Web      : www.mikrocontroller-4u.de
// CPU      : STM32F4
// IDE      : CooCox CoIDE 1.7.0
// Module   : CMSIS_BOOT, M4_CMSIS_CORE
// Funktion : Demo der UART-Library
// Hinweis  : Diese zwei Files muessen auf 8MHz stehen
//              "cmsis_boot/stm32f4xx.h"
//              "cmsis_boot/system_stm32f4xx.c"
//--------------------------------------------------------------
 
#include "main.h"
#include "stm32_ub_uart.h"
 
int main(void)
{
  char buf[RX_BUF_SIZE]; // puffer fuer Datenempfang
  UART_RXSTATUS_t check;
 
  SystemInit(); // Quarz Einstellungen aktivieren
 
  // Init der UARTs
  // Com2 und Com3 mit je 115200 Baud
  UB_Uart_Init();
 
  // Zwei String per UART senden (mit LineFeed+CarriageReturn)
  UB_Uart_SendString(COM2,"Hier ist UART2 [PA2,PA3]",LFCR);
  UB_Uart_SendString(COM3,"Hier ist UART3 [PD8,PD9]",LFCR);
 
  while(1)
  {
    // check ob Daten an UART2 empfangen werden
    check=UB_Uart_ReceiveString(COM2,buf);
    if(check==RX_READY) {
      // wenn Daten empfangen wurden
      // als Echo wieder zurücksenden
      UB_Uart_SendString(COM2,buf,LFCR);
    }
  }
}

Hier die Library zum Download :

ub_stm32f4_uart_v105

Hier der komplette CooCox-Projektordner zum Download :

Demo_12_UART

Hier der Link zu dem PC-Programm :

PC-Programme

58 Antworten auf 12-UART-Library (STM32F4)

1. X_X sagt:

   25. November 2013 um 22:17

   Achtung: UART4 und UART5 tragen kein “S” im Namen, daher werden die Interruptroutinen nicht registriert und man landet bei Datenempfang im Default Handler

   • admin_ub sagt:

     26. November 2013 um 19:51

     Danke für den Hinweis…werd’ ne neue Version hochladen (das betrifft den 429 wohl genauso)

2. Simon sagt:

   26. November 2013 um 13:06

   Ich hätte eine Frage, wenn ich die Lib. in einem komplexeren Programm benutze wo die Frequenzen in der:
   “cmsis_boot/stm32f4xx.h”
   “cmsis_boot/system_stm32f4xx.c”
   nicht auf 8MHz gestellt sind,
   kann ich die Lib. mit gewissen Änderungen trotzdem irgendwie benutzen?
   Danke für die Antwort!!

   • admin_ub sagt:

     26. November 2013 um 19:55

     Der Library ist egal was für ein Quarz eingebaut ist. Der Teiler für die Baudrate wird von der STM-Peripheral-Lib berechnet. Aber damit das funktioniert muss der verwendete Quarz mit der Einstellung in den beiden Files die du gepostet hast übereinstimmen. Also keinen 25MHz Quarz einlöten und dann in den Settings nur 12MHz reinschreiben…dann geht die Berechnung schief.

     • Simon sagt:

       27. November 2013 um 13:50

       Was mir gerade auffällt, auf dem Discoveryboard ist ein 8MHz Quarz eingelötet aber in den beiden Files sind jeweils 25MHz in den Settings?!

       • admin_ub sagt:

         27. November 2013 um 20:18

         dann stimmt wohl was in den Settings nicht

         • Simon sagt:

           3. Dezember 2013 um 10:51

           Habs jetzt zum laufen bekommen,
           auch in mein Projek eingebunden,
           aber sich lese die Daten mit dem Programm
           HTerm aus, der Mikrocontroller empfängt Daten sendet diese auch wieder aus, nur leider nicht ganz komplett bzw. vollständig, weißt du woran das liegen könnte?

           Es handelt sich um ein GPS Modul welches via UART 2x pro Sekunde Daten versendet, welche dann vom Mikrocontroller verarbeitet werden.

3. Simon sagt:

   4. Dezember 2013 um 15:29

   Gibt es eine begrenzung für die Größe von Strings die gesendet bzw. empfangen werden können?

   • admin_ub sagt:

     4. Dezember 2013 um 19:28

     im H-File wird die größe vom Empfangspuffer eingestellt “RX_BUF_SIZE”. Als Standard steht da “50″ drinn. Falls dieser Puffer überläuft z.B. wenn du nicht schnell genug die Daten wieder aus dem Puffer ausließt gibt es den Rückgabewert “RX_FULL” statt “RX_READY”.

4. Simon sagt:

   5. Dezember 2013 um 10:48

   Mein Problem ist, ch empfange GPS-Daten über UART, wenn das GPS-Modul kein Empfang hat sind die Daten recht ordentlich die ich empfange, doch sobald das GPS-Modul Empfang bekommt werden die Daten vorne und hinten und überall abgeschnitten, möglicherweise weil der string zu groß ist?!
   Kann ich die Größe der Bytes einfach ändern?

   • admin_ub sagt:

     5. Dezember 2013 um 19:19

     klar, kannst du so groß machen wie noch Platz im RAM ist.

5. kai sagt:

   20. Dezember 2013 um 02:55

   Hallo,

   ich habe ein linvor Bluetooth Modul, dass in meinem Windows als COM4 installiert ist. Ich habe das gleiche Modul mit einem Atmega und UART bereits in Betrieb gehabt. Leider tut sich selbst mit dem CooCox Beispiel Projekt nichts. Ich empfange nichts und kann auch nichts senden. Die Bezeichnungen COM2 und COM3 sind doch frei wählbar oder?

   Gruß
   kai

   • admin_ub sagt:

     20. Dezember 2013 um 09:01

     “Com2″ ist nur ein Text, denn kannst du ändern (aber dann auch im H-File). Die Library erwartet als String-Endekennung ein “0x0D” falls dein Modul was anderes an das Ende anhängt kannst du das im H-File ändern “RX_END_CHR”.

     • kai sagt:

       20. Dezember 2013 um 23:06

       vielen Dank für die Antwort. Ich habe das mit dem Bluetooth Modul leider nicht hinbekommen. Wahrscheinlich liegt es am Endezeichen. Da ich die UART Schnittstelle benötige, um zu debuggen, habe ich einen FT232R an das STM32F4 Discovery angeschlossen. Damit funktioniert die Library einwandfrei.

       P.S. Kannst du mir vielleicht einen Tipp geben wie man herausfinden kann wie das Endezeichen des Bluetooth Moduls lautet?

       • Joerg sagt:

         21. Dezember 2013 um 00:36

         Datenblatt würde ich mal sagen…

         • kai sagt:

           21. Dezember 2013 um 09:35

           Ok, sorry hätte ich eigentlich selbst drauf kommen müssen. Danke für die Antwort.
           Ich hoffe ich finde eins. Das ist ein Modul aus China.

         • Joerg sagt:

           21. Dezember 2013 um 13:37

           evtl. findest du auch was im demo code

6. kai sagt:

   21. Dezember 2013 um 17:25

   Habe es auf ddr Seite des Verkaeufers gefunden.

   Danke fuer die Hilfe.

7. Joerg B sagt:

   2. März 2014 um 01:41

   Ich versuche gerade Uart1 in betrieb zu nehmen:

   UART_t UART[] = {
   // Name, Clock , AF-UART ,UART , Baud , Interrupt
   {COM2,RCC_APB2Periph_USART1,GPIO_AF_USART1,USART1,9600,USART1_IRQn, // UART2 mit 115200 Baud
   // PORT , PIN , Clock , Source
   {GPIOA,GPIO_Pin_9,RCC_AHB1Periph_GPIOA,GPIO_PinSource9}, // TX an PA2
   {GPIOA,GPIO_Pin_10,RCC_AHB1Periph_GPIOA,GPIO_PinSource10}}, // RX an PA3

   // Name, Clock , AF-UART ,UART , Baud, Interrupt
   {COM3,RCC_APB1Periph_USART3,GPIO_AF_USART3,USART3,9600,USART3_IRQn, // UART3 mit 115200 Baud
   // PORT , PIN , Clock , Source
   {GPIOC,GPIO_Pin_10,RCC_AHB1Periph_GPIOC,GPIO_PinSource10}, // TX an PD8
   {GPIOC,GPIO_Pin_11,RCC_AHB1Periph_GPIOC,GPIO_PinSource11}}, // RX an PD9
   };

   com 3 funktioniert aber com2/uart1 nicht.

   ist uart1 getestet??

   • admin_ub sagt:

     2. März 2014 um 09:25

     gerade eben getestet mit meiner STAMP … funktioniert. Am Discovery-Board sind PA9 und PA10 nicht frei !!.

8. Joerg B. sagt:

   2. März 2014 um 10:25

   Mist auch meinem Core Board hängt da auch USB drauf. Muss ich mir wohl andere Pins suchen….

   Danke

9. Joerg B sagt:

   2. März 2014 um 11:00

   Ok das war es, läuft soweit.

   Leider ist das polling der Daten ziemlich unglücklich.
   Mein Programm läuft mit FreeRtos. Schon bei einem 1ms delay gehen mir Bruchstücke meiner Datensätze verloren. Ohne delay laufen die anderen Tasks nicht weiter.

   Ich bekomme ca alle 2 sekunden 3 Datensätze
   
28F5C9D0040000C9@17.0625
28BB90BF040000C3@16.7500
DHT22.OK@49


   Mit deley(1) sieht es dann teilweise so aus

   
28F5C9D0040000C9@17.0000
28BB90BF040000C3@16.6875
DHT22.OK@49
28F5C9D0040000C9@17.0000
@16.6875
28F5C9D0040000C9@17.0000
28F5C9D0040000C9@17.0000
@49
28F5C9D0040000C9@17.0000
00C3@16.6875
9
28F5C9D0040000C9@17.0000
28BB90BF040000C3@16.6875
DHT22.OK@49


   Hast du einen Tip dazu?

   • admin_ub sagt:

     2. März 2014 um 17:50

     Delay bei einem RTOS ?? da stimmt doch dann was Grundsätzlich nicht. Das ist doch gerade der Sinn von einem OS, das alle Tasks “theoretisch” parallel laufen. Ich kenne mich mit FreeRTOS nicht aus bin also nicht sicher wie dort die Interrupts verwaltet werden. Event. wird der RX-Interrupt zweitweise deaktiviert oder von einer höheren Prio blockiert.

10. Joerg B sagt:

    2. März 2014 um 23:50

    static void Background_Task(void * pvParameters)
    {

    /* Initilize the BSP layer */
    BSP_Init();

    /* Activate the use of memory device feature */
    WM_SetCreateFlags(WM_CF_MEMDEV);

    /* Init the STemWin GUI Library */
    GUI_Init();

    UB_Uart_Init();

    char buf[RX_BUF_SIZE]; // puffer fuer Datenempfang
    UART_RXSTATUS_t check;

    /* Run the background task */
    while (1)
    {
    /* toggle LED1..4 each 100ms */
    // STM_EVAL_LEDToggle(LED1);

    // check ob Daten an UART2 empfangen werden
    check=UB_Uart_ReceiveString(COM3,buf);
    if(check==RX_READY) {
    // wenn Daten empfangen wurden
    // als Echo wieder zurücksenden
    UB_Uart_SendString(COM2,buf,LFCR);
    }

    GUI_Delay(1);
    }

    Normalerweise wird damit das ledtoggle gesteuert.

    Irgendwie muss emwin zeitweise den uart interrupt blockieren denn es fehlen einfach teile der zu empfangenden Zeilen.
    emwin macht irgendwie nur probleme….

    • Joerg B. sagt:

      3. März 2014 um 00:31

      Uart ginge ja auch per dma, könntest du das auch realisieren? Selber bekomme ich das leider nicht hin.

      • admin_ub sagt:

        3. März 2014 um 09:17

        ich vermute “GUI_Delay()” ist auch nur eine “Dauerloop” damit braucht der Task 100% der CPU. Für pausen gibt es “vTaskDelay” das blocked den Task damit andere Tasks die CPU bekommen können. Und 1ms Abfragezeit ist etwas klein wenn du eh nur alle 2sec was sendest. da reichen doch 10ms oder 100ms locker aus. Und DMA wird nicht viel helfen, wenn der Interrupt blockiert wird, aber ich kann ja mal was vorbereiten.

11. Joerg B sagt:

    3. März 2014 um 11:56

    Ich habe einen Pin dazu genommen und frage jetzt so ab:

    while (UB_DigIn_Read(EMPFANGEN)==1) {
    // check ob Daten an UART2 empfangen werden
    check=UB_Uart_ReceiveString(COM3,buf);
    if(check==RX_READY) {
    // wenn Daten empfangen wurden
    // als Echo wieder zurücksenden
    UB_Uart_SendString(COM2,buf,LFCR);
    }
    }

    Das funktioniert gut.

    Falls du was mit DMA machst würde ich das trotzdem gerne testen.

    Grüße und danke fürs erste

    Jörg

12. MC.Einsteiger sagt:

    5. Juni 2014 um 20:56

    Hallo zusammen,
    wie kann ich in Htem herausfinden, welche Werte meine Sensor
    überhaupt sendet?
    in Arduino war einfacher via serielle Schnittstelle mit dem befehl serial.println( ).
    gibt in stm32f4 auch was ähnliches?.

    Gruß Rick

    • admin_ub sagt:

      7. Juni 2014 um 09:33

      “welcher” Sensor ?!?
      die UART-Library macht das gleiche wie die Arduino-Library
      aber stat “serial.println()” lautet hier die Funktion “UB_Uart_SendString”

      • MC.Einsteiger sagt:

        9. Juni 2014 um 11:59

        induktive Nährungsschalter.
        Ich habe mit STM32f4 Library und deine Libraray probiert funktionieren die beiden leider nicht!!. muss man für stm32f4 in Htem was umstellen!?.

        • admin_ub sagt:

          10. Juni 2014 um 09:13

          woher soll ich wissen was man in HTerm für deinen Sensor einstellen muss ?!? steht vermutlich im Datenblatt.

        • Joerg B sagt:

          10. Juni 2014 um 11:26

          Kommt denn überhaupt was heraus bei Hterm? Wenn es undefinierte Zeichen sind dann stimmt die Baudrate nicht.

          Grundsätzlich musst du ja auch erst mal ein Programm schreiben was die Daten deines Sensors überträgt.

13. MC.Einsteiger sagt:

    11. Juni 2014 um 13:40

    Ich habe einige Baudraten durch versucht wenn das mal nicht 115200 sein sollten und dennoch kein Erfolg !!.
    Ich habe im folgendem Programm probiert.
    Wäre sehr nett wenn jemand das Problem finden könnte.
    Danke im Voraus.

    #include
    #include
    #include “stm32f4xx.h”
    #include “stm32f4xx_gpio.h”
    #include “stm32f4xx_rcc.h”
    #include “stm32f4xx_tim.h”
    #include “misc.h”
    #include “stm32_ub_uart.h”
    #include “stm32_ub_led.h”

    void init()
    {

    SysTick_Config(SystemCoreClock/100);
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

    // Konfiguriere PD15
    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
    GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
    GPIO_Init(GPIOD, &GPIO_InitStructure);
    // Takt für Timer 7 einschalten
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM7, ENABLE);
    // Timer7 konfigurieren
    TIM_TimeBaseInitTypeDef TIM_TimeBase_InitStructure;
    TIM_TimeBase_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1;
    TIM_TimeBase_InitStructure.TIM_CounterMode = TIM_CounterMode_Up;
    TIM_TimeBase_InitStructure.TIM_Period = 4200;
    TIM_TimeBase_InitStructure.TIM_Prescaler = 1000;
    TIM_TimeBaseInit(TIM7, &TIM_TimeBase_InitStructure);
    TIM_ITConfig(TIM7, TIM_IT_Update, ENABLE);
    // Timer7 einschalten
    TIM_Cmd(TIM7, ENABLE);
    // Interruptcontroller konfigurieren
    NVIC_InitTypeDef NVIC_InitStructure;
    NVIC_InitStructure.NVIC_IRQChannel = TIM7_IRQn;
    NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
    NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0x0F;
    NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0x0F;
    NVIC_Init(&NVIC_InitStructure);
    }
    int main(void)
    {
    SystemInit();
    init();
    while(1)
    {
    UB_Uart_SendString(COM3,”Hier ist das Signal”,LFCR);

    }
    }

    void SysTick_Handler(void)
    {
    //leer
    }

    void TIM7_IRQHandler()
    {
    GPIO_ToggleBits(GPIOD,GPIO_Pin_15);
    TIM_ClearITPendingBit(TIM7, TIM_IT_Update);

    }

    • admin_ub sagt:

      11. Juni 2014 um 15:02

      wo ist das “UB_Uart_Init” ?!?
      und eine Pause in der While wäre auch keine schlechte Idee,
      so wird deine PC-Schnittstelle bombadiert mit Strings
      TIP : beginne mit einem funktionierendem Beispiel von hier
      (die sind alle getestet) und ändere es dann nach deinen wünschen
      Schritt für Schritt ab

14. MC.Einsteiger sagt:

    13. Juni 2014 um 01:13

    Danke für den Tip .Ich arbeite schon mit den Beispiele von hier alles läuft optimal nur das Beispiel 12-Uart Library ging bei mir nicht. die Verbindung steht schon mit Hterm aber es erfolgt keine Anzeige!!!!.

    • admin_ub sagt:

      13. Juni 2014 um 08:24

      wie schon geschrieben, meine Beispiele sind alle getestet, wenn du also das Demo_12 (ohne Änderungen !!) auf deine CPU programmierst musst du einen Fehler nur auf dem PC oder am Verbindungskabel suchen. Event. RX-TX vertauscht. Oder benutz statt H-Term mein PC-Terminal-Programm, da muss man gar nichts einstellen.

15. regnal sagt:

    8. Juli 2014 um 11:12

    Hi,
    Deine zahlreichen libs sind echt Klasse. Allerdings habe ich Probleme mit dieser UART lib hier. Leider bekomme ich auf keine Art und Weise ein Projekt zustande das daten vernünftigt sendet. Auch dein Beispielprojekt funktioniert nicht.
    Daten werden bei entsprechendem Funktionsaufruf zwar gesendet, allerdings Werte mit denen ich nichts anfangen kann. Der Hex Wert 0x01FF in dem Aufruf UB_Uart_SendByte(COM2, 0x01FF);
    hat zur Folge, dass in HTerm nur der Wert Null empfangen wird.
    Die Funktion:
    UB_Uart_SendByte(COM2, 0×000);
    hat dasselbe zur Folge.
    Leider weiß ich nicht wie man sich in deinem PC Programm die empfangenen daten anzeigen lässt. Aber es leuchtet die “LED” RxD oben rechts auf wenn das Board etwas sendet.
    Rufe ich die Funktion:
    UB_Uart_SendString(COM2, “h”, CR);
    auf, dann empfängt Hterm nur eine Folge von 0x1C, 0xE0 und 0×00.

    Also alles in allem wird etwas zur richtigen Zeit gesendet, aber was genau da verschickt wird, das verstehe ich einfach nicht.

    Für irgendeinen hilfreichen Tipp wäre ich dankbar.

    • admin_ub sagt:

      8. Juli 2014 um 12:18

      programmier das von mir compilierte HEX-File aus dem “debug/bin” Ordner…das läuft zu 100%, und such den Fehler bei Hterm bis das Beispiel funktioniert. Ist vermutlich die falsche Baudrate. Und “SendByte” sendet nur ein Byte und kein 16bit Wert. Bei meinem Terminal musst du unter “Receive File” die Endekennung auf “Timeout” stellen und den Haken bei “enable” dann werden alle empfangenen Bytes als Hex-Werte angezeigt.

      • gripper sagt:

        8. Juli 2014 um 17:26

        Problem gefunden und gelöst.
        Bzw. waren es zwei Probleme. An deinen Librarys lag es natürlich nicht.
        1. Komischerweise stimmte in meinem Projekt die Taktzahl Einstelllungen für das Board nicht…dann kann das mit den Baudraten auch nciht funktionieren
        Das war in deinem Beispiel natürlich korrekt…Aber
        2. Mein Serial – USB Converter für den Rechner wollte höhere Pegel haben….Das Problem hab ich dann gelöst indem ich einen Arduino zweckentfermdet habe indem ich Gnd direkt auf Reset gelegt habe und Tx vom STM32F4 direkt mit dem Tx Port vom Arduino verbunden habe (Rx ebenso). Dann hat man einen 1A Serial – USB Converter

        Danke auch für deine Schnelle Antwort!

16. Simon sagt:

    7. August 2014 um 17:31

    Hallo Zusammen .Braucht man für eine serielle Kommunikation mit dem PC einen Uart-TTL kabel oder erfolgt auch durch debugging/Programming USB.
    für eine schnelle Antwort wäre ich dankbar.

    • Cortex-Einsteiger sagt:

      9. August 2014 um 13:42

      ja, du brauchst ein RS232 Kabel und auch ein TTL Pegelwandler. Am einfachsten ist es aber, wenn du ein USB zu RS232 Adapter nimmst ( so groß wie ein usb Stick)

      Falls du es über USB machen willst, nicht über die Debugging Schnittstelle, dann musst du die USB-CDC Lib nehmen Nr. 31

      Die 3. Möglichkeit direkt über die Debuggingschnittstelle geht auch, allerdings gibt es hier soweit ich weiß keine Library zu, aber such mal nach “Semihosting” da wirst du finden wie es funktioniert.

      • Simon sagt:

        10. August 2014 um 14:36

        vielen Danke für die schnelle Antwort und Tipps

17. Jan sagt:

    24. August 2014 um 15:34

    Hallo,
    Ich möchte ein Signalwert in Dezimalzahl an die serielle Schnittstelle ausgeben. ich habe bis jetzt alles mögliches probiert aber ohne Erfolg.
    Es folgt nur die Ausgaben von Strings aber wenn ich z.B :
    signal = a+b;
    funktioniert das Senden mit dem Arduino über Serial.print(signal, DEC) ganz gut.
    aber senden mit dem stm32 über UB_Uart_SendByte(com3, signal) funktioniert nicht.
    weißt jemanden wie kann man sowas in stm32 realisieren.
    Gruß

    • admin_ub sagt:

      24. August 2014 um 16:22

      dann wandel die Dezimalzahl in einen String um
      
char string_buf[10];
sprintf(string_buf,"%d",zahlenwert);


      • Jan sagt:

        25. August 2014 um 21:18

        vielen Dank für die Antwort.
        mit sprintf habe ich es nicht hingekriegt .
        für ein einfaches Bespiel mit printf oder sprintf wäre ich sehr dankbar..

        • admin_ub sagt:

          26. August 2014 um 10:12

          Ich hab doch ein Beispiel geschrieben.
          Infos wie man eine Zahl in einen String wandelt gibts im Internet und in jedem C-Buch.
          Hier ist auch eine Library von mir : http://mikrocontroller.bplaced.net/wordpress/?page_id=3544

          • Jan sagt:

            26. August 2014 um 11:20

            das kenne ich schon aber in stm32f4 funktioniert bei mir nicht.

          • Jan sagt:

            26. August 2014 um 11:22

            vielen Dank jetzt funktioniert mit 75-String-Library.

18. Chris sagt:

    9. September 2014 um 13:28

    Hi,

    danke für die Lib, habe sie als Anregung benutzt um die UARTs auf einem STM32F103 zu benutzen.
    Dabei ist mir aufgefallen, dass deine Empfangsfunktion eingehende Zeichen einfach verwirft, wenn vorher ein \r empfangen wurde und man zwischenzeitlich nicht den empfangenen String abholt. D.h. man muss um nichts zu verpassen mindestens genauso schnell pollen, wie die Bytes ankommen. Das kann bei hohen Baudraten problematisch werden, wenn 2 oder mehr Strings ohne Pause direkt nacheinander ankommen. (Zumindest wenn der µC auch noch anderes zu tun hat)
    Wäre da nicht ein Ringpuffer zum Empfangen evtl. vorteilhafter, da man dann mehr Zeit zum Pollen hätte?

    lg
    Chris

    • admin_ub sagt:

      10. September 2014 um 09:22

      ja, du hast recht. Ein Ringpuffer ist schnell implementiert. Ich wollte es damals so einfach wie möglich halten (nur als Ausrede

    • admin_ub sagt:

      10. September 2014 um 18:18

      Bitte mal die Version 1.4 testen und bescheid geben ob Fehler oder OK.

19. Karl sagt:

    31. Mai 2015 um 17:29

    Hallo Uwe,
    vielen Dank für die Library.

    Eine Anmerkung die vielleicht einigen Hilft (betrifft STM32 U(S)ART generell): Wenn man das Parity Bit nutzen möchte (stm32_ub_uart.c) , dann muss die Wortlänge auf 9 Bit erhöht werden!
    z.B.
    USART_InitStructure.USART_Parity = USART_Parity_Even;
    USART_InitStructure.USART_WordLength = USART_WordLength_9b;

20. Cristian sagt:

    24. September 2015 um 23:45

    Hallo !!! Ich spreche aus Argentinien !! Ich fange an, die STM32F4 zu verwenden, und es ist alles mit Ihrer Bibliothek einfacher !!
    Ich teste dieses Beispiel, und es geschieht sehr selten. Verwenden Sie die USART3 (TX = PA2, RX = PA3), ohne die vorgenommenen Einstellungen (einer von ihnen: BAUD = 115200). Terminal-Programm in den Eingang Daten, aber 38.400 bpd, 115.200 bpd und nicht, wie in der STM32F4 konfiguriert. Was könnte passiert sein?

    Vielen Dank für alles !!
    Viele Grüße!

    • admin_ub sagt:

      26. September 2015 um 08:59

      check the PLL/Clock settings. Sysclock must be 168MHz.

21. Syed sagt:

    13. Oktober 2015 um 13:17

    Hi,
    I am using the USART6 for communication. The evaluation board is Devkit407. The problem with the program is that the transmission is fine but no reception and hence it does not go inside the loop in line 39(c-code above).

    Some changes i did for the USART6(COM1) are below:
    {COM1,RCC_APB2Periph_USART6,GPIO_AF_USART6,USART6,115200,USART6_IRQn, // UART2 mit 115200 Baud
    // PORT , PIN , Clock , Source
    {GPIOC,GPIO_Pin_6,RCC_AHB1Periph_GPIOC,GPIO_PinSource6}, // TX an PC6
    {GPIOC,GPIO_Pin_7,RCC_AHB1Periph_GPIOC,GPIO_PinSource7}}, // RX an PC7

    All seems fine but there is some problem which i cannot understand.

22. Syed sagt:

    20. Oktober 2015 um 12:37

    Hi Admin,

    Any idea why i cannot receive data through PC7 USART6 from PC but can send data to PC through PC6. I am using Devkit 407 board.
    I am stuck with this problem since a week. Need help.

    Regards,
    Syed

    • admin_ub sagt:

      23. Oktober 2015 um 17:53

      My uart library is waiting for an array of ascii-bytes
      with a termination character after the last byte
      (to detect the end of the string).
      The termination character is 0x0D (CarriageReturn)
      so your pc has to send a “CarriageReturn” at the end of the transmission.

      • Syed sagt:

        10. November 2015 um 14:25

        Thank you for your reply. The problem is solved now. I did the same as you mentioned in your comment.

Wie hat Dir dieser Artikel gefallen?

(Noch keine Bewertungen)

Loading...