Hallo,
ich beschäftige mich gerade mit einem Getränkeautomat und versuche die
einzelnen Komponenten anzusteuern.
Die Spiralen sind schon erledigt und wurden in einem anderen Thread
behandelt: Beitrag "Re: Unbekanntes Bus System entschlüsseln"
Der Automat hat auch einen Lift, welcher mit einem DC Motor mit Encoder
ausgestattet ist. Dieser Motor wird über einen Atmega48 gesteuert.
Auf der Platine befinden sich eine H-Brücke mit MOSFET und ein Eingang
für einen Endlagenschalter.
Ich habe mich bereits erfolgreich in den Bus gehängt und einen Dump von
einer zyklischen Abfrage erstellt.
Mein Logik-Analyzer könnte eigentlich I2C lesen und ausgeben, aber
leider nicht sehr zuverlässig.
Ich konnte schon das Positionier-Kommando entschlüsseln, bei der
Status-Abfrage hat sich der I2C Parser irgendwie verabschiedet.
Im anderen Thread wurde PulseView zur Analyse genutzt, leider bekomme
ich die Daten meines LA nicht ohne Nachbearbeitung rein.
Ich spiele mich mal ein wenig mit Python, im anderen Thread wurde hierzu
schon ein Script geschrieben, jedoch für USART und nicht I2C.
Eventuell ist hier wieder jemand schneller. ;-)
EDIT:
Daten vom Positionier-Befehl
...und was ist jetzt die Frage...?
Bei den "Positionierbefehlen" vermisse ich ein wenig das I2C-typische
(Adresse, Register-Nummer etc.).
Die Daten aus "i2clift.png" ergeben folgendes:
1
S 0101100 1 0 00000000 1 P
2
START Addr=0x2C Read ACK 0x00 NACK STOP
Seltsam ist hier, dass offenbar Register 0x00 von Device 0x2c ausgelesen
werden soll, allerdings fehlt die Übertragung des Registerinhaltes (nach
der Register-Nummer).
Stefan schrieb:> Das sieht eher SPI aus
Für mich sieht das eindeutig nach I2C aus.
Start/Stop conditions, Anordnung der Clock-Flanken zu den Daten,
tri-staten für das NACK/ACK Bit, alles deutlich sichtbar...
Joe F. schrieb:> ...und was ist jetzt die Frage...?>
wie muss ich den STM32L476RG in cubeMx Konfigurieren damit ich diese
Daten senden kann.
Aber mal step by step.
Ich denke, dass es I2C ist, nicht nur aufgrund der Beschriftung auf der
Platine.
Die Clk Data Signale sehen auch sehr danach aus
Daniel A. schrieb:> Aber mal step by step.
Genau, aber erstmal müsstest du evtl. erläutern, wie du auf die Daten
01011001 11011100 => Position 89
kommst. Ich sehe wie gesagt eine Device Adresse 0x2C, die kommt in
deinen Daten nicht vor.
Ein Screenshot eines solchen vollständigne Positionier-Kommandos würde
ausreichen (in der Art wie i2clift.png).
Das Decodieren "zu Fuß" ist nicht allzu schwierig...
Joe F. schrieb:> Daniel A. schrieb:>> Aber mal step by step.>> Genau, aber erstmal müsstest du evtl. erläutern, wie du auf die Daten>> 01011001 11011100 => Position 89>> kommst. Ich sehe wie gesagt eine Device Adresse 0x2C, die kommt in> deinen Daten nicht vor.
Die Daten hat mein LA noch ausgegeben bevor der I2C Parser den Geist
aufgegeben hat. Jetzt gibt er nur noch Müll aus. Hab noch ein weiteres
softoszi mit NucleoBoard, aber das brauche ich auch zum Entwickeln also
muss ich irgendwie mit diesen Daten was anfangen.
Mein LA konnte nämlich auf I2C Bytes triggers und somit konnte ich die
Daten schon mal rausfiltern und dokumentieren
Joe F. schrieb:> Ein Screenshot eines solchen vollständigne Positionier-Kommandos würde> ausreichen (in der Art wie i2clift.png).> Das Decodieren "zu Fuß" ist nicht allzu schwierig...
Hab leider keine Möglichkeit die Befehle aus dem zyklischen Stream zu
filtern. Muss ein I2C zu USB Interface suchen oder gleich am STM32 herum
probieren und mal Daten reinschieben und schauen was rauskommt. Will
aber nicht zu viel probieren, nicht dass ich eventuell noch Parameter
verstelle.
Daniel A. schrieb:> Joe F. schrieb:>> Ein Screenshot eines solchen vollständigne Positionier-Kommandos würde>> ausreichen (in der Art wie i2clift.png).>> Das Decodieren "zu Fuß" ist nicht allzu schwierig...>> Hab leider keine Möglichkeit die Befehle aus dem zyklischen Stream zu> filtern. Muss ein I2C zu USB Interface suchen oder gleich am STM32 herum> probieren und mal Daten reinschieben und schauen was rauskommt. Will> aber nicht zu viel probieren, nicht dass ich eventuell noch Parameter> verstelle.
Dann logge es doch als Rohdaten mit.
Mit dem .MSD File kann man auch was anfangen, die Bits kann man dann
z.B. auch in Excel importieren und als Waveform anzeigen lassen.
Hauptsache es ist das komplette Kommando zu sehen, und nicht irgendwas,
was ein offenbar kaputter Parser rauswirft.
Joe F. schrieb:> Dann logge es doch als Rohdaten mit.> Mit dem .MSD File kann man auch was anfangen, die Bits kann man dann> z.B. auch in Excel importieren und als Waveform anzeigen lassen.> Hauptsache es ist das komplette Kommando zu sehen, und nicht irgendwas,> was ein offenbar kaputter Parser rauswirft.
Da kann ich nur die zyklischen Daten aufzeichnen, ich müsste das Signal
der Tastatur abgreifen damit ich einen trigger für das interessante
signal hätte.
Daniel A. schrieb:> Da kann ich nur die zyklischen Daten aufzeichnen,
besser als nichts
> ich müsste das Signal> der Tastatur abgreifen damit ich einen trigger für das interessante> signal hätte.
oder vom Motor, der sich nach dem Befehl bewegt.
Lass' dir was einfallen... ;-)
Joe F. schrieb:> Daniel A. schrieb:>> Da kann ich nur die zyklischen Daten aufzeichnen,>> besser als nichts>>> ich müsste das Signal>> der Tastatur abgreifen damit ich einen trigger für das interessante>> signal hätte.>> oder vom Motor, der sich nach dem Befehl bewegt.> Lass' dir was einfallen... ;-)
Hatte das selbe Problem beim UART stream.
Ich werde mir dann wohl ein Nucleo Board als LA aufbauen damit ich
weiter analysieren kann.
Daten folgen...
Achso verstehe, dein jetziger "Logic Analyzer" mit dem das File erstellt
wurde scheint ein "MSO-19" zu sein, und das kann wohl nur 1000
Messpunkte aufnehmen...?!
Das taugt natürlich nicht viel.
Joe F. schrieb:> Achso verstehe, dein jetziger "Logic Analyzer" mit dem das File erstellt> wurde scheint ein "MSO-19" zu sein, und das kann wohl nur 1000> Messpunkte aufnehmen...?!> Das taugt natürlich nicht viel.
Nein, es ist ein MSO-28
Ist aber auch nicht besser.
Nun habe ich es geschafft alle gesendeten Kommandos und Status-Signale
zu interpretieren und der Automat läuft auch schon über meinen
Controller.
Problem war die Leitungslänge beim Analysieren. Das Kabel ist nämlich
20m lang vom Automat bis ins Büro. Das I2C Signal hatte daher ein paar
Peaks, was zu einer Fehlinterpretation bei meinem LA führte. Direkt
angesteckt mit 20cm Leitungslänge ging es dann wieder.
Der MSO-28 stößt hier an seine Grenzen. Deswegen habe ich mir gestern
einen LA um 15€ für PulseView bestellt.
Die Software Analyzer2Go, welcher Nucleo Boards unterstützt, hab ich mir
auch mal gekauft. Die aber ist extrem schlecht. Die Software stürzt
ständig ab und verwechselt intern die Signale. Das war ein richtiger
Fehlkauf.
Welchen LA würdet ihr für Bus-Analysen verwenden?
Hätte mir vor einiger Zeit mal ein Hantek 4032L für die Verwendung mit
PulseView bestellt, was leider nie gekommen ist :-(
Bin jetzt wieder auf der Suche nach einem Halbwegs vernünftigen Gerät,
das aber nicht gleich 1000€ kostet.
Bei einer anderen Anwendung habe ich einen 8 Bit parallel-Bus untersucht
und war mit 10 Signalen auch wieder am Limit. Ich denke PulseView wird
mir da schon viel helfen. Bin gespannt wie der billig LA funktioniert.
Daniel A. schrieb:> Welchen LA würdet ihr für Bus-Analysen verwenden?
Ich bin mit dem Saleae Logic Pro 16 äußerst zufrieden. Kostet zwar knapp
900 EUR, ist sein Geld aber durchaus wert.
Wenn man mit 8 Ch auskommt und die Signale nicht allzu schnell sind,
gibts auch günstige Saleae Clones am Markt für unter 10 EUR (für I2C und
die meisten SPI und UART Anwendungen absolut ausreichend).
Für deine Zwecke bei diesem Projekt würde es aber vermutlich ausreichen,
wenn du dir für irgend eines deiner Boards eine Firmware schreibst, die
dir die I2C Leitungen schnell genug sampelt und in eine Datei
wegschreibt.
Dann kannst du den Traffic bequem offline mit Sigrok (Pulseview)
analysieren.
Diese open source Software kann einige Fileformate importieren, z.B.
rohe Binärdaten oder .csv.
Dein .MSD file in .csv konvertiert und importiert sieht dann so wie im
Anhang aus.
Joe F. schrieb:> Ich bin mit dem Saleae Logic Pro 16 äußerst zufrieden. Kostet zwar knapp> 900 EUR, ist sein Geld aber durchaus wert.
Was würdest du zum Rigol MSO5072 sagen?
https://www.batronix.com/versand/oszilloskope/Rigol-MSO5072.html
Da ist gerade das Software Optionsbundle im Wert von 600€ dabei.
Nur der nötige LA Adapter PLA2216 um 300€ ist schon heftig.
Nach ein bisschen recherchieren im Netz habe ich keine vernünftige
Software gefunden und das Rigol hat eine höhere Abtastrate und größere
Speichertiefe.
Daniel A. schrieb:> Nach ein bisschen recherchieren im Netz habe ich keine vernünftige> Software gefunden und das Rigol hat eine höhere Abtastrate und größere> Speichertiefe.
Tja, keine Ahnung, kenne das Ding nicht.
Persönlich habe ich den Logicanalyzer lieber separat vom Scope und schön
klein (transportabel) muss es sein.
Die "Speichertiefe" des Pro16 ist im Prinzip nur durch den Rechner
begrenzt, das erlaubt minutenlanges Samplen. Ausserdem habe ich gerne
die Möglichkeit, Daten zu exportieren, um eigene Analyzer draufzuwerfen,
wenn die Möglichkeiten der mitgelieferten Software nicht ausreichen
(z.B. Timinganalysen, Fehlersuche in exotischen Protokollen).
Habe gestern versehentlich 5V anstelle einer Messleitung am SDA Pin der
Platine angeschlossen und auf einmal hat die Karte nichts mehr gesendet.
Ich habe die Platine dann schnell mal nachgezeichnet um das große Ganze
zu verstehen und eventuell nachzubauen. Ist eine ganz primitive H-Brücke
mit einfachstem I2C Pegelwandler auf PNP Transistor Basis.
Meine erste Vermutung war, dass die 5V durch das Low-Ziehen einen
Kurzschluss im Atmega48 verursacht hat. Habe daher zuerst den Atmega
ausgelesen, leider Schreibgeschützt. :-(
Also entweder tot oder ein anderes Problem finden...
Interessanterweise hat aber der Atmega48 noch auf Kommandos reagiert,
aber kein ACK-Bit und keine Antwort gesendet.
Daher war meine zweite Vermutung ein defekter Transistor und daher habe
ich den PNP Transistor der SDA Leitung ausgelötet und einen anderen
eingelötet.
*Angesteckt, eingeschaltet und ging wieder*
Dieser Fehler ist mir aber nur passiert, weil ich entdeckt habe, dass
meine FDTI-RS232-5V Kabel perfekte Logik Analyzer sind und ich das
gleich probieren musste. Leider waren auch 5V am Stecker und ich habs
mit einer Messleitung verwechselt.
Vor vielen Jahren habe ich für ein Projekt über 20 Stk. gekauft und nie
wirklich gebraucht. Jetzt waren sie die perfekte Lösung mit 8 Eingängen.
Im Anhang ist noch der Log von PulseView. Sieht jetzt viel besser aus
und die Startup Signalfolge ist schön ersichtlich.
Der Lift fährt zuerst eine Referenzfahrt nach unten aus und dann fährt
der Lift nach ganze unten und schlussendlich zum ersten Produkt.
Gibt es eine Möglichkeit in PulseView den Datenstream eines Kanals im
Terminal auszugeben oder umzuleiten? Mit dem CLI geht es ja, wäre in der
GUI aber auch schön.
Joe F. schrieb:> Ich bin mit dem Saleae Logic Pro 16 äußerst zufrieden. Kostet zwar knapp> 900 EUR, ist sein Geld aber durchaus wert.Daniel A. schrieb:> Nach ein bisschen recherchieren im Netz habe ich keine vernünftige> Software gefunden
...man "irgendeinen 0815-LA" für 10 Euro und als Software
https://sigrok.org/
Daniel A. schrieb:> Das Kabel ist nämlich 20m lang vom Automat bis ins Büro. Das I2C Signal> hatte daher ein paar Peaks
20 Meter bei I2C? Das ist schon extrem sportlich! Hast du da
zwischengeschaltete Verstärker? Du weißt schon das I2C nie als Feldbus
konzipieren war und, wie der Name schon sagt als Platinenbus?
Rene K. schrieb:> 20 Meter bei I2C? Das ist schon extrem sportlich! Hast du da> zwischengeschaltete Verstärker? Du weißt schon das I2C nie als Feldbus> konzipieren war und, wie der Name schon sagt als Platinenbus?
Nein, da ist kein Verstärker drin. Ich hatte einfach noch 6 Leiter im
CAT5 Kabel frei und habs einfach probiert. Interessanterweise
funktioniert über die 20m die Ansteuerung durch den STM32 besser als die
Auswertung über den LA mit Pulseview.
Thread beobachten
Seitenaufteilung abschalten