Hallo zusammen! Ich habe bei mir dieses Hutschienenmultimeter (https://www.conrad.de/de/p/entes-epm-06cs-din-programmierbares-3-phasen-din-schienen-ac-multimeter-epm-06cs-din-spannung-strom-frequenz-betrieb-103280.html) verbaut. Das Teil hat eine RS485 Schnittstelle die ich mit einem RasPi + RasPiComm- Karte auslese. Für die RS485 Schittstelle wird vom Hersteller der RasPiComm Karte ein Kernelmodul zur Verfügung gestellt, welches ich auch installiert habe. Die RS485 Schnittstelle wird via SPI über einen MAX3140 realisiert. Das Ganze funktioniert auch erst mal schon seit einiger Zeit. Jetzt wollte ich das ganze mit einer PiFace Digitalkarte erweitern die ebenfalls über den SPI Bus läuft. Auf der PiFace Karte ist ein MCP23S17SP verbaut, der ebenfalls über SPI gesteuert wird. Beide sollten eigenlich zusammen am SPI Bus funktionieren, da man ja 2 Kanäle CE0 (/dev/spidev0.0) und CE1 (/dev/spidev0.1) zur Verfügung hat. Theoretisch sollte es sogar mit einem Kanal funktionieren, da die RS485 mit CE0=1 und die Interfacekarte mit CE0=0 aktiviert wird. Das Problem ist das das Kernelmodul für die RS485 beim Laden die /dev/spidev* Devicefiles entfernt. Damit ist die Interfacekarte über diese Devicefiles nicht mehr ansprechbar. Eigentlich soll das Kernelmodul nur /dev/spidev0.0 entfernen, aber er entfernt beide. Ich kann zwar das Devicefile wieder anlegen aber es wird nicht erkannt oder geblockt. Also habe ich mir gedacht, verzichtest Du halt auf das Kernelmodul und schreibste halt was Eigenes. Es gibt da eine Bibliothek (bcm2835) mit der man SPI Gedöns relativ einfach ansprechen kann. Dies scheint auch zu funktionieren und für das PiFace gibt es auch genug Dokumentation so das man da eine passende Befehlssequenz hin bekommt. Beim MAX3140 sieht es da relativ dünne aus. Es gibt da lediglich ein Datenblatt wo am Ende etwas zur Programmierung steht, aber da werde ich nicht wirklich schlau draus. Habe mich versucht im Netz kundig zu machen aber daa hält man sich auch eher bedeckt. Deshalb meine Frage: Hat da jemand schon mal was in der Richtung oder kennt zumindest die Befehlssequenzen mit der der MAX3140 zu Mitarbeit zu bewegen ist. Also solche Sachen wie kann ich abfragen ob das Teil überhaupt vorhanden ist, wie erreiche ich das ein Byte per RS485 gesendet wird usw. Da ich da schon eine Weile sitze bin ich für jeden Hinweis dankbar. Das kann doch nicht so schwer sein. Achso die Abfrage der RS485 muß nicht permanent erfolgen, so wie beim Kernelmodul. Ich frage die Daten eh nur einmal pro Minute ab. Evtl. würde es auch reichen wenn man es hinbekommt das Löschen der spi-Devicefiles durch das Kernelmodul zu verhindern.
Zeno schrieb: > Theoretisch sollte es sogar mit einem Kanal funktionieren, da die RS485 > mit CE0=1 und die Interfacekarte mit CE0=0 aktiviert wird. Das muss dann aber an den Interfacekarten liegen. MAX3140 und MCP23S17 werden beide mit CS aktiv low angesteuert. Was soll das für eine RasPiComm-Karte sein, auf der CS invertiert gesteuer wird?
Hm, ich verstehe das Problem nicht so ganz.
Den bus kann man doch wunderbar ansprechen mit ioctl:
struct spi_ioc_transfer SpiTransfer[1];
Status = ioctl (FileSpiDevice,
SPI_IOC_MESSAGE(1),
&SpiTransfer[0] );
Und dann setzt man sich hin und implementiert eine Basiskommunikation
zum Chip, um Modi zu setzen.
Ich habe den Max3140 noch nie programmiert, aber alle andere
Datenblätter sehen genauso aus. Das erfordert ein bisschen Einlesen vom
Programmierer.
Man programmiert erst mal ein paar Basis-Sachen wie Abfrage der
Statusbits.
Und dann versucht man, den Chip zu einer sinnvollen Arbeit zu bringen.
Dauert meist so 2-4 Tage, und dann geht das Teil.
Ist eben mal Arbeit.
Wenn ich nach "RasPiComm- Karte" suche finde ich Karten der Fa. Amescon. Verwendest du die? Den Code zum Kernel-Modul gibt es hier wenn ich mich nicht täusche: https://github.com/amescon/raspicomm-module Leider recht unschön. Die verwenden direkt die SPI-Hardware anstatt über den SPI-Kerneltreiber zu gehen. Damit ist der Parallelbetrieb zum spidev-Treiber eigentlich ausgeschlossen.
John Doe schrieb: > Rührende Geschichte! > Was schreibt der Hersteller auf Deine Anfrage hin? Danke das hat jetzt echt weiter geholfen. Schön das es immer wieder Leute gibt die besser mal die Griffel still halten sollten. Wolfgang schrieb: > Zeno schrieb: >> Theoretisch sollte es sogar mit einem Kanal funktionieren, da die RS485 >> mit CE0=1 und die Interfacekarte mit CE0=0 aktiviert wird. > > Das muss dann aber an den Interfacekarten liegen. MAX3140 und MCP23S17 > werden beide mit CS aktiv low angesteuert. Was soll das für eine > RasPiComm-Karte sein, auf der CS invertiert gesteuer wird? Die ist von AMESCOM. Ja ich weis das der Chip mit 0 aktiviert wird. Habe jetzt gerade noch mal nach geschaut. Die haben da noch einen Pegelwandler drauf und der ist bei mir irgendwie als Inverter durchgegangen. Manchmal trampelt man irgenwie auf der Stelle. Danke! Das hat auch erst mal weiter geholfen. Da muß ich heute Abend mal schauen ob dich damit das Ruder schon rum reißen kann. PittyJ schrieb: > Den bus kann man doch wunderbar ansprechen mit ioctl: > struct spi_ioc_transfer SpiTransfer[1]; > Status = ioctl (FileSpiDevice, > SPI_IOC_MESSAGE(1), > &SpiTransfer[0] ); > Und dann setzt man sich hin und implementiert eine Basiskommunikation > zum Chip, um Modi zu setzen. Das ist eine Möglichkeit, aber diese möchte ich nicht nutzen, weil diese nur funktioniert, wenn die Devicefiles da sind. Die bcm2835 ist auch nicht schwieriger zu handhaben und umgeht den Kram mit den Devicefiles. Wenn man die Bytesequenzen kennt um den Chip anzusprechen ist das überhaupt kein Problem, aber ich kenne sie eben nicht und aus dem Geschreibsel von Maxim werde ich nicht wirklich schlau. Zumindest nicht was diesen Chip betrifft. PittyJ schrieb: > Ich habe den Max3140 noch nie programmiert, aber alle andere > Datenblätter sehen genauso aus. Das erfordert ein bisschen Einlesen vom > Programmierer. > Man programmiert erst mal ein paar Basis-Sachen wie Abfrage der > Statusbits. Ja Du Schlauberger was meinst Du wohl was ich die letzten Tage gemacht habe. Um selbige abzufragen braucht es erst mal eine entsprechende Bytesequenz um dies dem Chip mitzuteilen. Wenn mann die nicht kennt dann ist es halt essig. Beim DS2482 haben die das deutlich besser gelöst. Da steht im Dabla eindeutig drin wie man das Ding anspricht, da ist das Ganze an einem Nachmittag erledigt. Beim 3140 hingegen sind zwar die Registerbits ordentlich erklärt, aber eben nicht wie man da hin kommt. Es gibt im Dabla nur am Ende ein paar (mir) nichts sagende Codeschnipsel. Wer's täglich macht der wurstelt sich da durch, aber zu den Leuten gehöre ich nicht. PittyJ schrieb: > Und dann versucht man, den Chip zu einer sinnvollen Arbeit zu bringen. > Dauert meist so 2-4 Tage, und dann geht das Teil. > > Ist eben mal Arbeit. dito Dominik S. schrieb: > Wenn ich nach "RasPiComm- Karte" suche finde ich Karten der Fa. Amescon. > Verwendest du die? > > Den Code zum Kernel-Modul gibt es hier wenn ich mich nicht täusche: > https://github.com/amescon/raspicomm-module > > Leider recht unschön. Die verwenden direkt die SPI-Hardware anstatt über > den SPI-Kerneltreiber zu gehen. > Damit ist der Parallelbetrieb zum spidev-Treiber eigentlich > ausgeschlossen. Ja genau die. Die bauen einen Kerneltreiber, der auch funktioniert, und ein /dev/ttyRPC0 zur Verfügung stellt. mit ioctl läuft es ja auch darüber seit gut einem Jahr. Jetzt wollt ich halt noch was dazu bauen und dabei habe ich eben festgestellt das dieser Kerneltreiber mir die SPI-Devicefiles abschießt. Man könnte jetzt den 3140 sicher auch über ioctl ansprechen aber auch dazu braucht es die Steuersequenzen. Da ich beides gleich machen möchte habe ich mich für die bcm2835 Bibliothek entschieden und spreche die SPI-Hardware direkt an. Die Devicefiles brauche ich dann nicht mehr.
Hallo Wolfgang! Möchte mich bei Dir nochmals für den Tip nach CS zu schauen bedanken - das war's. Irgendwie war ich da auf dem falschen Dampfer. Jetzt antwortet das Ding und jetzt habe ich auch verstanden wie MAXIM das mit der Kommunikation meit bzw. wie das Datenblatt zu lesen ist. Im Prinzip werden immer 2 Byte übertragen, wobei Bit 14 und 15 bestimmen was gemacht werden soll. Falls es Dich interessiert: Bit15/14 = 1/1 >> Konfiguration (Bit 13 - 0) schreiben Bit15/14 = 0/1 >> Konfiguration (Bit 13 - 0) lesen Bit15/14 = 1/0 >> Daten (1Byte) senden (Daten stehen im Low-Byte) Bit15/14 = 0/0 >> Daten (1Byte) lesen Bei der SPI Übertragung Highbyte zuerst Danke! Grüße aus Thüringen
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.