|
Anzeige
|
PI 4 mit PIC18F KommunikationHallo in die Runde, mein Raspi 4 soll zukünftig die Netzleistungen vom Modbus TC/ IP abholen und an einen PIC18F senden. Welcher PIC es werden soll ist noch offen.. Welche Schnittstelle die EINFACH am PIC zu programmieren ist würdet ihr nehmen ? I2C SPI USB ?? Vielen Dank schon mal. UART
Warum? Was kann der, was ein Raspberry Pi nicht kann? Bzw. warum nicht einem Pic mit einer Ethernet-Schnittstelle ausrüsten?
Ethernet ist mir bekannter Maßen mit PIC für nicht Experten nicht so einfach PIC18F kann ich ganz gut „ohne Ethernet“ Thema Gab es schon mal.. Ich brauch eine einfache und für mich !! umsetzbare Lösung, zur Not mal hier oder den Arbeitskollegen mit einer Frage betteln aber nicht komplett Ethernet lernen Für dem PI 4 gibts ja Beispiele im Netz Danke
So kompliziert ist das auch nicht. Bei der richtigen Wahl des Controllers, gibt es auch entsprechende Beispiele. Da fällt der (genau dieser) PIC dann aber wohl raus.
Ja. Damit ist noch nicht die Frage beantwortet, warum du einen Pic an ein Raspberry Pi anbinden willst. Brauchst du den als I/O-Baustein?
Welcher wäre es den da ? Ein PIC32F
Der PI 4 soll nur die Leistung, Spannungen am Anschlusspunkt vom Homemanager lesen und zum PIC weiterleiten/ kommunizieren Das ist alles was er soll. Danke
Mit Kanonen auf Spatzen schießen, nur um den geliebten PIC zu nutzen - super Konzept. Und wieder einer Frage ausgewichen: Was soll der PIC überhaupt machen?
Für Modbus bietet sich UART mit RS485 an. Dann kannst Du einen käuflichen Modbus/TCP auf Modbus/RTU (seriell RS485) Umsetzer nehmen und das Modbus-Protokoll direkt auf dem PIC verarbeiten. Modbus/RTU ist ein wenig unterschiedlich zu Modbus/TCP, bei dem das TCP bereits die korrekte Übertragung sicherstellt. Bei Modbus/RTU fällt der Ethernet Header weg, und es kommt am Ende eine Prüfsumme dazu. So einen Umsetzer kann man sich auch leicht selber programmieren, aber es gibt das auch fertig zu kaufen, und in der Industrie wird sowas auch eingesetzt. Wenn Du das ganze nicht nur für Dich selber machen willst, solltest Du das genau so machen. Dann kann wer anders auch einfach ein anderes Modbus-Gerät anschließen. Es gäbe noch Modbus/Ascii, aber das verwendet heutzutage niemand mehr. Das war nützlich, als Kommunikationsstrecken noch 7-bittig waren, oder 5-Bit Baudot. Das Zeug kommt ja aus den 70'er Jahren. fchk
PIC24 wäre so eine Option. Die Programmierung entspricht in etwa dem PIC18, er hat aber mehr Ressourcen füt Ethernet. Gibt es auch Beispiele bei Microchip. Was natürlich immer noch nicht die Frage beantwortet, warum ein Pi was an den PIC schickt, was er nicht selber kann.
Der Pic + LCD soll einen einem Trafo mit Gleichrichter und Tiefsetzsteller betrieben werden, einen Akku tagsüber bei Überschuss laden und am Abend/ über Nacht über eine weiteren Tiefsetzsteller einen Mikrowechselrichter 600 oder 1000 W maximal stromgeregelt versorgen, so dass es ein Nulleinspeisung wird…
So ein Adapter/ Konverter kostet auch, 80 Euro wenn ich richtig gesucht habe .. Da macht es auch mein PI4, meine Meinung Entweder diese Lösung oder keine, weil PIC und Ethernet wird bei mir alleine nichts 🤷♂️
Schwere Geburt... Und das bekommst du (alleine) hin?
Wie stellst du dir denn die Umsetzung des Raspberry Pi auf PIC vor? Der Modubus-TCP-Konverter muss sein Signal ja irgendwie an den PIC weiterleiten (egal, über welche Schnittstelle). Oder gibt es da schon was fertiges? Ist von den Sachen überhaupt schon was vorhanden?
Du hast falsch gesucht. 51€ reichen. https://www.amazon.de/dp/B0B4JNWF7N
Dann solltest Du es aber standardkonform machen und nicht deinen eigenen Mist fabrizieren. Modbus/RTU (seriell, Binärformat): [CODE] [Addr][Func][Data 1....n][CRC1][CRC2] [/CODE] Modbus/TCP: [CODE] [TransIdH][TransIdL][00][00][00][06]{ff][Func][Data 1....n] [/CODE]
Die noch nicht beantwortete Frage war, warum Du das nicht komplett auf dem Pi implementierst. Der könnte das im Prinzip auch alleine. Wenn Du das auf dem Pi nicht hinbekommst, wirst Du auch die Protokollumsetzung nicht hinbekommen, denke ich. Deswegen der Hint mit den fertigen Gateways. fchk Uart ist zum Austausch selbst gefrickelter Daten das einfachste. Beliebige baudraten und Entfernungen möglich, da bidirektional und ohne clock-signal Problee (Doppelimpulse). In jedem uC vorhanden, simpelste Ansteuerung. Das ganze protokollgebastel ist trotzdem viel Arbeit: Telegramm-Format, Checksumme, Interrupt - Task synchronisieren (fifos), Timeouts, Fehlererkennung und Behandlung, ... Viele Designentscheidungen und Pitfalls. Ein fertiges Protokoll zu nehmen (z.b. modbus) oder eine Verbindung mit höheren Mechanismen (z.b. Can) ist da oft sinnvoll.
Für python gibt es fertige Modbus-Libraries. Ob die auch TCP können, weiß ich nicht (sollte sich aber herausfinden lassen - "not my job at the moment").
Falls irgendwas zeitkritisch-regelungstechnisch gemacht werden muss, wäre der PIC dafür geeignet. Für alles andere würde ich das Raspberry Pi verwenden. Für den PI 4 gibts das was fertiges für die SMA Umrichter… Hab mit dem PIC18F schon paar Sachen umgesetzt, läuft stabil und Elektronik Kenntnis gibts bzw. auf Arbeit verfügbar bei den Leiterplatten/ Schaltungsdesignern… Hätte auch Kollegen für die Software, aber will möglichst alleine vom Fleck kommen, nur für den Notfall/ Backup eben Wenn sich jemand hier findet auch als Open Source, aber das wird glaube ich nichts…. Naja, nicht wirklich hier weiter gekommen.. Werde mich mit SPI probieren ..
Sind denn noch Fragen offen? Und warum SPI? Schließlich gab es hier nicht einen, der da irgendwelche Vorteile sieht (genauso wie I2C oder USB). UART stand zwar nicht auf Deiner Liste, sollte aber in jedem Fall zwischen USB und SPI liegen. Geht auch anders, hab mit einem Aduino Mega und Ethernet Board Kommunikation zum Modbus aufgenommen und erfolgreich die Einspeiseleistung auf dem Serial Monitor zum Vorschein gebracht. Sehr übersichtliches Programm, worauf man aufbauen kenn… Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
