Forum: Mikrocontroller und Digitale Elektronik Verständnisfragen zum 8051


von Harald S. (harryhh)


Lesenswert?

Hallo zusammen,

ich steige gerade frisch in das Thema MCU ein. Bitte dennoch keine 
Antworten wie "diese Fragen stellen sich erst, wenn du mind. 200 Jahre 
Programmiererfahrung hast" o.ä. ;-)

Speziell zum 8051 sind mir ganz grundlegende Dinge unklar, die da wären:

1.) wenn ich den UART im Timermodus1 betreibe (sinnvoll, da ich eine 
Baudrate von 31250 benötige), ist Timer1 also "ausgebucht" und es bleibt 
nur mehr Timer2 übrig (z.B. für regelmässige interrupt-basierte Abfragen 
oder sonstige Einsatzzwecke)

2.) kann eine Matrixtastatur (3 Reihen, 4 Spalten, gesamt 7 belegte 
Portpins) interrupt-gesteuert abgefragt werden und zwar OHNE Verwendung 
eines Timer-Interrupts, der regelmässig den Tastaturstatus prüft? Müsste 
dafür nicht jeder Portpin eine Art "Interrupt-on-change"-Funktion (AVR 
kann das...) bereit stellen?

3.) MCUs mit integriertem ADC bieten stets einen hartkodierten 
ISR-Vektor, der bei erfolgter Wandlung angesprungen werden kann. Wie 
sieht es bei extern angeschlossenen ADCs aus? Muss hier über Polling der 
Wandlungsstatus abgefragt werden?

4.) Nach etwas Überlegen bin ich draufgekommen, dass - egal für welche 
Anwendung - doch eine "loop: rjmp loop" Mainroutine ohne 
Befehlsverarbeitung (ausser MCU-Setup) und eine komplette 
Programmgestaltung nur über diverse Interruptroutinen ein optimaler 
Pseudorealtime-Ansatz wäre. Ist dem so?

Danke im Voraus für eure Antworten!

von Falk B. (falk)


Lesenswert?

@  Harald Schiner (harryhh)

>2.) kann eine Matrixtastatur (3 Reihen, 4 Spalten, gesamt 7 belegte
>Portpins) interrupt-gesteuert abgefragt werden und zwar OHNE Verwendung
>eines Timer-Interrupts, der regelmässig den Tastaturstatus prüft?

Warum? Das kann man in den Timer problemlos eintegrieren. Man braucht 
NICHT für jede Aufgabe einen eigenen Timer.

>dafür nicht jeder Portpin eine Art "Interrupt-on-change"-Funktion (AVR
>kann das...) bereit stellen?

Jain. Das kann man aber auch über ein paar Dioden zusammenfassen und an 
EINEN Interrupteingang legen.

>sieht es bei extern angeschlossenen ADCs aus? Muss hier über Polling der
>Wandlungsstatus abgefragt werden?

Machen einige so. Andere haben eine Interruptleitung zum uC.

>Programmgestaltung nur über diverse Interruptroutinen ein optimaler
>Pseudorealtime-Ansatz wäre. Ist dem so?

Nööö. Das kann in einigen Fällen sinnvoll sein, muss aber nicht.
Mach lieber ein gescheites präämtives Multitasking, das ist besser 
und einfacher zu überblicken.
Ach ja, und nimm keinen 8051. AVR & Co sind deutlich moderner und 
besser. Flamewar on! ;-)

MFG
Falk

von Harald S. (harryhh)


Lesenswert?

Danke für die aufschlussreichen Antworten!

Bezüglich ADC-Interrupt:

Du schreibst: "Machen einige so. Andere haben eine Interruptleitung zum 
uC."

Das heisst, es gibt ADC-Modelle auf dem Markt, die einen expliziten Pin 
zur Interruptgenerierung des MUC bereit stellen? Im Prinzip müsste das 
dann ein ADC sein, der nach erfolgter Wandlung automatisch einen 
bestimmten Pin auf High setzt, der dazu genutzt wird,  den externen 
Interrupt des MCU zu triggern. Richtig so?

Zitat:
"Ach ja, und nimm keinen 8051. AVR & Co sind deutlich moderner und
besser. Flamewar on! ;-)  "

