ARM-GCC FILE retarget

[Pascal H. (_pascal_)]

Hi

ich moechte ein FreeRTOSserialStream implementieren.
Dazu habe ich ein unter Keil lauffaehiges Beispiel bekommen.

Dort wird das struct FILE neu definiert. Leider scheint das der ARM-GCC 
compiler nicht zu moegen.

Ich muss das tun um in meiner fputc eine referenz zum jeweiligen objekt 
zu haben.

int fputc(int ch, FILE *f)
{

  int ret = EOF;

  switch(f->handle)
  {

  case FREERTOS_STREAM_HANDLE:

    FreeRTOS_IOStream_Putch( (FreeRTOS_IOStreamHandle*)(f->devicePtr), (uint8_t)ch, portMAX_DELAY);
    ret = ch;

    break;

  case STDOUT_HANDLE:
  case STDERR_HANDLE:
  default :

    LPC_UART0->THR = ch;
    while (!(LPC_UART0->LSR & (1U << 5)));

    ret = ch;

    break;

  }

  return ret ;

}

Hier noch ein minimal Beispiel was nicht zu funktionieren scheint

#include <stdio.h>

struct __FILE
{
    int handle;
    void* devicePtr;
};

enum
{
    STDIN_HANDLE,
    STDOUT_HANDLE,
    STDERR_HANDLE,
    FREERTOS_STREAM_HANDLE,
    DISPLAY_OUT
};

int main(void) {

  FILE __stdin = {STDIN_HANDLE, 0};
  FILE __stdout = {STDOUT_HANDLE, 0};
  FILE __stderr = {STDERR_HANDLE, 0};

  while(1){

  }

}

Ich bekomme immer die warnung
"initialization makes pointer from integer without a cast"

Das passiert weil

FILE __stdin = {STDIN_HANDLE, 0};

STDIN_HANDLE ein integer ist aber im originalen struct FILE das erste 
argument ein "unsigned char *_p" ist.

Koennt ihr mir sagen warum das so in Keil funktioniert aber im ARM-GCC 
nicht? Was muss ich abaendern?

Gruss und Danke :)

[Karl H. (kbuchegg)]

Pascal Heinrich schrieb:

> Koennt ihr mir sagen warum das so in Keil funktioniert aber im ARM-GCC
> nicht? Was muss ich abaendern?

Weil FILE eine 'private' Struktur der Implementierung ist und es eine 
ganze schlechte Idee ist, zu versuchen die neu zu definieren.

Denk dir was anderes aus, wie du den Klimmzug von einem FILE Pointer zu 
den Zusatzdaten die du brauchst, schaffst.
Du wandelst hier sowieso auf dünnem Eis. Denn diese Dinge sind extrem 
Implementierungsabhängig. Sprich, das macht sowieso jeder Compiler 
anders und du musst dir ansehen, welche Möglichkeiten dir der jeweilige 
Compiler/Run time System bietet. Das sind Dinge, in die man ohne 
zumindest rudimentär intime Kentnisse des vorgegebenen I/O Systems nicht 
eingreift. Ein Beispiel, das für einen anderen Compiler geschrieben 
wurde, kann dir höchstens zeigen, was eigentlich das Ziel wäre. Aber 
ansonsten kannst du da wenig damit anfangen. Der dahinter stehende 
Mechanismus kann völlig anders aussehen. Auf eine gcc für AVR 
funktioniert das zb völlig anders, wie man dem I/O System neue 
Funktionen für den Low-Level I/O Zugriff unterjubelt.

[Markus F. (mfro)]

Ich muß vorausschicken, daß ich von FreeRTOS nur sehr rudimentäre 
Vorstellungen habe.

Dein Problem ist kein gcc-Problem, sondern ein Problem der verwendeten 
C-Library (was immer Du da hast, newlib?).

Völlig unabhängig davon: FILE umdefinieren zu wollen, ist 
höchstwahrscheinlich alles mögliche, bloß keine gute Idee (zumindest, 
wenn das I/O-Subsystem so funktioniert, wie ich mir das vorstelle).

Die Entwickler haben sich alle Mühe gegeben, FILE als opaque Struktur zu 
definieren, so daß sie "dahinter" treiben können, was sie wollen. 
Sprich: wie's da drin aussieht, geht dich nix an. Daran fummeln zu 
wollen, führt nur zu Problemen.

Wenn Du deiner C-Library einen neuen Gerätetyp unterjubeln willst (so 
habe ich deine Frage zumindest verstanden), solltest Du das eine Ebene 
"unter" stdio tun. Newlib beispielsweise stellt dazu als einheitliche 
Schnittstelle den devoptab_t Strukturtyp zur Verfügung, mit dem man der 
Library "I/O-Treiber" zur Verfügung stellen kann. Welche der Strukturen 
dann stdin, stdout und stderr bedient, wird dann der Library in einer 
struct __reent-Variable mitgeteilt, damit können unterschiedliche Tasks 
dann sogar unterschiedliche I/O-Treiber für die Standardkanäle benutzen.

[Pascal H. (_pascal_)]

Danke fuer Eure Antworten :)

Ja das neu Definieren von FILE ist dann wahrscheinlich nicht die beste 
Idee. Der Keil compiler macht das anscheinend mit.

Im Grunde will ich eingeltich nur zum Zeitpunkt von "_write" eine 
Referenz zu einem bestimmten Output Kanal herstellen ( zB. UART0, UART1 
oder einer RTOS queue). Das wurde in dem Beispiel welches ich bekommen 
habe dadurch geloest FILE so umzudefinieren dass es eig gar kein FILE in 
dem Sinne mehr ist sondern einfach ein Struct mit einem int und einem 
void*.

Das mit dem reent und devoptab_t werde ich mir mal naeher ansehen 
muessen.

Als workaround habe ich im Moment einfach selbst Funktionen definiert 
(serialStreamPutc, serialStreamPuts, serialStreamGetc ...) welche ich 
mit einem von mir definierten FreeRtosStreamHandle aufrufen kann -> 
newlib printf usw wird gar nicht benutzt.

Jetzt habe ich aber noch eine Frage zur verwendeten C-Library.

Woher weis ich welche ich eigentlich benutze? Klar ich verwende den 
arm-none-eabi-gcc als compiler (toolchain). Wenn ich mir den Linker 
Command anschaue steht da nirgendwo etwas von einer libc.a oder 
irgendeiner anderen lib. Es werden nur meine .o Dateinen gelinkt.