Forum: Mikrocontroller und Digitale Elektronik Welchen Mikrocontroller als Raspberry Ergänzung?


von Reinhard M. (reinhard_w)


Lesenswert?

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.

von Meister (Gast)


Lesenswert?

Moin,

passen die Module von http://www.coocox.org/hardware.html für dich 
eventuell, also das Embedded Pi?

Liebe Grüße, Jan

von Kurt H. (Firma: KHTronik) (kurtharders)


Lesenswert?

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

von Ulli-B (Gast)


Lesenswert?

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

von PittyJ (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Goff (Gast)


Lesenswert?


von Frank (Gast)


Lesenswert?

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...

von Reinhard M. (reinhard_w)


Lesenswert?

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
Noch kein Account? Hier anmelden.