Um ehrlich zu sein, ich gehe sehr merkwürdig an das Thema ran. Auch wenn 
es sich pathologisch anhört, aber wenn mir das jeweilige Datenblatt 
nicht zusagt (schlecht geschrieben, unübersichtlich gegliedert, 
unfreundliches Seitenlayout etc.) , entwickle ich eine innerliche 
Aversion (ist mir beim PIC so passiert). Ich habe schon immer so 
"getickt", wenn mir die begleitende Dokumentation nicht zusagt, werte 
ich auch das zugehörige Produkt subjektiv automatisch ab.
So, und jetzt könnt ihr die Psychiatrie in Hamburg-Eppendorf anrufen ;-)

von Falk B. (falk)


Lesenswert?

@  Harald Schiner (harryhh)

>Interrupt des MCU zu triggern. Richtig so?

Ja.

>So, und jetzt könnt ihr die Psychiatrie in Hamburg-Eppendorf anrufen ;-)

Dr. Prügelpeitsch, ein Patient wartet.

Axch ja, ich hab vorhin was verwechselt. Ich meinte, du solltest ein 
kooperatives Multitasking anpeilen, das ist relativ einfach. Siehe 
auch den Artikel, dort ist ein Beispiel drin.

MfG
Falk

von Helmut L. (helmi1)


Lesenswert?

>Das heisst, es gibt ADC-Modelle auf dem Markt, die einen expliziten Pin
>zur Interruptgenerierung des MUC bereit stellen? Im Prinzip müsste das
>dann ein ADC sein, der nach erfolgter Wandlung automatisch einen
>bestimmten Pin auf High setzt, der dazu genutzt wird,  den externen
>Interrupt des MCU zu triggern.

Ich kenne keinen der das nicht so macht. Allerdings heissen die nicht in 
allen Faellen direkt "INT" . Andere gaengige Namen fuer diesen Pin sind 
z.B. "BUSY" , "READY" , "CONVERSION COMPLETE" etc.

Schau dir mal ein paar Datenblaetter von ADCs an und dort das Timing des 
ADC.

Gruss Helmi

von Miraculix (Gast)


Lesenswert?

@  Harald Schiner (harryhh)

Wenn es schon ein µP der 8051-Reihe sein soll,
schau Dir mal die ADuC-Baureihe von Analog-Devcies
(ADuC 812, ADuC 832 u.A. an, Datenblätter bei
http://www.analog.com zu finden.) Die haben noch
weitere Timer auch für den UART nutzbar,
genügend DATA RAM, Flash, EEPROM etc. an Bord,
ebenso einen brauchbaren DAC und ADC, PWM....

Auch die Datenblätter sind meiner Meinung nach vernünftig
gestaltet.

Weiterer Vorteil: Das Data-Ram kann auch z. T. dem
Stack zugeschlagen werden. Ist recht brauchbar, wenn
Du mit vielen Interrupts arbeiten möchtest.

Ich verwende sowohl AVRs als auch die 8051-er, den ADuC,
das hängt ganz von der Anwendung ab.

Verstehen und teilen kann ich jedoch Deine Abneigung gegen
PICs.........

MfG

Miraculix

von Pieter (Gast)


Lesenswert?

moin moin,

zu 2: 2.) kann eine Matrixtastatur

Der AT8951ED2 hat ein KBF-Keyboard Flag Register (9Eh), das ist für 
soetwas vorgesehen.
Gebraucht habe ich das allerdings noch nicht. Bei Bedarf habe ich die 
Matrix in der MainLoop gepollt.
Den "richtigen" 8051ziger zu finden ist bei über 100 (oder schon 
1000???)verschiedenen Typen ein echtes Problem. Derzeit mache ich etwas 
mit den Silabs F340 und F365 und da ist einiges anders als beim 8951ED2. 
Besonders der F365 mit 100MIPS.

Mit Gruß
Pieter

von Harald S. (harryhh)


Lesenswert?

Für den Hobbybereich bevorzuge ich DIP-Gehäuse, da bleibt - trotz 
tausender Derivate - eigentlich nur mehr die Atmel 89C oder 89S - Serie 
übrig.

Die Entscheidung für einen 8051 habe ich nach Studium der jeweiligen 
Blockschaltbilder (interne Systemarchitektur) aus den Datenblättern 
getroffen.

