Fuer Linux-Leute: Raspberry-Konkurrent?

Am 16.06.2012 18:25, schrieb Olaf Kaluza:

Es gibt ein paar Produkte, die auf Linux basieren. Insbesondere in der Steuerungstechnik z.B. dieses hier:

formatting link

Bei den ganzen ARM Boards gibt es auch ja noch Unterschiede. Während z.B. der von mir verwendete PanelPC mit einem AT91RM9200 läuft und der Kernel und das rootfs schon angepasste Versionen im FlashROM sind, arbeitet das NanosG20 Board mit einem AT91SAM9G20 und einem Debian für ARM auf der SD-Karte.

Da hat man dann auch den Zugriff auf das volle Repository und kann schnell ein paar Versuche machen. Ich habe an meinem Dev-Board eine

1TByte USB-Platte, da macht dieses kleine Board am späten Abend einen rsync von meinem Haupt-Entwicklungsrechner. Aber mysql und apache laufen da permanent drauf.

Und was ich mal mehr aus Spaß probiert hatte, mit dem FreePascal Compiler Programme zu erstellen. Klappt!

Übrigens kann ich da CodeTyphon empfehlen, eine Zusammenstellung von Lazarus/FreePascal und nahezu allen verfügbaren Komponenten. Lazarus ist ja ähnlich Delphi (man kann sogar Code übernehmen) und CodeTyphon hat den Vorteil, dass man nicht erst alle Komponenten selbst installieren muss. Dabei sind auch schöne Drehregler, Schieberegeler, LED Anzeigen, 7-Segment Anzeigen und alles was den Elektroniker so erfreut.

Und eben Cross-Plattform, gleicher Code, im Moment für Windows und X (also Linux, BSD, Solaris usw.)

formatting link

OS X soll noch kommen. Wer Delphi als RAD kennt, kommt damit auch gleich klar.

formatting link

73, Tom
--
DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 *
http://www.dl7bj.de        https://twitter.com/#!/dl7bj
Do you know http://www.radiocaroline.co.uk?
Reply to
Thomas 'tom' Malkus
Loading thread data ...

Das ist leider zu befürchten, ja.

Nicht wirklich.

Das ist dummes Gesülze und keine Erklärung. Ich bezweifele ernsthaft, daß der Mann tatsächlich bei Broadcom arbeitet. Und falls doch, hat er mit diesem Erguß seiner Firma sicher keinen Gefallen getan.

1) Er erzählt da, daß es außer Registerbeschreibungen keine Dokumentation gäbe, weitere Hinweise zur Funktionsweise der Sachen wären nur direkt bei den Entwicklern der jeweiligen Funktionseinheit zu bekommen. Das kann natürlich nur Bullshit sein, keine seriöse Firma würde einen derartigen Zustand akzeptieren. Das wäre ein untragbares Geschäftsrisiko. Und selbst wenn es tatsächlich so wäre: Inwiefern spricht es dagegen, das zu veröffentlichen, was an Doku da ist? Die Registerbeschreibungen würden sicher schon sehr viel weiter helfen. 2) Er verbreitet sich darüber, wie komplex die Scheiße doch wäre und daß in dem verfügbaren Blob soundsoviele tausend Mannstunden Entwicklungsaufwand stecken würden. So what? Natürlich ist eine GPU ein recht komplexes Stück Hardware und natürlich macht es einige Arbeit, einen Treiber dafür zu schreiben, das wird wohl niemand ernsthaft bestreiten wollen. Aber: Inwiefern spricht das dagegen, andere diese Arbeit noch einmal machen zu lassen, wenn sie so scharf darauf sind? Das kostet ja nun die Firma garnix, die müssen die OS-Entwickler ja nicht bezahlen. 3) Er erzählt, wieviel "geistiges Eigentum" in dieser supertollen Hardware steckt. Das kann schon sein, aber was hat das mit dem Thema zu tun? Es verlangt ja niemand, daß sie die VHDL-Sources oder die Layout-Masken bereitstellen, mit denen die liebe Konkurrenz Clones fertigen könnte. Alles, was gewünscht wird, ist eine hinreichende Dokumentation, die die Benutzung der originalen Hardware ermöglicht. Intel veröffentlicht doch auch eine instruktions set reference und das hat ihnen nicht geschadet, sondern im Gegenteil den Verkauf ihrer CPUs deutlich gefördert...
Reply to
Heiko Nocon

