Zitat von
HaWe
... - in alten libs muss man das selber patchen.
Genau deshalb sollte man diese Hardware Abhängigkeiten nicht in eine Bibliothek packen. Der Linux Kernel ist hier mit dem Devicetree schon recht modern aufgestellt. Das ist vielleicht für Anwendungen zu aufwändig aber Port Zuordnungen im Code festzulegen ist böösseeee ...
Das ist aber das gute an OpenSource wer das so möchte kann es so tun aber ich kann es anders machen.
Demnach würde wiringPi auf meinem Raspi unter Gentoo so nicht funktionieren. Ein guter Grund mehr warum die Entscheidung es nicht zu benutzen für mich richtig war.
Mit den verschiedenen Version hatte ich dann scheinbar einfach Glück das bei mir alles Kompatibel ist. Ich hatte bisher angenommen es lag daran das die Hardware Entwickler darauf geachtet hätten.
Das folgende ist ein früheres Experiment zu Software PWM. Das will ich noch in eine Klasse verpacken evtl. mit Unterstützung als Software Signal Generator. Dann könnte man Treppenspannungen, Sinus, Dreieck und Rechteck auch erzeugen. Die braucht man zum Entwickeln doch immer wieder mal. Die Frequenzen sind zwar nicht hoch aber die Software Kontrolle hat schon auch ihre Vorteile.
Code:
long timeOn = 1000;
long timeOff = 29000;
auto func = [&] ()
{
std::ofstream filePortValue ("/sys/class/gpio/GPIO11/value");
for (;;)
{
// Port ausschalten
strConfig = "0";
filePortValue << strConfig;
filePortValue.flush ();
// Zeit für "aus" abwarten
microSleep (timeOff);
// Port einschalten
strConfig = "1";
filePortValue << strConfig;
filePortValue.flush ();
// Zeit für "ein" abwarten
microSleep (timeOn);
}
filePortValue.close ();
};
std::thread t1 (func);
Zitieren
Lesezeichen