Hallo,
Ich bin hier neu und hätte sogleich eine Frage. Vorab muss ich noch sagen, ich habe wenig Ahnung von mikrocontrollern aber bin willens, vorhandene Wissenslücken zu füllen.
Ich habe ein Anzeigeplatine mit 4 großen 7 segment Anzeigen drauf, welche mit einem 32 bit Schieberegister(UCN5833) verbunden sind. Dieser wird von dem AT89C2051 "gefüttert.
Am Pin 2, was der RX Anschluss ist, wird er noch über einen Transistor mit Daten versorgt. Nun stellt sich mit die Frage, wie bekomme ich heraus, mit welchen Signalen ich ihn versorgen muss um eine sinnvolle Anzeige von Werten zu bekommen?
Ich hätte allerlei Messmittel zur Verfügung, sowie eine USB > UART bridge.
wie bekomme ich heraus, mit welchen Signalen ich ihn versorgen muss
In erster Linie aus der Dokumentation. Ider man analysiert den Quelltext der Firmware, falls vorhanden. Ansonsten: vergiss es. Das ganze Produkt neu zu erfinden geht schneller und billiger.
4 x 7 = 28 ==> Jedes Segment an einen Ausgang. Such die Eingänge des Schieberegisters steuere es passend an und schiebe Bitmuster durch und man wird sehen.
Ich glaube ihr habt den TO missverstanden. Der Mikrocontroller ist Bestandteil der Anzeige. Diese hat einen seriellen Eingang. Er will das Kommunikationsprotokoll herausfinden, nicht den Mikrocontroller der Anzeige programmieren.
Mit dem UART des 2051 kannst du das Schieberegister nicht füttern.
In welcher Sprache willst du denn das Programm für den 2051 erstellen?
Das ist eine vorhandene Platine, ein kommerzielles Produkt wo ich auch dessen Programm nicht kenne. Ich hatte gehofft dass ich herausbekomme, mit welchen Signalen ich den UART füttern muss. Das schieberegister ist an den normalen IO Pins angeschlossen.
In erster Linie aus der Dokumentation. Ider man analysiert den Quelltext
der Firmware, falls vorhanden. Ansonsten: vergiss es. Das ganze Produkt
neu zu erfinden geht schneller und billiger.
Ich glaube ihr habt den TO missverstanden. Der Mikrocontroller ist
Bestandteil der Anzeige. Diese hat einen seriellen Eingang. Er will das
Kommunikationsprotokoll herausfinden, nicht den Mikrocontroller der
Anzeige programmieren.
Ach je, das geht natürlich nur wenn er eine funktionierende Kommunikation mitverfolgen kann.
Wenn ich ein Programmiergerät für den AT89C2051 hätte, würde ich dessen
Firmware mit meiner eigenen überschreiben.
Leider habe ich kein solches Programmiergerät, dafür aber bspw. eins für
AVRs. Da ich auch noch ein paar pinkompatible ATtiny2313 herumliegen
habe, würde ich diesen programmieren und anstelle des AT89C2051 in den
Sockel stecken.
Fertig.
Ob das auch für dich eine Option ist, hängt natürlich von deiner
Hardwareausstattung und deinen Programmierkenntnissen ab.
Läßt sich die Firmware des AT89C2051 auslesen oder sind die Lock Bits gesetzt? Falls sich die Firmware auslesen läßt stelle sie hier rein, dann kann man schauen wie die UART Kommunikation abläuft.
Vielen Dank für eure Antworten.
Auslesen kann ich den leider nicht auslesen, da ich kein HV programmer habe. Einen ATiny2313 müsste ich mir erst besorgen und dann könnt ichs mal versuchen selbst zu programmieren... so gleich als Übung.
Aber lässt sich das nicht empirisch ermitteln? Spannung ist ja klar, nur die baudrate durchprobieren? Variiert das so sehr, was als Zahlen gesendet werden kann?
Variiert das so sehr, was als Zahlen
gesendet werden kann?
Ja.
Mist... Ich könnte ja versuchen, vom PC mit nem teminalprogramm mit verschiedenen baudraten mal zu senden und wenns nicht klappt, dann halt Haken dran.
Mist... Ich könnte ja versuchen, vom PC mit nem teminalprogramm mit
verschiedenen baudraten mal zu senden und wenns nicht klappt, dann halt
Haken dran.
Du kannst auch ein Programm schreiben, das nacheinander für verschiedene
Baudraten zufällige Daten hinausballert. Wenn dann irgendwann etwas
angezeigt wird, weißt du, dass du auf dem richtigen Weg bist, und kannst
die Sache näher eingrenzen.
Wenn die Firmware die Nachrichten aber per Prüfsumme auf Korrektheit
testet und diese Prüfsumme auch eine der unzähligen CRC-Varianten ist,
wirst du ewig am Herumprobieren sein.
Du kannst auch ein Programm schreiben, das nacheinander für verschiedene
Baudraten zufällige Daten hinausballert. Wenn dann irgendwann etwas
angezeigt wird, weißt du, dass du auf dem richtigen Weg bist, und kannst
die Sache näher eingrenzen.
Um dazu ein Programm zu schreiben, fehlen mir die Kenntnisse. Gibt's sowas in irgendeiner Form fertig?
Dann kann man einen dieser kleinen CH340/341 USB/UART-TTL Adapter an den PC hängen und an den MC und dann mit z.B. HTerm einfach was senden.
Das wird nicht lange dauern und da kommt was. Gibt ja nicht mal Handshake oder sowas.
Die Übertragungsparameter (Baudrate, Parity etc.) herauszufinden, ist das eine, aber das /Protokoll/, mit dem das Ding seine Daten bekommen will, durch reines Raten herausfinden zu wollen, ist ... ein bisschen wie die Geschichte mit den Schimpansen und den Shakespeare-Sonetten.
Es /kann/ sein, daß da ASCII-Text mit CR oder LF gesendet wird:
"01234\n"
Es kann aber auch sein, daß der Wert als Binärzahl gesendet wird, und das wiederum in irgendeinen Protokollrahmen verpackt wird.
Die Binärzahl kann natürlich auch "packed BCD" sein, weils dann leichter zu decodieren ist.
Und für die Gestaltung von Protokollrahmen gibt es schier unendlich viele Möglichkeiten.
Zahlenwerte... da es eine Anzeige einer Waage war.
Die spannende Frage ist: Wenn man eine 12 (binär) oder 12 (BCD) oder "12" (ASCII) codiert an das Display sendet, wird es dann auch "12" anzeigen?
Was ist, wenn das Display Kommandos erwartet, zum Beispiel?:
10 Anzeige ein schalten
11 Anzeige aus schalten
12 In den Standby Modus gehen
13 Heller
14 dunkler
2xxxx Eine Zahl xxxx ausgeben
9A5FC Blockade nach unerwartetem Kommando/Daten zurücksetzen
Oder noch komplexer: mit Prüfsummen, oder gar verschlüsselt.
Versuche den einfachen Fall, aber sei nicht allzu enttäuscht, wenn du per Trial&Error nicht hinter das Kommunikationsprotokoll kommst.
Die Übertragungsparameter (Baudrate, Parity etc.) herauszufinden, ist
das eine, aber das Protokoll, mit dem das Ding seine Daten bekommen
will, durch reines Raten herausfinden zu wollen, ist ... ein bisschen
wie die Geschichte mit den Schimpansen und den Shakespeare-Sonetten.
Ich hatte mal ein Gerät, was mit Timeouts arbeitete. Mit Direkteingabe war da also nichts. Im Manual wurde empfohlen, ein Kommando in einem Texteditor zu schreiben und dann per C&P ins Hyperterminal zu kopieren. Nur dann kam auch eine Antwort.
Wer Protokolle mit Timeout erfunden hat, der gehört geteert und gefedert.
vielen Dank für eure Antworten. Nach meinem Urlaub werd ich mich mal
dranstürzen und berichten.
Dann bin ich mal gespannt... denn, wenn die Leute so was schreiben, dann kommt da oft gar nix mehr von denen, nicht einmal ein leises Kukuryku aus der Brust.
vielen Dank für eure Antworten. Nach meinem Urlaub werd ich mich mal
dranstürzen und berichten.
Dann bin ich mal gespannt... denn, wenn die Leute so was schreiben, dann
kommt da oft gar nix mehr von denen, nicht einmal ein leises Kukuryku
aus der Brust.
Im Moment basiert alles nur auf einem kleinen Fotoausschnitt und aufgestellten Behauptungen einer Person, die – wie sie selbst von sich sagt – wenig Ahnung von µControllern hat, wie es abgeblich funktionieren könnte – alle sind dann auf den UART-Zug aufgesprungen und senden mit bzw. spinnen die These weiter, manche führen schon Streitgespräche darüber, was der UART angeblich kann oder nicht kann und sogar wieviele Timer der AT89C2051 hat, was angesichts der dargebotenen Informationen und Fakten nicht nur absurd, sondern in gewisser Weise auch ziemlich naiv ist – ist aber leider die gängige Praxis in diesem Forum. Vielleicht stimmt das mit der anfänglichen Annahme zu der Funktionsweise der Schaltung, von der es nicht einmal einen Fetzen vom Schaltplan gibt, vielleicht ist aber alles oder ein großer Teil davon auch ganz anders und die ganzen aus dem Finger gesogenen Eingangsüberlegungen sind einfach nur eine schöne Erzählung, von der manche so beigestert sind. Mit Reverse Engineering hat das wenig zu tun – es ist einfach nur ein Rätseln, wie es zufällig auch in der Überschrift des Themas steht, aber vielleicht mag der Autor ja auch Rätsel raten und die Leute ebenfalls, dann passt es ja auch ganz gut zusammen.
Im Moment basiert alles nur auf einem kleinen Fotoausschnitt und
aufgestellten Behauptungen einer Person, die – wie sie selbst von sich
sagt – wenig Ahnung von µControllern hat, wie es abgeblich funktionieren
könnte – alle sind dann auf den UART-Zug aufgesprungen ...
Wenn ich dich richtig verstehe, bezweifelst du diese Aussage:
Am Pin 2, was der RX Anschluss ist, wird er noch über einen Transistor
mit Daten versorgt.
Sie erscheint mir aber sehr plausibel, auch wenn auf dem Foto nicht alle
Details erkennbar sind. Für mich sieht es jedenfalls so aus, dass ein
über die rote Schraubklemme kommendes RS-232-Signal mit dem Transistor
und zwei Widerständen von +(3..15)V und -(3..15)V auf UART-kompatible 0V
und 5V umgesetzt (also invertiert und im Pegel begrenzt) wird. Ob das
dann tatsächlich an Pin 2 des Mikrocontrollers geht, kann man auf dem
Bild nicht erkennen. Da Ronny die Platine vor sich liegen hat und die
Leiterbahn verfolgen kann, wird das aber schon stimmen.
Jetzt ist eben die Frage, ob man an weitere Informationen herankommt,
bspw. die Firmware des AT89C2051 (s. Beitrag von Dieter) oder eine
Aufzeichnung der RS-232-Daten (s. mein letzter Beitrag). Stellt sich
beides als unmöglich heraus, bleibt nur zu hoffen, dass es sich um ein
ganz primitives Protokoll handelt, das durch geduldiges Ausprobieren
ermittelt werden kann. Oder man ersetzt die Firmware (ggf. zusammen mit
dem µC) durch eine Eigenentwicklung, was ebenfalls schon vorgeschlagen
wurde.
Ich habe ein Anzeigeplatine mit 4 großen 7 segment Anzeigen drauf,
welche mit einem 32 bit Schieberegister(UCN5833) verbunden sind. Dieser
wird von dem AT89C2051 "gefüttert.
Die Anzeige hängt an einem Schieberegister, welches mit UART wohl nichts am Hut haben dürfte!
Am Pin 2, was der RX Anschluss ist, wird er noch über einen Transistor
mit Daten versorgt.
Welcher Pin 2 ist hier gemeint? Der des Controllers oder der des Schieberegisters.
UCN5833 ist ein ganz normales Schieberegister (mit eben 32-Bit) mit Standardanschlüssen: clock, data, strobe, output enable.
Einzig und allein eine serielle Datenleitung (an den TO, weil die anderen das garantiert wissen: seriell gibt es auch "außerhalb" von UART) reicht garantiert nicht, das Schieberegister zu bedienen.
Serieller Eingang mit RS232-Pegeln könnte schon sein, wenn es der rote Schraubklemmanschluß ist. Der Transistor als Inverter und Pegelwandler, die Diode kappt den negativen Pegel an der Basis, ein Widerstand vom Kollektor gegen +5V (dünne Leiterbahn, geht unterm IC zu Pin 20). Aber, der Kollektor geht auf Pin 9 des AT89C2051 und nicht auf den RX-Pin 2? Wäre merkwürdig, auf dem Foto ist keine Leiterbahn an Pin 2 zu erkennen. Oder sehe ich das falsch?
Wenn ich dich richtig verstehe, bezweifelst du diese Aussage:
Im Moment muss man alles in Zweifel ziehen, was der Autor und später andere sich selbst zusammengedichtet haben – ohne gute, komplette Fotos von beiden Seiten und ohne abgezeichneten Schaltplan und ggfs. zusätzliche Messungen ist das leider so, auch wenn Teile der Aussage einem durchaus plausibel erscheinen mögen. Er hat sich nicht einmal die Mühe gemacht, zu nennen, was das für ein Transistor ist – hier kann man nur vermuten, dass es z.B. ein NPN ist, vielleicht ein BC548, aber genau Vermutungen sind hier fehl am Platz. Ich darf in diesem Moment auch bezweifeln, dass es die vermeintliche UART-Kommunikation gibt und dass diese genau für die LED-Anzeigen bestimmt ist, und zwar so wie er oder alle sich das hier denken, weil sie sich von dem Gedanken haben blenden und leiten lassen, auch wenn alles bis dato in der Phantasie ersponnene sich am Ende vielleicht doch als richtig erweisen könnte. Also erstmal Fotos machen und Schaltplan (zumindest das Wichtgiste) abzeichnen, denn ohne diese grundlegenden Informationen sind das alles nur Spekulationen und Rätsel raten – das kann man auch von Hand mit Bleistift auf Papier zeichnen und Fotos machen ist heutzutage mit jedem Smartfon machbar. Und wenn das ein Gerät ist oder war, dann auch den Hersteller, die Modellnummer etc. versuchen zu ermitteln, denn damit kann man unter Umständen noch weitere Informationen im Netz finden.
Sorry, ich hatte Yalus Beitrag übersehen, in dem er schon auf die Pegelwandlung und Pin 2 hingewiesen hatte.
Wenn es tatsächlich, wie ich vermute, auf Pin 9 geht, wird es wohl kein UART-Signal sein.
Die Leitung verläuft zwischen Pin 8 und 9. Es ist anzunehmen, dass sie
unterhalb des ICs zu Pin 2 weitergeführt ist.
Gute Augen! Parallaxenfehler, sieht man auch bei den XTAL-Anschlüssen Pin 4 und 5.
Dann würde ich es doch einfach mal mit "1234\n" senden versuchen, über eine echte Serielle-COM mit RS232.
Die Anzeige hängt an einem Schieberegister, welches mit UART wohl nichts
am Hut haben dürfte!
Das Schieberegister hängt an einem Mikrocontroller. Das ist ein kleiner Computer, der die über RS-232 empfangenen Daten in Steuersignale für das Schieberegister umwandelt.
Welcher Pin 2 ist hier gemeint? Der des Controllers oder der des
Schieberegisters.
Pin 2 ist der RxD-Eingang des AT89C2051 Mikrocontrollers. Davor sitzt ein Transistor, der den RS-232-Pegel in TTL wandelt.
UCN5833 ist ein ganz normales Schieberegister (mit eben 32-Bit) mit
Standardanschlüssen: clock, data, strobe, output enable.
Und die werden von den GPIOs des Mikrocontrollers bedient.
Dann würde ich es doch einfach mal mit "1234\n" senden versuchen, über
eine echte Serielle-COM mit RS232.
Es gibt noch Dezimalpunkte, die so nicht angesteuert werden könnten, falls das wirklich eine Waage war und sie beim Anzeigen gebraucht werden. Das ganze Protokoll kann theoretisch nur 1-bytelang sein – damit hätte man das Problem der Synchronisation (das größte hier) damals so lösen können und auch wenn einer das nicht glauben mag, man kann damit alle 32 Segmente der Anzeige einzeln beliebig ein- und ausschalten und hätte in dem 1-Byte-Protokoll nebenbei noch Platz für sehr viele zusätzliche Befehle, wie dunkler, heller, EIN/AUS etc. Da die µC sehr wenig Speicherplatz haben, ist das Programm vermutlich in Assembler geschrieben und man muss auch beim SRAM auf den Verbrauch achten (musste ich damals auch, ich habe aber den AT89C4051 genommen und für größere Projekte den AT89C52), was mit so einer Kompaktheit des Protokolls im Einklang wäre, falls das wirklich der UART-Eingang für die Übertragung der Displaydaten ist, denn es kann genauso einfach etwas von einem Spezialsensor an dieser Stelle zum µC ankommen.
1-bytelang sein – damit hätte man das Problem der Synchronisation (das
größte hier) damals so lösen können und auch wenn einer das nicht
glauben mag, man kann damit alle 32 Segmente der Anzeige einzeln
beliebig ein- und ausschalten
Man muss es nicht auf 256 Befehle zerbröseln, da wir hier keine zwölf Digits, sondern nur „vier” haben – die 4 im Anführungszeichen, denn selbst die 4 Ziffern können einen Unerfahrenen mächtig ins Schwitzen bringen oder in die Verzweiflung treiben, aber theoretisch würde es sogar mit 15 Ziffern gehen (d.h. 120 Segmenten) – das Protokoll selbst wäre immer noch ein Byte lang und damit immer eindeutig, den gesamten Bildaufbau müsste man dann mit sehr vielen Befehlen vollführen, für alle Segmente bei 4 Digits wären mindestens 32 nötig, bei 15 Digits entsprechend mindestens 120. Bei 4 Ziffern kann man sich das Leben aber etwas leichter machen, indem man das Übertragungsbyte für sich im Kopf auf Nibbles aufteilt, z.B. als AAAADDDD – wobei A die Adresse bedeutet und D das Daten-Nibble und somit immer vier Bits auf einmal übertragen werden könnten, was deutlich angenehmer wegen der Anzahl der Sendebytes und damit verbundenen Verzögerung des Bildaufbaus ist (bei einer relativ niedrigen Baudrate kann sich das dann bemerkbar machen). Die ersten acht Adressen (0-7) wären beispielsweise für die LED-Segmente reserviert (8*4 Bits=32 Bits), die restlichen acht Adressen (8-15) würden noch Platz für diverse Befehle bieten, insgesamt hätte man noch 128 Kombinationen frei zur Verfügung. Den Befehl für die Helligkeitseinstellung könnte man z.B. gleich nach den Displaydaten bei Adresse 8 machen und dessen 4 Datenbits dann für den Wert der Helligkeit verwenden (0-15, also 16 Stufen); das µC-System müsste die Helligkeitsregelung natürlich auch irgendwie unterstützen, notfalls auch als eine in software geschriebene PWM-Regelung umsetzen – bei einer Waage bräuchte man solche zusätzlichen „Spielereien” eigentlich nicht, Display EIN/AUS als Befehle reichen vollkommen aus. Das Protokoll selbst bleibt weiterhin nur 1-Byte-lang und eindeutig, der Bildaufbau hier benötigt dann nur noch mindestens 8 Byte-Übertragungen (8x4=32Bits). Die Synchronisation ist immer gewährleistet, was im Gegensatz dazu bei längeren ASCII-Übertragungen (die heutzutage so beliebte Textkommunikation) einem immer entgleiten kann und wenn man keine Sicherheitsmechanismen und explizite Synchronisationszeichen einbaut, wird es irgendwann mal auf jeden Fall schieflaufen, aus dem Takt geraten. Man könnte sich noch andere Aufteilungsformen wie AAAAAADD oder umgedreht als DDDDAAAA ausdenken, falls nötig – diese vorgestellte Aufteilung auf zwei Nibbles sollte nur als Beispiel fungieren. Die Verwendung eines Displays mit acht Ziffern wäre damit auch noch gut realisierbar.
Übertragungsfehler kann es selbstverständlich auch bei einem 1-Byte-Protokoll geben – wenn man Pech hat, geht z.B. das Display aus, weil das falsch Empfangene genau dieser Bytebefehl war. Solche Fehler kann man aber hardware- und softwaretechnisch reduzieren, indem man z.B. solche Befehle während der Übertragung der LED-Daten (wenn diese immer gleich abläuft) herausfiltert und gar nicht zur Ausführung freigibt, sondern sie ignoriert – ein Restrisiko bleibt trotzdem, denn irgendwann mal – z.B. nach den Bilddaten – will man auch irgendwelche Steuerbefehle übertragen, mit doppelter oder gar dreifacher Übertragung hintereinander könnte man das Risiko aber noch weiter absenken. Bei dreifacher Übertragung wären mindestens zwei gleiche Bytes das Entscheidungskriterium, um den Befehl auszuführen – das hat aber auch seine Schattenseiten, insofern wird man das Restrisiko so nicht los, bei einer Waage, die vom Drucksensor mit Daten gefüttert wird, kann man es codemäßig aber anders lösen. Für die Assemblerprogrammierung ist diese Kodierungsart deutlich einfacher zu programmieren als Strings zu empfangen, sie in Echtzeit zu untersuchen und umzuwandeln und wird vermutlich auch weniger Flash und vor allem RAM verbrauchen, was bei diesen µControllern ein großes Problem darstellt, denn in den 128 Bytes sind die Registerfiles integriert, es gibt ein Bitfeld und den Stapel muss man dort auch noch irgendwo so klug platzieren, dass man bei größerer Tiefe nicht auf die relevanten Dateninhalte fährt und diese versehentlich 'zerstört'. Der µC hat auch den SWAP-Befehl ($C4), um Nibbles zu tauschen, was einem Programmierer, der das in Assembler schreibt, viele Schiebeoperationen erspart und der Zugang zu den ankommenden Bytehälften somit deutlich schneller bewerkstelligt werden kann – was bei einem Nicht-RISC µController durchaus wichtig sein kann, denn selbst wenn er mit 12MHz laufen sollte, wäre er im Vergleich zum 8-Bit-AVR, der auch mit 12MHz getaktet würde, eine lahme Ente. Beschleunigte C51-Derivate mit mehr Speicher gibt es für C51-Liebhaber, Mentalgefangene oder die Retroszene natürlich auch noch, aber im Normalfall ist das eine CISC-Architektur wie man sie von dem Urgestein 8751 mit Quarzfenster kennt – heutzutage würde man sie als altbacken bezeichnen, die hier vorgestellte Art der Kommunikation (ohne die Möglichkeit einer Rückmeldung zu haben) und kurz erwähnten Schutzmechanismen kann man heutzutage aber genauso gut verwenden. Mit einer Full-Duplex-Kommunikation (als Handshake) kann man naturgemäß eine deutlich komplexere Kommunikation ohne ASCII-Texte realisieren, incl. Autosynchronisation im Falle einer mutwilligen Kabelunterbrechung und Wiedereinstecken etc.
Nun ja, was soll er damit schon anfangen können, wenn er sich mit
µControllern wenig auskennt.
Ich habe damals vor vielen, vielen Jahren sowohl meinen C51-Programmer als auch die PC-Software in VB6 für WinXP selbst gebaut und geschrieben – alte Fotos im Anhang. Der Kern des Programmers war dann auch ein C51 als 40-Pinner, die Software natürlich von mir in Assembler geschrieben und die Kommunikation lief über den COM-Port, die USB-Buchse war nur für die Spannungsversorgung zuständig und die 12V wurden mit einem kleinen Solidwandler aus diesen 5V erzeugt. Funktionierte alles bestens, das Ding liegt bei mir zu Hause noch als Erinnerungsstück. Ich könnte das alles heute mit ganz anderen Möglichkeiten bauen und neugestalten (für Windows 10 und 11), nur fehlt mir die Zeit dazu, weil andere Projekte Vorrang haben, aber wer weiß schon, was in Zukunft noch passiert.