Kann ich mir schon vorstellen. Würde aber tatsächlich kein gutes Licht auf den Entwicklungsprozess bei Broadcom werfen, denn das klingt dann danach, möglichst schnell etwas zusammenzuschustern, ohne vollständige Dokumentation, Hauptsache es läuft irgendwie.

Solche halbgaren Dokumente der Notizen von Entwickern, könnte eine Firma nicht einfach so herausgeben, ohne sich zu blamieren, oder tatsächlich Firmengeheimnisse rauszugeben, weil die Doku z.B. nur in den HDL-Dateien enthalten ist, oder sehr damit verbunden ist, und erst extrahiert, abstrahiert und zusammengestellt werden müsste. Oder die Registerbeschreibungen würden zuviel über die interne Architektur verraten.

Eine gute Dokumentation zu erstellen, die man öffentlich rausgeben kann, ist einiges an Arbeit. Und wenn man dann die Doku einmal rausgegeben hat, kommen immer wieder Nachfragen und andere Supportanfragen, was dann auch ärgerlich wäre, wenn das dann einfach ignoriert würde.

Da kann schon was dran sein. Intel braucht nicht zu veröffentlichen, wie genau die Abhängigkeiten der Module im Chip sind. Eine GPU dagegen ist in Blöcke verschiedener Bauart mit verschiedenen Datenpfaden und Recheneinheiten aufgeteilt, dessen Konstruktion man kennen muß, wenn man Low-Level Programme dafür schreiben will (und nicht bereits OpenCL oder CUDA dafür hat). Diese Architektur könnten andere Firmen dann leichter analysieren und für eigene Produkte verwenden.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

Das tun sie aber. Indirekt über die Beschreibung der Laufzeiten der einzelnen Instruktionen. Jeder der was von der Sache versteht, kann daraus sehr viel über die Hardwaredetails erfahren. ALLERDINGS: Das ist zwar einerseits soviel, wie er wissen muß, um die CPU effizient zu nutzen, aber andererseits längst nicht genug, daß er sie einfach nachbauen könnte.

Das ist bei all-purpose CPUs nicht viel anders. Natürlich sind GPUs spezialisierter, aber die Mathematik dahinter ist genausowenig eine Geheimwissenschaft, die im alleinigen Besitz von Broadcom ist. Der größte Teil der GPU wird sicher nach genau denselben Prinzipien aufgebaut sein wie die der lieben Konkurrenz. Vermutlich wird es gewisse Bereiche geben, wo sie der Konkurrenz voraus sind. Dann sollen sie die einfach aus der Doku aussparen und wenigstens den Rest veröffentlichen.

Im Prinzip wird das ja bei aller Hardware so gehandhabt, die öffentlich verfügbare Doku ist fast niemals vollständig.

Wenn da wirklich schützenswertes Knowhow drinsteckt, dann können sie es ja ganz leicht durch entsprechende Patente absichern. In Zeiten, wo schon absolut lächerliche Trivialitäten als Patent dazu ausreichen, Einfuhrstops und Beschlagnahmungen von Produkten der Konkurrenz zu erreichen, sollten echte substantielle Innovationen ja supersicher und unangreifbar schützbar sein...

Reply to
Heiko Nocon

Ich habe mir auch einen Raspberry Pi bestellt (und warte immer noch). Projektidee: Er soll meinen 486er Server ablösen, der seit 11 Jahren die unten stehende Domain (und noch ein paar andere) hostet.

Der Vorteil wäre, dass er viel weniger Strom verbraucht, und dabei auch noch einiges schneller wäre.

--
http://www.heimers.ch/
Reply to
Stefan Heimers

Mir ist gerade noch etwas eingefallen was an den Dingern schlecht ist. :-)

