Forum: Mikrocontroller und Digitale Elektronik STM32 Welches Protokoll für Projekt


von Silvan R. (Firma: keine) (gabber)


Lesenswert?

Hallo Mikrocontroller-Forum,

ich bin dabei ein Projekt von Arduino Mini's auf STM32 zu zügeln.

In dem Projekt sind mehrere DC-DC Wandler (MPPTs und 
Batterieanbindungen), von diesen würde ich gerne regelmässig (von Rpi) 
den Status (Strom / Spannung) auslesen und evtl. Steuersignale senden.

Bisher mache ich dies per I2C mit der Wire-Bibliothek. Das hat aber zu 
Problemen geführt als ich die ADCs per interrupt genutzt habe (Anfrage 
per I2C hat den uP zum Hängen gebracht). Anstelle das zu debuggen habe 
ich mich entschieden auf eine neuere Platform zu wechseln: STM32.

Nun habe ich kaum Beispiele für einen I2C Master auf einem STM32 
gefunden und frage mich: Mache ich etwas sinnfreies? Bisher habe ich 
gute Erfahrungen gemacht mit I2C. Er lässt isch günstig isolieren, ist 
nicht sehr anspruchsvoll (2 Leitungen) und ich kann die PCBs einfach 
parallelschalten (kein Switch nötig)

Wie würded ihr die Kommunikation zwischen mehreren DC-DC Wandlern und 
einem RPi realisieren?


Gruess

Nachtrag: Die maximale Distanz ist 5m. Bisher schlaufe ich den I2C 
durch, die Boards selbst sind isoliert. Als Kabel setze ich LAN Kabel 
ein.

: Bearbeitet durch User
von Nolli (Gast)


Lesenswert?

I2c ist nicht besonders störfest und eher für kurze Verbindungen auf 
einer pcb gedacht. Nimm besser für den physikalischen layer ein 
differenzielles übertragungssystem und ein Protokoll deiner Wahl mit 
parity, crc etc...

von Nolli (Gast)


Lesenswert?

Nachtrag: bitte system exakt beschreiben. Dazu gehören auch 
Leitungslängen.

von Silvan R. (Firma: keine) (gabber)


Lesenswert?

Hoi Nolli,

Danke für deine Anregungen, ich habe den Beitrag ergänzt

Bei der Auswahl stehe ich ja gerade an, bisher habe ich nur Erfahrungen 
mit I2C via die Wire-Library. Da lief bisher alles rund von dem 
elektrischen bis zur Software.

Die Kommunikation soll 'good enough' sein für das Aufzeichnen von Daten. 
Wenn ab und zu ein Wert verloren geht ist das kein Problem. Nebst I2C 
kenne ich noch ModBus/TCP von gekauften Geräten.

Gruess

von Frank K. (fchk)


Lesenswert?

Es lohnt sich immer, abseits der Bastlerschiene auf die 
Automobilindistrie zu schauen. Was die machen, ist erprobt, billig und 
wird in gigantischen Stückzahlen produziert.

Ein Beispiel ist LIN: Das ist ein serieller 1-Draht Bus, der mit 
Bordnetzspannung betrieben wird. In Deinem Auto wirst Du mit Sicherheit 
auch CAN und LIN finden.

