[C++ Embedded omgeving] Logging systeem

[liquid_ice]

Ik ben met een embedded C++ applicatie op Linux hardware bezig. Ik moet dus rekening houden met de beperkte processor kracht en geheugen.
Hierom is er in het project gekozen om geen BOOST en STL te gebruiken (Wat ik erg jammer vind).

Ik heb een simulatie onder Windows, waar ik zoveel mogelijk gebruikt van maak vanwege de goede debug mogelijkheden van Visual studio. Ondanks dit merk ik nog teveel dat er problemen ontstaan als ik op de echte hardware draai.
Ik kan dan met een seriele verbinding inloggen, en de output van m'n prints bekijken...

Hier begint het probleem ook.
Of je hebt te weinig prints en je ziet nooit iets, of je hebt teveel prints en je word bedolven onder de prints. Je bent altijd bezig om prints tijdelijk toe te voegen en te verwijderen.

Waar ik naar opzoek ben is een logging systeem, dat in het meest ideale geval:

• Gemakkelijk in gebruik is.
• compile time loggings aan en uit gezet kunnen worden (Denk aan communicatie loggings, scheduler loggings en misschien per class nog specifieke loggings)
• Geen processor overhead levert, of zo min mogelijk in elk geval.

Nou kan ik helemaal zelf het wiel gaan uitvinden, maar zulke systemen moeten er toch al bestaan?

Ik heb met google gezocht, en dan kom ik vanalles tegen, maar dan heb ik nog geen idee wat past, overkill is of niet flexibel genoeg is.

Luxe als run-time setting en backwards logging ophalen enz. enz. mag altijd, als het maar niet teveel cpu of mem verbruikt, want dat hebben we niet onbeperkt

[ Voor 4% gewijzigd door liquid_ice op 15-04-2008 04:22 ]

[RobIII]

liquid_ice schreef op dinsdag 15 april 2008 @ 03:42:
Ik heb met google gezocht, en dan kom ik vanalles tegen, maar dan heb ik nog geen idee wat past, overkill is of niet flexibel genoeg is.

Dan ben ik toch erg benieuwd naar wat "vanalles" precies is, en op basis waarvan je dat 'afgeschoten' hebt of op basis waarvan je zelf al gezien had of het misschien overkill of niet flexibel genoeg was. Je kwantificeert nu 'overkill' of 'flexibel genoeg' namelijk niet en wij kunnen ook niet ruiken wat je 'overkill' of 'flexibel genoeg' vindt.

liquid_ice schreef op dinsdag 15 april 2008 @ 03:42:
Luxe mag altijd, als het maar niet teveel cpu of mem verbruikt, want dat hebben we niet onbeperkt

Wat is 'teveel cpu' of 'teveel mem'? 16k? 1024k? 800 bytes? 1000 cycles? 20ms?

[ Voor 19% gewijzigd door RobIII op 15-04-2008 03:50 ]

[liquid_ice]

Nee, dat snap ik.
wat is vanalles, nou bijv. dit http://www.google.nl/sear...l&q=logging+c%2B%2B&meta=

En het is niet zo dat ik alles afgeschoten heb, maar van veel systemen die ik tegen kom weet ik niet hoe groot, omslachtig, klein of whatever ze zijn.
Daarvoor ben ik hier, om een stukje ervaring op dat gebied te kunnen benutten en advies is te winnen.

en ik heb ook geen harde rand waarde voor cpu en max mem verbruik. Maar ik zet het erbij omdat een logging mechanisme voor een super-cluster met alle mogelijke opties en features, waarschijnlijk iets anders is dan voor een embedded systeempje.

[ Voor 24% gewijzigd door liquid_ice op 15-04-2008 04:04 ]

[Exirion]

Allereerst: volkomen terecht dat ze afzien van BOOST en STL. Sowieso is C++ op een embedded platform met beperkte caching en bandbreedte al wat zwakker dan C.

Verder: printf is your friend. Ik doe zelf niet anders dan implementeren en debuggen met feedback via printf. Soms gdb als een crash moeilijker te herleiden is (zeker als er veel meegecompileerde dependencies zijn). Wat je kunt doen om het allemaal wat flexibeler te maken is werken met debug levels en macro's die wel of niet iets printen afhankelijk van de ingestelde debug level. Daarmee voorkom je een stortvloed van output als je die niet nodig hebt.

[liquid_ice]

Exerion, dat klinkt zeker wel interesant.

Maar zulke opstellingen zijn toch al wel honderd keer gemaakt, zo iets moet toch wel ergens te vinden zijn lijkt me ?

Daarbij, is cout niet veel sneller dan printf?
Dacht altijd dat dat erg sloom was

[ Voor 20% gewijzigd door liquid_ice op 15-04-2008 09:46 ]

[Exirion]

liquid_ice schreef op dinsdag 15 april 2008 @ 09:43:
Maar zulke opstellingen zijn toch al wel honderd keer gemaakt, zo iets moet toch wel ergens te vinden zijn lijkt me ?

Even met Google:

http://www.oopweb.com/CPP...PP/Volume/techniques.html

"printf debugging"

Daarbij, is cout niet veel sneller dan printf?
Dacht altijd dat dat erg sloom was

Waar haal je dat vandaan? Er zijn implementaties van printf die langzamer zijn dan sommige implementaties van cout, net zoals er dingen bestaan die in Java sneller kunnen zijn dan in C, maar in het algemeen zijn de C-varianten van functies juist sneller. Zo ook met printf vs cout, maar laten we die discussie verder maar achterwege laten

[MSalters]

Hoewel C soms (niet vaak) sneller is, is printf tegen cout zelden fair voor C. printf moet feitelijk at runtime de format string compileren. cout<<(float) is al tijdens compile time geresolved.

[H!GHGuY]

Wij werken ook embedded en gebruiken wel STL en een subset van boost. STL en boost staan orthogonaal op memory usage. De enige vereiste is dat elke developer weet wat hij doet.

We zijn qua geheugen niet echt zwaar gelimiteerd (hoewel we toch met mem usage bezig zijn) en ook de processor is niet helemaal low-end, maar het is niet zo dat embedded meteen gelijk staat aan 'no fancy features'.

Waarom gebruik je syslog niet? Je kunt per facility een file (al dan niet op ramdisk) specifieren. Met logrotate ernaast maak je dat de boel binnen de perken blijft.
Je kan zelfs naar een extern toestel loggen over UDP.

C:

const int MODULE_A = 0;
const int MODULE_B = 1;
const int MODULE_C = 2;

const int NR_MODULES = MODULES_C + 1;

int logfacilities[NR_MODULES];

const int LOGDEBUG = 1;
const int LOGTRACE = 2;
const int LOGERROR = 4;

#define TRACE(MODULE, LEVEL, STR, ...) do { if (logfacilities[MODULES] | LEVEL) syslog(LOG_INFO, STR, __VA_ARGS__); } while (0)
#define DEBUG(MODULE, LEVEL, STR, ...) do { if (logfacilities[MODULES] | LEVEL) syslog(LOG_DEBUG, STR, __VA_ARGS__); } while (0)
// etc

void logmodule_init()
{
   // doe hier openlog()
}

void logmodule_exit()
{
  // doe hier closelog()
}

Thread-safety is waarschijnlijk (afh van platform) een non-issue aangezien ints gelezen worden.
Deze constructie is bovendien performant a ratio van 1 if statement per loglijn in het geval niet gelogged wordt. Typisch kun je een MustLog(...)/DoLog(...) implementeren en gebruiken in de macro en later kun je met deze beide doen wat je wil.