Ich finde beim 8051 die simple Vorgehensweise bei der Adressierung recht 
gelungen. Vom internen RAM in den Akku ist z.B. "mov A, 47h", vom 
allgemeinen Register R0-R7 ist es dann z.B. "mov A, R5". Der Befehl 
"mov" ist aber stets der gleiche, nur der Operand ändert sich.

Schaue ich mir die AVRs an, muss ich beim Adressieren des SRAMs mit STS, 
LDS etc. herumhantieren, beim Adressieren eines GPR von R16-R32 kann ich 
LDI verwenden, bei R0-R15 aber muss ich den Umweg über MOV gehen. Da ist 
m.E. keine klare Struktur drin.

Da ich aber totaler Anfänger bin, lasse ich mich gerne eines Besseren 
belehren...

Gruss,
Harald

von Matthias (Gast)


Lesenswert?

>Den "richtigen" 8051ziger zu finden ist bei über 100 (oder schon
>1000???)verschiedenen Typen ein echtes Problem.

Ein guter Überblick: http://www.keil.com/c51/chips.asp

von Falk B. (falk)


Lesenswert?

@Harald Schiner (harryhh)

>Ich finde beim 8051 die simple Vorgehensweise bei der Adressierung recht
>gelungen. Vom internen RAM in den Akku ist z.B. "mov A, 47h", vom

Die Architektur ist uralt und staubig. Der roginale 8051 braucht 12! 
Oszillatortakte für einen Maschinenbefehl. Wahnsinnig langsam. Jaja, es 
gibt neuere Clone die das in 4 oder weniger schaffen. Trotzdem.

>allgemeinen Register R0-R7 ist es dann z.B. "mov A, R5". Der Befehl
>"mov" ist aber stets der gleiche, nur der Operand ändert sich.

>Schaue ich mir die AVRs an, muss ich beim Adressieren des SRAMs mit STS,
>LDS etc. herumhantieren, beim Adressieren eines GPR von R16-R32 kann ich
>LDI verwenden, bei R0-R15 aber muss ich den Umweg über MOV gehen. Da ist
>m.E. keine klare Struktur drin.

Alles Gewohnheitsfrage. Und in C ist es sowieso egal ;-)
Und durch die vielen Register kann man Berechungen teilweise deutlich 
schneller und eleganter machen als mit dem 8051 mit seinem Akku.

MfG
Falk

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Harald Schiner schrieb:

> Zitat:
>> "Ach ja, und nimm keinen 8051. AVR & Co sind deutlich moderner und
>> besser. Flamewar on! ;-)  "
>
> Um ehrlich zu sein, ich gehe sehr merkwürdig an das Thema ran. Auch wenn
> es sich pathologisch anhört, aber wenn mir das jeweilige Datenblatt
> nicht zusagt (schlecht geschrieben, unübersichtlich gegliedert,
> unfreundliches Seitenlayout etc.) , entwickle ich eine innerliche
> Aversion (ist mir beim PIC so passiert). Ich habe schon immer so
> "getickt", wenn mir die begleitende Dokumentation nicht zusagt, werte
> ich auch das zugehörige Produkt subjektiv automatisch ab.
> So, und jetzt könnt ihr die Psychiatrie in Hamburg-Eppendorf anrufen ;-)

ähem räusper Du bist wirklich der Meinung, die Datenblätter zu AVR 
seien schleicht? nö, oder?

Da steht doch wiklich alles drin, sogar deutlich mehr als es muss. Z.B. 
ist bei I²C das komplette Busprotokoll und Arbitration-Schema erklärt! 
Voll der Luxus.

Die Dokumente sind sauber gegliedert, und hyper-Verlinkt, auch das 
Inhaltsverzeichnis.

Jedes SFR-BIt ist ausführlichst erklärt nebstt Seiteneffekten oder 
Querverbindungen zu anderen Modulen.

Und die ausführliche Erklärung jeder Function Unit ist 
selbstverständlich. (Was durchaus nicht bei jedem Hersteller so ist.)

Was willst du eigentlich noch mehr?

Naja, man könnte mäkeln, daß eine serifenlose Schrift für Fließtext 
nicht dem typographischen Nonplusultra entspricht, aber ok...