Für LIN gibt es Systemchips, die nach außen 12V Spannungsversorgung, 
Bustreiber und überspannungsschutz für Stromversorgung und Datenleitung 
(teilweise bis zu +60V/-24V) haben, und nach innen 5V oder 3.3V LDO für 
den angeschlossenen uC,  TX/RX für einen UART (der bei LIN ein paar 
speziellere Anforderungen erfüllen muss, daher sind die meisten AVRs 
dafür nur schlecht geeignet, Du kannst nur ein paar ausgewählte Typen 
nehmen wie Tiny817, die explizit LIN können; bei PICs ist die Auswahl 
VIEL größer) und Wake-Up-Logik. Diese Systemchips kostet den Hersteller 
nur Cents (z.B. MCP2004A, dazu ein kleiner uC wie z.B ein PIC16F18425, 
und fertig ist der LIN-Knoten für 30 Cent. In Einzelstückzahlen beim 
Katalogdistributor ist das natürlich viel teurer, aber auch da bist Du 
mit 1.50€ dabei.

https://www.kfz-tech.de/Biblio/Digitaltechnik/LIN-Bus.htm

https://www.microchip.com/design-centers/lin

fchk

von Johannes S. (Gast)


Lesenswert?

Wie wäre es mit good old RS485? Oder selbst Ethernet ist heute günstig 
einzusetzen. Entweder über die STM32 mit eingebauten MAC + ext. Phy 
board, oder mit Wiznet Chips die es auch günstig als Chinamodul gibt.

Beispiel F407 (mit SDC, dann kann man auch lokal loggen):
https://de.aliexpress.com/item/4000077989696.html
https://de.aliexpress.com/item/32947407343.html

von Silvan R. (Firma: keine) (gabber)


Lesenswert?

Besten Dank für die Inputs!

LIN sieht spannend aus, Ethernet schien overkill (ich habe vor jedem der 
15 PV-Panel einen MPPT zu spendieren). Aber mit LIN dazwischen sieht das 
wieder anders aus.

von TR.OLL (Gast)


Lesenswert?

CAN?

von Heinz M. (subi)


Lesenswert?

UART und I2C sind sehr einfach auf dem STM32, wenn man die CubeMX 
Bibliotheken nutzt.

Ein gutes Video was mir geholfen hat:
https://www.youtube.com/watch?v=v1_f5u5pChs

CAN ist doch etwas schwieriger. Da muss noch einiges an Code reinkopiert 
werden. Das Video ist sehr gut plus Teil 2:
https://www.youtube.com/watch?v=79TbYAKpIkg

Für mich klingt das aber mehr so, als wenn du einen Raspberry Pi hast 
und auf die Mikrocontroller zugreifen möchtest. Dann muss I2C als Slave 
laufen. UART und ein selbstprogrammierter Token zur Kollisionsvermeidung 
könnte die einfachste Realisierung sein.

ADC lasse ich immer permanent (continous convertion) mit DMA laufen. Im 
Interrupt der ausgelöst wird, wenn eine Konvertierung fertig ist, wird 
gleich noch etwas Oversampling betrieben und anschließend in eine 
Variable gespeichert. Diese wird in der Hauptschleife einfach abgerufen, 
wenn es benötigt wird. Währenddessen macht der ADC schon weiter. Dadurch 
vermeide ich solche Laufzeitprobleme und hab gleichzeitig viel mehr 
Rechenzeit für andere Sachen.

von Stefan F. (Gast)


Lesenswert?

Silvan R. schrieb:
> Nun habe ich kaum Beispiele für einen I2C Master auf einem STM32
> gefunden

Da hast du welche: http://stefanfrings.de/stm32/index.html

von Uli N. (uln)


Lesenswert?

Silvan R. schrieb:
> Nachtrag: Die maximale Distanz ist 5m.

Bei 5m würde ich Dir CAN empfehlen.

von Silvan R. (Firma: keine) (gabber)


Lesenswert?

CAN scheint mir ziemlich aufwendig, vorallem nachdem ich von LIN gehört 
habe :)


Stefan ⛄ F. schrieb:
> Silvan R. schrieb:
>> Nun habe ich kaum Beispiele für einen I2C Master auf einem STM32
>> gefunden
>
> Da hast du welche: http://stefanfrings.de/stm32/index.html

Sorry ich meinte natürlich Slave. Der Master wäre der RPi.

von Uli N. (uln)


Lesenswert?

Silvan R. schrieb:
> CAN scheint mir ziemlich aufwendig, vorallem nachdem ich von LIN gehört
> habe :)

Sehe da eigentlich keinen großen Unterschied im Aufwand - Du hast für 
beides auf der Hardwareebene einen entsprechenden Treiberbaustein und 
kannst bei der Software wohl in beiden Fällen auf entsprechende 
Libraries zurückgreifen - zumindest für CAN und STM32 ist entsprechendes 
in der HAL vorhanden. Der größere Protokollaufwand bei CAN wird ja 
komplett von der CAN-Hardware abgewickelt!

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.