Hallo allerseits, Der Raspberry ist nett, man möchte aber schon oft noch einen Mikrocontroller anschließen und da stellt sich mir gerade die Frage: Welchen? Rechenpower hat der Raspberry 2 genug, wichtig wäre also, daß er den Raspberry gut ergänzt, mit Timern, PWM, ADC usw. Mein erster Gedanke war ATmega über UART. Mein zweiter, weil dort mehr Peripherie vorhanden ist, ein xmega, ich kenne diesen Familienzweig allerdings noch nicht persönlich. Der Diskussion um eine Wunschliste für xmega-Nachfolger habe ich nun entnommen, daß es ja auch allerlei Alternativen gibt. PICs, was mit PowerPC, Cortex M lese ich hier öfter, eine ARMv7 Architektur wäre zumindest irgendwie "lustig", wäre halt ein Doppelsystem mit einem komfortablen Linux-µC und einem ca. gleichwertigen Partner für Echtzeitbelange und I/O... andererseits weiß ich nicht, wie sich ein nackter ARM programmieren läßt, ein intelligenzunabhängiges System wie ATmega oder PIC wäre als Raspberry- oder besser gesagt Raspbian-Begleiter vermutlich der weniger spektakuläre, aber weisere Weg. Und nicht daß es unbedingt nötig wäre, aber es wäre schon irgendwie nett, gleich auf dem Raspberry zu entwickeln, per pico oder vi über ssh oder remote X. Eine unter Raspbian laufende IDE bzw. toolchain wäre daher gut, insofern hätte es natürlich schon auch seinen Reiz, mit ARM-gcc zu nichtcrosskompilieren. Eine vernünftigere Variante (einfach aber schnell) wäre so ein Parallax-SX gewesen, aber die sind anscheinend leider ausgestorben.
Moin, passen die Module von http://www.coocox.org/hardware.html für dich eventuell, also das Embedded Pi? Liebe Grüße, Jan
Hallo Reinhard, beim Beagle Bone Black sind gleich zwei Controller für schnelles Realtime-IO mit an Bord. Allerdings fine ich die Programmierung dieser Prozessoren etwas schwierig. Beim Raspberry würde ich per SPI oder I2C einen STM32 anbinden. Der ist schnell, mit wenig Aufwand in C programmierbar und mit TQFP32 noch in selbst lötbaren Gehäusen verfügbar. Alternative wäre PIC 32-Bit oder andere Prozessoren aus der Familie ARM M0/M0+. Microchip ist ausserdem einer der wenigen Hersteller, deren Prozessoren noch in THT gefertigt werden. Grüße, Kurt
Zum tausendsten Mal die selbe Frage: Reinhard M. schrieb: ... und da stellt sich mir gerade die Frage: > > Welchen? Und zum tausendsten Mal die selbe Antwort: Es wird genau der Controller hinzu getüttelt, welcher die geforderte Aufgabe erfüllt. Ulli-B
Ich habe einfach einen Arduino über USB angeschlossen. Läuft stabil 24/7. Kein Löten notwendig. Komponenten können schnell getauscht werden. Ok, die IDE für den Arduino läuft noch nicht auf dem Raspi. Aber an dem habe ich auch kein Bildschirm/Tastatur, so dass eh ein PC im Spiel ist.
Für wichtiger als eine volle µC-IDE auf dem RPi halte ich die Möglichkeit, den RPi als Programmer für den µC zu verwenden. Dadurch kann man den Kram irgendwo fest einbauen und auf beliebiger Entfernung via SSH aktualisieren. Bei den AVRs geht das z.B. mit avrdude per SPI. Anderswo benötigt man eine portable Version eines Bootloader-Progs. Ich hatte unlängst den Bedarf nach einem UART/I2C Umsetzer, weil ja der RPi mit I2C seine Nöte hat. Es wurde dann ein ATtiny841, aber die Minimallösung ware ulkigerweise ein 32-Bitter gewesen, nämlich NXPs 8-Pin Version des LPC800.
Kurt Harders schrieb: > Beim Raspberry würde ich per SPI oder I2C einen STM32 anbinden. Mit I2C wäre ich da vorsichtig. Der RPi verkraftet clock stretching nicht, aber genau das gibts unweigerlich bei einem µC als I2C-Slave. Ein 50MHz 32-Bitter ist zwar fix genug um das bei 100kHz I2C-Takt noch ohne Glitch zu schaffen (ein 8MHz AVR in C programmiert ist es nicht), aber dann muss man die worst case Latenz des I2C-Interrupts sehr genau unter Kontrolle haben.
:
Bearbeitet durch User
Was spricht dagegen dass das neue Programm auf deinem PC übersetzt wird. Wenn dann alles getestet ist, kann es per SSH auf den Raspi übertragen werden und ein Skript ruft den Bootloader(SPI/UART...) auf und flash es auf den uC!? Zum UC: Wie schon viele vor mit gesagt haben, es kommt auf deine Anforderungen an. Was soll auf dem UC gemacht werden? Ein bisschen Echtzeit mit ein paar Signal IN/OUT ist auf jedem 8 Bitter bei anständiger Programmierung machbar. Bei höherer Performance würden bei mir die TI Piccolos, ein STM32F4 und für die ganz schnellen Sachen ein FPGA zum Einsatz kommen. Hängt alles vom Einsatzzweck ab...
Vielen herzlichen Dank für die vielen Antworten! Die Cortex-ARMs sind mehrfach genannt worden und kostenlose Linux-Developement tools gibt's da offenbar auch (das war implizit eigentlich der wichtigste Punkt! ;-) ) Xmega kam überhaupt nicht vor, auch interessant. Natürlich soll der Raspberry sein Helferlein "im System programmieren", Bootloader-Fähigkeit kann man ja hoffentlich mittlerweile bei allen µCs voraussetzen. Das Anlaß-Projekt ist immer noch das selbe wie in meinem monologischen thread zum Thema einstellbarer Schaltregler. Dessen Ausgangsspannung soll der kleine µC über einen DAC variieren um eine 24V-Spannung auf eine Spannung zu down-steppen, die eine temperaturkompensierte Ladung eines Bleiakkus über einen Widerstand bewirken soll. Eine vergleichsweise statische Angelegenheit, aber sie sollte stabil bleiben, während der µC resetiert bzw. programmiert wird, daher wird es ein externer DAC sein. Es wird auch der Lade- und ggf. Entladestrom gemessen. Da das Projekt eine Überwachungskamera im Außenbereich (deswegen die Temperaturkompensation) ist (ganz normal, wie zigfach im Internet beschrieben), müßte ich diese onoffable- oder coocox-Dinger ein wenig anders montieren um den Kameraanschluß nicht zu verbauen, oder ich suche ein kleineres Modul, wie die von Reusch, das wäre dort aber ein Cortex-M4. Das Gehäuse ist jedenfalls fertig, Raspberry, Kamera und LEDs montiert. Von der I2C Schwäche des Raspberry hab ich auch schon gelesen, beim SPI will ich ebenfalls nichts riskieren, daß das z.B. intern für etwas anderes gebraucht wird (eben z.b. die Kamera oder der Analogtonausgabe). Die I/O-Pins vom Raspberry sind nicht so wirklich robust wie bei den Bastel-µCs AVR/PIC, das ist auch genau so ein Punkt, der beim Raspberry fehlt und den ein Neben-µC ausgleichen soll. STM32 wäre da schon i.O. Daneben sind noch zwei Infrarot-LEDs und zwei weiße LEDs zu dimmen. Die weißen sind Hochleistungs-LEDs, da wird per PWM ein fertiges Stromregler gedimmt, die infraroten haben einen höheren zulässigen Spitzenstrom im Vergleich zum Nennstrom, da werde ich eine eigene Regelung riskieren - allerdings noch immer mit einem Angstwiderstand (über den auch der Strom gemessen wird). Wichtigste Vereinfachung gegenüber einer professionellen Schaltung ist der bewußte Verzicht auf echte Shunts und OPVs. Und unter Verwendung fertiger Module hoffe ich auch, auf eine gedruckte Schaltung verzichten zu können. Kleinkram wie Temperatursensor und Lichtsensor gibt's auch noch, Meßbereichsumschaltungen... Was der kleine µC ohne Verrenkungen erledigen kann, wird er tun, im Hintergrund ist aber eh der Raspberry, z.B. mit Echtzeit-Uhr übers Internet um die IR-LEDs zu schalten, wenn der Lichtsensor ausfällt und solche Scherze. Aber im Prinzip würden auch Übermittlung und Empfang reiner Rohdaten reichen. Also doch eine ganze Anzahl von ADC Kanälen, ein paar PWM Kanäle und SPI, so im Wesentlichen, diesmal nichts wirklich zeitkritisches. Eine gegenseitige Watchdog-Funktion drängt sich natürlich ebenfalls auf, ich mag das Gehäuse ja nicht aufschrauben, nur weil der Raspberry irrtümlich heruntergefahren ist, oder darauf warten, daß der Akku endlich leer ist. (Eine Notschaltung gibt es jedoch schon, bei einer Umpolung der Versorgungsspannung wird ein Relais-Öffner betätigt um den Raspberry abzudrehen.) Da mir bei den klassischen kleinen und mittleren AVRs allzu oft irgendwas gerade doch noch fehlt, wäre jetzt der Zeitpunkt für einen Umstieg nicht ganz unpraktisch, deswegen meine Orientierungsfrage. Der Raspberry ist gesetzt, da er im Kollegenkreis weit verbreitet ist. Da ich momentan weitgehend auf Linux umstelle und allgemein kein glückliches Händchen bei der Wartung meiner PCs habe, wäre es mir lieb, das Ding auch in einigen Jahren noch programmieren zu können, so daß es alles nötige dazu an Bord hat. Das ganze eventuell auch übers Internet, die Kamera bräuchte ich ja nicht, wenn ich eh immer vor Ort wäre. Und da ich hoffentlich noch andere Sachen mit dem Raspberry machen werde, möchte ich jetzt auf eine etwas modernere und leistungsfähigere Plattform setzen, auch wenn ich das konkrete Projekt natürlich problemlos mit einem dickeren AVRmega erledigen könnte. Soviel Zeit habe ich privat leider nicht, um mit jedem Projekt die µC-Familie zu wechseln nur um mit einem perfekt angepaßten Käfer ein paar Cent pro Stück zu sparen. Arduino hab ich mir mal spaßhalber angeschaut, ist ja ganz lustig und mit dem Raspberry-2 (...evtl. mit Ubuntu?) müßte die IDE eigentlich schon laufen können. Arduino ist aber nicht ganz so mein Ding. In den PIC32 habe ich mich jetzt nicht vertieft, was einer vorschlägt, nämlich wine zu installieren um an irgendwelche notwendigen Dinge ...headerfiles? Keine Ahnung ... zu kommen, kommt wohl eher nicht in Frage. Was immer es ist - es muß ja keine riesige IDE wie Eclipse sein -, was für ARMv7 zu kompilieren ginge noch, aber ich mag sicher nicht in den Sourcecode des Compilers wühlen gehen. Die Linuxunterstützung ist allgemein für µC SW-build und upload nicht so schlecht, aber mit arch=ARMv7... Theoretisch müßte man ja eine open source toolchain für linux auf arm kompilieren können, aber ich weiß halt nicht, ob das in der Praxis auch so ist. Ich geh jetzt mal Doku zu dem STM32 lesen. Mein erster Eindruck ist, der Bootloader wird nicht ganz so simpel sein. Beim AVR reicht dafür im wesentlichen ein ORG-Pragma um die Dinge dort hinzukriegen, wo man sie haben will, beim Cortex heißt es offenbar erst mal Linkerfile und Startupcode basteln. Aber tutorials gibt es ja genug. LG!
Bitte 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.