arm-gcc, newlib und iostreams

[Tobias P. (hubertus)]

Hallo zusammen

ich verwende den arm-none-eabi-gcc um mein Programm zu kompilieren für 
meinen STM32F407. Ich benutze streams für Input und Output auf 
verschiedenen UARTs.
Konkret habe ich den stdout, stdin und stderr auf dem UART1, sodass bei 
der Verwendung von printf() und Konsorten eine Ausgabe von Text über den 
UART1 passiert. Soweit so gut. Das geschieht über die read() und write() 
Syscalls:

_ssize_t _write_r(struct _reent *r, int file, const void *ptr, size_t len)
{
  switch(file)
  {
    case STDOUT_FILENO:
    case STDERR_FILENO:
    {
      const unsigned char *p = (const unsigned char*)ptr;
      for(int i = 0; i < len; i++)
      {
        if(*p == '\n')
        {
          txchar('\r');
        }
        txchar(*p++);
      }
      return len;
    }

    default:
    {
      r->_errno = EBADF;
      return -1;
    }
  }
}

_ssize_t _read_r(struct _reent *r, int file, void *ptr, size_t len)
{
  switch(file)
  {
    case STDIN_FILENO:
    {
      extern int kbhit(void);
      int numread;
      char* dest = (char*)ptr;

      for(numread = 0; numread < len; numread++)
      {
        int rxchar = kbhit();
        if(rxchar >= 0)
        {
          dest[numread] = (char)rxchar;
        }
        else
        {
          r->_errno = EIO;
        }
        break;
      }
      return numread;
    }

    default:
    {
      r->_errno = EBADF;
      return -1;
    }
  }
  return 0;
}

Jetzt möchte ich aber auf dem UART2 ebenfalls Daten ausgeben, und dazu 
wenn möglich auch die C Standardfunktionen nutzen. Ich habe das jetzt 
wie folgt gelöst:

FILE* uart2 = fdopen(UART2_FD, "w");
setvbuf(uart2, NULL, _IONBF, 0);
fprintf(uart2, "This message goes to UART2");
printf("This message goes to UART1");

die write()-Funktion habe ich entsprechend angepasst:

_ssize_t _write_r(struct _reent *r, int file, const void *ptr, size_t len)
{
  switch(file)
  {
    case STDOUT_FILENO:
    case STDERR_FILENO:
    {
      const unsigned char *p = (const unsigned char*)ptr;
      for(int i = 0; i < len; i++)
      {
        if(*p == '\n')
        {
          txchar('\r');
        }
        txchar(*p++);
      }
      return len;
    }

    case UART2_FD:
    {
      return uart2_tx(ptr, len);
    }

    default:
    {
      r->_errno = EBADF;
      return -1;
    }
  }
}

Das funktioniert wunderbar, aber es würde mich interessieren ob meine 
Vorgehensweise mit fdopen() richtig ist, oder ob man das anders machen 
muss. Wie macht man es "richtig" ?

[Bauform B. (bauformb)]

Tobias P. schrieb:
> wenn möglich auch die C Standardfunktionen nutzen

Dann möchte man das ja so schreiben können

FILE* uart2 = fopen("/dev/usart2", "w");

was ja praktisch das gleiche ist wie

int  uart2_fd = open ("/dev/usart2", O_WRONLY, 0);
FILE *uart2 = fdopen (uart2_fd, "w");

Normalerweise wird dabei fd vom open() fortlaufend vergeben, kann also 
nicht konstant sein. Aber man soll es ja nicht übertreiben. Genauso gut 
kann open() einfach den Devicenamen 1:1 zu einem festen fd mappen.

Die UARTs müssen in jedem Fall initialisiert werden, also brauchst du 
immer irgendwo irgendeine Art von open(). Der Mehraufwand für ein 
"echtes" open() scheint mir nicht allzu groß zu sein, nur ein paar 
strcmp und das passende int abliefern. Dafür kann man dann ganz normal 
fopen() statt fdopen() benutzen. Ein Bayer würde sagen "G'scheit oder 
garnicht" ;)

Was mich mehr irritiert ist die total unterschiedliche Behandlung von 
UART1 und UART2 im write(). Mit einem Pointer auf USART1 oder eben 
USART2 könnte der ganze Rest für beide komplett identisch sein. 
Einfaches Senden und Empfangen funktioniert für alle UART, USART und 
LPUART gleich.

[Tobias P. (hubertus)]

Hallo,

Bauform B. schrieb:
> Was mich mehr irritiert ist die total unterschiedliche Behandlung von
> UART1 und UART2 im write(). Mit einem Pointer auf USART1 oder eben
> USART2 könnte der ganze Rest für beide komplett identisch sein.
> Einfaches Senden und Empfangen funktioniert für alle UART, USART und
> LPUART gleich.

da hast du natürlich vollkommen recht und das ist auch so angedacht. 
Mein Code ist im Moment noch nicht komplett auf einem sauberen Stand: 
ich arbeite immernoch an einem GPSDO, mit dessen Software ich vor ca. 2 
Jahren begonnen habe, daher sind da noch alte Sachen drin.

Ich frage mich grade, ob z.B. die Initialisierung von stdout vielleicht 
noch besser so zu lösen wäre, dass der zugehörige UART mittels einer 
Funktion mit

__attribute__((constructor))

gelöst werden sollte. Dann sind nämlich stdin und stdout schon bereit, 
bevor main() startet.
Oder wie würdest du denn stdout behandeln? denn da geht die C-Umgebung 
ja einfach davon aus, dass es "funktioniert" und nicht erst noch 
initialisiert werden muss. Wenn aber stdout über einen UART gehen soll, 
muss man da sehr wohl zuerst noch einiges initialisieren.

[Bauform B. (bauformb)]

