Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
bei unseren PiXtend V2 Geräten mit CODESYS ist ein Problem mit dem SPI0 und dem IoDrvGPIO aufgetaucht. Wir verwenden den SPI0 mit CE0 am RPi zur permanenten Kommunikation mit einem Mikrocontroller. Wenn ich mit SP18 Patch 3 und RPi Package 4.5.0.0 oder später ein nagelneues Projekt erstelle, funktioniert die SPI Kommunikation nicht mehr sauber.
Habe in den GPIO Treiber geschaut und da war bis SP16 in der Methode GPIO.SetOutputs eine Abfrage drin, ob sich an den GPIOs was geändert hat und nur dann wurde auf den RPi GPIO Memory Bereich geschrieben. Seid 4.1.0.0 wird immer geschrieben!
Das Problem ist, dass nur die GPIOs für MISO, MOSI und SCK nach ALT0 umgeschaltet werden, die GPIOs für CE0 und CE1 nur als Outputs (O) vom Overlay konfiguriert werden.
Wenn der IoDrvGPIO jetzt startet, sieht er zwar GPIO 7 und 8 als Outputs und auch dass diese auf 1 (True) stehen, übernimmt diese Info, sieht aber nicht dass sie zum SPI0 gehörten. Im Betrieb wird jetzt bei jedem Buszyklus/Intervall fleißig auf GPIO7/8 immer eine 1 geschrieben, obwohl beim Datentransfer der SPI0-Treiber den CE0 auf 0 (False) ziehen muss. Dadurch kommen nicht mehr alle Daten beim MC an und es kommt zum CRC-Fehler.
Ist das noch jemanden aufgefallen?
Ich schlage eine Änderung des IoDrvGPIO vor, dass in der Methode GPIO.GetType geprüft ob der SPI0 aktiviert wurde, also GPIO9, 10 und 11 im Mode ALT0 sind, dann sollten auch die GPIO7 und 8 gesperrt werden. In meinem Vorschlag werden diese einfach auch mit ALT0 gekennzeichnet. Der Anwender kann diese in CODESYS eh nicht verwenden. Dasselbe gilt auch für SPI1.
Ich hab Bilder beigefügt der IoDrvGPIO Methoden von SP16 und 4.5.0.0 Versionen und wie ein ggf. Improvment aussehen könnte. Bei mir lokal scheint nach der Änderung alles wieder wie vorher zu funktionieren.
Ich habe aktuell immer mehr Kunden die SP18 einsetzen und das RPi Package 4.1.0.0 oder später und Probleme haben per SPI0 mit dem MC auf dem PiXtend Board zu sprechen und immer einen CRC-Fehler angezeigt bekommen, was sehr ärgerlich ist.
Hallo Zusammen,
bei unseren PiXtend V2 Geräten mit CODESYS ist ein Problem mit dem SPI0 und dem IoDrvGPIO aufgetaucht. Wir verwenden den SPI0 mit CE0 am RPi zur permanenten Kommunikation mit einem Mikrocontroller. Wenn ich mit SP18 Patch 3 und RPi Package 4.5.0.0 oder später ein nagelneues Projekt erstelle, funktioniert die SPI Kommunikation nicht mehr sauber.
Habe in den GPIO Treiber geschaut und da war bis SP16 in der Methode GPIO.SetOutputs eine Abfrage drin, ob sich an den GPIOs was geändert hat und nur dann wurde auf den RPi GPIO Memory Bereich geschrieben. Seid 4.1.0.0 wird immer geschrieben!
Das Problem ist, dass nur die GPIOs für MISO, MOSI und SCK nach ALT0 umgeschaltet werden, die GPIOs für CE0 und CE1 nur als Outputs (O) vom Overlay konfiguriert werden.
Wenn der IoDrvGPIO jetzt startet, sieht er zwar GPIO 7 und 8 als Outputs und auch dass diese auf 1 (True) stehen, übernimmt diese Info, sieht aber nicht dass sie zum SPI0 gehörten. Im Betrieb wird jetzt bei jedem Buszyklus/Intervall fleißig auf GPIO7/8 immer eine 1 geschrieben, obwohl beim Datentransfer der SPI0-Treiber den CE0 auf 0 (False) ziehen muss. Dadurch kommen nicht mehr alle Daten beim MC an und es kommt zum CRC-Fehler.
Ist das noch jemanden aufgefallen?
Ich schlage eine Änderung des IoDrvGPIO vor, dass in der Methode GPIO.GetType geprüft ob der SPI0 aktiviert wurde, also GPIO9, 10 und 11 im Mode ALT0 sind, dann sollten auch die GPIO7 und 8 gesperrt werden. In meinem Vorschlag werden diese einfach auch mit ALT0 gekennzeichnet. Der Anwender kann diese in CODESYS eh nicht verwenden. Dasselbe gilt auch für SPI1.
Ich hab Bilder beigefügt der IoDrvGPIO Methoden von SP16 und 4.5.0.0 Versionen und wie ein ggf. Improvment aussehen könnte. Bei mir lokal scheint nach der Änderung alles wieder wie vorher zu funktionieren.
Ich habe aktuell immer mehr Kunden die SP18 einsetzen und das RPi Package 4.1.0.0 oder später und Probleme haben per SPI0 mit dem MC auf dem PiXtend Board zu sprechen und immer einen CRC-Fehler angezeigt bekommen, was sehr ärgerlich ist.
Danke schon mal.
Gruß
Robin