Hi,
da ich was anderes suche, mache ich mal einen neuen Thread auf:
Der Raspberry Pi und speziell der Zero ist auf Grund seiner sehr
geringen Größe ein echtes Highlight, allerdings hat er für mich zwei
ganz fette KO-Argumente:
- die seltsame Stromversorgung über einen microUSB-Anschluss, der kein
USB ist (USB hat noch mal einen zweiten Stecker)
- die nicht vorhandene Dokumentation der Broadcom-CPU für
Bare-Metal-Applikationen (das, was es da tatsächlich gibt ist ein
schlechter Witz und das meiste fehlt)
Deswegen: welche Alternativen gibt es zum Pi Zero? Die typischen
Atmel-Boards mit 16 MHz (Arduino und Co). sind für meine Zwecke zu
leistungsschwach, der BeagleBone Black ist zwar erstklassig dokumentiert
aber mit inzwischen 60 Euro zu teuer für meine Anwendung.
Gibt's da noch was anderes, was irgendwie Pi Zero ähnlich (GPIO's,
geringe Größe, USB) aber vernünftig beschrieben ist?
Danke!
Zonk99 schrieb:> - die seltsame Stromversorgung über einen microUSB-Anschluss
Ist doch prima, kann man jede USB-Wandwarze als Netzteil verwenden,
einfach mit fertigen Kabeln.
MfG Klaus
Zu der Stromversorgung. Habe es nicht genauer angeschaut, aber bei den
anderen Pis kann man die auch über die Pinleiste versorgen... Und die
Belegung soll kompatibel/gleich sein.
Anstatt ein Besseres Teil als der Raspberry Pi Zero vorzufinden ( das
lese ich mit dem Titel aus "Besser als Raspberry Pi Zero" ) suchst du
eine Alternative?
Zonk99 schrieb:
> ..welche Alternativen..
Warum schreibst du das nicht in den Titel?
Dann hätte man sich den Aufruf sparen können, sowas irreführendes!
Klaus schrieb:> Ist doch prima, kann man jede USB-Wandwarze als Netzteil verwenden,> einfach mit fertigen Kabeln.
Ja aber ich benötige zwei Kabel: eins für die Stromversorgung, eins für
die USB-Kommunikation. Das finde ich - mal abgesehen davon das es blöd
aussieht - ehrlich gesagt eher beknackt.
Zonk99 schrieb:> Ja aber ich benötige zwei Kabel: eins für die Stromversorgung, eins für> die USB-Kommunikation.
Ist denn auf der "wirklichen" USB-Buchse die Versorgung nicht
angeschlossen? USB zum Laden oder als Versorgung ohne Datenleitungen
kenne ich. USB ohne Versorgung sondern nur Daten, hab ich noch nie
erlebt.
MfG Klaus
So weit ich das verstanden habe ja. Die Informationen sind bisher noch
spärlich, aber wenn man sich das Bild von
https://www.raspberrypi.org/wp-content/uploads/2015/11/rsz_img_4054.jpg
mal ansieht, könnte das schon passen (eine Buchse heißt PWR, die andere
USB).
Abgesehen davon bleibt das Problem mit der absolut unzureichenden
Entwicklerdoku für Bare Metal...
Zonk99 schrieb:> - die nicht vorhandene Dokumentation der Broadcom-CPU für> Bare-Metal-Applikationen (das, was es da tatsächlich gibt ist ein> schlechter Witz und das meiste fehlt)
Frei runterladbare Dokumentation solcher SoCs, einschliesslich allem was
ein Bare-Metal-Entwickler benötigt, ist eher ungewöhnlich. Da müsstest
du schon direkt an Broadcom herantreten.
Für z.B. den Sitara gibt's das in aller Ausführlichkeit und öffentlich
verfügbar. Broadcom wird mir kleinem Licht sicher nichts zusätzlich
offen legen. Aber es geht auch noch sclimmer, Allwinner hat noch weniger
zu bieten als Broadcom.
Hallo, damit es hier nicht ausartet als Äpfel und Birnen vergleicht
müssen die Requirments vom Raspberry PIZero als Minimum übernommen
werden.
Warum vergleicht Ihr ein ARM32 mit dem Raspberry PiZero oder soll ich
jetzt wegen der grösse sagen ein Atiny13?
- Wo ist die GPU?
- Wo ist der HMDI Anschluss?
Stephan G. schrieb:> guck mal hier>> https://asciich.ch/wordpress/raspberrypi-bare-metal-programmierung-compiler-unter-archlinux-einrichten/
Ja, diese Tutorials kenne ich - da gibt es mehr von. Die beschreiben
schon mal sehr gut GPIO-Zugriffe, Timer, Interrupts etc.
Aber ich habe noch keines gefunden, in dem ausreichend Informationen
darüber vorhanden wären, wie man die USB-Schnittstelle des Broadcom
anspricht (als CDC-Device, nicht als Hostcontroller).
Und letztenendes ist das alles dann doch nur reverse engineered, wenn
man eine komplexere Applikation hat und dann plötzlich seltsame Effekte
auftreten, weil irgend was doch nicht so 100% korrekt benutzt wird,
steht man komplett im Regen.
Stephan G. schrieb:> dann mußt du das mit raspberrypi.org klären
Und das ist mal ein hervorragendes Beispiel für einen komplett nutzlosen
Kommentar. Danke für nichts!
Da steht doch gaaanz oben:
The USB core used in the Videocore is build from Synopsys IP. Details
about the block can be found in DWC_otg_databook.pdf (Which can also be
downloaded
from https://www.synopsys.com/dw/ipdir.php?ds=dwc_usb_2_0_hs_otg ).
Bei ARM ist es doch auch üblich zig Dinge verstreut zu haben. Ist doch
beim STM32 nicht anders mit Core und Peripherie.
Die Situation ist natürlich alles andere als perfekt. Aber es gibt
Treiber-Implementierungen für Linux, NetBSD usw., die man als Referenz
nutzen kann. Längst nicht so gut wie eine richtige Dokumentation, aber
brauchbar.
John-eric K. schrieb:> Da steht doch gaaanz oben:>> The USB core used in the Videocore is build from Synopsys IP. Details> about the block can be found in DWC_otg_databook.pdf (Which can also be> downloaded> from https://www.synopsys.com/dw/ipdir.php?ds=dwc_usb_2_0_hs_otg ).
Dann guck mal auf die Site bei Synopsys. Da gibt es auch nur ein
abgekürztes Datasheet, sind nur ein paar Seiten.
Anmerkung: grundsätzlich stellt sich natürlich die Frage, ob man
tatsächlich bare metal arbeiten will, wenn's Richtung USB geht. :)
Selbst ein Device ist ja recht frickelig mit dem DWC zu implementieren.
Oder man macht etwas V-USB-style? Wahrscheinlich bekommt das Raspberry
Pi auch Bitbanging-USB mit fullspeed (12 Mbps) hin. :)
http://nextthing.co/
Soll angeblich komplett Opensource werden:
"We built C.H.I.P. to make tiny powerful computers more accessible and
easier to use. A huge part of making C.H.I.P. accessible is making sure
that it can change to meet the needs of the community. That's why both
C.H.I.P. and PocketC.H.I.P. are both TOTALLY OPEN SOURCE. This means all
hardware design files schematic, PCB layout and bill of materials are
free for you the community to download, modify and use."
"We've worked very closely with the amazing team at Allwinner Technology
to insure that all the necessary documentation and source code for the
System on Chip and Power Management Chips used in C.H.I.P. will be
available for the community to use and learn from."
Zonk99 schrieb:> OK, dann noch mal ganz deutlich, meine Frage lautete:>>>
1
WelcheAlternativengibteszumPi?
>> Und nicht:>> Kann ich bitte noch mal alle Quellen für die "Broadcom-Entwicklerdoku"> genannt bekommen, die ich schon als untauglich aussortiert habe?
war zumindest mal als Alternative zum Pi gedacht: Orange Pi
http://www.orangepi.org/
Gibt's bei Ali ab ca. €15...
Zonk99 schrieb:> OK, dann noch mal ganz deutlich, meine Frage lautete:>> Welche Alternativen gibt es zum Pi?
Wobei man sich die Anforderungen irgendwie zusammensuchen muss, weil sie
irgendwie kreuz und quer verteilt und unscharf formuliert sind.
Ich versuche mal, zusammenzufassen:
Du suchst laut erstem Satz des Ursprungspostings "was anderes".
Ein RPi kommt nicht in Frage, weil er einen separaten µUSB-Port zur
Stromversorgung benutzt und weil es keine vollständige Doku für's
bare-metal-Programmieren (für das er ja an sich auch gar nicht gedacht
ist) gibt.
Anforderungen:
- In irgendeiner Form schneller als "Die typischen Atmel-Boards mit 16
MHz"
- Preis < 60 Euro
- USB-Port für CDC als device
- Gute Dokumentation der Hardware für Programmierung ohne Betriebssystem
- ähnliche I/O-Ports und Abmessungen wie ein RPi zero
Sowas vielleicht?
https://www.reichelt.de/?ARTICLE=162345&PROVID=2788&wt_mc=amc141526782519998&gclid=CPeCv-7ZsMkCFdRuGwodUjIEHQ
Der RPi kann auch mit Linux als CDC betrieben werden. Und über den USB
port kann man ihn auch mit Strom versorgen...
Warum man sich unbedingt baremetal antum muss? Für wirklich
zeitkritische Dinge kann man einen code schnipsel in einem der vector
cores des videocore laufen lassen...
Markus F. schrieb:> Jobst Q. schrieb:>> Stephan G. schrieb:>> Das Pinguino Micro Board lohnt es sich anzuschauen>> Ganz nach unten bis zum "Selbstzerstörungs-Button" gelesen?
Der "programmer-to-go" Button gehört nicht zum Pinguino Micro Board,
sondern zum PICit3 Programmiergerät. Man kann das Board direkt und
gefahrlos über die USB-Schnittstelle programmieren.
Jobst Q. schrieb:> Markus F. schrieb:>> Jobst Q. schrieb:>>> Stephan G. schrieb:>>> Das Pinguino Micro Board lohnt es sich anzuschauen>>>> Ganz nach unten bis zum "Selbstzerstörungs-Button" gelesen?>> Der "programmer-to-go" Button gehört nicht zum Pinguino Micro Board,> sondern zum PICit3 Programmiergerät. Man kann das Board direkt und> gefahrlos über die USB-Schnittstelle programmieren.
Mit den PIC16 mochte ich eigentlich, aber wenn das offizielle
Programmiergerät des Chipherstellers bei versehentlichem Knopfdruck auf
einen genial exponiert daran angebrachten Taster den Controller
irreparabel zerschießt und ich sehe, wie selbiger Hersteller mit den
Beschwerden darüber (nicht) umgeht, dann such' ich mir einen anderen, wo
ich meine Kohle hintrage.
Das ist mir ziemlich egal, von meinem Geld wird eh kein Chip-Hersteller
reich. Aber ich habe den Pinguino Micro und kann ihn nur empfehlen für
Anwendungen, die für den Arduino zu anspruchsvoll sind, aber kein
Betriebssystem brauchen.
Innovationeer schrieb:> greg schrieb:>> BULLSHIT.>> Da habe ich aber etwas anderes gehört.
Aha, wo sind denn die offenen Treiber für die GPU? Da gibt es nichts
brauchbares, und da wird es in Kürze auch nichts geben ("lima" ist tot).
Der Video-Dekoder ist auch nur teilweise Open Source. Und was ist mit
aktuellen Linux-Kerneln mit voller Hardwareunterstützung? Gibt's nicht
[1]. Und so weiter.
Der C.H.I.P nutzt einen Allwinner-SoC. Das ist die Firma, die vor kurzem
wegen GPL-Verletzungen groß bekannt wurde [2]. Da müsste schon jemand
bei Allwinner das Ruder um 180 Grad drehen, damit sich da langsam mal
etwas ändern kann. Sieht aber nicht danach aus. Die sunxi-Community hat
auch ohne Hilfe von Allwinner schon Einiges zustande bekommen, aber von
"komplett open source für alles" sind die noch SEHR weit entfernt.
Da ist mir der Raspberry Pi schon lieber, denn da ist mittlerweile der
gesamte Code der auf dem ARM läuft quelloffen. (Daher gibt's ja auch
z.B. NetBSD/FreeBSD mit vollen Features.) Der Rest der auf dem VideoCore
läuft wird sehr gut von der Raspberry Pi Foundation unterstützt.
[1] https://linux-sunxi.org/Linux_Kernel
[2] https://linux-sunxi.org/GPL_Violations
greg schrieb:> Aha, wo sind denn die offenen Treiber für die GPU? Da gibt es nichts> brauchbares, und da wird es in Kürze auch nichts geben ("lima" ist tot).> Der Video-Dekoder ist auch nur teilweise Open Source. Und was ist mit> aktuellen Linux-Kerneln mit voller Hardwareunterstützung? Gibt's nicht> [1]. Und so weiter.
Ja, das ist korrekt und entspricht meinem Wissenstand. Es kommt halt
drauf an ob du die GPU brauchst oder ob dir ein Framebuffer reicht.
OSS-GPU-Treiber für ARM sind Mangelware, inwieweit zB etna-viv schon
benutzbar ist weiß ich leider nicht. Gefällt mir auch nicht.
> Der C.H.I.P nutzt einen Allwinner-SoC. Das ist die Firma, die vor kurzem> wegen GPL-Verletzungen groß bekannt wurde [2]. Da müsste schon jemand> bei Allwinner das Ruder um 180 Grad drehen, damit sich da langsam mal> etwas ändern kann. Sieht aber nicht danach aus. Die sunxi-Community hat> auch ohne Hilfe von Allwinner schon Einiges zustande bekommen, aber von> "komplett open source für alles" sind die noch SEHR weit entfernt.
Den Kernelport macht FreeElectrons, der ist mit Sicherheit GPL-compliant
und ich gehe auch von einem hohen Qualitätsniveau aus.
Phil E. schrieb:>> Aha, wo sind denn die offenen Treiber für die GPU? Da gibt es nichts>> brauchbares, und da wird es in Kürze auch nichts geben ("lima" ist tot).>> Der Video-Dekoder ist auch nur teilweise Open Source. Und was ist mit>> aktuellen Linux-Kerneln mit voller Hardwareunterstützung? Gibt's nicht>> [1]. Und so weiter.>> Ja, das ist korrekt und entspricht meinem Wissenstand. Es kommt halt> drauf an ob du die GPU brauchst oder ob dir ein Framebuffer reicht.> OSS-GPU-Treiber für ARM sind Mangelware, inwieweit zB etna-viv schon> benutzbar ist weiß ich leider nicht. Gefällt mir auch nicht.>
Naja, damit ist man aber wie gesagt meilenweit von "komplett open
source" entfernt. Dabei ist es fast egal, wie man das definiert. Die GPU
ist ja kein esoterisches Feature! Also immer noch gilt: BULLSHIT! (Bzw.
die sollten nicht solche vollmundigen Versprechungen machen, die sie
nicht einhalten können)
Zonk99 schrieb:> die nicht vorhandene Dokumentation der Broadcom-CPU für> Bare-Metal-Applikationen
Wir machen "Bare-Metal" was ist denn da nicht dokumentiert? Insbesondere
die Doku zum System Core (Vektoren, Hardware-Timer etc), Speicherzugriff
(MMU, GPUMMU), GPIO (UART, PWM) sind vorbildlich.
Was geht denn bei Dir nicht?
Lothar schrieb:> Wir machen "Bare-Metal" was ist denn da nicht dokumentiert?
Der USB-Port ist nicht wirklich dokumentiert. Ich müsste das Board als
CDC-USB-Device an einem Host-PC laufen lassen, dafür wäre ein
vernünftiger USB-Zugriff unabdingbar.
Den Rest, den ich brauche, habe ich mir schon aus den Seiten diverser
bewundernswerter Entusiasten zusammengeklaubt.
Naja, beim USB-Port ist das Problem eben auch, dass es Fremd-IP ist und
nicht von Broadcom selbst. Blöde Situation natürlich trotzdem. Aber
willst du wirklich USB selbst machen? USB ist fehleranfällig und
komplex. Die Stacks der großen OSe sind voller Workarounds für
fehlerhafte Geräte und/oder Hosts. Die sollte man nutzen, wenn man Lust
auf fehlerfreies und funktionierendes USB hat.
Es hat sich jemand übrigens schon die Arbeit gemacht und USB bare metal
ans Laufen bekommen. "Dokumentation" in Form von Source Code für den
DWC2 gibt's ja.
https://github.com/rsta2/circle
Das ist leider GPLv3.
greg schrieb:> Aber> willst du wirklich USB selbst machen?
Was heißt da wollen...müssen! Auf irgend einem Weg muss ich mit der
Außenwelt kommunizieren und da sehe ich irgendwie nur USB...
Zonk99 schrieb:> Der USB-Port ist nicht wirklich dokumentiert. Ich müsste das Board als> CDC-USB-Device an einem Host-PC laufen lassen, dafür wäre ein> vernünftiger USB-Zugriff unabdingbar.
In der Pinguino IDE, mit der der Pinguino Micro programmiert wird, ist
eine CDC-Library integriert. Es gibt Beispielprogramme, wie sie
angewendet wird, meist einfach mit CDC.printf.
Ich weiß nicht, was dein zu entwickelndes Gerät sonst noch braucht, aber
wenn du kein Betriebssystem brauchst, ist der Raspberry nicht von
Vorteil.