Die Bauform. Das sind ja im Prinzip ein Developmentboard das man eine Weile auf dem Schreibtisch stehen hat und irgendwann kommen sie in die Tonne. Sinnvoll waere aber eine Anordnung der Steckverbinder so das man die Platine in ein dazu passendes Gehaeuse setzen koennte und man dann an alles dran kommt. Ausserdem muesste es auf der Oberseite 1-2 Slots geben auf dem diverse wichtige Signale (I2C, SPI, AD-DA, Port) liegen.

Dann koennte jeder sich billig den kompletten Rechner mit Gehaeuse abgreifen und sich fuer seine spezielle Anwendung noch eine Einsteckkarte basteln.

Gerade ein Gehaeuse wer sehr wichtig. Sowas bekommen die meisten zuhause nicht hin, und selbst wenn man es kann sieht es immer nach Bastelkeller aus. Eine Firma die aber 10000Stk verkauft kann dagegen fuer sehr wenig Geld was ansprechendes auf die Beine stellen.

Deswegen hab ich mir uebrigens als ARM-Bastelkiste einen Chumby gekauft. Da war das Gehaeuse gleich mit dabei.

Olaf

Reply to
Olaf Kaluza

Am 17.06.2012 00:51, schrieb Frank Buss:

Ich befürchte, dass mittlerweile 95% aller Firmen weltweit genau so ticken :-( Zumindest in der Consumer Ecke sehen die Ergebnisse / Geräte genau so aus, und bei Autos habe ich auch meine Bedenken.

Butzo

Reply to
Klaus Butzmann

Das war halt offenbar die billigste Anordnung.

Im Herbst sollen die Dinger an englische Schulkinder verteilt werden, mit Gehäuse.

Die jetztige Version ist halt eindeutig noch eine rohe Beta-Version, bis da die zweite oder dritte Serie herauskommt, werden auch die paar wirklich problematischen Dinge (keine Montagelöcher, kein billiges Gehäuse in Großserienfertigung, ungünstige/undefinierte Situation bei den GPIO-Headern) sicher noch ausgemerzt werden.

Genauso fehlt ja noch die Dokumentation. Ohne die soll das ja auch nicht auf die Zielgruppe losgelassen werden.

/ralph

Reply to
Ralph Aichinger

Am Sun, 17 Jun 2012 12:44:48 +0200 schrieb Olaf Kaluza:

3D-Druck?

Marc

Reply to
Marc Santhoff

[schnipp]

Ein nicht ganz unwesentlicher Teil des Problems ist, daß die Leute denen die Hardware ja trotzdem aus den Händen reißen. Warum sollten sie also was ändern?

Wenn die Leute den undokumentierten Sondermüll[1] einfach nicht kaufen würden, dann wäre das anders. Leider nur ein schöner Traum.

[1] Sondermüll mag hart klingen. Aber Hardware, die man mangels Doku- mentation nicht ausnutzen kann, ist letztendlich genau das.

XL

Reply to
Axel Schwenke

Zu erwähnen ist hierbei, daß man die OpenGl ES Schnittstelle verwenden und damit die GPU-Hardware recht gut ausnutzen kann. Beispielprogramme dafür sind im Debian-Image enthalten und können direkt auf der Platform compiliert werden. 99% aller Programmierer werden nie mehr brauchen oder machen wollen.

Man kann eben nur keinen eigenen OpenGl ES Treiber schreiben, oder vielleicht OpenCL implementieren, was leider noch fehlt (allerdings werden Shader-Programme unterstützt, da ließe sich bestimmt was machen).

Wie sieht das eigentlich bei NVIDIA, ATI und anderen Grafikkartenherstellern aus? Ich konnte jetzt auch Anhieb keine detaillierte Information zu NVIDIA GPUs finden, außer eine Auflistung der Opcodes:

formatting link

Zumindest letztes Jahr noch musste der Open Source Linux NVIDIA Treiber per Reverse Engineering des Closed Source Treibers entwickelt werden:

formatting link

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

Dabei ist Broadcom ja noch gut. Wir wollten vor einiger Zeit Teile von Realtek einsetzen. Die verraten ohne NDA noch nicht mal welche Farbe das Gehäuse hat. Nach vier Wochen hin und her bis ein NDA zustande kam, fragten die nach der Stückzahl. Die lag leider unter 10k. Danach kam überhaupt keine Reaktion mehr. Arroganz pur.

--
Reinhardt Behm
Reply to
Reinhardt Behm

Am 17.06.2012 19:48, schrieb Axel Schwenke:

Ach was, die Firmen sorgen doch für gute Treiber und Updates ;)... ...Zumindest bis sie nach ein paar Monaten den nächsten Chip in der Linie haben.

