Hallo zusammen, na sowas, der Raspberry Pi ist soeben in Version 4 erschienen! https://www.raspberrypi.org/products/raspberry-pi-4-model-b/ Endlich ein ordentlicher Prozessor mit ausreichend Arbeitsspeicher, PCIe-Anbindung für USB (nun auch in Version 3.0) und Gigabit Ethernet. Außerdem zwei (micro-)HDMI Ports bis 4K - man braucht zwar Adapterkabel, aber dafür geht endlich der Dual-Monitor Betrieb... Muss mir direkt einen ordern :) Grüßt euch, Peter
:
Bearbeitet durch Admin
Super, die 4GB Variante ist anscheinend erst im September lieferbar... Aber immerhin... 73
Peter schrieb: > Endlich ein ordentlicher Prozessor Hurra, endlich einer mit Dokumentation und komplett Open-Source-Treibern? ... kleiner Scherz :)
Hans schrieb: > erst im September lieferbar... Hier ist der Pi4/4GB bereits bestellbar, habe mir aber erstmal die 1 GB Variante geordert. https://www.welectron.com/Raspberry-Pi-4-Modell-B-1-GB-RAM
Ich würde mir immer noch eMMC oder ähnliches anstelle der SD-Karte wünschen. Ansonsten, schon schick.
Das sie es nicht ordentlich können haben sie doch schon in den bisherigen Versionen bewiesen. Warum also die irrige Annahme das diesmal alles besser sei?
Sebastian R. schrieb: > Ich würde mir immer noch eMMC oder ähnliches anstelle der SD-Karte > wünschen. Oder eine Variante ohne den Dual4K-Schnickschnack, dafür mit SATA für eine zuverlässige und schnelle SSD, wie es bereits vor 5 Jahren der BananaPi-Pro hatte. Ein großer Teil aller RPi-Anwendungen ist headless, d.h. der Pi sitzt in einem einfachen Alugehäuse und verrichtet 24/7 seinen Dienst, ohne jemals einen Monitor zu sehen. Von einem onboard-FPGA, einem onboard-RTLSDR, einem ISM-Band-Transceiver, und den ganzen schönen (und wahrscheinlich auch teuren) Sachen, die mein Herz erfreuen würden, will ich garnicht anfangen. Leider geht das ganze mehr und mehr in Richtung Billig-PC für irgendwelche einfallslosen 0815-Mediaanwendungen. Dabei war der RPi anfangs mal als Lern- und Bastelrechner gedacht. Das einzige, was davon geblieben ist, ist der Pinheader.
Vancouver schrieb: > Das einzige, was davon > geblieben ist, ist der Pinheader. Naja. Es ist wie beim Arduino. Das gesamte Ökosystem zeigt noch in die Richtung. Es ist nicht nur die Hardware, sondern du bekommst dazu eben auch Betriebssysteme mit Skratch, Python und Co. und die Hardware ist immer noch preisoptimiert, um mit wenig Geld was erreichen zu können. Aber gerade da der RPi4 ja wirklich als Desktop-Ersatz beworben wird, wäre eine Alternative zum Flaschenhals SD-Karte schön gewesen. Echtes USB3 und GB-LAN über PCIe sind schon einmal ein guter Anfang. Aber wie du sagtest, SATA hätte dem ganzen auch nicht wehgetan.
Das GBIT LAN ist nich per PCIe angebunden. Der externe IC isn reiner PHY und der MAC sitzt im SoC. Also noch viel besser.
Mw E. schrieb: > Also noch viel besser. Was ist daran "besser", außer daß kein separater NIC verbaut wird?
Rufus Τ. F. schrieb: > Was ist daran "besser", Dass die CPU direkt ohne den Umweg über PCIe auf die MAC-Register zugreifen kann und für die DMA-Transfers keine Addressumrechnung gemacht werden muss.
Vancouver schrieb: > Oder eine Variante ohne den Dual4K-Schnickschnack, dafür mit SATA für > eine zuverlässige und schnelle SSD, wie es bereits vor 5 Jahren der > BananaPi-Pro hatte. Ein großer Teil aller RPi-Anwendungen ist headless, > d.h. der Pi sitzt in einem einfachen Alugehäuse und verrichtet 24/7 > seinen Dienst, ohne jemals einen Monitor zu sehen. Das ist die Sicht von uns Hardwareentwickler. Aber der Raspi war und ist hauptsächlich als Ersatz für Desktoprechner gedacht und dafür macht es durchaus Sinn, zwei Monitore anschliessen zu können.
Vancouver schrieb: > Dass die CPU direkt ohne den Umweg über PCIe auf die MAC-Register > zugreifen kann Du glaubst, daß das einen relevanten Unterschied ausmacht?
Rufus Τ. F. schrieb: > Du glaubst, daß das einen relevanten Unterschied ausmacht? Ja. Es hat geringere Latenz, braucht insgesamt weniger Chipfläche, verursacht weniger Verlustleistung und vereinfacht die Treiberentwicklung enorm. PCIe ist aus Sicht des SoC ein schwerfälliger Hardwarebrocken aus der PC-Welt, den man gerne loswerden möchte.
Vancouver schrieb: > Leider geht das ganze mehr und mehr in Richtung Billig-PC für > irgendwelche einfallslosen 0815-Mediaanwendungen. Dabei war der RPi > anfangs mal als Lern- und Bastelrechner gedacht. Nein, war er noch nie. Ganz im Gegenteil wurde er, von Anfang an, als genau das beworben: ein kleiner, sehr billiger Desktoprechner. Dass Bastler das Teil für sich entdeckt haben und der Raspi mittlerweile meist headless und nur ganz ganz selten mit Bildschirm und "richtiger" Desktopumgebung betrieben wird ändert an dieser Prämisse nichts.
:
Bearbeitet durch User
Sieht jemand die Info, ob ein neuer, bzw. welcher W-LAN-Chip verbaut worden ist?
Also wenn der jetzt WLAN ac und BT5 kann, dann muss das ein neuer IC sein. Welcher das ist sehe ich jetzt auch nicht. Rufus seine Frage zum PHY wurde ja schon beantwortet, muss ich das nicht mehr machen.
Le X. schrieb: > Ganz im Gegenteil wurde er, von Anfang an, als genau das beworben: ein > kleiner, sehr billiger Desktoprechner. Das halte ich aber für ein Gerücht. Die Stiftung hatte zum Ziel, den Jugendlichen den Einstieg in die Programmierung zu erleichtern, weil die Informatik-Anfängerzahlen ständig zurückgingen und die Kids nur noch am daddeln sind. Das Teil war nie dazu gedacht, dass die Leute damit ihre Mails schreiben oder Ballerspiele machen. Der typische PC-User vermisst keinen Pinheader mit irgendwelchen I2C oder SPI-Ports, interessiert sich einen Kehricht für die Schaltpläne und will in den meisten Fällen auch nicht mit Linux arbeiten und ganz sicher keine Erweiterungsboards entwickeln.
https://www.heise.de/ct/artikel/Raspberry-Pi-4-4-GByte-RAM-4K-USB-3-0-und-mehr-Rechenpower-4452964.html Hier steht ein bisschen mehr zu der Kiste. Ich denke auch man sollte erstmal der Software noch 1-2Monate Zeit zum reifen geben... Olaf
Die 4GB Version wird wohl nur mit einem 64Bit OS voll nutzbar sein. Villeicht ist die deshalb erst am September lieferbar? Man kann sich ja nicht den ganzen ADressraum mit RAM vollknallen, die Periphregister wollen ja auchnoch gemapped werden.
Mw E. schrieb: > Man kann sich ja nicht den ganzen ADressraum mit RAM vollknallen, die > Periphregister wollen ja auchnoch gemapped werden. Aber nicht für Userspace-Prozesse. Via LPAE kann man auf einem 32bit-System mehr als 4 GB RAM nutzen, aber halt nur 4 GB pro Prozess. Gibt's doch genauso auch bei x86.
LPAE war doch nur für den Hypervisor? Da muss der Linuxkernel dann aber ordentlich tricksen.
Mw E. schrieb: > LPAE war doch nur für den Hypervisor? Wenn ich das richtig verstanden habe, nicht nur. Mw E. schrieb: > Da muss der Linuxkernel dann aber ordentlich tricksen. Klar, aber das tut er bei der Speicherverwaltung eh schon. Der Kernel selbst braucht ja kaum 4 GB RAM. https://lwn.net/Articles/415190/
https://cdn.shopify.com/s/files/1/1560/1473/files/Inside_Raspberry_Pi_4.pdf?2142 Keine einzige Änderung des W-LAN's. Gleicher Chip, gleiche OnBoard-Antenne. Jetzt bin ich doch etwas enttäuscht. Muss wohl ein USB3.0-Port herhalten, damit man mal "etwas" Performance reinbekommt.
Immerhin: - I2C stretching (hardware) bug ist endlich behoben - bis zu 4 weitere UARTS (neben der Console) über die GPIOs möglich
Hmm. Das Hauptproblem (SD-Karte) haben sie aber nicht gelöst. Das gehört ein SATA-Stecker drauf. Oder wenigstens ein EMMC. Jedenfalls irgenwas, wovon man zuverlässig ein Betriebssystem betreiben kann. Ich verstehe es nicht. Ein dummer SATA-Stecker ist jetzt nicht so teuer. Man braucht ja keine 12V anzubieten, so gut wie alle 2,5 Zoll - Platten laufen mit 5V allein... So ist das wieder dieses unzuverlässige Gefrickel für Heimanwender.
Angehängte Dateien:
-
D902vvrXoAAAq81.jpg
290 KB
Christobal M. schrieb: > Support für 2x 4k displays… aber immer noch kein sata. Mö danke. USB3 hebt da dieses Problem für mich völlig aus. Da auch noch von deren gebootet werden kann und 200MBs (c`t Benchmark) reicht für dieses Ding völlig. BTW... Die 4GB Version ist doch Verfügbar?! Also in den Stores in GB stehen die 4GB Versionen rum, online sind sie allerdings ausverkauft...
Wozu bei einem solchen Board 2 x HDMI gut sein soll, weiss ich auch nicht. Aber tut ja auch niemandem weh. Nur muss man bei aller Kritik den Preis nicht aus dem Blickfeld verlieren. Ich finde für den Betrag, den man hinblaettert, bekommt man sehr viel zurück. SATA waere natürlich sehr wünschenswert gewesen. Aber vermutlich waere dann der Preis andersweitig plaziert worden.
Mehmet K. schrieb: > Wozu bei einem solchen Board 2 x HDMI gut sein soll, weiss ich auch > nicht. Aber tut ja auch niemandem weh. Ich brauche hier in einem (Halt wirklich nur einem) Anwendungsfall genau 2x HDMI - ist selten aber dafür steht aktuell noch ein Desktoprechner da. In einer Feuerwehr ein Info-Display (55" TV) und ein "Terminal" Touch-Display. Wo der Einsatzleiter seine Fahrzeugordnung angibt.
Chris M. schrieb: > https://cdn.shopify.com/s/files/1/1560/1473/files/Inside_Raspberry_Pi_4.pdf?2142 > > Keine einzige Änderung des W-LAN's. Gleicher Chip, gleiche > OnBoard-Antenne. Jetzt bin ich doch etwas enttäuscht. Muss wohl ein > USB3.0-Port herhalten, damit man mal "etwas" Performance reinbekommt. Danke für den Link, der ist ja sehr ausführlich. Da musst ich nochmal gucken: 3B -> WLAN n 3B+ -> hat schon WLAN ac Aber schon interessant, dass derselbe IC dann auf einmal BT5 kann. Eigentlich hätt man da doch was an der HW drehen müssen wegen doppelter Datenrate oder doppelter Reichweite. @Dr. Sommer Danke für die äh.. Aufklärung ;)
Mehmet K. schrieb: > Wozu bei einem solchen Board 2 x HDMI gut sein soll, weiss ich auch > nicht. Aber tut ja auch niemandem weh. > Nur muss man bei aller Kritik den Preis nicht aus dem Blickfeld > verlieren. Der Broadcom Chip hat das drin, also hat man ihn halt rausgeführt. > Ich finde für den Betrag, den man hinblaettert, bekommt man sehr viel > zurück. > SATA waere natürlich sehr wünschenswert gewesen. Aber vermutlich waere > dann der Preis andersweitig plaziert worden. Vermutlich hat der BC Chip kein SATA. Ist ja nicht so, dass der speziell für den Raspberry entwickelt wurde. Gruß Axel
Draco schrieb: > USB3 hebt da dieses Problem für mich völlig aus. Da auch noch von deren > gebootet werden kann und 200MBs (c`t Benchmark) reicht für dieses Ding > völlig. Hat nur einen sehr praktischen Nachteil, wenn du den RPi und die SSD in einem gemeinsamen Gehäuse unterbringen willst, sodass die Schnittstellen des RPi noch von außen zugänglich sind. Dann hast du so einen blöden USB-Rüssel, der zurück ins Gehäuse führt. Außerdem brauchst du eine SSD mit einem SATA/USB3-Konverter. Das ist doch alles Gefrickel. Mit einem einzigen SATA-Port wäre das elegant gelöst und die beiden USB3-Ports wären frei für externe Geräte. Aber offenbar haben mehr Leute nach zwei 4K-Displays geschrien als nach einem vernünftigen Massenspeicher. Versteh einer die Menschen.
Das Gefrickel Vancouver schrieb: > Das ist doch alles Gefrickel. Ein separates Sata-Stromkabel ist also kein Gefrickel? grübel
Auf dem GPIO Pinheader liegen 5V an, also nix Extra. Zudem hat USB auch wieder einen Overhead, der die CPU belastet beim Datenschaufeln. Warscheinlich haben viele nach Dualmonitor geschriehen, 4K is ja heutzutage normal und kommt dann eben direkt mit.
Draco schrieb: > Ein separates Sata-Stromkabel ist also kein Gefrickel? grübel Nicht wenn es im Gehäuse liegt.
Angehängte Dateien:
-
rpi4.jpg
110 KB
Heute wurde der neue Raspberry Pi vorgestellt. Neben besserer Rechenleistung gibt es nun Varianten mit deutlich mehr Arbeitsspeicher. Zudem lassen sich erstmals mehrere hochauflösende Displays ansteuern.
Zunächst fällt bei dem aktuellen Modell auf, dass zwei der USB-Ports durch USB 3.0 ersetzt wurden. Darüber hinaus verfügt die Platine über Gigabit-Ethernet, die Stromversorgung erfolgt über USB-C. Daneben fallen vor allem die beiden Micro-HDMI-Ports ins Auge. Hiermit lassen sich zwei Monitore bei einer Auflösung von bis zu 3840 × 2160 Pixeln nutzen.
Der Neuankömmling verfügt über vier Cortex-A72-Kerne, dabei kann zwischen mehreren Varianten mit verschiedener Arbeitsspeichergröße gewählt werden. So verfügt das Basismodell wie bisher über 1 GB RAM, wobei bis zu 4 GB möglich sind. Die Leistungsfähigkeit des neuen Modells vergleicht die Raspberry Pi Foundation mit der von Desktop-PCs im Einstiegssegment.
Der Formfaktor ist gleich geblieben, die bekannten Konnektoren für GPIOs, Kamera, Display und Audio sind ebenfalls vollständig erhalten geblieben. Drahtlose Schnittstellen sind in Form von WLAN und Bluetooth gegeben. Preislich liegt das Basismodell mit etwa 37€ im Bereich der bisherigen Modelle der B-Reihe. Das Modell mit 4 GB Arbeitsspeicher liegt preislich knapp unter 60€.
Weitere Informationen:
Alles in allem ein cooles Update zum Vorgänger. Leider wird weiterhin auf die MicoSD-Karte beharrt..
Chris M. schrieb: > Leider wird weiterhin auf die MicoSD-Karte beharrt Ich finde das sehr gut; es ist ein aktueller/verbreiteter Formfaktor, man bekommt sie günstig oder hat sogar noch welche rumliegen.
"Ich finde das sehr gut; es ist ein aktueller/verbreiteter Formfaktor, man bekommt sie günstig oder hat sogar noch welche rumliegen." Ganz genau, günstig zu bekommen und läuft doch gut
Ich finds aber auch schade, dass nicht mal nen bissel was an schnellem Flash direkt verbaut wird. Einfach 8 oder 16GB fix angebunden.
A. D. schrieb: > Ich finds aber auch schade, dass nicht mal nen bissel was an > schnellem > Flash direkt verbaut wird. Einfach 8 oder 16GB fix angebunden. Der BCM2711 hat halt nunmal nur ein MS Interface. Sollte ein zweiter Flash verbaut würde dies wiederrum auf einen externen Chip - wie auch bei SATA - hinauslaufen. Von dem Platzbedarf mal ganz zu schweigen. All das würde auch den extrem geringen Preis in die Höhe treiben. Nein nein, ist schon gut so. Was ich ääääußerst Interessant aber finde, ist Pin-27 und Pin-28 auf dem IO Header. Das ist ID_SD und ID_SC - daran kann man ein EEPROM mit einer Seriennummer betreiben der direkt beim Booten den Treiber / IO-Conf für das jeweilige HAT laden kann. Das ist interessant! War das beim 3er auch schon so?!
Mal wieder absichtlich Wlan und Bluetooth vergessen. Das hat dann die nächste Version bist Du schon im Kaufrausch ?
Werner S. schrieb: > Mal wieder absichtlich Wlan und Bluetooth vergessen. > Das hat dann die nächste Version bist Du schon im Kaufrausch ? ??? "2.4 GHz and 5.0 GHz IEEE 802.11ac wireless, Bluetooth 5.0, BLE"
Mw E. schrieb: > Warscheinlich haben viele nach Dualmonitor geschriehen, 4K is ja > heutzutage normal und kommt dann eben direkt mit. RasPis eignen sich recht gut zur automatischen Präsentation von Webseiten, Dashboards, Statistiken etc auf Grossmonitoren. Da werden auch gerne mal 2 Ausgänge gebraucht.
Mehmet K. schrieb: > Wozu bei einem solchen Board 2 x HDMI gut sein soll, weiss ich auch > nicht. Aber tut ja auch niemandem weh. Doch! 2x HDMI für Dualmonitor Ist bei mir zu Hause aber nur deshalb normal, weil ich keinen Platz für 3 27" habe
Draco schrieb: > Was ich ääääußerst Interessant aber finde, ist Pin-27 und Pin-28 auf dem > IO Header. Das ist ID_SD und ID_SC - daran kann man ein EEPROM mit einer > Seriennummer betreiben der direkt beim Booten den Treiber / IO-Conf für > das jeweilige HAT laden kann. Das ist interessant! War das beim 3er auch > schon so?! Das existiert schon seit Einführung des HAT-Standards mit dem Pi 1 B+. https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/
Vancouver schrieb: > Dabei war der RPi anfangs mal als Lern- und Bastelrechner gedacht. Das > einzige, was davon geblieben ist, ist der Pinheader. Und was ist davon nicht geblieben? Also was fehlt ihm, was der erste RPi hatte? Vancouver schrieb: > Le X. schrieb: >> Ganz im Gegenteil wurde er, von Anfang an, als genau das beworben: ein >> kleiner, sehr billiger Desktoprechner. > > Das halte ich aber für ein Gerücht. Die Stiftung hatte zum Ziel, den > Jugendlichen den Einstieg in die Programmierung zu erleichtern, weil die > Informatik-Anfängerzahlen ständig zurückgingen und die Kids nur noch am > daddeln sind. Und weil es so bastelfreundliche Computer wie früher den C64 nicht mehr so gibt. Das war der Grund, weshalb das ganze Projekt überhaupt ins Leben gerufen wurde. Dr. Sommer schrieb: > Mw E. schrieb: >> Man kann sich ja nicht den ganzen ADressraum mit RAM vollknallen, die >> Periphregister wollen ja auchnoch gemapped werden. > > Aber nicht für Userspace-Prozesse. Via LPAE kann man auf einem > 32bit-System mehr als 4 GB RAM nutzen, aber halt nur 4 GB pro Prozess. > Gibt's doch genauso auch bei x86. Nicht ganz. Auch Prozesse brauchen Platz für Memory-Mapping. Bei x86-Linux ist dafür per Default pro Prozess 1 GB reserviert, unter Windows sogar 2 GB von den 4. Axel L. schrieb: >> Ich finde für den Betrag, den man hinblaettert, bekommt man sehr viel >> zurück. >> SATA waere natürlich sehr wünschenswert gewesen. Aber vermutlich waere >> dann der Preis andersweitig plaziert worden. > Vermutlich hat der BC Chip kein SATA. > > Ist ja nicht so, dass der speziell für den Raspberry entwickelt wurde. Man könnte aber fast den Eindruck gewinnen, wenn man nach dem Chip auf Google sucht. Ich konnte kein einziges Suchergebnis finden, das nicht im Kontext des RPi4 steht.
Mal was zur "Warum der Pi erfunden wurde" Theorie: Ich nehme Euch jetzt mal alle Illusionen und schreibe Euch, wie das wahrscheinlich abgelaufen ist: Eben Upton arbeitet bei/für Broadcom und dessen Chef meinte mal in nem Meeting: Chef: "Hallo Leute, der Absatz unserer Chips ist etwas zurückgegangen. Wie können wir die Leute heiß machen, unser Produkt aus den Händen zu reissen ??" Eben: "Ich hätte da eine Idee …." ;):D
Outi O. schrieb: > ;):D Ha ha ha... wie lustig... heute morgen Lachwasser gesoffen? Gähn... heute wieder Patientenalarm?
Mw E. schrieb: > 3B+ -> hat schon WLAN ac > Aber schon interessant, dass derselbe IC dann auf einmal BT5 kann. > Eigentlich hätt man da doch was an der HW drehen müssen wegen doppelter > Datenrate oder doppelter Reichweite. Die doppelte Reichweite (125 kbit/s) ist bei BT5 optional - obs der rPi4 kann..?
Die Eignung als Bastelrechner verschlechtert sich weiter. Insbesondere bei einfacherer Software- Konfiguration Null Fortschritte. Statt dessen unausgereifte Software die von optimaler Nutzung der vorhandenen Ressourcen weit entfernt ist. Statt weniger noch mehr Strombedarf. Immer noch diese elendige langsame und ausfallgefährdete SD Karte als Betriebsgrundlage. Die nutzbaren IO Pins viel zu empfindlich. Für einen Bastellrechner erwarte ich viel mehr serielle Schnittstellen. Alles Fehlanzeige. Als vollwertiger PC Ersatz andererseits immer noch zu mager ausgestattet. Für multimedialen Einsatz gibts besseres. Der Raspi kann vieles aber nichts richtig.
>Der Raspi kann vieles aber nichts richtig
Genau so ist es. Die Dinger sind nutzlose Hardware,
weil kein wirklicher Fortschritt in der Entwicklung der
Boards zu sehen ist. Immer das gleiche Gefrickel.
Und dann immer noch die lahmen Broadcom SOCs.
Es gibt bessere SOCs, fürs gleiche Geld.
Dazu noch der microSD Shit. Kann man so machen, es geht aber auch besser
(Flash).
Und bitte, was soll ich mit nur 4 GB RAM?
Einfach lächerliche Boards.
Habe schon einige von den Boards Banana, Raspi, usw. getestet. Sind für
die Tonne, schade ums Geld.
Mir kommt von den Müllboards nix mehr ins Haus, sebst wenn sie die
verschenken würden.
Ich denke der Raspi ist zunächst mal eines: Ein Linux-Rechner. Wer die damit verbundene Frickelei sucht ist hier goldrichtig. Wenn nur das Ergebnis zählt sind andere, spezialisiertere Lösungen allermeistens besser: Vom einzelnen Mikrocontroller bis zum Multimedia-PC.
Codix schrieb: > Und dann immer noch die lahmen Broadcom SOCs. > Es gibt bessere SOCs, fürs gleiche Geld. Also ich hätte lieber einen gut dokumentierten SoC, auch wenn er dafür langsamer ist. Der Beagle Bone Black kommt dem nahe (nur die 3D Einheit ist geheim), ist aber fast doppelt so teuer :-/ Rolf M. schrieb: > Auch Prozesse brauchen Platz für Memory-Mapping. Achja, für mmap und Konsorten? Der PI hat halt den Anspruch, am Billigsten zu sein. Bessere SBC gibt es viele, aber die sind alle teurer! Das billigste Speichermedium sind SD-Karten, die billigste schnelle Schnittstelle ist USB, daher kein SATA. Mir ist gestern eine microSD-Karte im Slot des PI abgebrochen! Das Gehäuse ist auch so komisch geformt, dass das schnell passiert. Witzigerweise wurde die Karte noch erkannt, mit 30MB.
Welche soc Boards mit sata, GBit hdmi und USB gibt es denn, die empfehlenswert sind?
>> Ist ja nicht so, dass der speziell für den Raspberry entwickelt wurde. > > Man könnte aber fast den Eindruck gewinnen, wenn man nach dem Chip auf > Google sucht. Ich konnte kein einziges Suchergebnis finden, das nicht im > Kontext des RPi4 steht. Stimmt ja auch. Die Raspi Foundation suchte damals einen billigen SOC. Upton kannte/kennt jemand bei Broadcom der ein ausgedientes Teil hatte. So enstand der erste Raspi. Der SOC (Grafikkern mit angeflanschten CPU Kern) war auch nicht dafür gedacht ihn weiterzuentwickeln. Upton konnte aber mit seinem Raspierfolg und eben Stückzahlen überzeugen. Deswegen wurde er gegen jede damalige Vorstellung immer weiterentwickelt. Für große Verwunderung sorgt nun der Raspi 4 SOC wo jeder dachte jetzt muss doch einmal endlich eine aktueller SOC drauf. Wie man sieht nein, Broadcom hält dran fest. Irgendein halbwegs aktueller Mittelklasse Snapdragon wäre wohl dann doch zu teuer. Zudem die Raspi 4 Verfügbarkeit bis 2026 angegeben ist. Das überlebt kein Smartphone SOC. Als Bastelrechner finde ich die Raspi gar nicht schlecht. Booten kann man die neueren auch von USB oder Netzwerk. Das Einzigste ist nur die Empfindlichkeit der I/O Pins. Warum man dort keinen weiteren Schutz integrieren konnte weiß ich nicht. Ansonsten ist das Gemecker hier im Forum absolut sinnfrei.
Veit D. schrieb: > Irgendein halbwegs aktueller Mittelklasse > Snapdragon wäre wohl dann doch zu teuer. Qualcomm ist - höflich ausgedrückt - nicht dafür bekannt, öffentlich mit Dokumentation um sich zu werfen. Zudem wird es bei einen Smartphone SoCs vmtl an gewohnten Funktionen mangeln. In der Leistungsfähigkeit liegt ein Cortex A72 Quadcore mit 4GB durchaus in diesem Bereich.
:
Bearbeitet durch User
> Das billigste Speichermedium sind SD-Karten,
DAs muss im uebrigen nicht zwangslaeufig so sein. Wer SD-Karten haben
will die etwas zuverlaessiger sind, es gibt von Samsung spezielle Karten
die fuer besonders viele Schreibzyklen geeignet sind. (pro endurance)
Aber das sind dann auch nicht mehr die billigsten Karten. Qualitaet
kostet...
Olaf
Rolf M. schrieb: > Nicht ganz. Auch Prozesse brauchen Platz für Memory-Mapping. Bei > x86-Linux ist dafür per Default pro Prozess 1 GB reserviert, unter > Windows sogar 2 GB von den 4. Da geht es um Adressraum. Es gibt 4 GB davon, für die ein Teil reserviert ist (Kernel und Peripherie), egal ob das Teil nun mit oder ohne (L)PAE läuft. Der Rest steht für Prozesse zur Verfügung. Bastler schrieb: > Die Eignung als Bastelrechner verschlechtert sich weiter. > Insbesondere bei einfacherer Software- Konfiguration Null Fortschritte. Wie meinen? Du willst einen dicken Cortex-A72 Quadcore mit der Komplexität eines AVR haben? Das ist nicht sinnvoll. > Statt dessen unausgereifte Software die von optimaler Nutzung > der vorhandenen Ressourcen weit entfernt ist. Wie viele Jahre hat es gedauert, bis die Programmierer den C64 optimal genutzt haben? Frühe Demos vs. späte Demos? Siehste. > Für einen Bastellrechner erwarte ich viel mehr serielle Schnittstellen. Wenn ich mich nicht verlesen habe, wurde die Anzahl der seriellen Schnittstellen verdoppelt (von 2 auf 4). Wozu brauchst du denn noch mehr? Veit D. schrieb: > Irgendein halbwegs aktueller Mittelklasse > Snapdragon wäre wohl dann doch zu teuer. Du willst mit Qualcomm keine Geschäfte machen, nicht für solche Projekte. > Das Einzigste ist nur die Empfindlichkeit der I/O Pins. > Warum man dort keinen weiteren Schutz integrieren konnte > weiß ich nicht. Das müsste per externer Beschaltung passieren, die Geld kostet. Wenn man das nur auf manchen Pins macht, sind die Pins elektrisch nicht mehr identisch, was die Zielgruppe verwirrt; macht man das überall, leider die Nutzbarkeit wegen der Beschaltung (andere Pegel, schlechtere Flanken). Aber ja, ein paar 5V-tolerante Pins wären schon nett.
S. R. schrieb: > Wenn ich mich nicht verlesen habe, wurde die Anzahl der seriellen > Schnittstellen verdoppelt (von 2 auf 4). Wozu brauchst du denn /noch/ > mehr? Eine voll funktionsfähige I2C Implementierung wäre eine nette Geste. Für Anbindung eines Mikrocontrollers eignet die sich besser als eine UART.
S. R. schrieb: > Rolf M. schrieb: >> Nicht ganz. Auch Prozesse brauchen Platz für Memory-Mapping. Bei >> x86-Linux ist dafür per Default pro Prozess 1 GB reserviert, unter >> Windows sogar 2 GB von den 4. > > Da geht es um Adressraum. Es gibt 4 GB davon, für die ein Teil > reserviert ist (Kernel und Peripherie), egal ob das Teil nun mit oder > ohne (L)PAE läuft. Der Rest steht für Prozesse zur Verfügung. Ja. Ich wollte nur sagen, dass die Behauptung, ein einzelner Prozess könne auf einem 32-Bit-Linux 4 GB RAM nutzen, nicht ganz stimmt. >> Statt dessen unausgereifte Software die von optimaler Nutzung >> der vorhandenen Ressourcen weit entfernt ist. > > Wie viele Jahre hat es gedauert, bis die Programmierer den C64 optimal > genutzt haben? Frühe Demos vs. späte Demos? Siehste. Und ein C64 ist im Vergleich zu einem 64-Bit-Vierkerner geradezu trivialst aufgebaut. >> Für einen Bastellrechner erwarte ich viel mehr serielle Schnittstellen. > > Wenn ich mich nicht verlesen habe, wurde die Anzahl der seriellen > Schnittstellen verdoppelt (von 2 auf 4). Wozu brauchst du denn noch > mehr? Das hab ich mich auch gefragt. Ich wüsste schon nicht, was mit 4 Stück machen soll. > Veit D. schrieb: >> Irgendein halbwegs aktueller Mittelklasse Snapdragon wäre wohl dann doch >> zu teuer. > > Du willst mit Qualcomm keine Geschäfte machen, nicht für solche > Projekte. Das ist das große Problem für Geräte wie den Raspi. Man muss erstmal einen SOC finden, der wenigstens so weit offen ist, dass man die Features auch alle wenigstens einigermaßen nutzen kann. Das war ja schon immer der Fokus beim Raspi - ein Prozessor, bei dem nicht die Hälfte unbrauchbar ist, wenn man kein großer Handyhersteller ist. Ich hoffe ja, dass sich mit RISC-V da was tut, aber ich befürchte, dass darauf basierende Prozessoren am Ende genauso verdongelt und verrammelt sind, so dass sie für Bastler auch nutzlos werden.
Mir persönlich fehlt eigentlich nur QSPI, dann wäre das Compute Module der ideale Ersatz für ein bisheriges SoM.
Rolf M. schrieb: > Vancouver schrieb: >> Dabei war der RPi anfangs mal als Lern- und Bastelrechner gedacht. Das >> einzige, was davon geblieben ist, ist der Pinheader. > > Und was ist davon nicht geblieben? Also was fehlt ihm, was der erste RPi > hatte? Es fehlt ihm nichts, was der erste PI hatte. Aber die Ausstattung ist für Desktop-PC-Nutzer weiterentwickelt worden, für die Bastler/Maker higegen nicht oder nur wenig. Gut, es gibt zwei extra UARTs... kann man sich drüber streiten ob das so der große Fortschritt ist. Aber das ganze ist halt preisgetrieben. Mit der Massenware wie USB3 und HDMI kann man das Teil billig halten, die etwas spezielleren Goodies kosten Geld und senken die Verkaufszahlen. Ist auch ein Argument, das man anerkennen muss. > Und weil es so bastelfreundliche Computer wie früher den C64 nicht mehr > so gibt. Das war der Grund, weshalb das ganze Projekt überhaupt ins > Leben gerufen wurde. Korrekt. Das ganze RPi-Konzept ist einfach eine Spitzenidee gewesen, aber es geht jetzt einfach zu weit in Richtung Desktop-Ersatz. Das Ziel scheint zu sein, dass man mit den RPi alles machen kann, wan auch mit einem PC geht @Outi O. > Ich nehme Euch jetzt mal alle Illusionen und schreibe Euch, wie das > wahrscheinlich abgelaufen ist: Hast du dafür Belege? Und selbst wenn Broadcomm das ganze unterstützt hat, um damit Geld zu verdienen (was Firmen ja nun mal per Definition tun müssen), was ist daran auszusetzen?
Codix schrieb: > Genau so ist es. Die Dinger sind nutzlose Hardware, > weil kein wirklicher Fortschritt in der Entwicklung der > Boards zu sehen ist. Immer das gleiche Gefrickel. > Und dann immer noch die lahmen Broadcom SOCs. > Es gibt bessere SOCs, fürs gleiche Geld. > Dazu noch der microSD Shit. Kann man so machen, es geht aber auch besser > (Flash). > Und bitte, was soll ich mit nur 4 GB RAM? > Einfach lächerliche Boards. Soso. Ich frage mich manchmal, was in den Köpfen von Leuten wie dir vorgeht. Weltschmerz? Ich habe daheim etliche Pis im Einsatz und mehr als zufrieden mit den Dingern. Für kleines Geld (Anschaffung und Betrieb) habe ich - Eine komfortable Steuerung für meine 3D Drucker (Octoprint + Klipper + Webcam Streaming) - Ein Kodi-Mediacenter für die Ansteuerung von Beamer und Soundanlage - Diverse Server (Mumble, MQTT, Grafana, InfluxDB etc.) - Ein PiHole zur Werbe-Filterung im Heimnetz Für all diese Aufgaben sind die Pis wirklich hervorragend geeignet. "Frickeln" musste ich da gar nichts :-) Weder mit den SD Karten noch mit dem RAM (1GB) oder dem Chipsatz hatte ich bisher irgendwelche Probleme...
Wir haben mittlerweile einige Raspberries in der Firma im Einsatz, Tendenz deutlich steigend. Darunter ist urigerweise sogar ein RasPad.
:
Bearbeitet durch User
Ich hab mal ein bisschen rumgesponnen und überlegt, wie mein persönlicher "DreamPi" aussehen würde, völlig ohne Rücksicht auf den Preis und Machbarkeit: - 4 Core 64Bit RISC-V - 2-4GB RAM - SDCard, 16GB emmc, SATA - Je 2x USB2+3 extern, 2 USB2 auf Pinheader - Das übliche WiFi/BTLE/GBit LAN - 1x HDMI, max. HD 1080P, analog Audio - MIPI/CSI optional - Pinheader wie RPi - Onboard FPGA der Artix-Klasse, evtl optional als Steckmodul, mit Busanbindung an die CPU (z.B. APB oder AXI) - onboard GPS über UART oder SPI angebunden, Anschluss für ext. Antenne - onboard RTLSDR - onboard 9-Achsen-Bewegungssensor - onboard Luftdrucksensor - Anschluss und USB-Ladelektronik für LiPo-Akku <joke> und das Ganze im Zero-Formfaktor :-) </joke>
Rolf M. schrieb: > Axel L. schrieb: >>> Ich finde für den Betrag, den man hinblaettert, bekommt man sehr viel >>> zurück. >>> SATA waere natürlich sehr wünschenswert gewesen. Aber vermutlich waere >>> dann der Preis andersweitig plaziert worden. >> Vermutlich hat der BC Chip kein SATA. >> >> Ist ja nicht so, dass der speziell für den Raspberry entwickelt wurde. > > Man könnte aber fast den Eindruck gewinnen, wenn man nach dem Chip auf > Google sucht. Ich konnte kein einziges Suchergebnis finden, das nicht im > Kontext des RPi4 steht. Solche Chips werden ja nicht auf dem offenen Markt verkauft. Die gehen an Firmen, die die in ihre Smartphones oder so einbauen und vorher NDAs bis zum Abwinken unterschreiben müssen. Die NDAs dürften auch das Hauptproblem bei der Auswahl eines solchen Chips sein. Die Stückzahlen des Raspis sind für einen solchen Chip viel zu niedrig. Gruß Axel
Axel L. schrieb: > Solche Chips werden ja nicht auf dem offenen Markt verkauft. Die gehen > an Firmen, die die in ihre Smartphones oder so einbauen Die VideoCores wird man eher in DVB-Boxen finden.
> Aber ja, ein paar 5V-tolerante Pins wären schon nett. Mach dich von der AVR denke frei. Seit mindestens 15Jahren wird nichts mehr fuer 5V entwickelt. Es wuerde mich nicht wundern wenn bald alles von 3.3V auf 2.5V oder 1.8V runtergeht Olaf
Alte Standards haben ein sehr zähes Leben. RS232 stammt von 1960 und wird immer noch verwendet, obwohl die Pegel-Definition seit Ewigkeiten jenseits von Gut und Böse ist. Ebenso werden 5V Pegel an Eingängen noch lange relevant bleiben.
:
Bearbeitet durch User
>> Aber ja, ein paar 5V-tolerante Pins wären schon nett. >Mach dich von der AVR denke frei. Seit mindestens 15Jahren wird nichts >mehr fuer 5V entwickelt. Es wuerde mich nicht wundern wenn bald alles >von 3.3V auf 2.5V oder 1.8V runtergeht Ich finde 5V ist ein Wort! Zumindest besser als "aktuelle Spannung" (siehe Kleingedrucktes im Manual) die morgen schon eine andere sein kann. Ja, ich weiß, dass diese Definition schon ein paar Tage alt ist. Aber kein Grund den uralten Kalender rauszusuchen. Im Übrigen: Ich mag auch RS232. Ein ausgereifter Standard, der sich prima für Testorgien eignet und - von allem bei kleinen Rechnern - auch keinen ellenlangen Treibercode benötigt. Natürlich bin ich mir über die Grenzen des Teils im Klaren.
zuwenig RS232 kann doch wohl wirklich nicht das Killerargument sein, ein USB-RS232 Wandler für 2€ dran und fertig. Als Nebeneffekt kann man die empfindlichen IO Pins in Ruhe lassen. Oder man nimmt gleich einen µC mit USB, ist heute auch kein Hexenwerk mehr, ein BluePill kriegt heute auch jeder mit USB ans Laufen. Ich habe ein Android Box MiniX96 als Streaming Client, die machte nach den letzten Updates nur Ärger, hängt sich auf und das Android Zeug ist einfach unbedienbar. Für Kodi auf Adroid gibts keinen Client für eine Enigma2 Set Top Box, man muss schon 8€ in eine halbwegs brauchbare App investieren. Jetzt war ich es leid, habe einen unbenutzen RPi3 genommen, LibreElec installiert, dauerte keine 10 min. und das ist konfiguriert und läuft bestens. Mit schnellerem Netzwerk werden Ladezeiten noch kürzer, das ist einfach nur genial. Nur im geschlossenen Gehäuse wurde es dem kleinen bei den aktuellen Temperaturen zu warm, bei der Power sollte der RPi mittlerweile mit Kühlkörpern ausgerüstet werden. Wenn man den ganzen zusätzlichen Kleinkram addiert ist man doch schnell bei knapp 100€ für so einen Fertigrechner.
Vancouver schrieb: > Ich hab mal ein bisschen rumgesponnen und überlegt, wie mein > persönlicher "DreamPi" aussehen würde, völlig ohne Rücksicht auf den > Preis und Machbarkeit... Bis auf die ganzen On-Board-Geschichten gar nicht mal so übertrieben. Problem bei den ganzen Sensoren ist immer, dass sie in vielen Fällen ungenutzt bleiben und damit unnütz verbaut werden und in schlechtesten Fall unnötig Strom ziehen. USB-Ladeelektronik muss jetzt auch nicht sein, auch das kann man extern realisieren. Ansonsten hätte ich sowas gerne als SoM.
> Kleinkram addiert ist man doch schnell bei knapp 100€ für so einen > Fertigrechner. Das ist die Salamitaktik. :-) Wenn es ums Geld geht faehrt man sicher 10x besser wenn man sich fuer 50Euro einen alten Laptop mit mehr Rechenleistung kauft. Ich glaub das Geheimnis am Pi ist der Schnuckelfaktor. Man bekommt in Prinzip einen Linuxrechner mit der Leistungsfaehigkeit dessen was man Anfang der 90er auf dem Schreibtisch stehen hatte und das einfach so als kleine Karte die fast nichts kostet. Ich bin mal gespannt ob man auf der Kiste halbwegs zuegig Qt als Entwicklungsumgebung nutzen kann. Man sollte ja jetzt so in die Gegend kommen wo man nicht immer gaehnen muss.... Olaf
Maik schrieb: > Ich denke der Raspi ist zunächst mal eines: Ein Linux-Rechner. > Wer die damit verbundene Frickelei sucht ist hier goldrichtig. da denkt und schreibt wohl ein richtiger Experte! LOL
Also ich finde den RaspBerryPi Zero W völlig ausreichend. Das W-Lan ist abgeschaltet, dafür hängt ein billiger USB-Lan-Adapter dran. - Im Leerlauf verbraucht er etwa 0,46W - Wenn ich die Kamera (v.2.1) nutze und einen Video-Stream (mit 1640x1232 Pixel / 30fps) über das Netzwerk schicke, dann liegt die CPU-Auslastung bei etwa 9% und das System verbraucht 1,0W bis 1,1W. Die aktuelle Version ist eigentlich schon sehr gut und ausreichend. Der RaspBerryPi 3B+ ist für meine Zwecke eigentlich schon zu "overpowered". Eine kleine, aktualisierte Version des RaspBerryPi Zero wäre nett, vielleicht auch mit neueren Kern. Gibt es da etwas neues?
Mike J. schrieb: > Eine kleine, aktualisierte Version des RaspBerryPi Zero wäre nett, > vielleicht auch mit neueren Kern. Gibt es da etwas neues? Kommt drauf an, wie sehr du an Broadcomm hängst :-) Ich habe seit einiger Zeit den Nanopi Duo2 mit Armbian im Betrieb http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Duo2
Walter K. schrieb: > Maik schrieb: > Ich denke der Raspi ist zunächst mal eines: Ein Linux-Rechner. > Wer die damit verbundene Frickelei sucht ist hier goldrichtig. > > da denkt und schreibt wohl ein richtiger Experte! > > LOL Eben gerade nicht. Ich bevorzuge Systeme mit denen man schneller ans Ziel- und es nicht so dermaßen auf Expertentum an- kommt.
Vancouver schrieb: > Ich habe seit einiger Zeit den Nanopi Duo2 mit Armbian im Betrieb Ich habe auch einen Nanopo Duo2. Bei mir läuft "friendlycore-xenial_3.4_armhf_20181218". Kernel 3.4, weil ich die h.264 Endcoding-Funktion benötige. Schön ist dass er 4 Kerne hat und auch Pins für eine Netzwerkverbindung vorhanden sind. Außerdem ist er etwas kleiner (nur 2,54cm breit anstatt 3cm beim Zero). Etwas doof ist die recht hohe CPU-Auslastung (90% von 400%) wenn er mir einen Videostream (h.264) über das Netzwerk schickt. Er wird dabei auch recht warm (über 80°C) obwohl ich ihn auf 480MHz fest runter getaktet habe. Die Kamera für den Nanopi Duo2 hat einen Autofokus, aber man kann ihn nicht per Hand einstellen oder auf einen festen Wert setzen. So ein per Konsole-Befehl einstellbarer Fokus würde für meine Zwecke sinnvoll sein. Ich könnte so ein mini-Kameramodul mal versuchen zu öffnen und dann über diese Fokus-Spule einen eigenen Strom schicken. Viel besser wäre eine Software-Lösung, aber da habe ich noch nichts gefunden.
Naja, mindestens einen "muß" ich haben und werde wohl ein paar Tage auf die Lieferung warten müssen. Wie schon gesagt wurde ist es halt schon ein Spaß die selbstgeschriebene Software auf einem Raspi zehn und mehr mal schneller laufen zu sehen als auf dem damals sündhaft teuren 486er. Ich hoffe, daß Mathematica mit 4 GB RAM endlich vernünftig zu bedienen ist. Das ist m.E. ein echter Grund, den Raspi zu kaufen. Falls nicht, wird es halt ein Upgrade für meinen Web- und DNS-Server, der bisher noch auf einem Raspi 2 B läuft. Ich freue mich drauf!
Mike J. schrieb: > Kernel 3.4, weil ich die h.264 Endcoding-Funktion benötige. Ist die im 4er Kernel noch nicht drin? Hab mich noch nicht mit Videokompression beschäftigt. Ich glaube, der nanoPi Duo2 ist momentan bzgl. "Leistung pro Baugröße" das Beste auf dem Markt. Vor ca. 6 Monaten habe ich nichts gefunden, was beim Zero-Formfaktor mehr Rechenleistung und Ausstattung bietet. Mal ne Frage, vielleicht weißt du das: Ich hab mal vor längerer Zeit eine NoIR-Kamera für den RPi gekauft. Läuft die auch am NPi? Die Idee kam mir gerade. Ich noch nicht mal probiert, ob das Flachbandkabel passt.
Vancouver schrieb: > Ich noch nicht mal probiert, ob das Flachbandkabel > passt. Ich glaube, die Belegung ist an sich gleich, nur wurden dort nur 3,3V zur NanoPi-spezifischen Kamera gelegt, daher wird es wohl Anschlussmäßig nicht funktionieren. Ein Treiber für die Kamera v.2.1 vom RaspBerryPi wird wohl auch nicht in der Linux-Distribution von FriendlyARM vorhanden sein.
Olaf schrieb: > Ich glaub das Geheimnis am Pi ist der Schnuckelfaktor. Man bekommt in > Prinzip einen Linuxrechner mit der Leistungsfaehigkeit dessen was man > Anfang der 90er auf dem Schreibtisch stehen hatte und das einfach so als > kleine Karte die fast nichts kostet. Ich kann mir nicht vorstellen, dass du Anfang der 90er was auf dem Schreibtisch stehen hattest, das auch nur annähernd so leistugsfähig war, wie ein Raspi4. Der Intel Pentium (der echte) kam 1993 mit einer Taktrate von 60 Mhz raus. Die typische Speicher-Ausrüstung lag vielleicht so bei 4-8 MB. Die größten Desktop-Festplatten hatten deutlich weniger Kapazität als die kleinsten µSD-Karten, die es heute gibt. USB gab es noch nicht, WLAN und Bluetooth auch nicht. Ethernet gab es nur mit 10 Mbit/s.
:
Bearbeitet durch User
Olaf schrieb: > Ich glaub das Geheimnis am Pi ist der Schnuckelfaktor. Man bekommt in > Prinzip einen Linuxrechner mit der Leistungsfaehigkeit dessen was man > Anfang der 90er auf dem Schreibtisch stehen hatte und das einfach so als > kleine Karte die fast nichts kostet. Wohl eher, was man Anfang/Mitte der 2000er auf dem Schreibtisch stehen hatte. Anfang der 90er hatten wir 386 mit 33MHz und so. Die emuliert der Raspi im Halbschlaf. Ich finde, der Raspi ist ein richtig schöner Bastel- und Frickelrechner. Der 4er ändert nichts an der Philosophie. Ein paar modernere Schnittstellen und mehr RAM. Das wünscht man sich doch für so ein Gerät. Ich werde aber erstmal mit meinem 3B+ weiterspielen. Der Preis ist so günstig, dass man es verschmerzen kann, wenn mal einer hops geht. Für professionellen, produktiven Einsatz ist er nicht geeignet, aber da spielt der Preis ja meist auch nicht so eine große Rolle.
Der Cores der sich von 2013 bis 2019 sehr schnell weiterentwickelnden Cortex A57,A72,A73,A75,A76,A77 Reihe sind in ihrer internen Struktur mit Intel/AMD Prozessoren durchaus vergleichbar. Sie sind aber hinsichtlich Verlustleistung auf Mobilgeräte der Smartphone/Tablet-Klasse optimiert und die realen SoCs gehen Kompromisse ein, beispielsweise bei Speicherinterface und PCIe. Bei vergleichbaren Rahmenbedingungen ist der Abstand vom A77 zu aktuellen Intels nicht mehr sehr gross. Der schon ältere A72 dürfte ganz grob in der Region von Intels Silvermont bis Goldmont Atoms liegen. Und damit wirklich sehr sehr weit weg von allen CPUs der 90er. Im Raspberry ist ähnlich wie in Smartphones die thermische Situation der begrenzende Faktor. Ohne Kühlungsverfahren benötigt man entweder ein weit entwickeltes Leistungs/Temperatur-Management wie in Smartphones, bei denen man zudem mitunter interne Wärmeverteilmechanismen wie Heatpipes findet, oder man drosselt von vorneherein auf harmlose Werte.
:
Bearbeitet durch User
Mike J. schrieb: > Ich glaube, die Belegung ist an sich gleich, nur wurden dort nur 3,3V > zur NanoPi-spezifischen Kamera gelegt, daher wird es wohl Anschlussmäßig > nicht funktionieren. Beim RPi sind es 5V, nehme ich an? Ist das bei CSI nicht standardisiert? > Ein Treiber für die Kamera v.2.1 vom RaspBerryPi > wird wohl auch nicht in der Linux-Distribution von FriendlyARM vorhanden > sein. Ist zwar Armbian, aber da könntest du trotzdem recht haben. Danke.
Veit D. schrieb: > Das Einzigste ist nur die > Empfindlichkeit der I/O Pins. Warum man dort keinen weiteren Schutz > integrieren konnte weiß ich nicht. Die Chips zu ändern um das zu integrieren wäre sicherlich zu teuer geworden. Aber diese Anregung sollte die Pi-Foundation in der Form aufnehemn, dass ein Pi-Hat entwickelt wird, der einen wirksamen Schutz mitbringt, der besser natürlich besser ausfallen kann, als on-board integriert. Dieser kann dann für alle solchen Boards verwendet werden.
A. K. schrieb: > Im Raspberry ist ähnlich wie in Smartphones die > thermische Situation der begrenzende Faktor. Gerüchten zufolge hat jemand in der Firma ein semi-kaputtes, aktuelles Flagschiff-Smartphone (Gehäuse defekt) mal mit richtig massiv Kühlung (der Intel i7-Desktop-Klasse) ausgestattet. Und dann festgestellt, dass das Teil als ordentlicher Buildserver taugt. Hab das leider nicht gesehen bisher.
Mehmet K. schrieb: > Nur muss man bei aller Kritik den Preis nicht aus dem Blickfeld > verlieren. Ich finde für den Betrag, den man hinblaettert, bekommt man > sehr viel zurück. Das möchte ich mal unterstreichen. Welcher von den Clones (auch wenn mit SATA) hat eine so gut funktionierende Software und findet so breite Unterstützung? Ich finde Kritik nicht angebracht und allen kann man es eh nicht recht machen. Die Interessen sind halt unterschiedlich. Rolf M. schrieb: > Und weil es so bastelfreundliche Computer wie früher den C64 nicht mehr > so gibt. Das war der Grund, weshalb das ganze Projekt überhaupt ins > Leben gerufen wurde. Jetzt doch wieder: https://www.heise.de/newsticker/meldung/TheC64-Der-Commodore-Rechner-kommt-in-Originalgroesse-zurueck-4454962.html Dr. Sommer schrieb: > Das Gehäuse ist auch so komisch geformt, dass das schnell passiert. Nein, jeden Morgen steht ein Tollpatsch auf. Ich kann das nicht nachvollziehen, wie man ein SD- Karte da drin abbricht. Vielleicht mal auf Feinmotorik umschalten?
> Ich kann mir nicht vorstellen, dass du Anfang der 90er was auf dem > Schreibtisch stehen hattest, das auch nur annähernd so leistugsfähig > war, wie ein Raspi4. Natuerlich nicht. Aber Linux 0.95a auf einem 386sx (später 486DLC) mit 6MByte war gefuehlt so schnell wie ein Raspberry mit heutiger Software. :-D Olaf
olaf schrieb: >> Ich kann mir nicht vorstellen, dass du Anfang der 90er was auf > dem >> Schreibtisch stehen hattest, das auch nur annähernd so leistugsfähig >> war, wie ein Raspi4. > > Natuerlich nicht. Aber Linux 0.95a auf einem 386sx (später 486DLC) mit > 6MByte war gefuehlt so schnell wie ein Raspberry mit heutiger > Software. :-D > > Olaf Und ein C64 war sogar noch viel schneller, konnte man einschalten und eine Sekunde später schon loslegen mit programmieren. Trotzdem möchte man einen C64 heutzutage nicht mehr produktiv einsetzen.
> Trotzdem möchte man einen C64 heutzutage nicht mehr produktiv einsetzen.
Das stimmt nicht. Die Produktion des C64 wurde doch gerade wieder
aufgenommen weil die Win10 Juenger es verkackt haben und alle wieder
darauf zurueck wollen. :-)
Olaf
So richtiges echtes 802.3af wäre ein träumchen. Und natürlich sATA. Aber das bietet ja auch sonst keiner. Ich habe hier RPi3b, Odroid XU4, Odroid C2, NanoPi Neo Plus2 im Einsatz, aber die RPi3 sind in der Tat am "genügsamsten" in Sachen Konfigurationsaufwand. Bei den anderen fehlt ein wenig die große Community drumherum. Technisch sind für meinen Geschmack die NanoPi besser als ein RPi, aber das Ökosystem drumherum lässt sehr zu wünschen übrig.
Maik schrieb: > Ich denke der Raspi ist zunächst mal eines: Ein Linux-Rechner. Von den Einplatinenrechnern kenne ich nur den Odroid C2: Eigentlic benutze ich diesen nur mit LibreElec als Kodi-Mediacenter, aber da ich ein VPN benötige, habe ich gestern mal das Ubuntu 16.04-Image installiert. Bei der Installation von ffmpeg4 dann das erste Problem: Abhängigkeiten konnten nicht aufgelöst werden, da irgendein Package für arm nicht verfügbar ist. Tante Google schaffte keine Abhilfe, also die static Version von ffmpeg installiert. Gleiches Problem bei der Installation eines anderen Programmes, auch hier fehlte für die arm-Plattform irgendeine dependeny. Immerhin hier schaffte Google Abhilfe. Nach einigen Umwegen war das Programm dann schließlich installiert. Aber wer tut sich sowas öfter als notwendig an?
> einigen Umwegen war das Programm dann schließlich installiert. Aber wer > tut sich sowas öfter als notwendig an? Jeder der Linux seit Anfang der 90er genutzt hat. :-) Aber ich verstehe schon was du meinst. Seit jedes Programm 2453525235 verschiedene Libaries braucht und das auch noch jeweils im passenden Versionsstand ist Linux nicht mehr dasselbe wie frueher. Das es gefuehlt aehnlich viele Distributionen wie Libaries gibt, ist sicher auch nicht unbedingt hilfreich. Ein bisschen mehr Zentralisierung koennte nicht schaden. Olaf
Olaf schrieb: > Jeder der Linux seit Anfang der 90er genutzt hat. :-) Mmmm, also auf einem 'normalen' Desktop-Rechner mit Intel-Prozessor treten selten Probleme mit Abhängigkeiten auf und wenn, dann ließen sich diese bislang mit etwas Hilfe von Google beheben. Aber daß es überhaupt gar nicht funktioniert... Nach dem fehlgeschlagenen Versuch der Installation von ffmpeg aus einem ppa, versuchte ich das ganze selbst zu compilieren. Aber da fehlten dann wieder andere Pakete, die für den arm in keinem universe oder multiverse-repo vorhanden sind. Daher das Ausweichen auf den static build. Spaß ist was anderes ;-)
Markus schrieb: > habe ich gestern mal das Ubuntu 16.04-Image installiert. > Bei der Installation von ffmpeg4 dann das erste Problem: Abhängigkeiten > konnten nicht aufgelöst werden Für das schon recht betagte Ubuntu 16.04 gibt es doch gar kein ffmpeg 4. Markus schrieb: > Nach dem fehlgeschlagenen Versuch der Installation von ffmpeg aus > einem ppa Ach so, du hast es aus einem PPA versucht. Du hast also die allerälteste noch unterstützte Ubuntu-Version installiert und hoffst jetzt, darauf unter Nutzung zweifelhafter Quellen die allerneueste ffmpeg-Version zum Laufen zu bekommen. Das kann man natürlich versuchen, sollte sich aber nicht wundern, wenn der Erfolg ausbleibt. > Aber wer tut sich sowas öfter als notwendig an? > Spaß ist was anderes ;-) Weder das Odroid-Board noch der ARM noch Linux im Allgemeinen noch Ubuntu können etwas dafür, wenn du dir selber alle Steine der Welt in den Weg legst ;-)
:
Bearbeitet durch Moderator
> unter Nutzung zweifelhafter Quellen die allerneueste ffmpeg-Version zum > Laufen zu bekommen. Das kann man natürlich versuchen, sollte sich aber > nicht wundern, wenn der Erfolg ausbleibt. Das ist aber genau das was ich leider als Problem des heutigen Linux anprangere. Sowas war mal kein Problem. Du hast dir ein Programm besorgt und compiliert. Das hat in 50% der Faelle einfach so funktioniert und in den restlichen Faellen musstest du halt noch 1-2 Sachen anpassen oder vielleicht auch mal eine Library modernisieren. Heute mit Tausenden zirkularen Abhaengigkeiten ist das ein Problem. Und weil die Leute das heute nicht mehr hinbekommen selbst wenn sie ihre Distribution sklavisch abdaten, was ein Problem ist wenn du etwas dickes verwendest das nicht von deiner Distribution geliefert wird, bekommen sie das nicht mehr hin und verteilen jetzt ihren zusammen geschusterten Kram als Dockerpaket. Wir haben zwar heute 10x mehr Programmierer wie frueher, aber davon sind jetzt 90% der Bodensatz den man frueher nicht an die Tastatur gelassen haette. Und wenn du dann noch etwas exotische Hardware benutzt dann kann Ottonormalinuxer gleich aufgeben. Also kann ich dann nur dazu raten beim RP zu bleiben. Olaf
Olaf schrieb: >> unter Nutzung zweifelhafter Quellen die allerneueste ffmpeg-Version zum >> Laufen zu bekommen. Das kann man natürlich versuchen, sollte sich aber >> nicht wundern, wenn der Erfolg ausbleibt. > > Das ist aber genau das was ich leider als Problem des heutigen Linux > anprangere. Sowas war mal kein Problem. Du hast dir ein Programm besorgt > und compiliert. Das hat in 50% der Faelle einfach so funktioniert und in > den restlichen Faellen musstest du halt noch 1-2 Sachen anpassen oder > vielleicht auch mal eine Library modernisieren. Da ist meiner Erfahrung nach heute immer noch so. Wenn man bereit ist, selber etwas Hand anzulegen (bspw. eine Library in einer neueren Version zusätzlich zur existierenden zu installieren), sollten damit eigentlich die meisten Fälle abgedeckt sein. Ich baue öfter irgendwelche Pakete selber, wenn sie von der von mir verwendeten Distribution nicht (oder nur in einer älteren Version) Unterstützt werden, und habe dabei noch nie aufgeben müssen. > Heute mit Tausenden zirkularen Abhaengigkeiten ist das ein Problem. ffmpeg ist natürlich ein schwieriges Beispiel, da es eine große Zahl von Programmen und Bibliotheken unter einem Hut zusammenfasst und deswegen naturgemäß sehr viele Abhängigkeiten aufweist. Das treibt den Aufwand für das Selberbauen und -installieren entsprechend in die Höhe. Dass es vor 20 Jahren noch keine diesbezüglichen Probleme gab, liegt einfach daran, dass es noch kein ffmpeg gab :)
Hallo, dann hast du entweder sehr viel Ahnung vom Pakete bauen oder bis jetzt Glück gehabt. Denn in der Regel zerschießt man sich dabei auch Pakete die man wieder reparieren muss. Klar ist auch das wieder lösbar, aber nicht vom normalen Linuxnutzer. Der große Vorteil ist gleichzeitig der Nachteil wenn es schief geht. Ich durfte die Erfahrung bei einem Gnome Upgrade machen auf meinem PC. Habs nur mit Forumshilfe wieder hinbekommen.
Yalu X. schrieb: > Weder das Odroid-Board noch der ARM noch Linux im Allgemeinen noch > Ubuntu können etwas dafür, wenn du dir selber alle Steine der Welt in > den Weg legst ;-) Wie geschrieben: Auf einem normalen Desktop-PC konnte ich ffmpeg-4 unter 16.04LTS problemlos installieren, auf dem ebenfalls unter 16.04 laufenden Einplatinenrechner aber nicht. Scheint also kein generelles Problem des zugrundeliegenden ppas zu sein. Und überhaupt: Wer beschränkt sich schon auf nur in universe und multiverse vorhandene packages? Da ist die Auswahl teilweise sehr beschränkt, so war z.B. ffmpeg für 16.04 offiziell nur bis Version 2.8.15 verfügbar. Die Version war quasi schon mit Veröffentlichung von 16.04 veraltet. Ich update nicht das Betriebssystem (also auf 18.10), nur um ein Programm lauffähig zu bekommen. Zumal besagtes Programm selbst gar nicht auf Komponenten des neuen OS angewiesen ist.... https://launchpad.net/~jonathonf/+archive/ubuntu/ffmpeg-4
Veit D. schrieb: > dann hast du entweder sehr viel Ahnung vom Pakete bauen oder bis jetzt > Glück gehabt. Denn in der Regel zerschießt man sich dabei auch Pakete > die man wieder reparieren muss. Fremdpackete baut man idealerweise so, dass diese inklusive deren benötigte Libraries in einem separatem Unterverzeichnis liegen. Üblich sind /usr/local/ oder opt. Dann überschreibt man sich auch keine offiziellen Libraries der Distro. Musst halt das prefix richtig setzen.
> Da ist meiner Erfahrung nach heute immer noch so. Wenn man bereit ist, > selber etwas Hand anzulegen Ich sag ja auch nicht das es unmoeglich ist, aber das "etwas" ufert immer mehr aus. Ich hab bisher auch noch alles hinbekommen. Aber Sachen die frueher ein paar Stunden gebraucht haetten dauern jetzt gerne mal Tage. Es gibt im uebrigen noch jemand der da meiner Meinung ist. :-) Auf Youtube gibt es ein Video einer Fragestunde in einer Uni mit Linus wo er das auch beklagt. Und nicht vergessen, wir sind mit Linux gross geworden und kennen darin jede Schraube. Aber bei dem Nachwuchs sieht das anders aus. Wenn die ploetzlich von Win10 zu Linux ruebergeschubst werden weil Linux heute im Embeddedbereich immer selbstverstaendlicher wird dann klappern die mit den Zaehnen. Olaf
Veit D. schrieb: > dann hast du entweder sehr viel Ahnung vom Pakete bauen oder bis jetzt > Glück gehabt. Wahrscheinlich letzteres ;-) > Denn in der Regel zerschießt man sich dabei auch Pakete > die man wieder reparieren muss. Wichtig ist, dass man keine Pakete löscht bzw. ersetzt, zu denen noch weitere Abhängigkeiten bestehen könnten. Sonst kommt man unweigerlich in Teufels Küche. Von den shared Objects kann man dank den Versionsnummern in den Dateinamen mehrere Versionen parallel im /usr/lib installieren. Gibt es noch weitere Dateien, die kollidieren können, macht man es so: DPA schrieb: > Fremdpackete baut man idealerweise so, dass diese inklusive deren > benötigte Libraries in einem separatem Unterverzeichnis liegen. Markus schrieb: > Wie geschrieben: Auf einem normalen Desktop-PC konnte ich ffmpeg-4 unter > 16.04LTS problemlos installieren, auf dem ebenfalls unter 16.04 > laufenden Einplatinenrechner aber nicht. > Scheint also kein generelles Problem des zugrundeliegenden ppas zu sein. Das Problem bei den PPAs ist halt leider, dass sie i.Allg. nur auf einer einzigen Plattform getestet worden sind, nämlich auf der des Erstellers. Für alles andere kann es keine Funktionsgarantie geben. Markus schrieb: > Ich update nicht das Betriebssystem (also auf 18.10), nur um ein > Programm lauffähig zu bekommen. Zumal besagtes Programm selbst gar nicht > auf Komponenten des neuen OS angewiesen ist.... Klar, das würde ich auch nicht tun. Ich dachte nur, du hättest das Ubuntu frisch installiert, aber vielleicht war das ein Missverständnis: Markus schrieb: > Eigentlic benutze ich diesen nur mit LibreElec als Kodi-Mediacenter, > aber da ich ein VPN benötige, habe ich gestern mal das Ubuntu > 16.04-Image installiert. Olaf schrieb: > Es gibt im uebrigen noch jemand der da meiner Meinung ist. :-) Auf > Youtube gibt es ein Video einer Fragestunde in einer Uni mit Linus wo er > das auch beklagt. Ach, der Linus – so sehr ich ihn mag – ist ein alter Stänkerer ;-)
Yalu X. schrieb: > aber vielleicht war das ein Missverständnis: Das war ein Mißverständnis meinerseits: Zwar gibt es für den Odroid ein 18er-Image, aber ich habe explizit die 16er-Version gewählt, weil ich diese von meinem Desktop-PC kenne und keine Überraschungen erleben wollte. Offensichtlich falsch gedacht ;-)
Der Werbeslogan ist schon lustig: sehr nah am Desktop-PC :) Ja, wenn man ignoriert dass so ein PC so etwas wie eine Harddisk, SATA, Flash hat. Gerade lese ich tolle Storys: Der 40pol Header sei nun auf die alte P-ATA IDE HDD umgemodelt worden :D :D
:
Bearbeitet durch User
> Der Werbeslogan ist schon lustig: sehr nah am Desktop-PC :) > Ja, wenn man ignoriert dass so ein PC so etwas wie eine Harddisk, SATA, > Flash hat. Warum? Steck eine 128GB microSD rein und du hast deinen Desktop-PC. Nimm aber eine die genauso teuer ist wie der RP und auf haeufiges schreiben ausgelegt ist. Natuerlich, SATA waere besser, aber ist ja auch nur nah dran am PC. .-) Vermutlich ist die connectivity schon groesser wie bei irgendeinen beliebigen Apple PC der letzten Jahre. :-p Olaf
Olaf schrieb: >> Der Werbeslogan ist schon lustig: sehr nah am Desktop-PC :) >> Ja, wenn man ignoriert dass so ein PC so etwas wie eine Harddisk, SATA, >> Flash hat. > > Warum? Steck eine 128GB microSD rein und du hast deinen Desktop-PC. > Nimm aber eine die genauso teuer ist wie der RP und auf haeufiges > schreiben ausgelegt ist. Natuerlich, SATA waere besser, aber ist ja auch > nur nah dran am PC. .-) > Vermutlich ist die connectivity schon groesser wie bei irgendeinen > beliebigen Apple PC der letzten Jahre. :-p > > Olaf Ich habe eine SSD über USB dran, das funktionierte bisher deutlich besser als jede microSD. Selbst Swap ist kein Problem. Gruß Axel
Der Dual 4k "Schnickschnack" ist durchaus ein starker Kaufgrund und Alleinstellungsmerkmal. Falls es nämlich in Zukunft wieder einen steuerbaren Player wie den omxplayer und einen gpu beschleunigten chromium Browser gibt wird das Teil sehr interessant um es als gesteuerten standalone player z.B. für Mappings mit zwei Projektoren oder mehreren Displays im Werbe- oder Ausstellungsbereich umzusetzen. Früher zigfach eingesetzt und sehr Stabil. Morgens Strom an, Abends Strom aus. Mit read-only über Monate stabil. 4k ist nun Standard und da kommt er genau richtig. Die Alternativen sind bisher BrightSign Windows PCs (intel nuc, shuttle ...) inklusive Angst vor leeren Bios-Batterien diverse neue 4k signage player die jetzt nach und nach auf den Markt kommen. Alle >800€.
Wie es schon ein gewisser Webcomic ausgedrückt hat: https://www.xkcd.com/619 Es stimmt, der Raspi war als Bastelrechner gedacht. Dafür kann man aber auch noch die erste Version verwenden. Was mir fehlt, sind ein paar Fixes: Wenn ich unter BerryBoot neustarte (immerhin kann ich unter BB auch fast jedes System verwenden) ist nachher jedes Mal das OS hin umd ich kann das neu installieren. Auch umfangreiche Einstellmöglichkeiten ohne Console wären schön, denn wenn man als Einsteiger da rangeht will man sich nicht erst durch xtausend Seiten Dokumentation fressen müssen. Wie gesagt kann man für Projekte wo man nur "ein bisschen rumbasteln" will, auch einen älteren Raspi verwenden. Der neue ist eher für den "Bilschirmbetrieb", also für die Verwendung als Rechner der etwas auf einem (oder jetzt auch zwei) Bildschirmen anzeigen soll. Da muss man auch einfach erkennen, das sich die Ausrichtung des Raspi (und eigentlich die jedes Produktes) seinem Hauptverwendungszweck anpasst. Wem das nicht passt, der soll von mir aus einen kleinen Einplatinen-PC selber konfigurieren und bauen, oderan lebt mit den Krücken wie USB-zu-SATA-Adaptern. Es ist ganz einfach eine Frage der Alternativen... vincentg
olaf schrieb: > atuerlich nicht. Aber Linux 0.95a auf einem 386sx (später 486DLC) mit > 6MByte war gefuehlt so schnell wie ein Raspberry mit heutiger > Software. :-D Auf einem 368sx hat ein gcc-build 1-3 Tage gedauert.
Vincent G. schrieb: > Auch umfangreiche Einstellmöglichkeiten ohne > Console wären schön Brauchst du mehr als Raspi Config? Das hat inzwischen eine GUI.
Ist der ETH-Anschluss jetzt wirklich nicht mehr über USB drangefrickelt? Weiss das jemand verbindlich? Dann könnte es sich lohnen das Teil mal zu betrachten.
Doku lesen hilft: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/README.md "It [BCM2711 SOC] has a greatly improved GPU feature set with much faster input/output, due to the incorporation of a PCIe link that connects the USB 2 and USB 3 ports, and a natively attached Ethernet controller."
"and a natively attached Ethernet controller." danke. klingt doch gut. dann bin ich mal gespannt, wann es ankommt.....
Gibt auch mittlerweile zahlreiche Benchmarkings auf YouTube, die dir das und die anderen optimierten Features ebenfalls bestätigen bestätigen können.
Dann bin ich sehr gespannt. Ich habe die letzten 4 Wochen recht sinn- und ergebnisfrei mit einem stm32 rumprobiert und bin ein wenig frustriert. Es wäre schön, wenn man aus dem Raspi jetzt auch zuverlässige Responsezeiten im 2-stellingen usec-Bereich rausholen könnte.
> Es wäre schön, wenn man aus dem Raspi jetzt auch zuverlässige > Responsezeiten im 2-stellingen usec-Bereich rausholen könnte. Das wird wohl kaum gehen, noch kann man es von einem Multiuser-Multitasting Betriebsystem ohne Echtzeitanspruch erwarten. Olaf
Olaf schrieb: > Das wird wohl kaum gehen, noch kann man es von einem > Multiuser-Multitasting Betriebsystem ohne Echtzeitanspruch erwarten. a) warum sollte es nicht gehen? b) wer sagte, dass es überhaupt unter einem "Multiuser-Multitasting Betriebsystem" laufen soll? c) weisst Du schon näheres über die Latency des Raspi 4 unter rt-linux?
Sobald ein OS dazwischen hängt, kannst du keine stabile ns oder niedrige µs erwarten. RT Linux kann nur niedrigere Latenzen sicherstellen oder gar garantieren. Aber Zeiten wie unter direkter Programmierung sind nicht möglich. Auch werden die Latenzen unter RT-Linux schwanken. Das Einzigste was hier sichergestellt ist ist, dass sie eine gewisse Maximal-Latenz nicht überschreiten.
Veit D. schrieb: > Sobald ein OS dazwischen hängt, kannst du keine stabile ns oder niedrige > µs erwarten. RT Linux kann nur niedrigere Latenzen sicherstellen oder > gar garantieren. Aber Zeiten wie unter direkter Programmierung sind > nicht möglich. Auch werden die Latenzen unter RT-Linux schwanken. Das > Einzigste was hier sichergestellt ist ist, dass sie eine gewisse > Maximal-Latenz nicht überschreiten. Du musst schon präziserer werden. Mit deiner Antwort kann man nichts anfangen.
Wicki W. schrieb: > Ist der ETH-Anschluss jetzt wirklich nicht mehr über > USB drangefrickelt? > > Weiss das jemand verbindlich? > > Dann könnte es sich lohnen das Teil mal zu betrachten. Nein. Aktuelle c't 15/19 Seite 16. Im BCM2711 ist der MAC integriert der über einen PHY BCM54213PE Gbit Ethernet zur Verfügung stellt. Damit sind voll 100MB/s möglich. Der USB 3.0 Controller ist per PCI Express angebunden. Hier sind bis zu 80MB/s drin. Wenn Rasbian im Laufe der Zeit noch vollständig angepasst wird ist und bleibt ein Raspi die Eierlegendewollmilchsau. Man hofft ja immer noch auf ARMv8 Support. Der SoC kann es schon länger.
Bernd schrieb: > Veit D. schrieb: > >> Sobald ein OS dazwischen hängt, kannst du keine stabile ns oder niedrige >> µs erwarten. RT Linux kann nur niedrigere Latenzen sicherstellen oder >> gar garantieren. Aber Zeiten wie unter direkter Programmierung sind >> nicht möglich. Auch werden die Latenzen unter RT-Linux schwanken. Das >> Einzigste was hier sichergestellt ist ist, dass sie eine gewisse >> Maximal-Latenz nicht überschreiten. > > Du musst schon präziserer werden. Mit deiner Antwort kann man nichts > anfangen. Was ist denn unklar?
PCIe 1.0 = 250 MBytes/sek inzwischen sind wir bei 5.0 ist also die Frage welche Version verwendet wird. und ob sichs beide USB3.0 Anschlüsse teilen.
>> Einzigste was hier sichergestellt ist ist, dass sie eine gewisse >> Maximal-Latenz nicht überschreiten. mehr will ich ja gar nicht... wenn ich zuverlaessig auf unter 100usec komme, dann bin ich schon ganz gut zufrieden. je kleiner die 2-stelligen werte werden, um so besser. und was das OS angeht: wenn das mit 2 cores laeuft, dann reicht mir das. wenn ich dann noch 2 zum spielen uebrig habe reicht mir das auch. mein problem war bislang, dass auch immer noch irgendwelches gehaenge (vermutlich wg. des usb-eth) auftrat. mal abwarten, wie das beim PI4 aussieht. vielleicht ist das ding ja sogar flott genug, um linCNC mit stepgen brauchbar direkt zu betreiben.... (da zweifel ich aber noch etwas dran)
Wicki W. schrieb: > mehr will ich ja gar nicht... > wenn ich zuverlaessig auf unter 100usec komme, dann bin > ich schon ganz gut zufrieden. Da wird man auch mit einem Realtime-Linux nicht drankommen. Hier mal ein Latency-Plot von einem Raspi2 mit Realtime-Linux: https://www.osadl.org/Long-term-latency-plot-of-system-in-rack.qa-3d-latencyplot-rbs3.0.html?shadow=0 Man sieht: Unter 200 µs geht, aber unter 100 nicht. Hier übrigens mal zum Vergleich ein Raspi3, aber mit einem nicht-Realtime-Kernel: https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs3.0.html?shadow=1
Wenn ich kleine Schaltungen bauen möchte, muss ich mir dann für jede Schaltung einen sau teuren Raspi kaufen, oder könnte ich das auch mit einem Microcontroller für 2 € ?
Wicki W. schrieb: > und was das OS angeht: wenn das mit 2 cores laeuft, dann > reicht mir das. > wenn ich dann noch 2 zum spielen uebrig habe reicht mir > das auch. Wäre schon interessant wenn sowas ginge, aber fürchte das Lässt die Architektur nicht zu. Z.B. gibt es Cache der für alle cores ist. Daraus resultiert bereits dass ein Core u.U. auf andere Cores warten muss. Wenn ich mich nicht irre hat aber der Beaglebone extra zwei zusätzliche Cores die sich separat ansprechen lassen. Programmierung damit scheint aber recht umständlich zu sein. Die übliche Problemlösung für solche Fälle im Bastler-Umfeld: Latenzsensitives mit einem Arduino regeln und diesen per UART, SPI oder I2C mit dem Raspi kommunizieren lassen. Netter Nebenefekt davon: Man kann das Arduino-Programm schön über den PC Testen/Debuggen und muss nicht alles auf dem Raspberry machen (wobei das beim schnelleren 4er wohl angenehmer als früher geworden sein dürfte). Im idealfall kann der Arduino auch bereits erste Berechnungen durchführen die den Datendurchsatz zum Raspi verringern. Als Datenlogger der Echtzeitdaten ohne große Verarbeitung direkt ins Ethernet pumpt ist der Raspi nicht die erste Wahl. Herbert schrieb: > Wenn ich kleine Schaltungen bauen möchte, muss ich mir dann für jede > Schaltung einen sau teuren Raspi kaufen, oder könnte ich das auch mit > einem Microcontroller für 2 € ? Das ist extrem anwendungsspezifisch. Gelegentlich kann hinter so einer "kleinen Schaltung" mehr stecken als man denkt. Daher: Zuerst planen was man braucht. Vieleicht sogar das Programm (z.b. in C) auf dem PC programmieren und mit generierten Input-Daten (statt Sensoprwerten etc.) testen. Dann sieht man was für ressourcen der Mikrocontroler später braucht.
:
Bearbeitet durch User
Herbert schrieb: > Wenn ich kleine Schaltungen bauen möchte, muss ich mir dann für jede > Schaltung einen sau teuren Raspi kaufen, oder könnte ich das auch mit > einem Microcontroller für 2 € ? Das kommt - wie so oft - drauf an. Für eine blinkende LED brauchst du keinen Raspi. Willst du aber ein Display anschließen und eine schöne Bedien-Oberfläche haben, das Bild einer Kamera einlesen, Bewegungen im Bild erkenenen und es per WLan verschicken, dann könnt's mit dem 2€-µC etwas eng werden.
mit dem 2-EUR uC wird es schon etwas eng, wenn man gerne eth haben möchte - oder haben muss. klar, man kann vieles per software selbst von hand stricken. aber selbst wenn man nur ein raw-eth-paket senden will, ist man damit schon ganz gut beschaeftigt. deutlich länger als mit einem sendmsg(). ;-) Wicki W. schrieb: > > wenn ich zuverlaessig auf unter 100usec komme Rolf M. (rmagnus) schrieb : > Da wird man auch mit einem Realtime-Linux nicht drankommen. > Man sieht: Unter 200 µs geht, aber unter 100 nicht. hab ich selbst auch ausprobiert. http://erste.de/ethraw/readme.de.html#5kHz daher bis ich ja gespannt, was das PI4 kann.
grade mit reichelt telefoniert: über 30k im rückstand - nun angekündigt für freitag. (wird aber bestimmt auch nix werden) grmbl hat jemand eine idee, wo ich kurzfristig eins beschaffen kann?
Schau mal bei den Briten, schließlich sind die ja immer noch in der EU: https://thepihut.com/ https://shop.pimoroni.com/ Lieferzeit und Versand sind auch nicht viel langsamer oder teurer als wenn man in Deutschland bestellt.
tja, leider wahr: musste ich bei amazon (fernversand aus GB ordern). Garantiertes Lieferdatum für diesen Artikel: 11. Juli 2019 alle anderen kuendigen nur an "voraussichtlich 10.-19.7."
Hallo, das schweift zwar hier schon ganz schön ab, aber warum lässt du nicht deine Motoren von µC'er steuern und nutzt den Raspi nur zur Steuerung dieser. Raspi 4 Bestellungen: Immer diese Drängler. :-) Wäre er nicht da ginge es auch weiter. Ist er da muss er schon gestern auf dem Tisch liegen. Zudem ich jetzt noch keinen kaufen würde. Raspian muss erstmal fertig angepasst sein. Für deine CNC reicht auch ein 3B+.
> Zudem ich jetzt noch keinen kaufen würde. Raspian muss erstmal > fertig angepasst sein. Sehe ich auch so. Erstmal noch wenigstens zwei Monate warten. Ausserdem hat man dann was fuer die kalten Wintermonate. .-) Olaf
> Zudem ich jetzt noch keinen kaufen würde. Raspian muss erstmal > fertig angepasst sein. wer sagt, dass man "Raspian" benutzen will? und man kann auch kernel compilieren.... aber ob der läuft, das sieht man erst, wenn man eins auf dem tisch liegen hat.
Wicki W. schrieb: > und man kann auch kernel compilieren.... Siehe debian-arm Mailing-List: https://lists.debian.org/debian-arm/2019/07/msg00036.html > * Date: Mon, 8 Jul 2019 11:27:30 -0400 > > Debian almost certainly won't run. I don't even see RPi4 support in the > linux kernel upstream yet, so Raspbian is using a patched kernel to make > it work I suspect. Debian won't patch in support for anything that > isn't already supported upstream in the kernel. > > So for now, most likely Raspbian is the only thing that will run easily > on the RPi4. > > -- > Len Sorensen
heise schreibt (und ich unterstelle mal, dass sie halbwegs wissen was sie tun): An Raspbian muss die Entwickler-Community allerdings noch gehörig schleifen und polieren, weil vieles noch nicht klappt: Booten per USB und Netz, 64-Bit-Kernel und -Anwendungen, H.265-Videos und die Einbindung der Video-Decoder in Chromium und andere Software. Auch der Zwei-Schirm-Betrieb ist noch nicht ohne Tücken. das sind alles Sachen, die mich nicht die Bohne interessieren. Ich will nur sehen, wie sich Eth- und Echtzeit-/Timingverhalten gegenüber den Vorgängerversionen geändert haben. Und ich hoffe, dass ich das bald testen kann ;-)
Hallo, für den Raspi 4 verwendet Raspian das frische Debian Buster. Logisch das da noch Anpassungen notwendig sind. Funktionieren tut es, es wird an Feinheiten geschraubt. Die Kerne werden aber weiterhin nur mit ARMv7 Support laufen. Ob irgendwann ein 64Bit Raspian mit ARMv8 Support kommt weiß niemand. ARMv8 wäre bestimmt nett weger der möglichen besseren Nutzung der Kerne und damit möglichen höheren Rechenleistung. Egal, Raspi bleibt für seinen Zweck dennoch die Nummer 1.
Hallo, bevor hier jemand unvollständig zitiert. Entweder c't 15/19 lesen oder https://www.heise.de/ct/artikel/c-t-uplink-28-2-Raspberry-Pi-4-Tipps-zum-Monitor-Kauf-5G-Start-in-Deutschland-4462404.html anschauen
Ich nutze bei RaspBerryPi die H.264 Encoding Funktion um einen Videostream über das Netzwerk zu schicken, mit 1640x1232 Pixel (2x2 Pixel zusammen gefasst für weniger Bildrauschen). Es wäre doch toll wenn ich den Stream mit H.265 (also mit dem neueren Format) Encodieren könnte. Warum wurde das nicht in den RP4 integriert? Die Decodierung funktioniert ja. Ist diese Hardware-Funktionalität schlichtweg nicht im aktuellen Video-Core drin?
> Ob irgendwann ein 64Bit Raspian mit ARMv8 Support kommt > weiß niemand. Wer mag, kann es ja mit Buster für arm64 versuchen, das scheint passend für den SoC des Pi4. Kann mir aber auch gut vorstellen, dass es in nicht zu ferner Zukunft was darauf basierendes fertig für den Pi geben wird. https://www.debian.org/ports/
Christoph B. schrieb: > die Stromversorgung erfolgt über USB-C nur so nebenbei: Es ist jetzt ganz offiziell, dass sie die Stromversorgung für den RPi 4 versemmelt haben. Er kann mit manchen Ladegeräten bzw. Ladekabeln nicht ordentlich mit Strom versorgt werden, weil diese fälschlicherweise (oder besser gesagt zu recht) annehmen der Raspberry sei ein "Audio Adapter Accesory". Es wurde ein Widerstand zu viel wegrationalisiert ;) https://arstechnica.com/gadgets/2019/07/raspberry-pi-4-uses-incorrect-usb-c-design-wont-work-with-some-chargers/
> Es ist jetzt ganz offiziell, dass sie die Stromversorgung für den RPi 4 > versemmelt haben. Interessant waere ja ob die Leiterbahnen zugaenglich sind damit man das hinbiegen kann oder ob sie in einer Zwischenlage sind. Sonst waere es wohl besser die naechste Boardrevision abzuwarten. Olaf
Christopher J. schrieb: > Es ist jetzt ganz offiziell, dass sie die Stromversorgung für den RPi 4 > versemmelt haben. so lange man irgendwo 5v anlöten kann ist mir auch das erst mal egal....
An USB-C ist nur der Stecker Standard, alles Andere ist Glückssache ;)
> An USB-C ist nur der Stecker Standard, alles Andere ist Glückssache ;)
Das hab ich auch schonmal gedacht. :-)
Ich warte noch darauf das die erste Kombination aus Ladegeraet, Kabel
und Geraet die alle knapp am Standard vorbei sind 12V/5A an ein Device
liefern das damit nicht klar kommt.
Olaf
Mw E. schrieb: > An USB-C ist nur der Stecker Standard, alles Andere ist Glückssache ;) In der Tat. Mein neues Firmennotebook hat auch so eine Buchse. Also einen passenden USB3.1-Hub geholt, angesteckt, geht nicht. Alle Geräte haben Strom, aber nichts wird erkannt. User Manual runtergeladen, mehrfach durchgelesen -- siehe da: die Buchse ist eine "Thunderbolt-Ladebuchse". Da kann man das Notebook aufladen, da kann man Geräte am Notebook aufladen, oder eine Dockingstation anschliessen. Aber USB kann diese USB-C-Buchse nicht. Immerhin können sich Smartphone und Notebook über diese Buchse abwechselnd gegenseitig aufladen :-)
"Thunderbolt-Ladebuchse"
warum assoziiere ich da jetzt "Donnerbalken"?
...oooo{... sinnier ...}
Olaf schrieb: > Interessant waere ja ob die Leiterbahnen zugaenglich sind damit man das > hinbiegen kann ... Angeblich hätten zwei 5,1kOhm Widerstände verbaut werden, aber es wurde nur einer verbaut. Komisch dass noch niemand davon mal ein Foto im Netz gepostet hat.
> Angeblich hätten zwei 5,1kOhm Widerstände verbaut werden, aber es wurde > nur einer verbaut. Es wurden zwei Leitungen am USB-C Port zusammengelegt. Man muesste diese Verbindung auftrennen und da einfach noch einen weiteren 5.1k nach Vcc oder GND (weiss ich jetzt nicht) dran machen. Die Frage ist halt nur wie zugaenglich diese Verbindung ist. Wenn das irgendwo auf der Unterseite ist dann waere das ja gar kein Problem. Naja, wenn das es geht wird es hoechstens noch 8h dauern bis die ersten Anleitungen dazu beim Youtube auftauchen. :) Olaf
Olaf schrieb: > ch warte noch darauf das die erste Kombination aus Ladegeraet, Kabel > und Geraet die alle knapp am Standard vorbei sind 12V/5A an ein Device > liefern das damit nicht klar kommt. könnte hier schon passiert sein: https://forum-raspberrypi.de/forum/thread/43563-rpi4-4gb-zeigt-kein-bild-stinkt-und-wird-extrem-hei%C3%9F/?pageNo=1 Also Vorsicht mit Quickcharge Netzteilen. Habe auch einen RPi4 bestellt, den werde ich mit so einem Kabel https://www.reichelt.de/usb-3-1-c-stecker-freie-enden-ws-1-8-m-usb-c-10080115-p208105.html?r=1 an ein 5V Festpannungsnetzteil anschliessen.
Gibts irgendwo einen vertrauenswürdigen Link, wo man die 5V beim PI4 am sinnvollsten einspeist, wenn man keinen usb-c stecker verwendet?
Wicki W. schrieb: > Gibts irgendwo einen vertrauenswürdigen Link, > wo man die 5V beim PI4 am sinnvollsten einspeist, > wenn man keinen usb-c stecker verwendet? Das würde mich auch interessieren. Beim 3er war, wenn ich mich recht entsinne, das Problem, wenn man über den PinHeader eingespeist hat, dass man die Polyfuse "übersprungen" hat.
Wicki W. schrieb: > Gibts irgendwo einen vertrauenswürdigen Link, > wo man die 5V beim PI4 am sinnvollsten einspeist, > wenn man keinen usb-c stecker verwendet? Der Raspi hat ja schon seit dem aktuellen 3er, PoE pins. Damit sollte es gehen.
Chris M. schrieb: > Beim 3er war, wenn ich mich recht > entsinne, das Problem, wenn man über den PinHeader eingespeist hat, dass > man die Polyfuse "übersprungen" hat. Beim 3B+ gibt es keine Polyfuse auf der Platine! Die Anschlüsse sind also nicht mehr gegen Überstrom geschützt. Die haben damals schon mitbekommen dass die Leute ihren RaspBerryPi oft über den USB-Hub mit Spannung versorgen. Da fließt dann der Strom vom Hub über den USB-Anschluss in den RaspBerryPi. Der Vorteil liegt darin dass die Peripherie, welche am Hub hängt, nicht über den mini-USB-Anschluss versorgen muss. Da glüht dann doch der winzige Kontakt oder es entsteht ein großer Übergangswiderstand durch die Hitze und dem Strom. Es ist dann egal wie hoch der Strom ist der von der Peripherie gezogen wird. Wenn man die 5V direkt an dem 5V Pin am Header einspeist dürfte nichts passieren. So habe ich das auch mit einem RaspBerryPi 2b gemacht und es läuft gut.
> wo man die 5V beim PI4 am sinnvollsten einspeist, > wenn man keinen usb-c stecker verwendet? Wenn du kein USB-C verwenden willst dann könntest du trotzdem USB-C verwenden. :-) Also ein USB-C Kabel nehmen, den Stecker auf der einen Seite abkneifen und direkt an dein 5V Netzteil anklemmen. Letztlich ist das ja auch nur eine Steckverbindung an der GND und 5V vom RP an den richtigen Kontakten angelegt werden muss. BTW: Was ist eigentlich der Sinn der SMBJ5.0 im Schaltplan des RP? Wenn die leitend wird dann hat der RP doch IMHO sowieso diese Welt verlassen. Olaf
Olaf schrieb: > Wenn du kein USB-C verwenden willst dann könntest du trotzdem USB-C > verwenden. :-) was voraussetzt, ein usb-c kabel zu haben. und neben USB 2, Standard-A,Standard-B, USB 3 Powered-B, Mini-A USB 2,Mini-B USB 2, Micro-A USB 2,Micro-B USB 3,Micro-B USB 3.1 und einigen herstellerspezifischen steckern, die so ähnlich aussehen, habe ich es bislang erfolgreich geschafft, Typ C von mir fern zu halten. mich nervt es, das einfach alle immer "intelligent" sein muss. auch netzteile, die nichts anders machen sollen, als 5 V zu liefern. auch wenn es abschweift: wie bitte soll sowas funktionieren? https://www.lidl.de/de/silvercrest-universal-laptop-netzteil/p298745?gclid=EAIaIQobChMItOrZlIas4wIVT-d3Ch2V6Q9eEAQYASABEgIUJPD_BwE technische daten? och, noeee... nicht so wichtig... "Automatische Spannungseinstellung" kann ich damit ein raspi versorgen, wenn ich es in ein laptop-gehaeuse einbaue?
Wicki W. schrieb: > Olaf schrieb: >> Wenn du kein USB-C verwenden willst dann könntest du trotzdem USB-C >> verwenden. :-) > > was voraussetzt, ein usb-c kabel zu haben. Gerüchten zufolge gibt es Menschen, die haben so viele davon, dass sie sie verkaufen müssen. > und neben USB 2, Standard-A,Standard-B, > USB 3 Powered-B, Mini-A USB 2,Mini-B USB 2, > Micro-A USB 2,Micro-B USB 3,Micro-B USB 3.1 > und einigen herstellerspezifischen steckern, > die so ähnlich aussehen, habe ich es bislang > erfolgreich geschafft, Typ C von mir fern zu halten. Das wird dir auf Dauer wohl nicht gelingen. Das soll ja in Zukunft der neue eine Standard-Stecker werden. > mich nervt es, das einfach alle immer "intelligent" > sein muss. auch netzteile, die nichts anders machen > sollen, als 5 V zu liefern. Die machen inzwischen deutlich mehr, z.B. mit höherer Spannung laden, damit das Smartphone mit großem Akku nicht ewig laden muss. Bei meinem wird z.B. zum Schnellladen auf 9V hochgeschaltet. Von Laptops ganz zu schweigen. Die Spannung kann auf bis zu 20 V erhöht werden. Zusätzlich gibt's Geräte, die den Strom entgegennehmen oder selber liefern können, je nachdem, was angeschlossen ist. Das muss dann eben alles mit dem Netzteil ausgehandelt werden. > auch wenn es abschweift: > wie bitte soll sowas funktionieren? > > https://www.lidl.de/de/silvercrest-universal-laptop-netzteil/p298745?gclid=EAIaIQobChMItOrZlIas4wIVT-d3Ch2V6Q9eEAQYASABEgIUJPD_BwE > > technische daten? och, noeee... nicht so wichtig... > "Automatische Spannungseinstellung" Im Stecker ist eine Kodierung. Du schaust im Handbuch nach, welcher Stecker zu deinem Laptop passt, steckst den drauf, und er sagt dem Netzteil welche Spannung es einstellen soll. > kann ich damit ein raspi versorgen, wenn ich es in ein > laptop-gehaeuse einbaue? Wenn dieser Laptop mit 5V geladen werden wollte, ja.
:
Bearbeitet durch User
Wäre vllt gut vorweg die fehlerhafte USB-C Schaltung zu erwähnen. Ich werde mir den Raspi erst holen wenn das behoben ist.
Die Performance rockt jedenfalls :-) https://hackaday.com/2019/07/10/raspberry-pi-4-benchmarks-processor-and-network-performance-makes-it-a-real-desktop-contender/
Wicki W. schrieb: > https://www.lidl.de/de/silvercrest-universal-laptop-netzteil/p298745?gclid=EAIaIQobChMItOrZlIas4wIVT-d3Ch2V6Q9eEAQYASABEgIUJPD_BwE > > technische daten? och, noeee... nicht so wichtig... > "Automatische Spannungseinstellung" Da steht es etwas verschlüsselt, aber es sind wohl 19V. Leistung: 90 W Ausgangsstrom: 4.74 A "Automatische Spannungseinstellung" Ich bin mir sicher dass es da keinen dritten Pin gibt durch den eine intelligente Kommunikation mit dem Netzteil ermöglicht wird. Das ist ein einfaches 19V Netzteil mit ein paar Adaptern.
Wurstrakete schrieb: > Die Performance rockt jedenfalls :-) > > https://hackaday.com/2019/07/10/raspberry-pi-4-benchmarks-processor-and-network-performance-makes-it-a-real-desktop-contender/ Wie kann es ohne jegliche Veränderung des Wifi-Chips und dessen OnBoard-Antenne zu so erheblichen Verbesserungen kommen?
Atmega8 A. schrieb: > Ich bin mir sicher dass es da keinen dritten Pin gibt durch den eine > intelligente Kommunikation mit dem Netzteil ermöglicht wird. Das ist ein > einfaches 19V Netzteil mit ein paar Adaptern. das nehme ich auch an - daher ist es eigentlich Betrug. Zumindest unlautere Werbung. Was sagt denn z.b. der eeePC z.b. zu so einem Netzteil? Aber wir kommen vom Thema ab.... ;-) Die 5V beim Raspi 4 also wohl am besten via Pin 6(-) und 4(+) einspeisen? Spricht das was gegen?
Peter Petersson schrieb: > Wäre vllt gut vorweg die fehlerhafte USB-C Schaltung zu erwähnen. Ich > werde mir den Raspi erst holen wenn das behoben ist. gut wenn viel so denken, dann gibts hoffentlich bald den Resteverkauf der Rev.1 bei Pollin :)
Chris M. schrieb: > Wurstrakete schrieb: >> Die Performance rockt jedenfalls :-) >> >> > https://hackaday.com/2019/07/10/raspberry-pi-4-benchmarks-processor-and-network-performance-makes-it-a-real-desktop-contender/ > > Wie kann es ohne jegliche Veränderung des Wifi-Chips und dessen > OnBoard-Antenne zu so erheblichen Verbesserungen kommen? Die Anbindung an den SOC ist jetzt wohl besser
Erstmal abwarten welche Netzteile wirklich ein Problem damit haben werden. Bin mir recht sicher dass vorallem billige Netzteile nicht diese Strombegrenzung drin haben und darum funktionieren dürften.
Die Lieferzeit meines RPI4 bei Reichelt, hat sich heute um weitere 5 Wochen verschoben anscheinend produzieren die schon neue RPis. Aber die Einspeisung über die PoE Anschlüsse könnte hilfreich sein, den beim 3B und 3B+ hatte ich folgendes Problem beim einstecken einer externen Festplatte stieg immer der Logitech Unitify Empfänger aus da die Platte beim Hochlaufen diesem den Saft wegzog der Strompfad von der µUSB-Büchse quer übers Bord war wohl etwas klein ein Y Adapter hat geholfen die Platte ausreichend zu versorgen. Am besten man holt sich ein Netzteil das nur 5V liefern kann, dann spielt das keine Rolle welche Widerstandskennung das Board aufweist.
Alex G. schrieb: > Der Raspi hat ja schon seit dem aktuellen 3er, PoE pins. Damit sollte es > gehen. Soweit ich weiß, sind die PoE-Pins auf dem 4-Pin-Header Ausgänge, über die man die PoE-Spannung abgreifen und z.B. über das PoE Shield für die 5V-Versorgung nutzbar machen kann...
Wicki W. schrieb: > Es wäre schön, wenn man aus dem Raspi jetzt auch zuverlässige > Responsezeiten im 2-stellingen usec-Bereich rausholen könnte. Das würde ich von einem Linux System generell nicht erwarten.
angekommen... 08/15-netzteil vom marktkauf ran, 16GB-class10-karte rein, mikro-hdmi-d adapter (beide ebenfalls marktkauf) dran. installiert .... und laeuft.... aber die bogomips.... naja.... ;-) PI4 cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 PI-zero cat /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) BogoMIPS : 997.08
Herbert schrieb: > Wenn ich kleine Schaltungen bauen möchte, muss ich mir dann für jede > Schaltung einen sau teuren Raspi kaufen, oder könnte ich das auch mit > einem Microcontroller für 2 € ? Ich kann auch Mikrocontroller für 1€ einsetzen. Ob du das kannst, vermag ich nicht einzuschätzen. Vermutlich wirst du lernen müssen. Du kannst ja mal hiermit antesten, ob Dir Mikrocontroller gefallen: http://stefanfrings.de/mikrocontroller_buch2/index.html
Peter Petersson schrieb: > Wäre vllt gut vorweg die fehlerhafte USB-C Schaltung zu erwähnen. Gerade darum geht's doch hier. > Ich werde mir den Raspi erst holen wenn das behoben ist. Es ist wohl nicht jeder so geduldig :) Stefanus F. schrieb: > Wicki W. schrieb: >> Es wäre schön, wenn man aus dem Raspi jetzt auch zuverlässige >> Responsezeiten im 2-stellingen usec-Bereich rausholen könnte. > > Das würde ich von einem Linux System generell nicht erwarten. Es gibt schon Systeme, die das schaffen. Sowas findet man auch bei OSADL. Hier mal was auf die schnelle gefundenes: https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs5.0.html?latencies=&showno=&shadow=0&slider=171 Oder gar das hier: https://www.osadl.org/Latency-plot-of-system-in-rack-1-slot.qa-latencyplot-r1s0.0.html?latencies=&showno=&shadow=0&slider=285 Atmega8 A. schrieb: > Ich bin mir sicher dass es da keinen dritten Pin gibt durch den eine > intelligente Kommunikation mit dem Netzteil ermöglicht wird. Woher weißt du das so sicher? Man sieht auf den Bildern die Anschlüsse nicht - wenn das denn überhaupt vom gleichen Typ ist und nicht nur "Abbildung ähnlich". Und "intelligente Kommunikation" wäre etwas übertrieben. Im Stecker ist halt ein Widerstand verbaut.
Rolf M. schrieb: >>> Es wäre schön, wenn man aus dem Raspi jetzt auch zuverlässige >>> Responsezeiten im 2-stellingen usec-Bereich rausholen könnte. >> >> Das würde ich von einem Linux System generell nicht erwarten. > > Es gibt schon Systeme, die das schaffen. max interval (in einem 25 us thread) von weniger als 30 und jitter von weniger als 10 das ist schon drin. nur eben mit dem raspi nicht.... heute messe ich an dem 4er auch nicht mehr rum. aber morgen wahrscheinlich.
hmmm.... gibts vom aktuellen kernel keine config.gz in /proc? Linux raspberrypi 4.19.50-v7l+ #895 SMP Thu Jun 20 16:03:42 BST 2019 armv7l GNU/Linux ahja.... ;-) modprobe configs
:
Bearbeitet durch User
Rolf M. schrieb: > Wicki W. schrieb: >> mehr will ich ja gar nicht... >> wenn ich zuverlaessig auf unter 100usec komme, dann bin >> ich schon ganz gut zufrieden. > > Da wird man auch mit einem Realtime-Linux nicht drankommen. Hier mal ein > Latency-Plot von einem Raspi2 mit Realtime-Linux: > https://www.osadl.org/Long-term-latency-plot-of-system-in-rack.qa-3d-latencyplot-rbs3.0.html?shadow=0 > > Man sieht: Unter 200 µs geht, aber unter 100 nicht. > > Hier übrigens mal zum Vergleich ein Raspi3, aber mit einem > nicht-Realtime-Kernel: > https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs3.0.html?shadow=1 Finde schon erstaunlich wie schlecht der Raspi2 etwa gegenüber einem imx6 aussieht: https://www.osadl.org/Long-term-latency-plot-of-system-in-rack.qa-3d-latencyplot-rbs7.0.html?shadow=0
Beitrag #5904565 wurde von einem Moderator gelöscht.
Wicki W. schrieb: > Die 5V beim Raspi 4 also wohl am besten via Pin 6(-) > und 4(+) einspeisen? > Spricht das was gegen? Pin2 und Pin4 als +5V Versorgung. Die GND-Pins je nach Bedarf nutzen. Dieser USB-Anschluss ist eigentlich auch nur dazu gemacht dass man etwas auflädt oder das Gerät schnell ausprobieren kann. Wenn man den RaspBerryPi jedoch dauerhaft betreiben möchte, dann sollte man ein Kabel an die +5V Anschlüsse löten oder stecken. Die meisten Probleme mit dem RaspBerryPi gibt es wegen dieser doofen USB-Stromversorgungs-Anschlüsse. Manchmal ist das schwere USB-Kabel etwas wackelig oder der Übergangswiderstand an den winzigen Kontakten ist immer größer geworden. Wir hatten auch kein Ladegerät verwendet, sondern ein normales 5V/4A Netzteil für die Hutschiene besorgt.
4.19.57-v7+ ist gerade eben offiziell über das normale update rausgekommen.
1 | sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade |
also ich hab gestern versucht, den hier zu compilieren: https://github.com/raspberrypi/linux aber der erwies sich beim erstversuch als wehrig. naher mal weiter sehen. vielleicht sollte ich ja etwas konzentrierter an die sache rangehen ;-) After an upgrade using rpi-update the kernel could be upgraded. The script download the kernel from an other gihub repository rpi-firmware.
das war schon mal nix: rpi-update ..... *** Backing up modules 4.19.50-v7l+ PARTSIZE:268434432 Partition size 255M may not be sufficient for new Pi4 files This could result in a system that will not boot. 256M FAT partition is recommended. Ensure you have a backup if continuing. Would you like to proceed? (y/N) dazu heisst es dann: It's a monster pain to fix that. At the moment the firmware fits in 44MB. ....... That's because gparted can't resize FAT32 partitions that are less than 256MB in size. es geht auch so: sd-karte raus inhalt von /dev/sdx6 sichern sdx7 verkleinern (vorne platz schaffen) sdx6 loeschen und als groessere fat32 neu anlegen inhalt von sdx6 zurueckspielen karte wieder rein und booten rpi-update ..... *** Syncing changes to disk *** If no errors appeared, your firmware was successfully updated to f8060224e53e26cdaea5b9f6f010ac8c3692e2ea *** A reboot is needed to activate the new firmware das tut.... Linux raspberrypi 4.19.57-v7l+ #1244 SMP Thu Jul 4 18:48:07 BST 2019 armv7l GNU/Linux
kernel compilieren auf dem PI4 dauert ca. 1h Linux raspberrypi 4.19.57-v7l+ #1 SMP Fri Jul 12 07:59:48 BST 2019 armv7l GNU/Linux cd linux KERNEL=kernel7l make bcm2711_defconfig make -j4 zImage modules dtbs sudo make modules_install sudo cp arch/arm/boot/dts/*.dtb boot sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/ sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/ sudo cp arch/arm/boot/zImage /boot/$KERNEL.img kann jetzt aber nicht mehr sagen, wie lange es auf den vorgängern gedauert hat
tja, so weit, so gut... aber einen rt-patch gibts fuer den kernel nicht. der letzte 4.19er mit rt-patch ist 4.19.50. der mag sich aber nicht einfach so compilieren lassen: make bcm2711_defconfig *** *** Can't find default configuration "arch/arm/configs/bcm2711_defconfig"! RT ist also wohl erst mal noch nicht. oder hat jemand ne idee ?
> RT ist also wohl erst mal noch nicht. > oder hat jemand ne idee ? Klar, leg dich zurueck und warte einfach mal 6 Monate. Als das Dingen raus kam konntest du ueberall lesen was das fuer eine tolle Ueberraschung war, und damit konnte ja keiner rechnen und es sollte doch eigentlich erst naechstes Jahr... Daraus kann man doch messerscharf schliessen das die ganzen Entwickler fuer Treiber, Kernel und sonstwas auch noch keinen in den Fingern hatten weil das sonst garantiert was durchgesickert waere. Also wird das auch garantiert noch jede Menge Probleme geben. Das geht gar nicht anders. Ich kauf mir einen zu Weihnachten! Olaf
Olaf schrieb: > Klar, leg dich zurueck und warte einfach mal 6 Monate. das ist wenig konstruktiv....
> das ist wenig konstruktiv....
Dann beuge dich vor und hacke die notwendigen Aenderungen selber in den
Kernel. :-p
Olaf
Wicki W. schrieb: > RT ist also wohl erst mal noch nicht. > oder hat jemand ne idee ? Einfach den RaspberryPi Kern selber mit dem passenden RT patch patchen und kompilieren. Hab ich das letzte mal mit 4.9.65-rt56 gemacht und hat ganz akzeptabel funktioniert (für einen RaspberryPi), also mit isolierter CPU ca. 30µs Jitter, max Jitter < 100µs, gut genug für eine 1kHz Servo Schleife. Allerdings musste man die bekannten Dinge mit dem USB IRQ anstellen, und die HW-Beschleunigung für OpenGL deaktivieren, mit aktivierter Beschleunigung wars unberechenbar, ob man OpenGL benutzt hat oder nicht.
hmm. hab da was überlesen. man muss schon einen kern als ausgangsbasis verwenden der sich für den bcm2711 kompilieren lässt. meistens passt auch ein älterer -rt patch (für frühere point-releases), eventuell muss man ein paar hunks minimal anpassen.
"hab da was überlesen. man muss schon einen kern als ausgangsbasis verwenden der sich für den bcm2711 kompilieren lässt." ja... die frage ist: laeuft ein alter kern mit dem PI4 ? ist das problem "nur" der bcm2711 oder gibts noch andere fallen? mal sehen, was man da in den naechsten tagen so rausfindet....
rµ schrieb: > Einfach den RaspberryPi Kern selber mit dem passenden RT patch patchen > und kompilieren. Hab ich das letzte mal mit 4.9.65-rt56 gemacht und hat > ganz akzeptabel funktioniert (für einen RaspberryPi), also mit > isolierter CPU ca. 30µs Jitter, max Jitter < 100µs Dass das für einen Raspi so gut aussieht mag wohl daran liegen das der RPi4 den GCI (Generic Interrupt Controller) von ARM drin hat und keinen speziellen von Broadcom (wie die vorigen Raspis). Habe die Info aus einem Blog-Post in dem es eigentlich um die native 64 Bit Unterstützung des RPi4 geht (sowohl Kernel als auch Userland). Momentan gibt es noch eine Limitierung auf 1GB RAM aber immerhin scheint es schonmal zu funktionieren: https://blog.cloudkernels.net/posts/rpi4-64bit-virt/
da is sie wieder offen, die dose würmer..... da war ja gestern noch ein 4.19.50 drauf... *** Backing up modules 4.19.50-v7l+ jetzt ist es natürlich geplättet durch ein 4.19.57-v7l+ für das 4.19.50 gibts aber ein RT-patch. für 4.9.57 nicht. also den ganzen rotz wieder zurück... grmbl neuinstallation mit altem image bricht jetzt schon zum 2. mal mit "archiv-error" ab. immer bei knapp über 50% (eigentlich untypisch - normal kommen solche errors doch immer erst bei 98 oder 99%) naja... jetzt laeufts und ich schau mal, ob ich den 4.19.50 sauber compiliert bekomme. bislang ja: rund 50 minuten zeitbedarf (PI3 brauchte wohl >60) Linux raspberrypi 4.19.50-v7l+ #1 SMP Sat Jul 13 07:11:29 BST 2019 armv7l GNU/Linux nun mal sehen, ob man gepatched bekommt... patch nochmal 50 minuten compiliern: Linux raspberrypi 4.19.50-rt22-v7l+ #2 SMP PREEMPT RT Sat Jul 13 09:21:03 BST 2019 armv7l GNU/Linux tut offenbar! ;-)
Solange der RPI kwin echtes Windows kann ist er doch eh kein ordentlicher Computer :-)
> olange der RPI kwin echtes Windows kann ist er doch eh kein > ordentlicher Computer :-) Echtes Windows ist X11, Windows fuer Wohngemeinschaften kam spaeter. Olaf
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.