Tobias P. schrieb:
> Ich frage mich grade, ob z.B. die Initialisierung von stdout vielleicht
> noch besser so zu lösen wäre, dass der zugehörige UART mittels einer
> Funktion mit __attribute__((constructor))
> gelöst werden sollte. Dann sind nämlich stdin und stdout schon bereit,
> bevor main() startet.

Muss man sich überhaupt darum kümmern? Das muss doch alles von newlib, 
libgloss, gcc, libgcc erledigt werden. Oder stelle ich mir das viel zu 
einfach vor?

Für C++ müssen vor main() so viele Dinge richtig zusammen spielen, dass 
ich mich strikt an die Gebrauchsanweisung der newlib halten würde. 
Demnach muss man doch nur ein paar genau definierte syscalls¹ wie open() 
und write() bereit stellen und sonst nichts. Und auf der Ebene muss doch 
auch ANSI-C ausreichen, also write() statt write_r()?

Für stdout wird dieses open() (hoffentlich) von einer lib vor main() 
aufgerufen und initialisiert daraufhin UART1. Später kann man es genauso 
für UART2 usw. benutzen.

Dieses open() muss ziemlich viel Hardware initialisieren. Das UART läuft 
dann mit 9600, 8N1 mit dem Takt vom HSI16. Die Umschaltung auf einen 
anderen Takt wird ja traditionell erst in main() gemacht. Danach stimmt 
dann die Baudrate nicht mehr, aber die muss ja sowieso mit ioctl() o.ä. 
einstellbar sein.


1) https://sourceware.org/newlib/libc.html#Syscalls

[Tobias P. (hubertus)]

Bauform B. schrieb:
> Muss man sich überhaupt darum kümmern? Das muss doch alles von newlib,
> libgloss, gcc, libgcc erledigt werden. Oder stelle ich mir das viel zu
> einfach vor?

Funktionen, die du mit __attribute__((constructor)) kennzeichnest, 
werden (korrektes Linkerscript vorausgesetzt) in das preinit_array rein 
geschrieben. Der Startupcode, welcher für die Newlib nötig ist, muss vor 
dem Aufruf von main() schauen, ob es im preinit_array Einträge drin hat, 
und wenn ja, muss er die alle aufrufen. Das geschieht über die funktion 
__libc_init_array(). Wenn du einen UART initialisieren willst, dann 
kannst du entweder die Initialisierungsroutine aus main() heraus 
aufrufen, oder sie als constructor deklarieren, dann wird sie 
automatisch aufgerufen, bevor main() dran kommt. Oder, eben, wie du 
sagst, man könnte die Initialisierung auch im open() Aufruf machen.

Bauform B. schrieb:
> Für C++ müssen vor main() so viele Dinge richtig zusammen spielen, dass
> ich mich strikt an die Gebrauchsanweisung der newlib halten würde.

Wo findet man die eigentlich? was man vor main() alles aufrufen muss, 
und wie und welche Daten kopiert oder auf 0 gesetzt werden müssen und 
welche Sektionen es im Linkerscript dafür alle braucht, habe ich mir 
mühsam zusammen suchen müssen, ich habe nirgends an einer zentralen 
Stelle eine gute Dokumentation dazu gefunden. Ich habe aber das mit C++ 
begonnen genauer anzuschauen und teste grade einen C++ Code auf dem 
STM32. Konstruktoren, Destruktoren, globale Instanzen von Klassen, das 
alles funktioniert bisher gut, aber nur wenn man vor main() die 
__libc_init_array aufruft. Ob man noch mehr tun muss, weiss ich nicht.

Bauform B. schrieb:
> Und auf der Ebene muss doch
> auch ANSI-C ausreichen, also write() statt write_r()?

Soweit ich das herausgefunden habe bisher ist write_r nur eine Kapselung 
von write, und die C-Library ruft auf jeden Fall write_r auf. Wenn man 
das mit einem RTOS verwenden möchte, ist das glaube ich keine dumme 
Idee, aber sicher weiss ich es eben auch nicht.

[Bauform B. (bauformb)]

Tobias P. schrieb:
> Wo findet man die eigentlich? was man vor main() alles aufrufen muss,
> und wie und welche Daten kopiert oder auf 0 gesetzt werden müssen...

Naja, wozu Dokumentation schreiben, wenn es kaum einen interessiert ;) 
Die Linker-Scripte, die ich so gefunden habe, sehen auch alle genauso 
aus.

> Ich habe aber das mit C++ begonnen genauer anzuschauen und teste
> grade einen C++ Code auf dem STM32. Konstruktoren, Destruktoren,
> globale Instanzen von Klassen, das alles funktioniert bisher gut

Wahnsinn, ich bin schon froh, dass ich es für simples C ansatzweise 
verstanden habe.

Tobias P. schrieb:
> Bauform B. schrieb:
>> Und auf der Ebene muss doch
>> auch ANSI-C ausreichen, also write() statt write_r()?
>
> Soweit ich das herausgefunden habe bisher ist write_r nur eine Kapselung
> von write, und die C-Library ruft auf jeden Fall write_r auf.

Ich glaube auch; die libc braucht das für Threads, aber der syscall ganz 
innen drin darf ein einfaches write() sein.

> Wenn man das mit einem RTOS verwenden möchte, ist das glaube ich
> keine dumme Idee, aber sicher weiss ich es eben auch nicht.

Kommt drauf an, ob man fette Prozesse oder schlanke Threads mag. Mit 
genug RAM und einem "richtigen" RTOS hat jeder Prozess sein eigenes RAM 
(stack, data, bss). Dann kann man eine libc ohne Threads und ohne die _r 
Funktionen benutzen. Umgekehrt braucht man kein RTOS. Und Mittelwege 
sind auch noch denkbar.