Johann

von Eddy C. (chrisi)


Lesenswert?

Jo, die Datenblätter vom AVR sind schon ok, nur das Setzen der Fuses 
artet immer in einen Blätterwahnsinn aus. Kein Wunder, dass deswegen 
hier oft nachgefragt wird.

von (prx) A. K. (prx)


Lesenswert?

Die AVR Fuses sind einfach und übersichtlich im Vergleich zu manch 
anderen Takterzeugungen, Zum Problem werden sie vor allem, weil es Fuses 
sind und keine vom Programm gesteuerten Register, so dass man leicht 
ohne Takt dastehen kann.

Manch andere Architekturen kommen grundsätzlich mit internem Takt hoch 
und setzen den gwünschten Takt dann per Software. Aussperren kann man 
sich so nicht. Muss sich aber sehr wohl durch etliche Seiten Doku mit 
etlichen teils verschiedenen Takten pro I/O-Modul, Prozessor, ... 
kämpfen.

Über den Daumen gepeilt kann man sagen: Je neuer die Implementierung 
eine Controllerfamilie ist, desto umfangreicher sind die Möglichkeiten 
zur Taktung, desto schwerer is es zu überschauen.

Das gleiche gilt auch für I/O-Ports. Die Steuerung der I/O-Ports des 
ursprünglichen 8051 war schon etwas urtümlich als der noch frisch war. 
Dafür aber leicht zu verstehen. Insbesondere bei aktuellen 32bit 
Controllern, aber auch den 8bit AvrX, sieht es sehr viel komplizierter 
aus. Will man aktuell bleiben muss man damit zurecht kommen können.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Eddy Current schrieb:
> Jo, die Datenblätter vom AVR sind schon ok, nur das Setzen der Fuses
> artet immer in einen Blätterwahnsinn aus. Kein Wunder, dass deswegen
> hier oft nachgefragt wird.

Das liegt nicht an miesen Datenblättern, sondern weil die Leute zu faul 
sind, sie zu lesen.

Wenn man eine Technik einsetzt, muss man sich eben auch mit ihrer 
Komplexität vertraut machen. Ein Auto lernt man ja auch nicht fahren, 
indem man auf nem Tretroller übt.

Johann

von Eddy C. (chrisi)


Lesenswert?

Johann, Du weichst vom Thema ab ;-)

Hier geht es gerade um die Leute, die bereit sind, ein Datenblatt zu 
benutzen. Wenn man sich mal für eine Prozessorfamilie entschieden hat, 
muss man ja nicht gleich in Selbstzufiedenheit verfallen. Keine 
Prozessorfamilie ist 100% ohne Kritik.

Ich selber programmiere beispielsweise des öfteren 8051 mit SDCC und bin 
regelmäßig begeistert, wie easy ich hier mit Globalzeigern umgehen kann, 
die in unterschiedliche Addressräume zeigen (code, data, xdata). Sowas 
fände ich für AVR auch praktisch/sinnvoll, aber leider läuft die 
Unterstützung des SDCC für AVR aus. Ob das für GCC angedacht ist, weiss 
ich nicht. Andere Prozessorfamilien (z.B. MSP430) können über so eine 
Diskussion nur müde gähnen.

von Harald S. (harryhh)


Lesenswert?

Danke für die Antworten und die rege Diskussion.

Das AVR-Datenblatt habe ich übrigens nicht schlecht geredet, allerdings 
jenes des PIC.

Sobald es um komplexere Dinge geht, bin ich ganz klar der 
Blockschaltbild-Typ. Ein kurzer Blick darauf und es ist jedem klar, wie 
das jeweilige Teil grob funktioniert. Und nur diesbezüglich war mein 
erster Eindruck, dass der AVR erstmal komplizierter anmutet als ein 
8051er. (ob das in der Praxis tatsächlich so ist, weiss ich nicht 
mangels AVR-Programmiererfahrung)

Mal sehen, vielleicht gehe ich heute abend mal fremd und installiere 
testweise das AVR-Studio. Meine Frau ist da tolerant ;-)

von (prx) A. K. (prx)


Lesenswert?

Eddy Current schrieb:

