ZitierenHabe mal was in Richtung PWM gemacht leider kein OSSI da um zu gucken. Gefühlt dreht der Lüfter unterschiedlich schnell.
das C schnell als C++ habe ich nie gesagt. Und ich finde es Ok wenn C Programmierer weiterhin C machen auch das wurde Modernisiert und besser guten C Code als schlechter C++ Code.
Das die Spracherkennung Zuhause Funktioniert und nicht auf dem Gerät ist klar hat aber weniger den Grund der Rechenleistung der Mobileingeräte. Wobei wir hier noch das Thema alt Geräte ins Feld führen könnte.
Schon mal Probiert ein Modernes Smartphone mit 8 Kernen wirklich aus zu lasten und dabei in der Hand zu halten ? Auch der Akku hält das nicht lange durch.
Aber wir kommen zu Weit vom Thema ab. Versuchen wir unsere Software zu unseren Bedingungen zu machen und so die Welt ein bisschen besser. Nur rum Kriteln bringt uns alle nicht weiter.
Das einzige was mir echt zu denken gibt ist das Thema keine Zeit um Software machen zwar gibt es in immer mehr Sachen Software aber bei der Entwicklung wird 0 Zeit für die Software eingeplant. Software ist ja oft nur
Gentoo auf dem PI finde ich echt heftig den das Kompilieren auf der SD Karte mach doch nicht wirklich Spaß wie viele Karten hast du schon durch ?
Ich finde Debian schon ganz Ok und ich habe das auf Desktop und PI dann klappt es ganz gut mit dem Transfer der Software. Desktop Testen und dann auf den PI Portieren so weit nötig. Wobei ich fast nix habe was bis dato Portiert werden musste. Neu Compilieren natürlich.
P: Meine Tochter (06.11.07) und https://www.carnine.de
M: Träumen hat nix mit Dummheit zu tun es ist die Möglichkeit neues zu erdenken
Habe mal was in Richtung PWM gemacht leider kein OSSI da um zu gucken. Gefühlt dreht der Lüfter unterschiedlich schnell.
P: Meine Tochter (06.11.07) und https://www.carnine.de
M: Träumen hat nix mit Dummheit zu tun es ist die Möglichkeit neues zu erdenken
ich meinte es anders:Genau deshalb sollte man diese Hardware Abhängigkeiten nicht in eine Bibliothek packen.... - in alten libs muss man das selber patchen.
dir wird gar nichts anderes übrig bleiben, als es ebenso zu machen wie wiriningPi, denn es haben sich ja nun mal die GPIO-Nummern teilweise verändert, und der dev tree ebenfalls für die herausgeführten UART-GPIOs (z.B. der UART "Pfad" /devAMA0 ist ja nicht mehr wie früher auf den GPIOs, sondern wird ab Pi3 intern für BT verwendet - die GPIO UART heißen jetzt anders). wiringPi als lib prüft ja intern automatisch auf die aktuelle Hardware und die OS-Version, und kmpiliert dann entspr. abhängig.
Auch I2C0 und I2C1 haben eine Änderung erfahren von Pi A bis hin zum B+ design.
Wenn du also für verschiedene Pi-Plattformen kompilierst, muss du irgendwo in deinem Code die boardabhängigen dev Pfade reinschreiben, einmal so, und einmal so. Und für andere Plattformen wie BPi oder BBB oder gar Linux-PCs ebenso, erst recht.
Die SD-Karten sind von Samsung und haben damit kein Problem. Für große Sachen ist der Raspi beim compilieren schon ein bisschen langsam. Würde man große Programme darauf Entwickeln ist das Störend aber so nicht der macht das ja alleine muss ich nicht darauf warten.
Ja man kann ein Smartphone mit 8 Kernen in der Hand halten ohne Brandblasen zu bekommen. Es wird deutlich warm das schon mehr nicht weil die CPU die Notbremse zieht wenn es zu warm wird. Sprache erkennen können die trotzdem. Braucht Strom keine Frage aber man braucht die ja nicht andauernd. Wäre aber immer noch besser als das ganze Leben an Ami Konzerne zu streamen.
Software PWM kann man vielleicht leichter Testen wenn man eine LED an den Port klemmt. Ich glaube Mensch erkennt Helligkeitsunterschiede leichter als Drehzahlunterschiede. Kann auch sein das die Frequenz für einen Motor zu hoch ist. Du musst ja drei Sachen einstellen die Grundfrequenz und das Tastverhältnis also ton/toff. Bei Software PWM stellt man das alles halt mit den Wartezeiten ein. Bei Hardware PWM wird die Frequenz ja aus dem Takt und dem gewählten Teileverhältnis eingestellt. Motore haben mit zu hohen Frequenzen Problem wegen der hohen Mechanischen Trägheit.
Zum Thema dev Pfade man kann es auch einfach in die Konfig packen für mich hat das nichts im Code zu suchen. Klar der Benutzer muss ein Gewisses Technisches Verständnis dann mit bringen aber mit Sample Config sollte es klappen. Warum sollte ich jemanden vorschreiben das die GPS Mouse an /dev/AMA0 hängen muss. Er könnte auch eine USB benutzen und dann heißt der Dev port anders.
Das mit der LED muss ich mal überlegen Thema ist halt die Belastung vom PIN.
Warum drei Werte vom PWM ja es sind 3 das richtig aber ich brauche ja nur 2 der Dritte ergibt sich immer. Mein source mach es so: Hz und ein wert zwischen 1 und 1000 damit stellst du die On Zeit ein in 0.1 % bis 100.0 % wenn ich meine Log Ausgaben trauen kann passt das dann auch. Vielleicht hat ein Bekannter auch mal Zeit würde mich schon Interessieren wie das auf dem OSSI aussieht was ich da mache.
Was ich auf jeden Fall noch ansehen muss ist das Thema CPU last das habe ich ganz vergessen.
P: Meine Tochter (06.11.07) und https://www.carnine.de
M: Träumen hat nix mit Dummheit zu tun es ist die Möglichkeit neues zu erdenken
Logisch man muss das irgendwo einstellen wo welche Devicefiles zu finden sind. Nur wie schon oben geschrieben darf einem die Bibliothek nicht aufzwingen. Welcher Port, Timer oder Wandler was tut. Das ist Sache der Anwendung nur die kann wissen wie es am besten gemacht werden soll. Um es dem Anwender leichter zu machen kann man ja für alle unterstützten Platinchen eine Beispiel Konfiguration mit dazu geben. Die Bibliothek kann auch der Anwendung eine Funktion zum verarbeiten der Konfig mit liefern. Dann muss der Anwender kaum mehr tun und es ist trotzdem unter seiner Kontrolle welcher Port was tut.
Es ist so merkwürdig Raspi und Co wurden ja in erster Linie für die Ausbildung geschaffen. Das die ganzen Bastler die Dinger in Stückzahlen verbauen die keine Industrie zusammen bekommt war nie vorgesehen. Von dem Standpunkt ist es sogar schlecht wenn die Bibliothek alle Hardware Besonderheiten zu verbergen versucht. Jemand der Lernen will wie das Funktioniert und wie man es Anwendet muss schon mit bekommen wo die Hacken sind sonst ist die Ausbildung nicht vollständig.
Du hast doch einen Lüfter wie auch immer über den Port geschaltet dann kannst Du mit einem entsprechendem Vorwiderstand eine LED statt dem Lüfter anklemmen. Eine kleine Glühlampe aus einer Taschenlampe oder ähnlichem würde am Lüfteranschluss auch funktionieren. Eine LED ist aber mit einem passendem Vorwiderstand normal auch direkt an einem Port kein Problem. Du kannst den Widerstand aber einfach ein bisschen größer wählen dann wird die LED zwar nicht mit maximaler Helligkeit leuchten aber das ist zum testen auch nicht nötig. Sollte man dann halt in nicht zu heller Umgebung machen den Test.
CPU Last ist ja unter Linux leicht zu beobachten mit "top" zum Beispiel.
Die gesamte Last kann man mit "time ls" das zeigt dann vom ls die verbrauchte Rechenzeit an.
Ok jetzt müsste man definieren wo Lib und so anfängt und aufhört Natürlich wäre es falsch bzw komisch wenn jetzt zur Lib noch eine Konfig gibt. Da gehört es in den Lib aufruf. Ich hatte schon gedacht das das Nutzende Programm die werte weiter gibt. Schluss endlich sieht man das ja auch am Construtor deiner/meiner Klasse das hier der Pfad übergeben wird. Aber hier jetzt auch noch über "gutes" Design einer API zu Diskutieren wird Interessant den auch da gibt es nicht nur eine Meinung.
https://stackoverflow.com/questions/...ocess-on-linux
Damit habe ich neben top die CPU Last an gesehen und was soll ich sagen nichts ergo kein Dummer drin.
Zum Thema LED Test:
Mein Problem ist die LED's die da sind habe ich keine Werte zu, den das war so ein Alles Drin pack von Vilros den ich mal zu Weihnachten geschenkt bekommen habe. Ergo kann ich den Vorwiederstand nicht ausrechnen an 5V. 5V Deshalb da ist ein TBD62083A zwischen PIN und Lüfter. Klar ich könnte jetzt wieder alles auseinander bauen und die LED am Pin direkt betreiben aber auch dann müsste ich nicht was das für eine LED ist.
Meine Elektronik Sammlung ist im Moment sehr bescheiden da ich lange nichts mehr gemacht habe und vor Jahren mal aussortiert habe weil habe ja eh keine Zeit...
Das ich noch mal Anfange hätte ich so nicht gedacht. Wollte ja nur mal eben eine CarPC bauen mit Standardteilen und jetzt sitze ich da und mache Unteranderem das hier und Controller Software (ATMega) fürs Netzteil.
P: Meine Tochter (06.11.07) und https://www.carnine.de
M: Träumen hat nix mit Dummheit zu tun es ist die Möglichkeit neues zu erdenken
da gebe ich dir völlig Recht -Zitat von alexander_ro
nur leider wird C/C++ ja überhaupt nicht von der raspberrypi.org supportet, sondern, erbärmlicherweise, ausschließlich Python (sogar Adafruit bietet für seine Produkte nur Python Treiber für den Pi an, keine in C/C++, obwohl sie für Arduinos vorhanden sind)
- alles andere sind libs und Tools von ± Privatnutzern, die hier etwas für die Community zur Vereinfachung bereit gestellt haben
(und GPIO-Steuerung samt deren dev trees ist ja auch nichts, was irgend etwas mit dem "normierten" C seit Kernighan und Ritchie oder Stroustrups C++ zu tun hat.)
LED sind sehr ähnlich den größten Unterschied macht die Farbe. Da muss man nicht wirklich wissen was es genau für eine ist. Im Netz gibt es LED Rechner da wählt man die Farbe aus und bekommt brauchbare Werte vorgegeben. Man kann ja dann zur Sicherheit immer noch mit einem bisschen größeren Widerstand zum testen anfangen. Ein Labornetzgerät wäre da hilfreich aber nicht unbedingt nötig.
https://www.elektronik-kompendium.de...au/1109111.htm
Bibliotheken sind meist leicht zu erkennen weil sie eher allgemein gültige Dinge zur Verfügung stellen. Anwendungen sind dann die Teile die ein Bestimmtes Problem für den User lösen. Also eher spezielle Dinge. Aber ich sehe jetzt kein Problem warum ein Bibliothek keine Schnittstelle anbieten sollte um Konfig Dateien zu lesen. Logisch die sollte dann die Anwendung benutzen und wie Du schon meintest z.B. per Konstruktor an die Bibliothek übergeben. Aber mit der Bibliothek gelieferte Programm Beispiele könnten dann auch gleich ein Muster Config für die unterstützten Platinen auch anbieten.
Arduino C/C++ kann man aber gut als Beispiel benutzen um dann eine Version für den Raspi zu schreiben. GPIO ist auf jeder mit Linux laufenden Platine eigentlich nur ein Filesystem Zugriff. Abgesehen von den Namen der Devicefiles ist das auf allem mit Linux Kernel der gleiche Ablauf. C++ hat seit C++17 auch die Möglichkeit auf das Filesystem zuzugreifen. Mit fstream konnten ja Dateien schon immer gelesen und geschrieben werden. fstream kann man auch für die Zugriff auf Devicefiles benutzen.
https://en.cppreference.com/w/cpp/experimental/fs
Ich habe jetzt für meine I2C Klasse erst mal noch die Log Klasse fertig gebaut. Man muss jetzt zuerst ein Log Objekt erzeugen und beim Konstruktor der I2C Klasse mit übergeben. Je nachdem welche der Log Klassen man erzeugt ist dann das Log Ziel die Standard Ausgabe, eine Datei oder Syslog. Eine LogNoLog Klasse entfernt soweit möglich den Code aus der Klasse. Das erledigt die Optimierung des Compilers muss man natürlich dem Compiler sagen das er Optimieren soll.
https://git.hts-software.de/cgit.cgi...a-Api/tree/Log
https://git.hts-software.de/cgit.cgi...a-Api/tree/I2c
Geändert von alexander_ro (22.11.2018 um 11:06 Uhr)
Arduino C++ lässt sich schlecht als Vorlage zu Linux C++ libs benutzen, da die Arduino-Libs zu viele spezielle Arduino-Funktionen benutzen (i2c, UART, SPI, avrgcc, Arduino String, kein File system etc.) - das Umschreiben können nur Könner, ich z.B. nicht. Selbst wiringPi funktioniert völlig anders als Arduino Wiring. Aber manche Könner haben tatsächlich portierte Versionen geschrieben, ohne dass ich die aber auch nur annähernd verstehe.Arduino C/C++ kann man aber gut als Beispiel benutzen um dann eine Version für den Raspi zu schreiben. GPIO ist auf jeder mit Linux laufenden Platine eigentlich nur ein Filesystem Zugriff. Abgesehen von den Namen der Devicefiles ist das auf allem mit Linux Kernel der gleiche Ablauf.
Berechtigungen
Lesezeichen