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!
@ 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
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 ;-)
@ 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
>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
@ 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
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
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
>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
@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
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
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.
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.
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
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.
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 ;-)
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.
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
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.
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
Pieter schrieb:
> Und was ist mit PLCC?
Ist insgesamt gesehen noch deutlich toter als DIP.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.