Hallo, ich habe beim Aufräumen eine von mir vor vielen Jahren entwickelte Platine mit einem 80C32 und einem UART TL16C550C gefunden. Sie war dazu gedacht, Meßwerte mit 115200 Baud interruptgetrieben an einen Linux-PC zu senden. Damit keine Zeichen verloren gehen, hatte ich sogar einen RTS/CTS-Hardware-Handshake implementiert. Leider kann ich den Code für den 80C32 beim besten Willen nicht mehr finden. Gibt es jemanden, der noch alten Code rumfliegen hat, mit dem er mir helfen könnte? Vielen Dank im Vorraus! Michael
Die 16550 ist seit Äonen die Standard-UART im PC, daher dürfte so gut wie jedes DOS-Programm, das serielle Schnittstellen ansteuert, Dir als Grundlage dienen können. Die Kombination MCS-51 und 16550 ist hingegen eher ... ungewöhnlich, daher vermute ich, daß es kaum fertigen Code für ausgerechnet diese Kombination geben dürfte. Allein das Businterface der 16550 ist für einen MCS-51 schon recht aufwendig, es sei denn, man spricht das Ding mit "memory-mapped I/O" an.
Er ist ab $7F00 eingebunden und aktiviert /INT0. Ich würde mich trotzdem freuen, wenn mir jemand helfen könnte.
Naja, wo ist jetzt Dein Problem? Deinen Code hat natürlich niemand hier, und --wie ich bereits schrieb-- die Kombination ist so selten, daß kaum jemand fertigen Code dafür haben wird. Der Hinweis auf die PC-Vergangenheit war Dir nicht genug? Erinnerungsvermögen hast Du auch keins mehr? Du hast das Ding doch selbst entwickelt ... http://public.beuth-hochschule.de/~rozek/pdf/VorlesungTeil8_EMC.pdf Hier die DOS/BIOS-Teile überspringen, der "direkte Zugriff" (ab Seite 23) ist für Dich von Relevanz. Und hier noch etwas mehr Erklärung über die Register: http://www.lammertbies.nl/comm/info/serial-uart.html
Gast
#4493838
Rufus Τ. F. schrieb: Allein das Businterface der 16550 ist für > einen MCS-51 schon recht aufwendig, es sei denn, man spricht das Ding > mit "memory-mapped I/O" an. Schaut für mich wie eine Standardanbindung an die 8051-Serie an. In alter Zeit, als die Daten noch im externen ROM waren. Der Rest ist Lese- und Schreibzugriffe im Adressraum.
Der 80C32 braucht externes ROM, das könnte man auslesen und disassemblieren.
Das 16550 UART war das beste UART ever, denn eh hatte 16byte Buffer, der Rx interupt konfigurierbar nach 1, 4, 8, 16 bytes. Ein Treiber dazu sollte sehr einfach zu schreiben sein.
Wozu umständlich nen 16550 ranpappen, der 8051 hat doch selber eine UART.
Gast
#4494069
Peter D. schrieb: > Wozu umständlich nen 16550 ranpappen, der 8051 hat doch selber eine > UART. 115000 bit/s Fehlanpassung des Prozessorquarzes bei hohen Übertragungsraten. Eine Schnittstelle zu wenig. Irgendetwas in der Art.
Gast
#4494101
Michael K. schrieb: > Leider kann ich den Code für den 80C32 beim besten Willen nicht mehr > finden. Wozu, der steht im angeschlossenen EProm. Michael K. schrieb: > Gibt es jemanden, der noch alten Code rumfliegen hat, mit dem er > mir helfen könnte? Wobei helfen? Georg
@noreply Mit einem 11.092 MHz-Quarz erreicht man bei einem 80C32 57600 Baud. Dann laufen aber auch die Timer / Counter mit einem zwölftel der Quarzfrequenz. Wenn man Zeitintervalle mit einem Vielfachen von einer Mikrosekunde exakt generieren / messen muß, kommt man bei Baudraten über 1200 Bd um die Verwendung eines extenen UARTs nicht umhin. Nachdem der ursprünglich verwendete 82C51 nicht mehr lieferbar war, bin ich seinerzeit notgedrungen zuerst auf einen 82C50, dann auf einen 16C450 und schließlich auf einen 16C550 umgestiegen. Später habe ich dann noch einen 82C250 CAN-Controller mit einggebunden, den ich aber irgendwann schließlich auch durch einen SJA1000 ersetzen mußte. @Georg Das Ganze geriet schließlich irgendawann einmal in Vergessenheit. Wie bereits gesagt habe ich beim Aufräumen schließlich wieder ein altes Muster dieser Baureihe gefunden - leider ohne EPROM. Ich habe keine Ahnung, wann und wo ich die zugehörigen Dateien verschlampt habe. Ich hatte mir gedacht, ich frage mal, ob jemand noch alte Sourcen rumfliegen hat, mit dem man das Ganze vielleicht wiederbeleben könnte. (Eine Neuentwicklung der aufwendigen Firmware scheint mir hinsichtlich der veralteten Microcontroller-Architektur nicht sinnvoll.)
Gast
#4499639
Michael K. schrieb: > Eine > Neuentwicklung der aufwendigen Firmware scheint mir hinsichtlich der > veralteten Microcontroller-Architektur nicht sinnvoll Glaub mir, das ist noch die billigere Variante. Es sei denn, du findest einen Hobby-IT-Archäologen, der das Reengeneering aus reiner Begeisterung macht. Hast du überhaupt einen definitiven Schaltplan? Georg
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.