FreeRtos/Newlib nano /Printf /mutex

[Root (Gast)]

Hallo,

ich muss eine bestehende Software portieren. Verwendet wird jetzt der 
GCC Compiler und ein STM32L431. Es laufen zwei Tasks die gelegentlich 
per Printf ausgaben machen.
Jetzt sehen aber die Ausgaben auf der Schnittstelle aus wie ein Mix aus 
beiden Tasks.
Die Frage ist nun wie ich den Printf bei der NewLib Nano dahin bekomme 
einen zusätzlichen mutex zu verwenden.
Sowas in der Art:

void __printf_lock()
   {
   xSemaphoreTake(xSemaphorePrintf, PRINTF_TIMEOUT);  
   }
void __printf_unlock()
   {
   xSemaphoreGive(xSemaphorePrintf);
   }

[Emma (Gast)]

Wo ist nun die Frage?

[Nop (Gast)]

Root schrieb:

> Die Frage ist nun wie ich den Printf bei der NewLib Nano dahin bekomme
> einen zusätzlichen mutex zu verwenden.

Indem Du das beim printf der nanolib einbaust und sie neu compilierst. 
Einfacher und wahrscheinlich auch sinnvoller wäre es aber wohl, das bei 
den Tasks zu machen.

[Root (Gast)]

Naja ich wollte eher an einer zentralen Stelle eingreifen und auch nicht 
die min neu combilieren. Gibt es denn da keine Lösung oder eine 
Alternative zur Newlib nano die sowas bietet? Die min von crossworks 
haben sowas eingebaut. Aber von denen will man weg portieren

[Root (Gast)]

... die Lib neu ....

[Felix F. (wiesel8)]

Schreib dir einen Wrapper.

void My_printf(...)
{
    Get_mutex();
    printf(...);
    Release_mutex();
}

mfg

[Johannes S. (Gast)]

Der gcc hat einen Mechanismus um Libfunktionen durch Wrapper zu 
ersetzen, dazu gibt es eine Linkeroption und die heisst sogar so wie man 
es vermuten könnte: '--wrap=printf'.
Dazu gibt es eine Aufrufkonvention um an die originale Funktion zu 
kommen.

Hier ist ein Beispiel aus der mbed lib für malloc wrapper:
https://github.com/ARMmbed/mbed-os/blob/master/platform/mbed_alloc_wrappers.cpp

Umgebogen werden die mit den Linkeroptionen:
--wrap=_malloc_r
--wrap=_free_r
--wrap=_realloc_r
--wrap=_memalign_r
--wrap=_calloc_r

Bei den Unterstrichen muss man genau zählen, das basiert alles auf 
Konventionen. Und die Aufrufreihenfolge der Libs und objs beim Linker 
ist wichtig, da bekommt man schnell unresolved Fehler. Aber wenn man es 
richtig macht funktioniert es :-)

[Chlorotroll (Gast)]

Es ist schon schlechtes Design zwei Tasks printen zu lassen...

[Nop (Gast)]

Chlorotroll schrieb:
> Es ist schon schlechtes Design zwei Tasks printen zu lassen...

Nö, eigentlich nicht. Für Debug-Ausgaben ist das ganz OK. Ist halt nur 
doof, wenn der Scheduler einen unterbricht.

Eventuell wär's ja auch schon ausreichend, printf auf unbuffered zu 
stellen.

[Uli (Gast)]

Per MSG Daten an einen Ausgabe Threat senden und der ist dann der 
einzige der die SIO benutzt, gilt auch für die andere Richtung.
Das ist dann eine saubere Sache und man kann dann unentlich viele Task 
als sender einbauen.
Nur irgentwann ist die Queue halt voll und auch 115.200 können nicht 
zaubern.

[Root (Gast)]

Vielen Dank für die Vorschläge. Sind sicher auch brauchbar. Aber im 1. 
Schritt soll die SW halt "nur" portiert werden.

Und gerade dabei sind Debug Ausgaben via Printf nicht schlecht ....

Deshalb werd ich mir das mit dem "wrap"pen mal anschauen.

Theoritisch müsste ich ja puts auch entsprechend nachbearbeiten oder 
gibt es eine Funktion die von beiden (printf, puts) gemeinsam benutzt 
wird?