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. Ich hoffe ihr habt da eine Idee. Mit freundlichen Grüßen
Ronny schrieb: > 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.
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?
H. H. schrieb: > Mit dem UART des 2051 kannst du das Schieberegister nicht füttern. Natürlich geht das, siehe UART Mode 0.
Ronny schrieb: > Ich hoffe ihr habt da eine Idee. 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.
Peter D. schrieb: > H. H. schrieb: >> Mit dem UART des 2051 kannst du das Schieberegister nicht füttern. > > Natürlich geht das, siehe UART Mode 0. Und woher kommt der Takt für das Schieberegister?
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.
Angehängte Dateien:
-
20241005_043740.jpg
210 KB
H. H. schrieb: > 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. Monk schrieb: > 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. Ok, wäre schade.
Beitrag #7748254 wurde vom Autor gelöscht.
Monk schrieb: > 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.
Ersetz den einfach durch einen Attiny2313 und schreib deinen eigenen Code. Dort kannst du dann die Daten in deinem Wunschformat entgegen nehmen...
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. Edit: Max war schneller.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
Max D. schrieb: > Ersetz den einfach durch einen Attiny2313 Auf die Polarität des Resetsignals achten!
Ronny schrieb: > ich habe wenig Ahnung von mikrocontrollern[,] aber bin willens, > vorhandene Wissenslücken zu füllen. Wenn Du wenig Ahnung von µControllern hast, dann ist das, was Du Dir hier vorgenommen hast, genau der falsche Weg (dafür).
:
Bearbeitet durch User
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?
Ronny schrieb: > Variiert das so sehr, was als Zahlen > gesendet werden kann? Die Frequenz des Quarzes kann dir zumindest vermitteln, ob du es da mit Standardbaudraten zu tun hast.
H. H. schrieb: > Ronny schrieb: >> 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.
Ronny schrieb: > Ich könnte ja versuchen, vom PC mit nem teminalprogramm mit > verschiedenen baudraten mal zu senden nur WAS willst du senden?
Ronny schrieb: > 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. Ronny schrieb: > Einen ATiny2313 müsste ich mir erst besorgen und dann könnt ichs > mal versuchen selbst zu programmieren... so gleich als Übung. Du kannst auch einen anderen nehmen, musst dann halt eine Adapterplatine anfertigen.
Matthias S. schrieb: > Ronny schrieb: >> Variiert das so sehr, was als Zahlen >> gesendet werden kann? > > Die Frequenz des Quarzes kann dir zumindest vermitteln, ob du es da mit > Standardbaudraten zu tun hast. Da ist nen 12 MHz Quarz verbaut.
Ronny schrieb: > Da ist nen 12 MHz Quarz verbaut. Damit sind alle üblichen Baudraten von 300 bis 38400 bps möglich.
Monk schrieb: > nur WAS willst du senden? Zahlenwerte... da es eine Anzeige einer Waage war. Yalu X. schrieb: > 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? H. H. schrieb: > Ronny schrieb: >> Da ist nen 12 MHz Quarz verbaut. > > Damit sind alle üblichen Baudraten von 300 bis 38400 bps möglich. Das ist schonmal eine ordentliche Spanne. Es scheint wohl wirklich schwer, mit der gegebenen Hardwarekonstelation was auf die Anzeige zu gekommen.
H. H. schrieb: > Damit sind alle üblichen Baudraten von 300 bis 38400 bps möglich. Bei 12MHz sind nur max 2400 Bd erreichbar, mehr geht nur mit einem Baudratenquarz (11.059MHz). Der 89C2051 hat keinem Timer2.
Thomas Z. schrieb: > Der 89C2051 hat keinem Timer2. In der Tat. Ich hatte dem kleinen mehr zugetraut.
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.
Ronny schrieb: >> nur WAS willst du senden? > 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.
Hallo an alle, vielen Dank für eure Antworten. Nach meinem Urlaub werd ich mich mal dranstürzen und berichten. Habt ein schönes Rest Wochenende. Mit freundlichen Grüßen
Harald K. schrieb: > 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.
Ronny schrieb: > 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.
Gregor J. schrieb: > Ronny schrieb: >> 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. Dann lass dich mal überraschen:-D
Ronny schrieb: > Zahlenwerte... da es eine Anzeige einer Waage war. Gibt es den Rest der Waage nicht mehr? Sonst könnte man die Kommunikation zwischen den beiden Teilen abhören und reverse-engineeren.
Yalu X. schrieb: > (...) reverse-engineeren (...) 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.
Gregor J. schrieb: > 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: Ronny schrieb: > 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.
:
Bearbeitet durch Moderator
Der wohl wichtigste Hinweis dürfte wohl dieser sein: Ronny schrieb: > 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! Ronny schrieb: > 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. Im Anhang siehe Datenblatt. By the way: Taktübernahme bei steigender Flanke
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?
Yalu X. schrieb: > 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.
:
Bearbeitet durch User
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.
Erni schrieb: > Aber, > der Kollektor geht auf Pin 9 des AT89C2051 und nicht auf den RX-Pin 2? Die Leitung verläuft zwischen Pin 8 und 9. Es ist anzunehmen, dass sie unterhalb des ICs zu Pin 2 weitergeführt ist.
Erni schrieb: > Sorry, ich hatte Yalus Beitrag übersehen, in dem er schon auf die > Pegelwandlung und Pin 2 hingewiesen hatte. Kein Problem. Ich hatte oben vergessen, die Diode zu erwähnen, weswegen dein Beitrag den meinigen vervollständigt.
> 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.
Ralph S. schrieb: > 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.
:
Bearbeitet durch User
Ronny schrieb: > 20241005_043740.jpg > > 210 KB Gibt's vielleicht noch scharfe, hochauflösende Bilder von der gesamten Vorder- und Hinterseite? Gruss Chregu
Erni schrieb: > 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.
:
Bearbeitet durch User
Beitrag #7749403 wurde vom Autor gelöscht.
Gregor J. schrieb: > 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 Ja klar! Gruss Chregu
Christian M. schrieb: > Ja klar! 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
AT89C2051_01.jpg
180 KB -
AT89C2051_09.jpg
45 KB
Kann der TO damit etwas anfangen? Er suchte doch einen Programmer und die passende Software dazu. ciao gustav
Beitrag #7750127 wurde vom Autor gelöscht.
Angehängte Dateien:
-
1_min.JPG
600 KB -
2_min.JPG
770 KB -
3_min.JPG
740 KB -
4_min.JPG
680 KB -
C51-Programmiergeraet.png
16 KB
Karl B. schrieb:
> Kann der TO damit etwas anfangen?
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.
:
Bearbeitet durch User
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.