Reply to
Heiko Lechner

Nur der Teil für den Graphikchip ist closed source.

Soweit ich das sehe, hat die Olimex-Alternative keine 3D-Grafik und Videobeschleunigung, kann also nicht mehr, als der Raspberry Pi *ohne* den closed-source-Teil - oder habe ich das was übersehen?

cu Michael

Reply to
Michael Schwingen

Das weiss Frank besser. Ich habe das nur als Link von s.e.design zur Information rueberkopeiert weil manche dort nicht mitlesen.

--
Regards, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

Ja, siehe zwei Postings höher von mir. Allerdings ist nur die Implementierung der 3D-Grafik und Videobeschleunigung selbst Closed Source. Man kann es aber per OpenGl ES verwenden, mit Beispielprogrammen auf der Plattform.

Was aber leider außerdem noch undokumentiert ist, sind die beiden auf der Platine bestückten Flex-Stecker. Einer ist für eine externe Kamera gedacht, wie letztens im Raspberry Pi Blog vorgestellt wurde. Der andere ist zum Anschluß eines externen Displays gedacht (zusätzlich zu den bereits vorhanden HDMI und Composite Ausgängen).

Im Schaltplan sieht man eine Standardbelegung für viele TFT-Displays für die Display-Buchse: drei LVDS-Leitungspaare. Auf der Kamerabuchse sind ebenfalls drei LVDS-Leitungspaare, ein weiterer I2C-Anschluss ist dort herausgeführt, sowie ein Leitungspaar was CAM_GPIO/CAM_CLK heisst.

Ist aber bestimmt sowieso alles nur eine geschickte Marketing-Kampagne von Broadcom, um ihren Chip Handyherstellern schmackhaft zu machen. Mit kostenloser Entwicklung des Linux Systems (was als Basis für Android verwendet werden kann) durch Freiwillige für ihr Evaluierungskit: dem Raspberry Pi :-)

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

Moin, zusammen,

Ich sehe noch eine andere Gemeinsamkeit. Die ARM-Boards mit Linux wie Beagleboard, Raspberry Pi usw. sind schwierig zu programmieren. Die Pins müssen nach dem Einschalten vom Bootloader oder vom Betriebssystem konfiguriert werden, die Hardware ist sehr komplex. Man muß sich um die passende Treiber kümmern, usw. Wenn man nicht furchtbar viel Rechenleistung braucht oder kein Display mit vielen Pixeln braucht, ist man mit einem weniger komplexen Prozessor Arduino oder einem Infineon C167 deutlich besser bedient.

Christian

Reply to
Christian Keck

OpenGL ist ehrlich gesagt überhaupt nicht mein Gebiet. Aber Plattformen wie der Pi sind ja prädestiniert für Videoplayback und AFAIK hilft einem GL nur sehr bedingt dabei, das effizient zu implementieren.

Nicht wesentlich besser. Allerdings hat man auf dem PC typischerweise viel mehr CPU-Power. Da kann man dann die brachliegenden GPU-Fähigkeiten verschmerzen und bewirft das Problem mit CPU-Zyklen, bis es tot ist.

Wie es besser geht, zeigt Intel. Grafikhardware von Intel ist derzeit unter Linux am schmerzärmsten zum Laufen zu bekommen.

XL

Reply to
Axel Schwenke

Am 18.06.2012 09:07, schrieb Axel Schwenke:

IMHO unterstützt AMD die OS-Treiberprogrammierer. Aber wie? Keine Ahnung.

Reply to
Heiko Lechner

Es sei denn, Du hast ein Atom-Netbook mit GMA500-Grafik :-(

eine nicht zu neue AMD-Grafikkarte, die von den Open Source-Treibern unterstützt wird, ist ziemlich schmerzarm.

cu Michael

Reply to
Michael Schwingen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.