Linux-Kernel: Raspberry Pi 4 bekommt Support für freien Grafiktreiber

Bild hier  Die Upstream-Arbeiten für den Raspberry Pi 4 haben nun die Display-Pipeline des Grafiktreibers erreicht. Damit sollte die Videoausgabe auf dem Bastelrechner bald mit dem Mainline-Linux-Kernel genutzt werden können. (Linux-Kernel, Linux) Bild hier  

Weiterlesen...

Sag deine Meinung zu der Meldung und diskutiere im Roboternetz.

News Quelle: Golem
Diese Nachricht wurde automatisiert vom Roboternetz-Bot gepostet. Verantwortlich für den Inhalt ist daher allein der Herausgeber, nicht das Roboternetz.de oder deren Verantwortliche.


Anzeige

Sehr schön,
ich kann es leider nicht programmieren.

Nun, ein paar mehr Hardware-PWMs Pin sind mir lieber.
Gruß
AR

der Rpi 4 geht mir zu sehr in Richtung Multimedia-PC, mir wären auch mehr GPIOs samt ADC und DAC lieber (größere Platine, Zusatz-Header), inkl. auch breiter benutzerfreundlicher C/C++ driver-Lib-Unterstützung durch die raspberry.org (nicht nur dieses dämliche Python)

Du sprichst mir aus dem Herzen.

Gruß
AR

PS
was ist Python?
Das langsame System !?

Zitat:

---

Zitat von HaWe

der Rpi 4 geht mir zu sehr in Richtung Multimedia-PC, mir wären auch mehr GPIOs samt ADC und DAC lieber

---

Auf einer Platine, auf der ein Prozessor und seine Umgebung mit 1GHz und mehr trommelt, ist irgendetwas analoges eine echte Herausforderung. Das wird entweder Spielkram oder unverhältnismäßig teuer. Geht man da irgendeinen Mittelweg, wirds für die Bastler zu teuer und für die Profis bleibts Pfusch. Und alles, was das SoC, das ja nicht für den Rasperry erfunden wurde, nicht schon drin hat, macht alles nochmal problematischer.

Zitat:

---

auch breiter benutzerfreundlicher C/C++ driver-Lib-Unterstützung durch die raspberry.org (nicht nur dieses dämliche Python)

---

Die ist doch da. Nach der Unix Devise "alles ist ein File" sind die GPIOs auch nur ein File: "/sys/class/gpio....". Und die spricht man mit den klassischen Filefunktionen wie open(), read() und write() an. Python (oder auch WiringPi) ist doch auch nur einen Wrapper um diese Funktionen. Im Source von WiringPi kann man das schön nachlesen.

MfG Klebwax

ich sprach zunächst nicht von GPIO libs, sondern von C(++) device driver libs, ähnlich wie die ganzen Arduino-Libs (z.B. für div. Sensoren, Encoder oder Port-Multiplexer etc).
wiringPi ist allerdings für "nackte" GPIOs und I2C/SPI/UART schon ganz nett gewesen, nur leider ist es inzwischen deprecated - und pigpio wiederum ist ein einziges Kauderwelsch, gleiches gilt für die ganzen low-level bcm- und file I/O Funktionen.
Die Betonung lag ja aber auch einerseits auf "benutzerfreundlich", was beim Pi nicht gegeben ist (vgl. Arduino C++ API und Libs) und andererseits auch auf "supported durch raspberrypi.org", was ebenfalls nicht gegeben ist, denn die supporten nur Python.
Das bisschen, was es an benutzerfreundlicher C/C++-API gab, stammte nicht von der raspberrypi.org, sondern von Privatleuten (Henderson, Joan, PiGraham,...).

PS,
was analog-Ports angeht, könnte man aber durchaus Zusatz-ICs (wie MCP3008 etc) fest verbauen, schließlich sind ja auch schon USB-, BT-, WiFi-, Audio-, Video-, TFT- und HDMI-Chips mit drauf...

Zitat:

---

Zitat von HaWe

ich sppach zunächst nicht von GPIO libs, sondern on C(++) device dreiver libs, ...

---

Device Driver werden in Unix/Linux über open(), read(), write() oder auch ioctl() angesprochen. Und das sind C-Funktionen und die sind da. Das ist das die einzige Möglichkeit, auf die GPIOs in Unix/Linux zuzugreifen. Die Hardware eines Unix/Linux Systems ist vollständig unter Kontrolle des Kernels. Auch eine Library, die auch nur ein Stück Usermode Code ist, muß dieses Interface benutzen. In Unix/Linux ist alles ein File.

Ob man das Programmieren auf dieser Ebene "benutzerfreundlich" nennt, hängt vom Benutzer ab. Wer unter Linux programmiert, dem ist das geläufig. Der Autor von WiringPi hat versucht, eine Usermode Library darüber zu setzen, ist aber wohl an der Ignoranz der Benutzer gescheitert. Warum sollte sich jemand anderes das nochmal antun?

Zitat:

---

ähnlich wie die ganzen Arduino-Libs

---

Beim Arduino ist das ganz anders. Da gibt es kein Betriebssystem und jedes Programm kann direkt auf die Hardware zugreifen. Ob man die Funktionen, die das machen, dann eine Library nennt, ändert daran nichts. Äpfel und Birnen gehören nicht in denselben Korb.

MfG Klebwax

Du hast da noch was nachgeschoben

Zitat:

---

was analog-Ports angeht, könnte man aber durchaus Zusatz-ICs (wie MCP3008 etc) fest verbauen, schließlich sind ja auch schon USB-, BT-, WiFi-, Audio-, Video-, TFT- und HDMI-Chips mit drauf...

---

Was du da aufzählst ist eigentlich alles digital. Um in dem Störumfeld etwas brauchbares analoges zu machen, reicht ein Chip nicht aus. Schon jetzt versaut das HDMI Signal bei bestimmten Auflösungen WiFi. Stell dir das also nicht so leicht vor.

nein, ich meinte eben benutzerfreundliche high-level-API-Libs, kein low-level Kauderwelsch - ähnlich wie es wiringPi mit seinen Wrappern mal gemacht hat, auch für Geräte wie PCFs , MCPs, ADS1115, RTC und GPS und auch div. Raspi Weatherstation-Sensoren, nur eben künftig original von raspberrypi.org gestellt und supportet. wiringPi hat ja auch Wiring (also die Arduino-Systematik) mit Wrappern ansatzweise "simuliert" (wenn auch oft nur halbherzig und unvollständig), und künftig wird es ja nicht einmal mehr das geben: Welchen Teil davon hast du nicht verstanden? Unter Python braucht man sich auch nicht mit /sys/class/gpio...., open(), read() und write() für alles mögliche herumschlagen, warum soll es also nicht auch mit highlevel-C(++) Libs gehen? Und selbstverständlich meine ich ADC-onboard-Zusatzchips wie den genannten MCP3008 (oder andere, ebenfalls per SPI, oder meinetwegen auch ganz andere per I2C), warum soll man die nicht mit drauflöten können, mit zusätzlichen Headern? Aber ich will ja auch nicht dich überzeugen...