Hallo, ich habe das Gefühl, ich komme auf Dauer nicht um Microcontroller herum. Da tun sich bei mir aber zwei grundlegend Fragen auf. Derzeit werden meine GPIO's von einem Mini-Computer (raspberry pi, ARM prozessor, linux) gesteuert. Das Problem: Der Bootvorgang kann bis zu einer Minute dauern. Daher habe ich auf Hardwareebene eine Blinkanimation eingebaut. Schöner wäre jedoch, wenn direkt zu beginn das OLED-Display (per GPIOs) angesteuert werden könnte per Microcontroller. Ist Linux hochgefahren, soll der Microcontroller "nichts mehr machen" und der Linuxrechner soll die GPIO's steuern. Ich bin mir nicht sicher, wie ich die verdrahten könnte. Die GPIOs sind ja direkt mit dem Linux-rechner verbunden (GPIOs für Shift-Register (parallel to seriell, seriell to parallel), OLED-Ansteuerung, etc.). Wie kann ich denn nun den Microcontroller da ran bekommen? Einfach parallel schalten? Kommen sich die High-Low-Pegel da nicht in die Quere? Anders ausgerückt: Soll der Linux-Rechner schweigen und der Microcontroller arbeiten, müssen dann die Ausgänge vom Linux-Rechner auf High oder Low sein? Natürlich low, aber dann auch das HIGH vom uC dorthin ab. Ich weiß jetzt nicht, ob ich die Ausgänge in einen "High-Impedance" Status versetzen kann(10K). Soweit ich weiß, kann ich das nicht mit allen Ausgängen/Eingängen. Toll wäre da doch so ein "20 Kanal - Mutli-Umschalter). Gibt es so etwas? Eine andere Alternative wäre, den Microcontroller einfach in Reihe zu schalten, statt parallel. Dann dann müssten jedoch "alle" Daten durchgeschliffen werden. Hätte aber auch vorteile. Zeitintensive Dinge wie ständig die 64 Schalter abfragen (Schachbrett), dass wäre ja idealer für den uC. Der Bildschirmaufbau (mal abgesehen von einer simplen Ladeanimation) kann dann ja so realisiert werden: Der Linux-Rechner schickt das BIld zum uC, dieser sendet es dann direkt weiter um OLED-Screen. Habe nur Angst, dass sich dann Übertragungsfehler einschleichen könnten bzw. das ganze dann doch "sichtbar" (z.B. flackern) werden könnte. Das nächste ist, ist der Chip aufgelötet, muss/sollte er auf jedenfall auch nachträglich geflasht werden können. Aber so weit ich weiß, kann man die meisten uCs per SPI flashen. Kann mir da jemand Erfahrungswerte/Tipps geben? PS: Bei der Kommunikation mit dem OLED zählte taktzyklus, ansonsten wirds ruckelig. Eine direkt-Anbindung (Linux zu OLED) hat daher einen Vorteil. Beim booten soll aber der uC eine Ladeanimation anzeigen (uC zu OLED). Lieben Gruß, Sebastian
Sebastian Loncar schrieb: > ich habe das Gefühl, ich komme auf Dauer nicht um Microcontroller herum. Mit scheint, du hast da sogar schon einen. Der Pi ist nämlich ein (sogar ziemlich leistungsfähiges) µC-System. > Derzeit werden meine GPIO's von einem Mini-Computer (raspberry pi, ARM > prozessor Das beibehalten. > linux Das wegwerfen. Schon ist das Problem gelöst. Nunja, dann tun sich allerdings ein ganze Reihe anderer Probleme auf. Ohne OS ist der Pi ein ziemlich dummes µC-System. Aber das ist ein reines Softwareproblem, wenn auch nicht in einer Nacht zu lösen. Allerdings scheinst du ja in deiner Anwendung weder den Displaykram noch die anderen komplexen Schnittstellen des Pi überhaupt zu nutzen, sondern sowohl Ein- als auch Ausgabe komplett über die GPIOs abzuwickeln. Dann rückt der Aufwand doch schon recht nahe an eine durchprogrammierte Nacht. Schließlich gibt es schon ziemlich viel von anderen geleistete Vorarbeit für eine Art "Minimal-OS" für den Pi. Und das schleppt halt nicht die unheimlichen Blähungen eines universell einsetzbaren OS wie Linux mit sich herum.
Nun, mehrere durchprogrammierte Wochen trifft es schon eher. Wir sprechen hier von mehreren tausend Zeilen Quelltext für die Logik der Auswertung der Sensoren, Ansteuerung des Display, Benutzerführung auf der Oberfläche (OLED), ein abstraktes Modell eines Schachspiels, als auch die Ansteuerung der Schachengine. Ich werde jetzt bestimmt nicht hergehen und die Engine (C++) zu einem uC portieren, als auch meine umfangreiche "Steuerungssoftware", welche übrigens in C# geschrieben ist (Mono.NET). Außerdem wäre ein uC viel zu schwach um das alles zu stemmen. Geschweige denn, dass der Speicher reichen würde. Natürlich kann man das auch mit Mini-uCs hinbekommen, aber das ist und war nie das Ziel, denn es soll nicht "irgendein" Schachcomputer werden. Eine Internetanbindung ist z.B. ja auch erwünscht. Mir ging es eher darum abzukären, was der richtige Weg wäre, denn ein falscher Weg/falsche Idee würde unter Umständen mehrere Wochen Zeit vernichten. Mein Gedanke ist im Prinzip, dass eine 60 Sekunden Blink-Animation vielleicht etwas unbefriedigend ist für einen Kunden, und da eine vorläufige Ansteuerung des OLED per uC "anwenderfreundlicher" wäre. Dieser soll/sollte dann aber die Kontroller der GPIOs hinterher komplett an den linux-rechner übergeben, ohne des es zu elektrischen Frickeleien kommt. Lieben Gruß, Sebastian
Sebastian Loncar schrieb: > Ich werde jetzt bestimmt nicht > hergehen und die Engine (C++) zu einem uC portieren, als auch meine > umfangreiche "Steuerungssoftware", welche übrigens in C# geschrieben ist > (Mono.NET). Außerdem wäre ein uC viel zu schwach um das alles zu > stemmen. Du HAST da bereits ein µC-System, nämlich den Pi! Begreifst du das nicht? Und das System wird nicht schwächer, wenn du ein anderes OS zu seinem Betrieb benutzt. > Geschweige denn, dass der Speicher reichen würde. Auch der wird davon nicht weniger.
Mehrere durchprogrammierte Wochen sind wohl übetrieben. Der OP hat ja seinen "Anwendungscode" schon fertig. Er muss also "nur" die Hardwaretreiber für seine Datenerfassung neu schreiben bzw aus einem Framework portieren. Das Display (als Hardwaretreiber) ist da schon bei. Das ganze dann in ein schlankes rtOS verpackt, und fertig ist die Laube. Schätz mal 1..2 normale Arbeitstage. Was Zeit kosten wird, ist ein eigenes(G)UI zu bauen...
Danke für den Hinweis, dass der Pi auch ein uC ist. Ich war der festen Überzeugung, er sei ein FPGA. Scherz beiseite. Meine Frage/mein Problem ist ein anderes. Und mir geht es auch nicht darum, das Linux schneller hochzufahren (worin übrigens in der Tat Optimierungspotenzial besteht) oder eine andere Software auf den Pi aufzuspielen oder gar "alles" auf einen anderen uC zu portieren. Mir geht es doch nur darum, beim booten ggf. das OLED VORHER schon anzusprechen, bevor Linux hochgefahren ist. Das ließe sich prima mit einem kleinen uC lösen, der muss nicht viel können. Die Frage war einzig allein nach Feedback zu dieser Idee. Es gibt ja folgende Lösungsvorschläge: In einen (weiteren) uC Reihe schalten mit den GPIOs (z.B. den uC zwischen OLED und Linux-Rechner): Alles muss durch den uC, "könnte" vieles verlangsamen. außerdem muss der uC dann doppelte so viele GPIOs haben, wie man am Ende braucht. (z.B. 5 benötigt: 5 rein, 5 raus). Parallel schalten: uC wird zum schweigen gebracht, sobald Linux hochgefahren ist. Dazu müssten alle GPIOs dann von "dem" Chip (linux oder der kleine uC) auf High-Impedance gesetzt werden, der gerade "nicht" steuert, weil soweit ich weiß die Signale sich sonst verlaufen bzw. in de quere kommen. Oder halt ein Chip, der einen ganzen Datenbus "umschalten" kann. Wenn 0, werden Kanäle 0-16 an chip 0 geleitet, wenn 1, dann alle Kanäle nach chip1. Mir geht es NICHT darum, meinen Raspberry Pi zu ersetzen oder da ein anders OS oder sonst was aufzuspielen ;) Es wurde sich ganz bewusst für die Lösung "Raspberry Pi mit vollwertigem Linux" entschieden, es gibt viele Pläne mit dem Gerät. Der keine (weitere) uC soll nichts anders machen, als einen anwenderfreundlichen Start des Gerätes ermöglichen. Ca. 60 auf einen shwarzen Bildschirm zu starren ist nicht anwenderfreundlich. Daher habe ich ja bereits eine Blinkende LED eingebaut, aber ich dachte, ich mache etwas eleganteres. Im Einfachsten fall sollen einfach nur ca. 10 GPIOs mit einem initialem Bit-Muster geflutet werden (natürlich mit timings), es wird keine bzw. kaum Logik im uC hinterlegt. Wie gesagt, das wäre das "einfachste", um eine Ladeanimation der LEDs als auch des OLED-Screens beizubringen. Danach hat der uC "nichts mehr zu sagen". Lieben Gruß, Sebastian
Oder noch einfacher ausgedrückt: Wie kann man bei einem Datenbus auswählen, mit welchen Chip er gerade verbunden ist. So, dass der Bus elektrisch auch sauber getrennt/verbunden ist von Chip. Ein "Chip-Select"-Flag reicht nicht, weil der Datenbus selber dann ja nicht getrennt sind bzw. die GPIOs vom "deaktivierten" Chip ja noch gültig verbunden sind, und die Ströme nicht dahin fließen, wohin sie sollen.
Ich schätze, dass die GPIO Pins vom Raspberry initial alle inaktiv (bzw als Eingang geschaltet) sind. Falls das stimmt, kannst Du einen weiteren Mikrocontroller einfach parallel schalten. Bevor der Raspberry die GPIO Pins aktiviert (das programmierst Du ja selbst) muss der andere Mikrocontroller seine Pins deaktivieren. Also brauchst Du wenigstens einen Pin, über den sich die beiden Controller gegenseitig umschalten.
Sebastian Loncar schrieb: > Oder noch einfacher ausgedrückt: Wie kann man bei einer Datenleitung > auswählen, mit welchen Chip sie gerade verbunden ist. So, dass die > Leitung elektrisch auch sauber getrennt/verbunden sind von Chip. Ein > "Chip-Select"-Flag reicht nicht, weil die Datenleitung selber dann ja > nicht getrennt sind bzw. die GPIOs vom "deaktivierten" Chip ja noch > gültig verbunden sind, und die Ströme nicht dahin fließen, wohin sie > sollen. Du musst garnichts auswählen, verbinde einfach dein PI direkt mit deinem Display und den Controller über Widerstände. Wahrscheinlich (alles andere wäre lächerlich) sind die GPIOs des PI beim Start hochohmige Eingänge. Also kann dein kleiner Controller bestimmen was das Display "sieht". Nach einiger Zeit übernimmt dann dein PI das Display, durch die Widerstände kann der kleine Controller nicht mehr reinpfuschen und legt sich schlafen :)
Sebastian Loncar schrieb: > Mir geht es doch nur darum, beim booten ggf. das OLED VORHER schon > anzusprechen, bevor Linux hochgefahren ist. Dazu braucht man keine extra Hardware. Sieh dir mal eine Live CD von GPartEd an - da erscheint sofort ein kompletter grafischer Bildschirm, sogar mit Menüauswahl was man starten möchte, und erst NACH dieser Auswahl wird Linux hochgefahren. Viele andere zeigen vor und/oder während des Hochfahrens Splash Screens an. Gruss Reinhard
> Mir geht es doch nur darum, beim booten ggf. das OLED VORHER schon > anzusprechen, bevor Linux hochgefahren ist. Das ließe sich prima mit > einem kleinen uC lösen, der muss nicht viel können. Das sollte sich doch auch mit einem gepatchten Linux-Kernel (oder Bootloader?), der gleich am Anfang ein paar IO-Befehle ans Display sendet,erledigen lassen? Gruß Roland
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.