> wie easy ich hier mit Globalzeigern umgehen kann,
> die in unterschiedliche Addressräume zeigen (code, data, xdata). Sowas
> fände ich für AVR auch praktisch/sinnvoll

Suche dir einen anderen Compiler und schon geht es. Leider ist dann 
deine Kasse etwas leerer.

GCC hat mit verschiedenen Adressräumen bekanntermassen Probleme und ist 
sowieso nicht für 8bit Controller gebaut worden.

Ich ziehe es deshalb vor, bei grösseren Programmen das Problem durch 
Einsatz von Controllern mit weniger Adressräumen zu umgehen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Eddy Current schrieb:

> Ich selber programmiere beispielsweise des öfteren 8051 mit SDCC und bin
> regelmäßig begeistert, wie easy ich hier mit Globalzeigern umgehen kann,
> die in unterschiedliche Addressräume zeigen (code, data, xdata). Sowas
> fände ich für AVR auch praktisch/sinnvoll, aber leider läuft die
> Unterstützung des SDCC für AVR aus. Ob das für GCC angedacht ist, weiss
> ich nicht. Andere Prozessorfamilien (z.B. MSP430) können über so eine
> Diskussion nur müde gähnen.

Wobei ich mich frage, wie die Compiler das anstellen, ohne den 
Sprachstandard zu verlassen. Müde über den Sprachstandard gähnen?

Wie wird das ausgedrückt, ob eine Adresse ins Flash zeigt oder ins RAM?

In gcc 4.5 werden Teile von ISO/IEC DTR 18037 implementiert (Draft 
N1275), aber en detail hab ich da noch net reingeschaut.
   http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00053.html

Johann

von (prx) A. K. (prx)


Lesenswert?

Johann L. schrieb:

> Wobei ich mich frage, wie die Compiler das anstellen, ohne den
> Sprachstandard zu verlassen. Müde über den Sprachstandard gähnen?

MP430: Ein einziger Adressraum, Problem löst sich in Luft auf.

Andere Compiler für Architekturen mit mehreren Adressräumen (*): 
Attributierung von Pointern und Variablen, wie es sie in GCC ja auch 
gibt. Im Unterschied zum GCC sind diese Compiler aber in der Lage, 
verschieden attributierte Pointer unterschiedlich zu verwenden und 
unterschiedliche Grösse dafür zu verwenden. Üblicherweise ist einer 
dieser Pointer in der Lage, über tagging und Laufzeitfunktionen alle 
Adressräume zu erreichen. Das ist nicht schnell, aber bequem.

*: Die unseligerweise auf Busse statt Adressräume gemünzten Begriffe 
Harvard/Von-Neumann vermeide ich bewusst.

von Pieter (Gast)


Lesenswert?

moin moin,

>>Für den Hobbybereich bevorzuge ich DIP-Gehäuse...

Und was ist mit PLCC?

Der AT89LP4052 ist auch DIP20.
Leider gibt es die DIPs nur noch selten, also baut (oder kauft man) 
einen passenden SMD-DIP Adapter. Nur wegen einer (fehlenden) Gehäuseform 
auf einen MC zu verzichten...? Naja, wer auch privat fast nur in SMD 
baut, kann so etwas nicht verstehen.

Mit Gruß
Pieter

von (prx) A. K. (prx)


Lesenswert?

Pieter schrieb:

> Und was ist mit PLCC?

Ist insgesamt gesehen noch deutlich toter als DIP.

von GAST IV (Gast)


Lesenswert?

Bei den 8051er ist die große Auswahl an Herstellern und kompatiblen 
8051er µC am schlimmsten. Man hat keine Übersicht über die vielen 
Modelle und darin verbauten Funktionen. Die neuen Varianten teilen den 
Quarztakt nur durch 2 .
Die Portins sind umschaltbar (Quasi-bidirectional, Push-pull, Input only 
(high-impedance), Open drain). Zig Timer verbaut (CCU), Interrups auf 
mehreren 8-bit-Ports für Tastatur-Anwendungen 
("Interrupt-on-change"-Funktion). Z.B. P89LPC93soundso.
Super ADCs, in jeder Hinsicht. (ADuC845 o.ä.)

Ja, die Dinger sind furchtbar.

Bitte 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
Noch kein Account? Hier anmelden.