Hallo,
danke für die Informationen. auf fork() war ich auch schon gestossen, jedoch habe ich es nicht angewendet, da in der Beschreibung stand, dass mein Programm als Kopie erneut geöffnet wird und auch alle Parameter soweit übernimmt. Da wusste ich dann nicht, ob dann evtl. die ganzen Routinen nochmals ausgeführt werden oder nicht. Meine Motivation es herauszufinden war gleich Null und so habe ich mich für (erstmal) 3 Programme entschieden, welche soweit prima zusammenarbeiten. Oder halt auch mein Programm in drei Teile geteilt, je nachdem, wie man es sehen möchte.

Wenn bei BASH am Ende das & quasi zu einem fork() macht, dann hätte mir das eh nicht weitergeholfen, da ich ja den Umweg über eine BASH ein Programm mittels & Parameter probiert habe, was das ursprüngliche Programm auch blockiert hat.

Die vom GCC compilierten Programme benötigen laut TOP etwas weniger CPU Rechenzeit. BASH wäre auch gegangen, aber das Empfangen über die UART hatte Probleme bereitet. Ich wollte ja solange Empfangen, bis ein CR erkannt wird und dann den String auswerten und nebenbei weiterempfangen. Das Problem am Raspi war, dass bei jedem öffnen der UART ein CHR(255) beim AVR ankam. Was für mich eher nach einem unkontrollieren PIN Zustand aussah.

Durch das C-Programm habe ich das Sympton nicht. Da kommt nur beim allerersten öffnen der ttyAMA0 ein CHR(255) am AVR an und der wird dann einfach ignoriert. Die Dateirechte gleich beim öffnen mit anzugeben, war auch eine meiner Ideen, jedoch die Suche im Netz nach den richtigen Parametern erfolglos. Und da ich bei jeder Suche nach ein paar erfolglosen Treffern keine Motivation zum Fortsetzen dieser habe, breche ich dann irgendwann diese ab, wenn ich schon einen Umweg im Hinterkopf habe.

Hauptsache es funktioniert so, wie ich es mir vorgestellt habe. Ob am Ende mein Programm gleich die Rechte setzt, oder diese Aufgabe an das System delegiert, ist mir dann egal. Hauptsache das php Script kann darauf zugreifen (und auch überschreiben, was aber nicht nötig ist, da der AVR eh jeweils die Änderung zurückmeldet). Denn wenn ich die Lichtfarbe über Fernbedienung per AVR ändere, soll halt im WebIf des Raspi diese auch tatsächlich angezeigt und natürlich auch geändert werden können.

Das parsen konnte ich wieder herausnehmen, denn meine Suche hatte ergeben, dass man "text\"text" in einem String verwenden soll, damit die Hochkommas angezeigt werden. Geholfen hatte dann tatsächlich aber "text 'text.

Hilfetexte und die Möglichkeit eine andere Schnittstelle und Baudrate per Parameter mit zu übergeben hatte ich erst geplant, dann aber wieder herausgenommen. Durch den veröffentlichten Code kann sich dann jeder selbst diese Werte anpassen.

Wobei der Code durchaus Kritikfähig sein kann, ich diese aber wenn, so wie du es gemacht hast, lieber hier bespreche als in dem Internetradio-Thema. Der dort veröffentlichte Quelltext hat bestimmt auch einige #Includes zuviel, meine Tests haben aber ergeben, dass GCC diese dann einfach nicht mit einbindet, da die fertigen Programme die selbe Größe hatte, wenn ich mal probehalber welche auskommentiert hatte.

Was wo in welcher Include zu finden ist, ist mir noch nicht so klar. Da bin ich aber schmerzfrei, wenn es am Ende funktioniert. Die von mir veröffentlichten Quellcodes sehe ich da eher als Inspiration an. Ich meine aber, bei meinen Ausflügen zu c++ etwas mehr Komfort gehabt zu haben. Da lassen sich z.B. Strings einfach per + verbinden, wenn ich mich richtig erinnere. Aber deswegen heisst es ja auch C++ und nicht mehr nur C.

C an sich mache ich nicht dafür verantwortlich. Eher die Vielfalt an doch recht ähnlichen Sprachen, wo ich das dann schon als Dialekt durchgehen lassen würde. Da ist es halt wie überall sonst auch. Jeder hat da seine eigenen Vorstellungen und auch im Programmieren bzw. der Entwicklung der Sprachen dazu ist Bewegung. Was durchaus Sinn macht, denn was ich für einen Webserver an Befehle benötige, brauche ich nicht unbedingt für eine Kaffeemaschine. Hätte ich damals nicht mit C64 Basic(V2), Amiga Basic/V7??), QBasic(V4??) und später Visual Basic (6 ist da mein Favorit) angefangen, sondern gleich mit C und Co, würde ich mich jetzt wohl schwer tun, VB Code an meine Bedürfnisse anzupassen.

Aber die Programme sind soweit fertig und jetzt geht es erstmal wieder an die Hardware. Die Soundqualität des analogen Anschlusses ist irgendwie nicht 100% HiFi tauglich. Jetzt teste ich erstmal die nächsten Tage über HDMI, wie da der Ton so ist und vor Allem, ob ein Bufferunderrun vorkommt, denn der Alsa Takt scheint minimal zu schnell zu sein, da der Buffer nach einiger Zeit leer läuft. Leider habe ich nirgends herausgefunden, wie ich diesen Takt beeinflussen kann. Selbst ein Underclocking nutzt nichts, da der Soundteil wohl separat getaktet wird und ich an diesen Takt einfach nicht rankomme. Da ist meine Hoffnung, dass digital übertragen der Empfänger für das Takten zuständig ist. Rauschen und die kleinen Knackser sind über HDMI jedenfalls nicht vorhanden. Leider kostet ein einfacher HDMI>Analog Adapter soviel wie der ganze Raspi. Es gibt noch einen für 19 EUR, dieser wird aber per HDMI gespeist, das möchte ich dem Raspi nicht antun.