Hallo ich lese hier immer wieder Diskussionen welcher uC nun besser ist, die PIC's oder die AVR's. Jetzt würde mich doch mal interessieren wer sich schon mal mit beiden auseinandergesetzt hat und sachlich/objektiv sagen kann wo welcher Vor- bzw Nachteile hat. Ich arbeite schon seit etwa 5 Jahren mit PIC12, 16, 18 und PIC30, aber ich habe noch nie das Gefühl gehabt, daß es da etwas gibt, was ich mit denen nicht machen kann. Alternativen zum PIC sehe ich nur bei uC, die besondere Features haben, wie z.B. MSP430 als besonders energiesparende uC oder good old 80C166 als Vertreter mit herausgeführten Bus oder echte DSP's. Also welche Features haben die AVR's - rein auf Hardware-ebene oder eben auf Feature-ebene, die sie besonders auszeichnet ? Gerhard
soweit ich weis, leigt der Unterschied fast nur in der programmierung! Ich hab mich mit dem pics noch nicht beschäftigt, aber gehört, dass da der speicher irgendwie segmentiert ist oder so ... (du solltest es wissen, wenn du schon so lange mit denen arbeitest) Vorteil beim tiny26 ist, dass man sehr hohe PWM frequenzen erzeugen kann ... obs nen gegenstück bei den pics gibt, weiss ich nicht
Wobei man klar sagen muß, daß es für die neuen PICs eh C-Compiler gibt und somit kann einem die Segmentierung völlig egal sein.
@Gerhard "ich lese hier immer wieder Diskussionen welcher uC nun besser ist" Die Frage ist superleicht zu beantworten: "Der, mit dem ich am effektivsten arbeiten kann". Und damit ist auch klar, daß die Antwort für jeden eine andere sein wird. Ich habe mich z.B. für den 8051 entschieden und damit keine schlechte Wahl getroffen. Mit über 600 verschiedenen Typen gibt es eigentlich nichts, was es mit dem 8051 nicht gibt (MP3, LAN, USB, CAN usw.). Die 8051 waren auch die ersten weltweit, die preiswert als Flash verfügbar waren (etwa 1993: Atmel AT89C51). Wo andere noch Löschgeräte quälten, habe ich schon längst geflasht. Die 8051 sind auch 100% kompatibel, d.h. mit jedem A51-Assembler oder C51-Compiler kann ich alle 8051 programmieren von original Intel von 1980 bis zum neuesten Silabs- oder Maxim-Typen, ohne auf Updates angewiesen zu sein. Zur Frage AVR vs. PIC: Die AVRs finde ich auch sehr interessant für kleine Sachen ohne Quarz oder Resetbeschaltung. Die 8051-er hatten da den Zug eindeutig verschlafen, inzwischen gibts da ja auch was (Philips LPC-Serie) und selbst Atmel hat viel Neues angekündigt (bis 20MIPS). Auch war es überhaupt kein Problem sich mit den AVRs zurechtzufinden, wenn man den 8051 schon kannte. Insbesondere sind die Änderungen, wenn man C-Code vom 8051 auf den AVR übernimmt, nur sehr gering (Hardwarezugriffe). Mit den PICs habe ich mal was versucht (PIC12-Derivat), aber da war mir zu vieles von hinten durch die Brust ins Auge (keine Interruptvektoren, kein Carry bei Addition, nur 1 Pointer, nur Hardwarestack, RAM-Banking, Flash-Paging usw.). In Assembler würde ich also sagen, ist der AVR eindeutig leichter zu lernen und bequemer zu programmieren. In der C-Programmierung dürften sich dann diese Vorteile auch niederschlagen (schnellere Ausführung, geringere Codegröße). Auch liest man oft, daß viele PIC-Compiler nicht alle Typen können, sondern nur einige wenige (die 12-er wohl garnicht) und oft nur eingeschränkte Variablentypen haben (kein long, kein float). Aufgrund der Unterschiede ist bei neuen PIC-Derivaten in der Regel auch immer ein Update des Compilers nötig, damit diese programmiert werden können. Peter
Ein paar Kriterien für den CPU-Core und die µC-Familie: - Compiler verfügbar, bzw wieviel will man dafür ausgeben? Für AVR und MSP430 gibt's mit GCC einen guten Compiler für lau. PIC und i51 entweder SDCC (über dessen Qualität mögen andere urteilen, ich kenne ihn nicht). Oder diverse Löhnwares, bis 4-stellige Beträge, teils auch als Demoversion mit Tricks. - Sind für CPU-spezifische Erweiterungen in C erforderlich? 8051: ja, 5-6 Speicherklassen für die diversen RAM-Varianten. AVR,PIC: für die RAM/ROM-Problematik (s.u.) ja, sonst nein. MSP430: nein. - Sind Daten in RAM und ROM mit dem gleichen Code benutzbar? AVR, PIC, alle übrigen Harvard-Architekturen: NEIN. Daten im ROM erfordern anderen Zugriff als Daten im RAM. Entweder versteckt das der Compiler in Runtime-Routinen für Pointerzugriffe, oder man kann Routinen nicht so schreiben, dass sie beides als Parameter verdauen können. Bei kleinen Programmen von ein paar KB kein Problem, bei grösseren jedoch schon. Bei AVR/GCC ziemlich fehlerträchtig. MSP430: saubere von-Neumann Architektur. Problemlos. - Lineare Adressierung vom RAM? PIC: PIC16 ja, PIC14,PIC12 nein. RAM-Puffer die gösser sind als das RAM in einer Bank sind nur mit Klimmzügen möglich. 8051,AVR,MSP430 kein Problem. - Skalierbarkeit? Vor allem für jene wichtig, die sich scheuen, für verschiedene Aufgaben verschiedene Lösungen zu verwenden. AVR: 8-Pin/1K bis 64pin/128K Tendenz steigend. PIC: innerhalb der Familie verschiedene Architekturen. i51: von klein bis ganz gross (aber jenseits von 64K wird's hässlich). MSP430: bei 60K Flash ist definitiv Schluss. Meine Empfehlung hier trotzdem: diese Klasse nur bis 40-60K verwenden, darüber auf 32bit (ARM-Core) umsteigen. - Wie komplex ist interrupt-feste Programmierung von I/O-Ports? Das ist besonders beim AVR ein Problem. Architekturbedingt ist nur ein Teil der Ports ist bitweise schaltbar, kein Port kann mehrere Bits gleichzeitig interrupt-fest schalten (Ausnahme: ganz neue Devices wie Tiny2313). Daher ist es eigentlich oft nötig, um Port-I/O herum die Interrupts abzuschalten. Macht aber kaum jemand. Folge: ab und zu "seltsames Verhalten", nicht repoduzierbar. Besonders gefährlich bei Software-Baukasten-Prinzip, wenn da manche Selbstverständlichkeiten eines Moduls plötzlich nicht mehr so selbstverständlich sind. PIC,i51,MSP430 können AND/XOR/XOR zum Port hin, daher im Prinzip kein Problem - dran denken muss man aber trotzdem (auch das kommt wohl eher selten vor). - Priorisierte Interrupts? AVR,PIC: nein. Folge: es ist schwierig bis unmöglich, Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren. i51: ja. - I/O Spannung? AVR,PIC,i51: 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). MSP430: nur 3V. Nicht 5V-kompatibel, d.h. 5V-Devices sind nur mit Pegelkonvertierung einsetzbar. - Debugging in der Schaltung? Ist beispielsweise ein günstiges JTAG-Interface für In-Circuit Debugging verfügbar? AVR: ab 40-Pin-Devices, darunter nicht oder arg teuer. Andere Familien: keine Ahnung. - Gehäuse? Mit DIP oder PLCC bastelt es sich leichter als mit *QFP. Die Domäne von AVR/PIC/i51.
Hallo allerseits. Hallo Peter So sehr ich Deine Beiträge schätze, kann ich deine Aussage: >Die Frage ist superleicht zu beantworten: "Der, mit dem ich am >effektivsten arbeiten kann". nicht ganz ohne Widerspruch stehen lassen. Das Ziel ist es doch, den passenden Controller für die jeweilige Applikation zu finden. Also müsste die Aussage lauten: "Der, welcher für die jeweilige Aufgabe am besten geeignet ist." Die PICs haben teilweise sehr interessante Peripherie z.B. für DC/DC Wandler etc. Es gibt Chips bis 125 Grad Umgebungstemp. etc. Dafür, und da muss ich Dir leider zustimmen, sind die eigentlichen CPUs kein grosser Lichtblick. Auch der CAN-Controller ist mehr eine Notlösung, aber für bestimmte Applikationen völlig ausreichend. Der AVR bietet mit seinen freien Tools (gcc/WinAVR, AVRStudio, etc.) einen schnellen preiswerten Einstieg. Der CAN-Controller (Mega128-CAN) ist sehr leistungsfähig, und die CPU ist sehr schnell. Die Ports können 20mA in beide Richtungen treiben. OnChip Debugging per JTAGICE möglich. Leider gibt es keine Chips für automotive Applikationen (125 Grad). An sonsten, ein relativ problemloser Controller für breite Anwendungen. Beim 8051 benötige ich leider sehr unterschiedliche Tools um meine Software in die Hardware zu Übertragen. Vom EPROM-Emulator bis zum JTAG-Flash Tool ist hier, je nach Chip, die Bandbreite ziemlich groß. Und weder die CPU noch die diversen 8051 Drivate lösen Begeisterungstürme bei mir aus. (EMV, Befehlssatz, etc.) Sorry habe meine ersten Gehversuche auf 6800/05/09 Systemen gesammelt. Und nach meinen ersten Projekten mit Philips ARM7 Controllern habe ich meine Meinung über Philips mal wieder deutlich nach unten korrigieren müssen. Wenn man sehr viel Rechenpower zu einem niedrigen Preis benötigt ist der ARM7 sicherlich eine gute Lösung, allerdings auch mit diversen Stolperfallen gespickt. Ergo. Es gibt viele verschieden Aspekte für die Auswahl des passenden Controllers. Und es ist nicht immer ganz leicht die vollmundigen Datenblattangaben richtig zu interpretieren. (z.B. 80C515C 4 PWM Ausgänge, selten habe ich so dumm aus der Wäsche gesehen). Also am besten mal die Zeit investieren und selbst versuchen ob man mit dem Chip klar kommt und wo die Fallen sind. Man erweitert damit auf jeden Fall den eigenen Horizont. Grüsse Josef Zimmermann
> "Der, welcher für die jeweilige Aufgabe am besten geeignet ist."
Nicht jeder springt von Lösung zu Lösung zwischen verschiedenen
Familien locker hin und her. Sicher, manchen fällt das leicht, dann ist
das eher eine Frage der zur Verfügung stehenden Werkzeuge. Andere
wiederum kämpfen schon an einer einzigen Famile arg mit dem Verständnis
der Vorgänge - wie hier oft zu beobachten ist.
Welchen Controller würdet ihr für extrem schnelle digitale datenverarbeitung empfehlen?also daten von einem externen (sehr schnellen) AD wandler zu lesen und auf eine ram zu speichern und zwischendurch vl noch die daten etwas um zu rechnen. oder die daten vom ram auf einen DA wandler zu schreiben. er sollte auch relativ schnelle rechenoperationen durchführen können. und was eigentlich auch sehr wichtig ist! Es sollte für ihn einen vernünftigen C-Compiler geben. Welche architektur empfehlt ihr? RISC oder CISC? mfg schoasch
je schneller desto besser ;-) wenn man zb einen pin nur ein- und ausschaltet, sollte dies schneller als 2MHz möglich sein. er sollte die 1,6MHz variante des SPI busses schafen (am liebsten wäre mir ja die 26MHz variante, aber das wird sich nicht ausgehen ;-)) er soll lediglich so schnell wie möglich daten von einem port einlesen und diese auf ein anderes port wieder ausgeben und das eben im MHz bereich. sorry, ich weis nicht wie ich es erklären soll.(ist aber auch schon spät) mfg schoasch
@Schoaschi: Du beschreibst ziemlich genau das Aufgabenfeld von DSPs. Und bis damit vermutlich ein bischen neben dem Thema / den Erfahrungen dieses Forums.
Einlesen und einfach wieder ausgeben ist klingt eher nach CPLD/FPGA. Ohne genauere Informationen deinerseites kann man aber nur raten.
FPGAs kann man zwar auch zum Rechnen bewegen (das ist ja eine der Forderungen), aber an C Compilern (eine andere seiner Forderungen) hapert's bisweilen.
was sind denn bitte DSPs CPLD/FPGAs? naja im endeffekt soll es ein gerät werden zur ton aufnahme. also ich nehme ein audiosignal her und digitalisiere dieses und schreibe es danach auf eine festplatte oder halt einen anderen speicher. nur je schnell das das ganze ginge, desto besser wäre es, denn theoretisch könnte man das ganze auch auf ein kleines KO umbauen. und in weiterer folge will ich dann den umgekehrten weg angehen. aber das ist eine andere geschichte ;-)
DSP: aka Signalprozessor. Konstruiert zur digitalen Verarbeitung analoger Signale. Das heisst nicht unbedingt, dass da ADCs/DACs drin sind, sondern dass sie die dafür nötigen Rechenoperationen, Schnittstellen und Datenverschiebebahnhöfe implementieren. Gibt's von ziemlich vielen Herstellern, beispielsweise Texas Instruments (320Cxx), neuerdings auch von Microchip (dsPIC). CPLD/FPGA: Programmierbare Logik, keine Prozessoren irgeneiner Art (wenngleich man in grösseren FPGAs welche selber bauen kann).
Ein AVR bringt mit "Pin ein- und ausschalten" vielleicht mit Mühe noch einen Kanal auf die Festplatte (bei 16 MHz Takt und 44.1kS/s bleiben 181 Takte pro Byte). Viel schnellere IOs als beim AVR wirst du nicht finden, wenn du mehr Geschwindigkeit willst musst du die Platte direkt an den Bus deines Prozessors hängen. Eventuell ist noch (mehr oder weniger umfangreiche) Interfacelogik nötig. Compact Flash oder SD-Card wäre für den Anfang einfacher, da die sich direkt mit Prozessorbus/SPI vertragen. Die sinnvolle Untergrenze für den Prozessor (von Controller zu reden passt da schon langsam nicht mehr) ist so etwa im Bereich LPC2xxx (60 MHz ARM). Wenn du höher hinaus willst, schau dir mal den Blackfin an (RS hat ein Board für 130 Euro), damit gehen auch "härtere" Dinge wie Effekte, MP3-Kodierung in Echtzeit usw. Aber da geht's langsam aus dem Hobby-Bereich heraus, und wenn du fragst "RISC oder CISC?" hast du dir vermutlich ziemlich viel vorgenommen ;)
"Und nach meinen ersten Projekten mit Philips ARM7 Controllern habe ich meine Meinung über Philips mal wieder deutlich nach unten korrigieren müssen. Wenn man sehr viel Rechenpower zu einem niedrigen Preis benötigt ist der ARM7 sicherlich eine gute Lösung, allerdings auch mit diversen Stolperfallen gespickt." @jozi ist wohl OT, vieleicht einen neuen Thread? würdest Du dazu bitte noch ein paar Sätze (oder Stichpunkte) schreiben, was Dich an den Philips ARM stört? Mich interessiert schon länger das Board (LPC-P2106) hier vom mikrocontroller.net Shop. Wenn Du hier einige Stolperfallen ansprichst, weiß ich (und andere) worauf man sich beim Philips ARM einlässt, oder vieleicht lieber von einem anderen Hersteller kauft. Danke und Grüße Quark
@andreas Achja.. viel habe ich mir schon vorgenommen ;-) aber wenn ich das nicht tun würde, würde ich noch immer mit widerständen und leds (ohne µC) arbeiten ;-) Und das hier ist mal ein sammeln von informationen. danach muss ich erst mal entscheiden was ich mache. bezüglich der frage: CISC oder RISC. Mir ist teilweise noch nicht so ganz klar in welchen fällen welche architektur besser ist. denn jede hat sicher ihren vorteil und nachteil, ansonst würds ja keine CISC mehr geben wenn die so schlecht sind oder? jetz noch ne dumme frage ;-) (ein bisschen träumen wird man wohl dürfen :-)). ist es möglich das man einen alten Prozessor(Intel 486 DX2) aus einem PC anspricht und mit diesem arbeitet? hat jemand links dazu oder sonst irgend eine info. ausser: du bist verrückt und solltest koch werden;-)... oder ähnliche aussagen. mfg schoasch
Was denkst Du, gewinnst Du mit dem alten 486er ? Das ist ja ein CISC-Prozessor, der bei 66MHZ wohl nicht mal 10MIPS schafft. Die ollen Intel-Prozessoren benötigen auch noch zusätzliche Chips zum Ansteuern von Peripherie und RAM. Ist sicher interessant zum Studium, aber damit eine Steuerung bauen ? Ne danke. Gerhard
Um noch mal ganz auf den Anfang dieses thread zurück zu kommen: Ich muss mich beruflich mit PIC beschäftigen und mir stinkt am meisten die zum Teil noch nach vielen Monaten ellenlange Mackenliste in den errata sheets. Aktuelles Beispiel 18F242 ist zwar noch erhältlich wird aber nicht für Neukonstruktion empfohlen, Nachfolgetyp 18F2420. Jetzt habe ich ein mit 18F242 funktionieres UART Modul (ASM) genommen und ins Prg. eingebaut. Ende vom Lied: es kommt nur Mist raus, weil man während der TX ein Byte rausschiebt, nicht das Paritybit des nächsten Bytes in das TXSTA Register schreiben darf weil dabei der (Hardware) Prescaler des Baudratengenerators zurückgesetzt wird! Da kann man nur sagen: ohne worte. Dass ein früheres Projekt um 3 Monate verzögerte wurde, weil die Interruptpriorität beim 18F242 bis ca. 9 Monate nach Beginn der Serienlieferung! (nicht samples!) nicht richtig funktionierte sei nur am Rand erwähnt. Da muss man sich bei Microchip offenbar dran gewöhnen. Dieter
@Schoaschi: Das mit dem 486er habe ich mir auch schon überlegt (schon vor einigen Jahren, als ARM-Derivate noch kein Thema waren). So ein 486er ist immerhin 32Bit, kann Multiplikation und Division, hat eine FPU, er kommt auch mit mehreren MB Speicher problemlos zurecht usw. usf. Wenn man sich dann aber mal überlegt, was da alles an Peripherie ran muß, dann merkt man schnell, daß das nicht trivial ist. Da braucht man eine ganze Menge ICs - aber das gibts ja auch schon fertig, als sogenannten Chipsatz. Sogar fertig verlötet auf einer Platine - das Mainboard eben. Das ist an dieser Stelle dann auch die Lösung: Wer einen 486er verwenden will, der sollte einfach einen alten PC dafür hernehmen. Wobei - wie oben schon gesagt wurde - ein 486er nicht mehr Stand der Technik darstellt. Es gibt heutzutage eben auch Microcontroller, die mit einem 486er mithalten können.
Hallo allerseits, hallo Quark. Anbei auf besonderen Wunsch ein paar Hinweise zu meinen Problemen mit dem LPC2114 von Philips. 1.) Das Datenblatt/User Manual ist unvollständig und teilweise irreführend. 2.) Der interne I/O-Bus ist ziemlich langsam und wurde mehr oder weniger direkt von der 8051 Familie übernommen. Ich habe jetzt keine exakten Zahlen, aber nach meiner Abschätzung sind die Portzugriffe bei Ti (TMS470) deutlich schneller. 3.) Einige Funktionen des Orginal ARM7TDMI Kerns fehlen bei Philips (Umschaltung Big/Little Endian, etc.). 4.) Dummerweise verhält sich der I2C Controller ähnlich wie der im 8051, allerdings nur teilweise. Beispielsweise ist zum Senden des Stop Bits das Löschen des Interrupt-Flags nötig. Und genau hier wird im Manual auf das Datenblatt aus der 8051-Familie verwiesen. 5.) JTAG-Interface nur zum flashen und debuggen. Kein Boundary Scan. 6.) Der ARM Debugger ist selbst ziemlich buggy. Abstürze, vergessene Breakpoints, kein Reset Button. Gut den letzen Punkt kann man nicht Philips anlasten. Vielleicht bin von meinem letzen AVR Projekt noch zusehr verwöhnt, aber im Grossen und Ganzen scheint mir die Dokumentation von Philips mit der heissen Nadel gestrickt zu sein. Dafür ist der Chip gnadenlos billig. Ich denke das gibt meine ersten Eindrücke wieder. Vorher bin ich schon einmal mit einem 8051 von Philips bei der EMV-Prüfung ziemlich auf die Nase gefallen. Grüsse J. Zimmermann
Von ST und Analog gibt's interessante Alternativen zum LPC2xxx.
@jozi Danke nochmal, sehr aufschlußreich. Dann werde ich erstmal intensiver die Dattenblätter studieren. @Andreas guter Tipp, danke. Grüße Quark
Ich bin eigentlich noch recht neu in der Thematik, darf aber hier in der Firma etwas mit PICs "herumspielen", weswegen ich ein paar Anmerkungen machen möchte. Ich habe mich überwiegend mit dem PIC16F84A und dem PIC18F452 beschäftigt, weswegen sich meine Kommentare auch überwiegend auf diese Varianten beziehen werden. @Peter Dannegger "kein Carry bei Addition" Das stimmt definitv für die von Dir angesprochene M-Klasse, aber nicht mehr für die H-Klasse, also die PIC18 (keine Ahnung, ob es für die 17er auch gilt, aber wahrscheinlich schon, da die Erweiterung des Befehlssatzes mit der größeren Befehlskodierung zusammenhängt). @A.K. "Compiler [...] teils auch als Demoversion mit Tricks" Die Limitierungen des CC5X sind, daß maximal 1024 Instruktionen pro Modul und nicht ganz so gut optimierter Code erzeugt werden, außerdem können Variablen maximal 16-Bit haben. Ich denke mit den Limitierungen läßt sich sehr gut leben, wenn man bedenkt, daß die meisten PICs ohnehin kaum mehr Instruktionen aufnehmen können. http://www.bknd.com/cc5x/downl-stud.shtml "Priorisierte Interrupts? [...] PIC: nein" Der 18er hat zumindest zwei unterschiedliche Interruptverktoren, einen für niedrige und einen für hohe Priorität. Für die einzelnen Interruptquellen kann unabhängig eingestellt werden, welche Priorität sie haben sollen. Was den Interrupt ausgelöst hat, muß man leider immer noch in der ISR händisch feststellen. "Debugging in der Schaltung?" Sollte bei PIC über ICD2 in Kombination mit MPLAB möglich sein. Ich kann es nicht genau sagen, da ich bisher mit einem etwas veralteten MPLAB gearbeitet habe, wo es nicht möglich war. Wenn ich mich nicht irre, bin ich vor kurzem auch über eine Seite gestolpert, wo beschrieben wurde, wie man sich einen ICD für PIC selber bauen kann.
@Michael: schreib das bitte direkt in http://www.mikrocontroller.net/articles/AVR_PIC_51-Vergleich mit rein.
Nachdem hier die Frage ob RISC oder CISC aufkam, möchte ich auch dazu noch ein paar Kommentare abgeben. Der originale Defintion des Begriffs RISC (Reduced Instruction Set Computer), den man aber nicht zu wörtlich auslegen sollte, stammt von David Patterson. Ich werde mich auf eine etwas generalisierte Definition beziehen, da Patterson sich doch stark am Berkeley-RISC-Project (aus dem sich SPARC entwickelte) orientierte und deswegen auch sog. Register-Fenster vorsieht. Die wichtigsten Punkte der Definition sind: * Eine Instruktion pro Zyklus Dies wird übrigens häufig so ausgelegt, daß jede Instruktion einen Zyklus benötigt, was natürlich falsch ist. Gemeint ist eigentlich, daß unter der Verwendung von Pipelining im Idealfall eine Instruktion pro Zyklus abgeschlossen werden sollte. Hier scheint bei PIC ürigens die Marketingabteilung zugeschlagen zu haben, da hier auch behauptet wird, daß der Prozessor eine Instruktion pro Zyklus ausgeführt wird. Interessanterweise meint Microchip damit aber einen Instruktionszyklus, der allerdings vier Taktzyklen benötigt. Pipelining ist bei CISC-Prozessoren aufgrund der (unterschiedlichen) Komplexität der einzelnen Instruktionen deutlich schwerer zu bewerkstelligen. Ohne Pipeline würde eine PIC-Instruktion sogar 8 Taktzyklen benötigen, da PIC eine zweistufige Pipeline hat. Da Interrupts nur zwischen Instruktionen stattfinden können, wirkt sich die Eigenschaft von RISC-Architekturen, wenige Takte pro Instruktion zu benötigen, positiv auf die Latenz aus. Dies war wohl auch einer der Hauptgründe für Acorn nicht auf einen vorhanden Prozesser zurückzugreifen, sondern den ARM zu entwickeln. * Eine kleine Zahl von uniformen Instruktionsformaten RISC bedeutet nicht etwa, daß man sehr wenige Instruktionen hat (es gibt natürlich architektonische Beispiele dafür, aber mindestens genauso viele Gegenbeispiele), sondern daß die Zahl der Instruktionsformate recht gering ist und Instruktionen normalerweise die gleiche Länge haben, um die Decoder-Einheit des Prozessors zu vereinfachen. Im weitesten Sinne halten sie die üblichen RISC-Architekturen daran, gelegentlich gibt es aber Ausreißer, wo ein Teil einer längeren Adresse in einer Folgeinstruktion eingebaut ist, die ohne die Vorgängerinstruktion als NOP interpretiert würde. Das ist bei Embedded-RISC häufiger anzutreffen, da dort die Instruktionen ohnehin möglichst kurz sein sollten. Die Instruktionslänge ist hier natürlich der wichtige Faktor. Während bei einer RISC-Instruktion aufgrund der festen Länge einige "tote" Bits vorkommen können, kann man bei CISC versuchen, die Instruktion so kurz wie möglich zu machen (obwohl sich die gängigen Architekturen zumindest an das Byte als Grundelement halten). In der Theorie sollte CISC-Code also weniger Speicherplatz verbrauchen, als vergleichbarer RISC-Code. Und Speicherplatz ist in Mikrocontrollern ja meist recht begrenzt. Ich muß allerdings gestehen, daß ich bei den mir bekannten Architekturen bisher noch keine gravierenden Unterschiede feststellen konnte. * Load/Store-Architektur D.h. Operation werden ausschließlich auf Registern durchgeführt und der Datenaustausch zwischen Registern und dem Speicher findet ausschließlich über sog. Lade/Speicher-Instruktionen statt. Dieser Punkt folgt ja eigentlich aus den beiden vorhergehenden, da man auf diese Weise sowohl die Instruktionen einfacher gestalten, als auch die Komplexität der Instruktionsformate reduzieren kann. Dummerweise heißt das auch, daß einem während einer Operation, die einen Speicherwert modifizieren soll, ein Interrupt dazwischen kommt, da man den Wert ja erst laden, dann im Register modifizieren und dann erst in den Speicher zurückschreiben muß. Aus diesem Grund ignoriert SuperH (ehemals Hitachi jetzt ???) diese Vorgabe wohl teilweise und läßt zumindest einige Bit-Instruktionen direkt auf den Speicher zugreifen. * Große Zahl von Universalregistern "Groß" ist hier natürlich relativ. Die meisten Embedded-RISC-Architekturen haben "nur" 16 Register, wobei AVR mit 32 Registern (?) doch recht ordentlich dasteht. Auch das hier ist natürlich eine Folgeerscheinung der Load/Store-Architektur: Wenn man nur auf Registern operieren kann, sollte man zumindest einige davon haben. Da Registerzugriffe immer noch am schnellsten sind, wirkt sich das natürlich wieder recht positiv auf die Latenz aus. Bei PIC von vielen Registern zu sprechen, halte ich allerdings für etwas überheblich, da diese sog. "Register" fast ausschließlich im SRAM liegen (zumindest ist damit die Latenz nicht so schlecht wie bei DRAM). Beides hat seine Vor- und Nachteile. Im Embedded-Bereich zeichnen sich die RISC-Prozessoren vor allem durch gute Latenz-Zeiten aus, allerdings kann sich die Load/Store-Architektur als ungünstig herausstellen, wenn einem "eine Operation" durch einen Interrupt unterbrochen wird. Theoretisch sollte es möglich sein für CISC-Prozessoren kompakteren Code zu erzeugen. Im Desktop-Bereich haben die RISC-Prozessoren schon längst gewonnen, da sich die Prozessoren durch die einfacheren Schaltungen und das Pipelining deutlich höher Takten lassen. Selbst die IA-32 hat die x86-Instruktionen nur noch in der Software, die aber vor der Verarbeitung in der ALU vom Decoder in kleinere RISC-ähnliche Operationen zerlegt werden. Ich hoffe, daß der Beitrag zumindest halbwegs nützlich war ;-)
Durchaus informativ und gut zu lesen, danke sehr! Zufälligerweise der M.K. aus de.rec.modelle.bahn?
"Der originale Defintion des Begriffs RISC (Reduced Instruction Set Computer), den man aber nicht zu wörtlich auslegen sollte, stammt von David Patterson. Ich werde mich auf eine etwas generalisierte Definition beziehen, da Patterson sich doch stark am Berkeley-RISC-Project (aus dem sich SPARC entwickelte) orientierte und deswegen auch sog. Register-Fenster vorsieht." Wobei erwähnenswert ist, das der nach üblicher Definition erste RISC-Computer die CDC6600 von Thornton und Cray ist, gebaut 1964!, er hatte eine Load-and-Store-Architektur mit nur zwei Addressierungsarten, Pipelining und nur 74 Opcodes. Das erste Projekt eines RISC-Chips ist wohl der IBM801, aus dem auch einiges in die Power-Architektur geflossen ist. "RISC bedeutet nicht etwa, daß man sehr wenige Instruktionen hat" Doch, so war das ursprünglich schon angedacht, es geht ja einher mit der verringerten Anzahl von Instruktionsmodi. "Berkeley-RISC-Project (aus dem sich SPARC entwickelte)" Genaugenommen war es das zweite RISC-Projekt (das RISC-II-Design), welches Sun sich genommen hat und daraus dann den SPARC entwickelte. "Im Desktop-Bereich haben die RISC-Prozessoren schon längst gewonnen, da sich die Prozessoren durch die einfacheren Schaltungen und das Pipelining deutlich höher Takten lassen. Selbst die IA-32 hat die x86-Instruktionen nur noch in der Software, die aber vor der Verarbeitung in der ALU vom Decoder in kleinere RISC-ähnliche Operationen zerlegt werden." Naja, das kann man natürlich auch anders sehen. Es stellt sich einem doch sofort die Frage, wieso man dann überhaupt noch den (unzulänglichen) x86-Aufsatz draufsetzt und nicht gleich nur noch den RISC-Kern als Komplett-Prozessor verkauft. Das Ganze nur mit der vorhandenen Software zu erklären, greift wohl nicht (siehe Apple: 68000 -> PowerPC). Was die PICs von Microchip angeht, so muss man bedenken, dass das eine uralte Architektur ist, die ja ursprünglich von General Instruments 1975 entwickelt wurde (PIC1650) und somit natürlich den AVRs technisch stark unterlegen ist.
Einen kleinen Sprung zurück in die Praxis.. habe als Avr Fan immer die PIC`S gemeidet...aber momentan bastle ich an einem Funkthermometer mit dem PIC 16F684: 1,6 microA im Sleep Mode mit laufendem Watchdog der den Pic alle 268 Sekunden weckt, das schafft kein AVR!! Arno
"das schafft kein AVR!!" "Der MSP430 sollte da noch besser sein.?" Das Spielchen könnte man schier endlos ausdehnen. Ich frage immer zuerst, was brauche ich. Also z.B. die Batterie hat **Ah und soll **h halten, dann kann ich **µA verbraten und alles was darunter ist, ist o.k.. Ich suche also nicht das beste, sondern nur das, was gut genug ist. Peter P.S.: Laut Datenblatt zieht der ATTiny2313V mit Watchdog bei 1,8V auch nur 1,8µA.
Bei Batteriebetriebenen Geräten gilt aber auch unabhängig von der Mindestspezifikation "je länger, desto besser". Der MSP430 kommt bis in den nA-Bereich runter.
Watchdogüberlauf: ATMega8 ca. 2Sekunden ATTINY23213 8 Sek. PIC16f684 268 Sek.!! Wenn ich nur alle 5 Minuten eine Messung machen muss,ist das schon ein Unterschied. Weiterhin kann man beim Pic während der Laufzeit des Programms zwischen den verschiedenen internen/externen Oszillatoren umschalten.
Wenn ich alle 5 Minuten für ein Funkthermometer eine Messung machen muss, dann nehme ich einen anderen Quarz und habe bei jedem Controller eine längere Watchdog-Laufzeit. Du betreibst das Ding doch nicht etwa im Mhz-Bereich?
@ A.K. Ich denke jetzt müßte ich alle Änderungen an dem MCU-Vergleich gemacht haben. Hat etwas gedauert, weil ich einige Punkte erst noch überprüfen wollte. @ remstal Was denn, noch ein Namensvetter? (D.h. ich bin nicht der M.K. aus de.rec.modelle.bahn...) @ Jochen "Wobei erwähnenswert ist, das der nach üblicher Definition erste RISC-Computer die CDC6600 von Thornton und Cray ist" Stimmt, die CDC6600 war ihrer Zeit weit voraus. Wurde deswegen von IBM mit viel FUD niedergemacht, wenn ich mich nicht irre, weil sie Angst hatten, daß ihr noch nicht fertiges System/360 dagegen alt aussehen könnte. Ist eigentlich witzig, daß wir damit zwei der wichtigsten Computer in direkter Konkurrenz hatten. Die CDC6600 als RISC-Vorläufer und die 360er als erste Computerarchitektur, die auch so bezeichnet wurde, und als erster Computer mit Byte-Adressierung. "Das erste Projekt eines RISC-Chips ist wohl der IBM801, aus dem auch einiges in die Power-Architektur geflossen ist." Auch Korrekt. Allerdings war das meiner Ansicht nach nur ein interner Prototyp, der erst später der Öffentlichkeit bekannt gemacht wurde. Außerdem sehe ich POWER/PowerPC fast eher als RISC-CISC-Hybrid. Der erste kommerzielle RISC-Prozessor war übrigens der ARM. "Doch, so war das ursprünglich schon angedacht, es geht ja einher mit der verringerten Anzahl von Instruktionsmodi." Nicht zwangsläufig. Man hat eben nicht so viele Adressierungsarten und überwiegend Instruktionen, die mit vollkommen gleichem Layout auf Registern operieren. Insbesondere bei letzeren kann man sich ordentlich austoben. "Genaugenommen war es das zweite RISC-Projekt (das RISC-II-Design), welches Sun sich genommen hat und daraus dann den SPARC entwickelte." Kann gut sein, ich habe mich damit nur am Rande beschäftigt. Iteressant ist allerdings, daß SPARC V1 (?) in bester RISC-Manier auf Integer-Multiplikation und -Division verzichtet hat. Aufgrund schlechter Performanz wurden die aber recht schnell nachgeflickt. ARM und Alpha haben aber bis heute keine Integer-Division und andere Architekturen (SuperH, PA-RISC, TriCore) zerlegen die Berechnung zwecks besserer Latenz in einzelne Divisionsschritte. "Naja, das kann man natürlich auch anders sehen. Es stellt sich einem doch sofort die Frage, wieso man dann überhaupt noch den (unzulänglichen) x86-Aufsatz draufsetzt und nicht gleich nur noch den RISC-Kern als Komplett-Prozessor verkauft." Die Frage stelle ich mir jedes Mal, wenn ich mir die IA-32 anschaue. Ich denke mal, daß man es nicht gewagt oder geschafft hat, dem Kunden eine andere Architektur unterzuschieben. Ansonsten bin ich nämlich auch der Meinung, daß man spätestens ab dem 386er die Architektur wechseln und die alten Programme hätte emulieren können. "Das Ganze nur mit der vorhandenen Software zu erklären, greift wohl nicht (siehe Apple: 68000 -> PowerPC)." Genau genommen hat Apple in der Zeit, seit der IBM PC existiert, bereits die dritte Prozessorarchitektur, da ja vorher der 6502 aktell war und der Mac erst ca. zwei oder drei Jahre nach dem IBM PC auf den Markt kam. Ich glaube, daß Apple da einfach Risikobereiter (und beim Einsatz von Emulatoren auch irgendwie intelligenter) war als die PC-Hersteller und Microsoft. Noch idiotischer ist, daß AMDs x86-64 ebenfalls noch mit 2-Adresscode, variabler Befehlslänge (dank weiterem Präfix von 1 bis 17 Byte) und immer noch vergleichsweise wenigen Registern ankommt, dabei muß der 64-Bit Instruktionssatz ja zu gar nichts existierendem kompatibel sein. Das ist jetzt aber ziemlich off-topic... Tatsache ist nur, daß die meisten noch aktuellen CISC-Architekturen intern RISC-Techniken einsetzen, um von der Geschwindigkeit her mithalten zu können. Insbesondere bei Intel und AMD ginge wohl nichts mehr ohne das Know-How ehemaliger Alpha-Entwickler. Bei Mikrocontrollern bin ich mir nicht ganz sicher, obwohl ich mir nicht vorstellen kann, daß ein Coldfire wie mein alter 68000er operiert, da die Instruktionen teilweise so viele Taktzyklen fressen, daß die Latenz-Zeiten äußerst übel wären. "Was die PICs von Microchip angeht, so muss man bedenken, dass das eine uralte Architektur ist, die ja ursprünglich von General Instruments 1975 entwickelt wurde (PIC1650) und somit natürlich den AVRs technisch stark unterlegen ist." Vollkommen klar. Ich finde es nur witzig, daß PIC quasi als RISC angepriesen wird, was aus meiner Sicht einfach nicht der Fall ist. Mal eine andere Frage zum eigentlichen Thema das Threads: Wie ist eigentlich die Codequalität das AVR-Backends vom GCC? Ich weiß nur, daß ich von dem Code das ARM-Backends nicht besonders begeistert war, als ich von auf meinem RiscPC gearbeitet habe, und das PPC-Backend scheint selbst nach einigen Änderungen von Apple immer noch einiges zu wünschen übrig zu lassen.
Wo wir beim Thema Architektur sind: der MSP430 ist eine ziemlich genaue Kopie der PDP-11. Irgendwie lustig, dass aus einem schrankgroßen Stromfresser einer der sparsamsten Prozessoren überhaupt geworden ist.
"der MSP430 ist eine ziemlich genaue Kopie der PDP-11" Naja, wie man es nimmt: auto-decrement und pre-increment fehlen, es sind weniger Instruktionen, die Multiplikation funktioniert ganz anders...
Die PDP-11 als Vorbild ist wirklich nicht die schlechteste Wahl.IMHO hat MSP430 die mit reichlich Abstand eleganteste Architektur unter den 8/16-Bit µC. Wobei man MSP430 freilich auch in der Tradition von TIs eigenem Minicomputer, der 990-er Reihe, sehen kann (auch 9900). So arg weit war der auch nicht von der PDP-11 weg, nur nicht annähernd so sauber. Wenn die eher hardwareseitigen Nachteile nicht wären (3V I/O, wenig RAM, magere Ausstattung mit Funktionsmodulen vor allem am unteren Ende der Famile, keine bastelkonformen Gehäuse).
Vielleicht sollte man noch die Z8 Encore in den Vergleich aufnehmen. Kennt sich jemand mit denen genauer aus?
@ Michael ("Wie ist eigentlich die Codequalität das AVR-Backends vom
GCC?"): der Code ist, wie man ihn vom gcc erwartet, also etwas größer
und etwas langsamer als nötig. Aber ohne Kompromisse in Zuverlässigkeit
oder Standardtreue. Ich selbst hüte mich, seine Nachteile zu
kritisieren, denn ich selbst habe nichts dazu beigetragen. Der Vorsatz
ist allerdings schon da, wenn ich im Debugger das Compilat betrachte
...
Vielleicht sollte man zur MCU-Vergleichsseite noch ein paar Chip-Empfehlungen hinzufügen. Hintergrund ist folgender: Ich habe gerade einen neuen Aufbau mit PIC16F84A bekommen und mußte feststellen, daß ich ihn mit ICD2 leider nicht programmieren kann... Ich werde wohl auf den pinkompatiblen 16F627A umsteigen (€3,70). Wenn man ICD2 und eventuell den PICC Lite von HI-TECH verwenden will, würden sich vor allem folgende PICs anbieten: 16F877(A), 16F627A (der 16F627 geht mit ICD2 nicht) und 16F684. Wer es möglichst klein will, die beiden 8-Pin, 12F675 & 12F629, gehen auch. @Philipp Danke und Gruß an einen weiteren Mac-User ;-) Machst Du Embedded-Programmierung auf dem Mac? Ich versuche ein hier in der Firma herumliegendes PICkit abzustauben, da das netterweise mit USB arbeitet.
Hallo Leute! Folgendes steht in WikiPedia über Philips: Koninklijke Philips Electronics N.V. (Royal Philips Electronics), kurz Philips, ist einer der weltgrößten Elektronikhersteller. Philips setzte 2002 31,8 Milliarden um und beschäftigte 166.000 Menschen in über 60 Ländern. Philips ist in folgende Geschäftsbereiche eingeteilt: Philips Unterhaltungselektronik, Philips Halbleiter, Philips Beleuchtung, Philips Medizintechnik und Philips Forschung. Toll. Und da hat Philips nicht mal das Geld, dass sie einen deutschsprachigen Mitarbeiter beschäftigt, der sich halbwegs mit ARM µControllern auskennt. Wenn man eine Frage hat müsste man irgendwo in Holland anrufen. Ich glaube die wollen uns verarschen. Bei Infineon oder Atmel, überall erwischt man jemand in Deutschland oder Österreich, aber nicht bei Philips. Tschuldigung, aber das musste raus. Tschüss Mario
@ Michael: Nein, noch nicht. Mein "prähistorisches" PowerBook hat noch kein USB und über die LocalTalk-Unterstützung von OS X konnte ich nicht genug herausfinden, um eine Brücke nach RS-232 zu schlagen. )-: Also erstmal nicht. (Aber ewig wird das Wally auch nicht halten ...) @ Mario: Hast Du denn mal in Holland angerufen? Ich habe oft dienstlich mit NL Firmen (nicht Philips) zu tun und habe noch keinen an der Strippe gehabt, der sich auf höfliche Nachfrage nicht herabgelassen hätte, Deutsch mit mir zu sprechen. Und kosten tut das ja heute auch nichts mehr.
Hallo, hier noch eine Info zum Pic. Ich arbeite hauptsächlich mit AVRs, hab aber mal im Studium mit PICs angefangen. Es ging um Frequenzmessung und der PIC hatte den Vorteil dass der ext. Counter unabhänig vom Quarztakt läuft. Beim AVR wird der ClockIn Pin im Quarztakt gesampelt. So war es möglich mit dem PIC bis zu 40 MHZ zu zählen, wärend beim AVR bei 1/2 Quarztakt (also max. 8 MHZ) Schluss ist. cu Peter
Hi, schade, daß die RISC Serie c166/ST10 fast nur ohne Flash zu erhalten ist, sonst würde ich diese zu meinem Lieblingcontroller küren. Die Serie hat ganz viel Pheripherie. So arbeite ich meist mit den Atmel risc. Die MSP430 benutze ich aus u.g.Gründen (keine Leistungsausgänge zum direkten Ansteuern von LED's) nicht. Georg
Hallo Georg der C167 gehört nicht gerade zu meinen Lieblings- Mikrocontrollern. Bei der Konfigurationsdatei werd ich fast wahnsinnig. Wenn man ein Phytec-Board verwenden kann gehts, die liefern gleich das passende dazu. Aber ich finde die Doku von Siemens/Infineon eine Katastrophe - zumindest hab ich noch keine vernünftige gefunden - daß man ohne Probieren die richtigen Einstellungen für selbstdesignte Boards findet. Da sind mir die PIC's schon lieber. Gruß Gerhard
hmm, ich muss ein Fazit erfragen. Zwar habe ich kenntnis im bereich Elektronik, aber garnicht im Bereich µC. Nun wollte ich schließlich anfangen und eine kleine Schaltung mit einem PIC oder AVR aufbauen. Lerning by doing. Eine fertige platine will ich mir keinesfalls kaufen. Nun will ich mit festlegen, denn ich glaube, ich werde auch später mit dem µC arbeiten auf den ich mich festlege. Oder ist es nicht so, dass man immer den µC benutzt den man gelernt hat? Jedenfalls wollte ich fragen was mehr sinn macht. Sich in die Materie vom PIC oder AVR reinzuhaken?
Hallo Kokosnuss die Frage ist eher, ob für den Heingebrauch oder Bruflich. Berulich ist es nach meiner Erfahrung so, dass der uC "schon da ist", das heisst, zumeist ist man nicht der Erste, der sich in der Firma mit der Materie auseinandersetzt. In meinem Fall zumindest war das so (C167 bzw PIC). Dadurch hat sich mir diese Frage nie gestellt. Für den privaten Gebrauch ist es so, dass ich mich persönlich von Preisen für Bauteile als auch von der Bezugsmöglichkeit und dem Supportleiten lassen würde. Ich kann aber nach wie vor nur über die PIC's reden. Wenn du privat oder beruflich einen PIC (Menge 1) brauchst, bekommst du den von Microchip kostenlos gegen Angabe deines Projektes und wann du vorhast welche in Stückzahlen einzusetzen. Für PIC18, 24, 30 und 33 gibts einen kostenlosen C-Compiler von Microchip (Studentenversion) und der Support im Netz ist ok. Mit dem PICKIT2 hat MIcrochip jetzt auch einen bezahlbaren Programmer/Debugger auf den Markt gebracht. Die PIC16 sind preislich günstig aber nicht mehr so ganz state-of-the-art. Die sind aber noch ok, um sie in Assembler zu programmieren. An sonsten würde ich zum Starten nur PIC18 (z.B. PIC18F1320 (4,40 Euro bei Reichelt) als 18-pinner oder PIC18F2220 (5,75E bei Reichelt) als 28-pinner verwenden. Die Preise liegen damit glaube ich schon deutlich über denen der ATMEL's, aber, wie gesagt, gibt es die auch kostenlos von Microchip. Gerhard
Der Beitrag ist zwar schon uralt, da aber eine aktuelle Anfrage dazu kommt, poste ich hier mal einen kleinen (persönlichen) Vergleich zwischen den bastlerfreundlichen PICs und AVRs. (16Fxxx, 18Fxxx) Vergleich: - ATmegas takten nicht ganz so hoch, benötigen aber weniger Taktzyklen für einen Befehl. Damit sind sie etwas schneller als PICs (16Fxxx, 18Fxxx). Die 16Fxxx haben zudem keine Hardware-Multiplikation. Berechnungen werden daher aufendig(Codegröße, Laufzeit). - ATMegas kosten sehr viel weniger als PICs. - Für ATmegas gibt es einen kostenlosen C-Compiler. Für die 16Fxxx PICs gibts kostenlos eigentlich nur die Demoversion von CC5. Diese ist zwar sehr gut, aber eben auf 1k Code begrenzt. Damit lassen sich nur kleine Projekte bewerkstelligen. Der SDCC bindet sich nicht in MPLAB ein und scheidet daher für mich aus. - Alle PICs kann man mit zwei Pins in-circuit debuggen. Diese ist nicht bei allen AVRs möglich. Deren JTAG benötigt zudem 4 Pins. - Die Unterstützung ist für PIC und AVR im Internet ziemlich gut. - PICs haben sehr gute/übersichtliche Datenblätter. Bei den AVRs gibts dagegen ein unübersichtliches Fließtext-Datasheet. Das sind wirklich zwei verschiedene Welten. Ich persönlich steige jetzt von PIC auf AVR um. Der Preis und vor allem der freie C-Compiler waren für mich ausschlaggebend. Muss ich mich halt mit den lumpigen Datenblättern rumärgern ;-)
@Kokosnuss: Hier das gewünschte Fazit: Wenn du diesen uralten Thread aufmerksam durchgelesen hast, wirst du festgestellt haben, dass, solange du selber die Wahl hast, es fast Jacke wie Hose ist, ob du mit AVRs oder PIC arbeitest. Wenn nicht einer der genannten Vor- oder Nachteile für dich persönlich ein besonders hohes Gewicht hat, nimmst du am besten den, bei dem dir das Firmenlogo besser gefällt ;-) Wenn du Support speziell aus diesem Forum hier erwartest, bist du vielleicht bei den AVRs etwas besser aufgehoben, da sich hier die Mehrzahl der Leute offensichtlich auf den AVR eingeschossen hat. Deswegen gibt es hier ein auch paar gute Einsteiger-Tutorials für AVRs, und Fragen werden i.Allg. sehr schnell beantwortet. Das heißt aber nicht, dass du mit einem PIC alleine gelassen wirst. Du wirst aber sicher woanders im Netz Foren finden, die PIC-lastiger sind. Igor Metwet schrieb: > PICs haben sehr gute/übersichtliche Datenblätter. Bei den AVRs gibts > dagegen ein unübersichtliches Fließtext-Datasheet. Das sind wirklich > zwei verschiedene Welten. Sind die AVR-Datenblätter wirklich so schlecht? Ich komme eigentlich sehr gut damit zurecht, habe immer schnell die Informationen gefunden, die ich suchte, und die praktische Umsetzung (bspw. ADC- oder Timer-Programmierung) hat dank der präzisen Schreibweise fast immer auf Anhieb funktioniert. Die mir bekannten DBs von C16x und diversen 8051-Derivaten sind nicht besser, die PIC-DBs müsste ich mir mal anschauen.
Vielleicht ist das AVR Datenblatt nur für mich schwerer zu lesen. PIC-Datasheets sind so aufgebaut, dass man z.B. beim AD_Wandler-Kapitel sofort alle wichtigen Register sieht. Darunter wird jedes Register aufgeführt und jedes Bit, bzw. dessen Funktion beschrieben. Das ganze ist optisch gut sortiert aufgebaut. Danach kommt noch ne "Checkliste" was man alles einstellen muss. Das ist bei AVRs zwar auch so ähnlich, allerdings ist die Übersichtlichkeit bei microchip -meiner Meinung nach- deutlich besser. Mit der Zeit und Routine kommt man aber wohl mit allen Datenblättern zum Ziel - bin da optimistisch ;-)
Danke an euch. Ich habe mir bereits ein paar schaltungen angeguckt. Die sehen ja allgemein nicht kompliziert aus. Zwar sind mit die verschiedenen werte von den einzelden kondensatoren und überhaupt der grund warum die da eingesezt sind nicht ganz ersichtlich, aber das kommt wohl mit der Zeit. Jedenfalls danke :)
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.