Hi, immer noch bei der Entscheidung für einen µC. Hab mir das AVR Datenblatt angeschaut und sieht schon ziemlich beeindruckend aus im Vergleich zum SX nur z.B. der ADC Wandler oder der PWD Ausgang. Gibt es echte Nachteile oder ist es für den Hobbybereich der ideale Prozessor. Gibt es den AVR auch mit mehr als 20Mhz? (Hab aber noch kein gefühl dafür wie viel MHz man bei µC wirklich braucht, komme halt aus der 32.Bit Welt. Gruß Thomas
Nachteile vom AVR sind, dass es keinen mit mehr als 4kByte SRAM gibt. Dann muss man extern einen Speicher dranhängen. Wenn man viel mit großen Zahlen (32bit aufwärts) rechnet, dann wird es ziemlich langsam, aber das ist halt bei allen 8bit Controllern so. Davon abgesehen reichen die 20MHz eigentlich für nahezu alles aus, wenn man nicht gerade irgendwelche komplexen DSP Sachen oder ähnliches vorhat. Ich denke vom Preis her sind die im 8bit Segment eindeutig günstig.
Ich persönlich habe kaum Gründe gegen einen AVR. Ich hab mal auf PICs angefangen bin dann auf AVRs umgestiegen und habs nie bereut. Hier gibts ein super Forum mit super Unterstützung für AVRs! Soweit ich weiß gibts keine AVRs mit mehr als 20 MHZ, aber für den Großteil der Hobbyprojekte mehr als ausreichend. Schau Dir doch mal die Projekte an die mit AVRs geacht werden : Webserver, Bilderrahmen, Steuerungen, X-Ufo-Steuerungen und und und
Hab mir mal kurz den SX angeschaut. Für mich käm der schon wegen den fehlenden Hardwereschnittstellen nicht in Frage, kein SPI, TWI, ADC, UART, PWM, etc
Wenn Du aus einer anderen Welt bist (32 Bits), dann bleibt doch dort ;-) AVRs sind klein und handlich, und wenn sie zur Lösung des Problems ausreichen auch in Ordnung. Wichtig für Dich sollte sein, daß sie für Deine Anwendung ausreichen. Insbesondere Timer, I/O, ... können sehr wichtig sein. Wenn Du aber nicht kleckern willst, dann wäre auch ARM eine Alternative, um damit zu spielen. Die beschränken einen nicht durch kleine Speichergrößen oder zu kleinen Adressraum. Viel teurer sind sie auch nicht.
Mist, hätte ich doch nachschauen und 8k schreiben sollen. Aber selbst das ist manchmal wenig, 32kB wären teilweise schön (für Webserver usw.)
Als kommende Alternative zwischen ARM und üblichen AVRs bietet sich vielleicht der ATXMEGA an, der möglicherweise schon auf der embedded world vorgestellt wird...? :)
>möglicherweise schon auf der embedded world Ja, alle fahren hin, in der Hoffnung das er kommt und dann wirds doch nix. Bis der XMega auf dem Markt ist wird sich der OP bestimmt schon entschieden haben und ist bis dahin ein Hervorragender AVR-Programmierer ;-)
>Bis der XMega auf dem Markt ist...
Mal kurz anfassen würde mir schon reichen... und dann schnell weg damit!
;-)
Benedikt K. wrote: > Mist, hätte ich doch nachschauen und 8k schreiben sollen. Ist mittlerweile auch Schnee von gestern. Guck dir mal das part description file ATmega1284P.xml im letzten AVR Studio an... der hat 16 KiB.
@Jörg Wunsch: Was sagt denn Deine Glaskugel bezüglich der Verfügbarkeit von AVR32UCxxx Controllern? Die haben mehr Speicher, sind schneller als die 8-Bit-AVR's. Jens
der ad wandler ist vielleicht für manche sachen ein bißchen langsam. dann kann man zwar wunderbar per spi einen externen dranhängen, aber so richtig einfach ists dann nimmer und es wird teurer. ob das bei anderen µC der preisklasse anders ist bezweifel ich aber. ansonsten finde ich die dinger ganz gut. eigentlich sogar sehr gut.
Hab mir grad mal die verschiedenen Typen und Preise bei Reichelt angeschaut. So wie es aussieht ist der ATMega 32L8 für 4€ doch wohl ideal wenn ich noch nicht abschätzen kann wieviel Ressourcen ich brauchen werde oder? Gruß Thomas
Die getrennten Adressräume für ROM und RAM sind bei der C-Programmierung (zumindest mit GCC) lästig.
Wie macht sich das bemerkbar? Sollte doch selten vorkommen dass ich per pointer arithmetik von ROM nach RAM will oder?
Der Befehlssatz ist zwar tausendmal komfortabler als der eines PIC, birgt allerdings auch einige Ärgernisse für den Assemblerprogrammierer- denn er könnte wesentlich einheitlicher und konsistenter sein. Verschiedene Befehle sind (aus Anwendersicht völlig unverständlich) auf eine Teilmenge der allgemeinen Register beschränkt. Sowas einfaches wie lade Register 7 mit einem Integerwert geht zum Beispiel nicht- nein, es muss schon Register 16-32 sein. Dazu diese Beschränktheiten beim Zugriff auf I/O Register. Bitadressierbar etwa sind die wenigsten (beim 2560 noch nicht einmal alle Ports) und dann ist ja da auch noch diese dumme Unterscheidung, für den Zugriff IN/OUT oder aber wieder LDS/STS nehmen zu müssen. Na ja, da könnte man wohl noch einige Ärgerisse mehr hinzufügen oder aber gleich noch einige schmerzlich vermisste Instruktionen. Der Assemblersatz eines Z80 war doch irgendwie sympathischer :-) Nun gut, den C-Programmierer wird's wenig interessieren. Und für den Assemblerfrek gibts wohl heutzutage keine ernstzunehmende bessere Alternative in dieser 8-Bit Leistungsklasse, oder? Egon
Jens wrote: > Was sagt denn Deine Glaskugel bezüglich der Verfügbarkeit von > AVR32UCxxx Controllern? Da habe ich keine Idee. Ich hätte auch gern einen UC3. ;-) > Die haben mehr Speicher, sind schneller > als die 8-Bit-AVR's. Naja, ein ganzes Stück schneller, aber eben auch energiehungriger.
Von den MHz alleine solltest du dich aber nicht leiten lassen. Auch wenn die AVR nur bis 20MHz gehen, so gibt es doch nur einen Teil der Befehle, welche mit 1-2 Takten auskommen. Viele Befehle benötigen 3-4 Takte. Die PICs z.Bsp. gibt es zwar bis 48MHz (oder noch mehr?), die teilen den Takt aber immer durch vier, so das 48MHz eigentlich nur 12MHz entsprechen. Allerdings gibt es beim PIC fast keinen Befehl mit 3 oder mehr Zyklen. Ein CALL benötigt beim ATmega32 4 Takte, was bei einem Takt von 20MHz also 5 MIPS entsprechen würde. Der selbe Befehl bei einem PIC 18F2550 benötigt nur 2 Zyklen, was 8 Takte entspricht. Daraus ergeben sich 6 MIPS. Bei anderen Befehlen ist es anders herum. Daraus ergibt sich, dass ein PIC mit 48MHz vermutlich genau so schnell ist wie ein AVR mit 20MHz (zumindest ist das meine Meinung). Sven
@egon. Das mit den Registern beim AVR ist auch ein Grund, warum ich bis jetzt bei den PICs geblieben bin. Dort gibt es keine Unterscheidung zwischen Register und RAM (es sei denn man sieht als Register nur das W an). Für mich ist der gesamte RAM Register und ich muss die Werte nicht erst aus dem RAM in ein Register kopieren. Finde ich persönlich irgendwie einfacher. Sven
@Jörg Wunsch:
>Naja, ein ganzes Stück schneller, aber eben auch energiehungriger.
Ich habe jetzt keine Zahlen zur Hand, aber ist das so deutlich?
Irgendwie habe ich noch im Hinterkopf das die gemessen an der
Leistung doch ziemlich gut dastehen sollen. Falsch aufgeschnappt?
Jens
@Sven Ja, da hast Du natürlich recht. (Fast) alles mit allem machen zu können vereinfacht immer ganz enorm und spart so manchen Blick ins Datenbuch und auch viele Fehler. Egon
Thomas Burkhart wrote: > Gibt es echte Nachteile - Kein ROM im Datenadressraum. Folglich sind konstante Daten (Strings, Tabellen) nicht mit normalen Datenadressen erreichbar und machen entweder spezielle Compilererweiterungen erforderlich - oder umständliche und fehlerträchtige Programmierung (GCC, weils da nicht anders geht). Kann auch zur Folge haben, dass manche Funktionen mehrfach implementiert werden müssen, ja nach Adressraum des Parameters. Besser: MSP430 als Beispiel für alle von-Neumann-Typen mit nur einem Adressraum. PIC30, obwohl Harvard-Typ, weil Microchip pfiffig genug war, ROM in die ungenutzte obere Hälfte des Datenadressraums einzublenden. Was bei AVRs grundsätzlich auch möglich gewesen wäre, aber anscheinend auch bei dem MegaX nicht realisiert wird. - Interrupt-feste Modifizierung von Bits in Port- und Steuerregistern geht ohne Abschaltung der Interrupts nur in den ersten 32 Adressen, und auch dort nur für Einzelbits. Die dafür nötigen AND/OR-Operationen auf die I/O-Adressen fehlen RISC-typisch weitgehend. Besser: So ziemlich alle anderen machen das besser. Sogar bei ARMs, die dank RISC ein ähnliches Problem haben, wird das mehr oder weniger konsequent über speziell konstruierte Portregister abgefangen, aber in jeder Familie anders.
Jens wrote: >>Naja, ein ganzes Stück schneller, aber eben auch energiehungriger. > Ich habe jetzt keine Zahlen zur Hand, aber ist das so deutlich? Ja, wenn du die höhere Taktfrequenz denn auch benutzen willst. Aber wenn du das nicht willst, kannst du auch bei den ,,Kleinen'' bleiben. > Irgendwie habe ich noch im Hinterkopf das die gemessen an der > Leistung doch ziemlich gut dastehen sollen. Das schon.
Andreas Kaiser wrote: > Was bei AVRs grundsätzlich auch möglich gewesen wäre, aber anscheinend > auch bei dem MegaX nicht realisiert wird. Naja, der Grund für Harvard ist ja, dass man Daten- und Adressbus trennen kann und damit parallel zugreifen. Genau das geht bei Datenzugriffen in den ROM nicht mehr, weshalb sie zwar auch bei Harvard möglich sind aber langsamer.
Jetzt bekomme ich wieder Zweifel gegenüber den AVRs, der TI sieht wirklich nett aus. Hilfe!!! Wer kann das wirklich beurteilen?? Kann es sein, dass es derzeit für den AVR mehr freie Tools gibt?
Thomas Burkhart wrote: > Hilfe!!! Wer kann das wirklich beurteilen?? Das kann man erst dann, wenn Du mal erzählst, was Du damit machen willst. Die AVRs kann man z.B. an ner Batterie von 1,8V..5,5V direkt ohne Spannungsregler betreiben, was auch ganz nett ist. Oftmals wird übersehen, daß Spannungsregler auch nen Stromverbrauch haben. Die hochgezüchteten Boliden brauchen dagegen oft ne eng tolerierte gut stabilisierte Spannung. Peter
Also was freie tools angeht ist der AVR spitze, ich kann mit meinen gewohnten tools ala gcc, make, ... arbeiten, optimal. Fuer mich immer ein Killerargument, da ist man schneller und produktiver.
Jörg Wunsch wrote: > weshalb sie zwar auch bei > Harvard möglich sind aber langsamer. Klar. Aus Sicht des Hardware-Entwicklers kann ich das durchaus verstehen. Es wird komplizierter wenn der Befehlszyklus vom Wert der Adresse abhängt. Wobei Microchip das anscheinend ohne Verzögerung hinbekommt. Aber der Befehlszyklus vom PIC30 ist ohnehin ein Kuriosum. Der einzige mir bekannte Prozessor, bei dem mal ein überflüssiges Ergebnis in den Speicher schreibt um es kostengünstig zu entsorgen (ein Vergleichsbefehl ist ein Subtraktionsbefehl, der sein Rechenergebnis in den Stack schreibt).
Ich überleg eher das da zu benutzen: http://www.westerndesigncenter.com/wdc/w65c265s-chip.cfm Nur, 25 Dollars nur wegen 6502/65816-kompatibel ist nicht von Pappe, da lohnt sich schon ein kleiner FPGA und der T65 Core im 65816 Modus.
Thomas Burkhart wrote: > Jetzt bekomme ich wieder Zweifel gegenüber den AVRs, der TI sieht > wirklich nett aus. Lass dich von mir nicht kirre machen. Letztlich haben alle ihre Vor- und Nachteile. So hat MSP430 zwar eine wundervolle angenehm zu programmierende Architektur. Leidet aber andererseits unter bastelunfreundlichen Gehäusen, 5V-Inkompatibilität und geringer Funktionalität besonders der kleinen Modelle. Und der GCC für AVR scheint mit deutlich besser gepflegt zu werden, als der für MSP430. Unter dem Strich schneidet daher AVR im unteren Sektor ziemlich gut ab. Aber hat eben auch seine schwachen Seiten.
Ohne gleich wieder einen Klassenkampf generieren zu wollen nur eine kurze Anmerkung: Mit PICs kannst Du vom Programm aus das (Flash-)ROM relativ einfach lesen und es auch (neben dem RAM und dem EEPROM) neu beschreiben. Für Datenmengen bis ca. 50k-Byte kann das sehr konfortabel sein.
Ein (meiner Meinung nach) großer Vorteil der AVRs ist, dass diese relativ Fehlertolerant sind. Wenn man da mal ein Bit, das eigentlich als Reserved beschrieben wird setzt, dann funktioniert es trotzdem. Bei anderen Controllern bekommt man dann die merkwürdigesten Fehler, quer durch die Peripherie, vor allem sind auch solche Sachen betroffen die mit dem falsch gesetzen Register rein garnichts zu tun haben. Und dann ist erstmal Fehlersuche angesagt, die teilweise recht lange dauern kann. Weiterhin haben die AVRs meiner Meinung nach relativ wenige Bugs, naja, zumindest die älteren wie mega8, 16, 32 usw. Gleiches gilt für die recht gute Dokumentation: In jedem Abschnitt ist die Funktion ziemlich ausführlich erklärt, dann kommen die Register und oft noch Beispiele in C oder Asm. In diesem Punkt finde ich, dass z.B. die dsPICs eine absolute Katastrophe sind. Eine Datasheet von jedem Controller in dem alle Features nur kurz angeschnitten werden, aber ausführlich (für alle unterschiedlichen Controller) nochmals in extra Datenblättern erklärt sind, ist absolut nervig, da man schnell bei einem falschen Controllertyp ist. Weiterhin stört mich an denen dass ich einige Funktionen nicht richtig zum Laufen bekomme, was an Bugs in den Librarys oder im Compiler liegt, oder auch an der teils unvollständigen Dokumentation. Sowas sollte man auch bedenken. In dieser Hinsicht sind z.B. die AVRs sehr viel besser.
> Mit PICs kannst Du vom Programm aus das (Flash-)ROM > relativ einfach lesen Das geht bei fast allen Controllern, darunter allen leidlich aktuellen AVRs. Die Frage ist also nicht, ob man an solche Daten lesend rankommt sondern wie. Mit normalen Datenbefehlen (MSP430), oder mit speziellen Befehlen (AVR,PIC).
Benedikt K. wrote: > Eine Datasheet von jedem Controller in dem alle > Features nur kurz angeschnitten werden, aber ausführlich (für alle > unterschiedlichen Controller) nochmals in extra Datenblättern erklärt > sind, ist absolut nervig, Da wirst du mit dem MSP430 auch nicht warm werden. TI macht das genauso. Da steht im Datasheet drin, das sei ein Timer vom Typ "A", und in der Referenz der Gesamtfamilie sind dann die diversen Timer-Typen ausführlich dokumentiert. Denke aber, das ist Gewöhnungssache.
> Jetzt bekomme ich wieder Zweifel gegenüber den AVRs, der TI sieht > wirklich nett aus. Dann fang doch morgen einfach einen neuen Thread namens "Gründe gegen einen MSP" an ;-) Oder: Buddelst du nur lange genug, wirst du für jeden Controllertyp beliebig viele Nachteile finden. Bei jeder Chipentwicklung müssen Kompromisse eingegangen werden, da sich Geschwindigkeit, Stromverbrauch, Speicherkapazität, Umfang der On-Chip-Peripherie und Herstellkosten nun mal nicht gleichzeitig optimieren lassen. Bei den AVRs habe ich zumindest den Eindruck, dass die genannten Nachteile nicht "fahrlässig" entstanden sind, sondern bewusst in Kauf genommen wurden, um nicht an andere Stelle deutlich größere Abstriche machen zu müssen. Andere Frage: Wie lange hast du denn in der 32-Bit-Welt gebraucht, um /den/optimalen Prozessor/Controller für dich zu finden?
Ich gehe mal davon aus, dass hier die XMega gemeint sind: http://www.atmel.com/corporate/embeddedworld2008.asp?source=home "A New Member of the AVR® Family" Also Stand besuchen und jemanden schütteln. :-) Und die UC3 sollen wohl angeblich noch im 1. Quartal 2008 verfügbar werden. Wo mein EVK1101 schon seit August oder so "rumliegt".
Ein Manual der XMegas ist schonmal irgendwo aufgekreuzt. Die o.A. Problematik der I/O-Ports wurde immerhin adressiert, es gibt wie bei diversen ARMs nun Register für Bitsetzen und solche für Bitlöschen. Ansonsten erinnert mich das eher an 8051 mit 1MB-Speicher - nett gedacht, vor allem wenn man nix anderes kann als AVR, aber 32-Bitter können sowas besser.
Ich habe bisher mit 16F und 18F-PICs gearbeitet und war rundum zufrieden. Jetzt habe ich ein Projekt, bei dem der Kunde mir mal einen Vertriebler seines Distris ins Haus geschickt hat. Es wird eine BLDC-Motor-Steuerung und da möchte er den kleinsten dsPIC33F verbaut haben - 2€ !!!! Und der kann richtig was ! (3-Phasen-PWM für 3 Halbbrücken bei genügend MHz...) Leider muß ich jetzt in C programmieren, weil die anderen Tools, die ich sonst verwende (BASIC) noch nicht den Prozessor unterstützen. Welcher I**** hat denn C erfunden ? Und welcher SM-Bruder verwendet diesen Mist auch noch für uCs (Jeder Befehl/Zugriff ist eher eine Ausnahme als die Regel) ? Also - grauenhafte Syntax ! Hätte vor Jahrzehnten schon verboten gehört, gleich mit den passenden Lochkarten, Fortran und ALGOL. Da lob ich mir mein BASIC mit Assembler-Support ohne Linker. !! Jedenfalls hat mein Kunde auch mal AVRs eingesetzt. Sollte da heute noch einmal jemand den AVR vorschlagen wird er gekündigt oder des Hofes verwiesen. Für einen industriellen Einsatz ist es nicht spaßig, daß uCs ohne Ankündigung einfach nicht mehr produziert werden oder der Hersteller einfach gar keinen Support liefert bei Bugs im Silizium (und das sogar bei einem großen Kunden). Der ist mit dem Thema durch und setzt nur noch Microchip für Neuentwicklungen ein. Bei meinen bisherigen Projekten konnte ich immer alles realisieren, auch die Speed reichte völlig (Ich kann in Assembler und meinen PicBasic Pro sehr effektiv programmieren, weil ich es schon länger mache und noch weiß, was ein Prozessor bei einem bestimmten BASIC-Befehl machen muß). Betriebssicher bis zum Umfallen, Alle Prozessoren in allen Gehäusen (auch genügend DIPs für die Bastler und Prototypen!). Aber - keine Frage - die 16Fs sind schon eine Plage für den Assembler-Programmierer und werden auch den C-Compiler ärgern. Das ist aber alles Käse von gestern - so wie der EEPROM-Bug bei den alten AVRs.
Für einen Bastler ist BASIC ja vollkommen okay, aber wenn es profesioneller sein soll muss man schon C beherschen. Weil C ist einfach Standard, schließlich gibt es für fast jede Plattform einen C compiler und der Code ist dadurch sehr portabel. BASIC ist total unportabel, non-standard und meistens auch langsam (kommt ja nicht immer drauf an). Ich hab mal PICs (18er) und AVRs verglichen, hab bisher nur AVRs benutzt - wenn man die Datenblätter mal durchgeht sieht man, dass es eigentlich nicht viele Unterschiede zwischen der Peripherie gibt. Ich fand ein paar features der PICs sogar noch besser realisiert als beim AVR. Ich vermute mal AVRs sind für C compiler besser geeignet, weil ein C compiler möglichst viele Register braucht und nur schlecht mit einem Arbeitsregister zurecht kommt. Was ich am PIC gut finde ist, dass er in assembler einfach zu programmieren ist (besonders bei den kleinen Typen, bei denen man kaum Platz für ein großes C Programm hat). Ich vermute mal beide haben so ihre Nachteile, aber im grunde kann man alles was man mit einem AVR realisieren kann auch mit einen PIC realisieren - oder?
C und portabel ? Bei uCs sind die Funktionen eher in der Hardware an bestimmte Register und Bits statt an Software gebunden. Da portiert man nix vom AVR zum PIC oder MSP, 8051 oder so, da schreibt man quasi alles neu ! Bei C verliert man ja noch schneller den Überblick, was der Compiler erzeugt, als bei meinen niedlichen Basic. Wenn ich mir da die Beispiele für den dsPIC32 ansehe, dann werden da mal richtig die Hardware vom DSP eingesetzt, den portiert man dann gar nicht ohne Anpassung. Befehle in C gibt es dafür gar nicht und einheitliche LIBs auch nicht. Ich kann es verstehen, wenn man am PC einheitliche Schnittstellen definiert und Libs schafft, die von allen Routinen genutzt werden können - aber - am uC scheitert das durch die Beschränkung des Einsatzes und es wird doch wieder umgeschrieben etc. pp. C gibt es einfach für jeden uC, weil es einfach die Grundlage für die Nutzung des Prozessors bildet, weil es einfach nach dem "Guß" des Siliziums immer einen angepaßten C-Compiler gibt, der den richtigen Code rauswirft - Optimierungen mal außen vor. C hat es auch schon immer gegeben, evtl. auch nur aus diesem Grund. Das erste, was es für einen neuen Prozessor gibt, ist C! C beherrschen ? Ich habe eher den Eindruck, das beherrscht mich ! Wenn ich Konstanten verwende, warum nicht #defines ? Und welche (int) oder (unsigned) setze ich vor jeden Wert oder immer oder auch dazwischen, damit die richtigen Wertebereiche erzeugt werden und nicht unnötig umgewandelt werden ? Floats und Strings vermeide ich sowieso - die Libs sind nichts für einen uC ! (da finde ich die signed fracs im dsPIC aber mal richtig gut!) Aber egal, es ging um den besten uC (Flameware is opened!) Jeder findet sich da am besten zurecht, wo er aufgewachsen ist ! Ich bin bei 6502 und auch Z80 angefangen (APPLE ][), habe an pdp8 (mit Schaltern und Lampen wie in alten Filmen) mit der words und pages in Assembler gerungen, habe mal einen MCS-48 bearbeitet (Tastatur-Prozessor in PC-Tastaturen), auch mal einen 8051 programmiert (direkt aus der Steinzeit!), und jetzt nach langer Abstinenz zum PIC gefunden. Ich weiß noch, was ein Byte ist und was es kostet, was eine Multiplikation bedeutet und warum man nicht nach einer ATAN-Funktion fragt, wenn man eine Tabelle anlegen kann.... Aber dem AVR werden ja sehr starke Funktionen nachgesagt. Ich hätte bei den PICs auch gerne mal etwas mehr Funktionen, Timer zur freien Verfügung, INTs-on-Change... Ich habe aber auch das Gefühl, daß die dsPIC33s bzw. PIC33s geschaffen wurden, um den AVRs das Fürchten zu lehren. Die Funktionen sind schon genial. Man hat ja auch einen Prozessor-Kern zugekauft und das eigene Zeugs über Board geworfen... ;-)
Marius Schmidt wrote: > Ich vermute mal beide haben so ihre Nachteile, aber im grunde kann man > alles was man mit einem AVR realisieren kann auch mit einen PIC > realisieren - oder? Du kannst fast alles mit fast allen Controllern machen, es sei denn der Code wird so umständlich, dass er nicht mehr reinpasst oder zu langsam ist. Die Frage ist also eher: Erfüllen die Funktionsmodule (Schnittstellen, Timer, ...) die Anforderungen? Wie umständlich ist die Programmierung in der favorisierten Sprache? Ich persönlich finde beispielsweise Banking schaurig, was mich trotz aller Neugierde zuverlässig davon abhalten dürfte, jemals mit 12- und 14-Bit PICs etwas in Assembler anzufangen. Und mit Microchips Assembler muss man m.E. das Programmieren gelernt haben, um den schön zu finden. Aber hier sind wie genau in den Gefilden des Geschmacks, und um den kann man ewig ohne Ergebnis streiten. Drum: Erst kommen die Anforderungen, dann die Lösung. Nicht umgekehrt. Und so gibt es keine Grosse Optimimale Lösung Für Alles (tm).
Bernd Rüter wrote: > Bei C verliert man ja noch schneller den Überblick, was der Compiler > erzeugt, als bei meinen niedlichen Basic. Eigentlich nicht. Jedenfalls nicht, wenn man selber mal welche geschrieben hat. ;-) > C hat es auch schon immer gegeben, evtl. auch nur aus diesem Grund. Ginge es nach Vernunft, wäre möglicherweise Ada führend. Aber als Ada rauskam, war es für reale Maschinen nicht handhabbar, und als es handhabbar war, war C schon die Universalsprache, so grässlich sie auch ist. Der historische Grund für C: Als in den 80ern die Unis Maschinen, Compiler und Betriebssysteme brauchten, da gab es PDP11/VAX, C und Unix. Diese Maschinen waren bezahlbar, Compiler und Betriebssysteme für Unix entweder kostenfrei oder zumindest günstig. Was man von den Alternativen nicht behaupten konnte (PASCAL gabs zwar auch, war aber in der Urform für praktische Belange unbrauchbar). Und was diese Leute damals mitgenommen haben, damit plagt sich jetzt die ganze Industrie herum. > Man hat ja auch einen Prozessor-Kern zugekauft und das eigene Zeugs über > Board geworfen... ;-) Kann es sein, dass du grad PIC32 (MIPS 32-Bit) und PIC33 (Microchip 16-Bit) durcheinander bringst?
Andreas Kaiser wrote: > Kann es sein, dass du grad PIC32 (MIPS 32-Bit) und PIC33 (Microchip > 16-Bit) durcheinander bringst? Ja!
Marius Schmidt wrote: > Für einen Bastler ist BASIC ja vollkommen okay, aber wenn es > profesioneller sein soll muss man schon C beherschen. Weil C ist einfach > Standard, schließlich gibt es für fast jede Plattform einen C compiler > und der Code ist dadurch sehr portabel. > > BASIC ist total unportabel, non-standard und meistens auch langsam > (kommt ja nicht immer drauf an). > Ich gebe dir insofern recht, dass C einen eindeutigeren und verbreiteteren Standard hat als BASIC. Viele machen aus BASIC eine extra Wurst. Allerdings finde ich gerade im Hinblick auf AVRs das BASCOM BASIC enorm effizient. Man kann einfach mit extrem wenig (selbsterklärendem) Code relativ komplexe Dinge (UART, I2C) implementieren. Und ob eine Sprache langsam ist oder nicht hängt auch damit zusammen wie gut die Hochsprachenelemente in ASM und Maschinencode codiert werden. Das ist auch Sache des Compilers und nicht der Sprache an sich. Da schenken sich BASIC und C praktisch nichts. Ich programmiere schon seit einiger Zeit PICs in C und AVRs in BASCOM BASIC und muss sagen, dass von der Effizienz her BASCOM BASIC mein klarer Favorit ist. Ich finde es ist problemorientierter. Zumindest war es bei mir so, dass ich bei C mehr "Vorarbeit" leisten musste um eine Aufgabe zu verwirklichen als bei BASIC. Aber alles hat Nachteile. Was Mathematik angeht ist BASIC grottig.
>C beherrschen ? >Ich habe eher den Eindruck, das beherrscht mich ! Wenn Du mehr Erfahrung damit hast, wird es bestimmt besser. >Jeder findet sich da am besten zurecht, wo er aufgewachsen ist ! >Ich bin bei 6502 und auch Z80 angefangen (APPLE ][), Wie heist das heute: lebenslanges Lernen Im Alter vertraut man halt eher der Erfahrung, als dem Neuen.
Andreas Kaiser wrote:
> Der historische Grund für C: ...
Ein zweiter: es war die erste, nun ja, ,,höhere'' Programmiersprache,
die auch dafür geeignet war, große Teile des Betriebssystems damit
zu schreiben (und damit in diesem Feld den Assembler abzulösen).
Damit konnte man sowohl System als auch Anwendungen in dieser Sprache
schreiben.
zero wrote: >>Ich bin bei 6502 und auch Z80 angefangen (APPLE ][), > Wie heist das heute: lebenslanges Lernen Nicht nur heute. Das war wohl schon immer so. Lenin wird der Spruch zugeschrieben: ,,Lernen, lernen, nochmals lernen!''. Ich habe auch Z80 unter CP/M in Assembler und Pascal programmiert und (schauder) FORTRAN auf einem RSX-11 kennenlernen dürfen. Es hat mich nicht davon abgehalten, C zu lernen und Unix und das Programmieren von Microcontrollern in mehr als nur dem Assembler, den ich seinerzeit für den Z8 zur Verfügung habe (wobei ich mich heute noch frage, wie ich in diesen damaligen Projekten mit einer einfachen 7-Segment-Anzeige das Debuggen geschafft habe).
Die Wahl der (Software-)Werkzeuge hängt aber auch stark von der Aufgabenstellung ab. Ich programmiere häufig sehr zeitkritische Prozesse. Da bleibt als einzige Programmiersparche dann nur noch Assembler übrig. Mit etwas Übung ist dann selbst eine Division (mit mehreren Byte großen Divisor) kein Problem mehr. Statt über eine schön bunten Programmieroberfläche freue ich mich auch schon mal über einen schnellen und kompetenten Herstellersupport. Ach ja, wenn solch eine Software erstmal läuft, sollten auch die Controller dazu über Jahre ohne Probleme lieferbar sein. Hier gibt es wohl die größten Unterschiede bei den verschiedenen Herstellern.
Ich bin eigentlich ein Fan vom 8051. Die schnellen Deivate von SILABS sind super. So schöne Sachen in Assembler, da kommt ein ARM7 TDMI mit gleicher Taktfrequenz nicht hinterher. Wo der 8081 z.B schreibt
1 | CPL P1.7 |
siehts beim ARM7 so aus:
1 | 0x0008039C E59F0054 LDR R0,[PC,#0x0054] |
2 | 0x000803A0 E5901000 LDR R1,[R0] |
3 | 0x000803A4 E2211502 EOR R1,R1,#0x00800000 |
4 | 0x000803A8 E5801000 STR R1,[R0] |
Also hat das 8051-Derivat bei gleicher Taktfrequenz die Nase vorn. N.B. von Atmel gibt's sogar 8051er mit MP3 Decoder.
Ich denke mal ARM war auch nie für Mikrocontroller gedacht, sondern eher für Spielkonsolen und andere Consumer Geräte. Also ich kann mir grade nicht wirklich vorstellen mein GP2X mit irgendwas anderem als wie dem verbauten ARM7 Doppelkern zu nutzen.
naja aber so ein arm7 ist schonmal eine ganz andere architektur... das teil ist superskalar, ist 32-bit und ein RISC... dein 8051 ist alles andere als RISC.. und RISC/CISC dirskussionen bringen nix weils da einfach von der anwendung abhängt, was schneller ist... ich staune noch immer wie schnell mein g4-ibook ist... obwohls nur bei knapp 700Mhz läuft... wenn du nur 8bit zahlen herumschiebst und bit-banging machen willst, bringt dir ein arm überhaupt nix... der ist sogar verdammt langsam wenn er einzelne pins setzen/lesen muss... wenn du aber mp3 auf dem ding in software decodieren willst wirds nicht wirklich probleme machen... aja.. so ein avr auf 16mhz und 5V braucht gleich viel strom wie ein arm7 bei 64Mhz der braucht dafür 3.3V (und 1.8 wenn er nicht den regler eingebaut hat) wo wir wieder beim thema "wie einfach kann ich damit arbeiten" wären ;) avr+irgendwas zwischen 1.8 und 5.5V (wenn die neuen stromspar-teile sind.. sonst sind 3V min) und das ding rennt... (wenn man den interenen oszillator einschaltet... ein arm braucht schonmal recht genau eine spannung(en) und der 8051 kommt dank seiner "der akku kann alles"-architektur einem avr nicht das wasser reichen (wenn sie gleich schnell takten)... so jetzt ist aus mit OT... was nehmen.. 8051, pic, arm, avr, msp430... 8051 ist glaubich unbestritten die meisten code-beispiele, compilier,... dafür ist die archtiktur nicht zeitgemäß... alleine schon die tatsache, dass du portpins nicht auf input schalten kannst oder tristate oder pullup,... zum pic will ich nix sagen weil ich ihn nicht gut genug kenne.. aber zumindest bei den compilern schauts dort nicht so gut aus.. dafür gibts auch nicht wenig zeug im netz... arm sind nett, schnell, günstig und es gibt gute compiler unterstützung.. dafür darfst du dich auf die suche nach einem linker-script, startup-code usw für deinen arm7 machen.. weil arm7 ist nicht arm7 zumindest wenn du einen lpc von nxp oder einen von atmel nimmst gehts eigentlich ganz brauchbar... ;) der msp von TI ist für mich absolutes neuland.. ich hab mir mal die datenblätter angeschaut.. klingt gut.. bei uns auf der uni habens dazu nur gesagt, dass man sich mit den dingern im EMV-Labor richtig probleme einhandelt... ein bisserl ESD und tot ist er... dann noch der avr.... hat alles was man sich wünscht.. schnell, günstig, gut unterstützt, und genug doku/libs,... richtig gut zum einsteigen in die 8-bit welt eben ;) 73
Da gibt es einen Microcontroller von Freescale, der STAR 12. Hatte mal die Instruction Set Summary durchgelesen, da gibt's einen Befehl der macht folgendes was ich hier mal versuche zu beschreiben: Eine bestimmte Anzahl von Bit's (beginnend bei Bit0) im Register 1, wird um eine bestimmte Zahl nach links geschoben und in Register 2 eingesetzt. Die Anzahl der Bits und die Anzahl der schiebungen werden im Befehl angegeben. Leider weiss ich nicht mehr, welcher Mikrocontroller es geau war, noch wie der Befehl heisst. :-(
Hans wrote: > zum pic will ich nix sagen weil ich ihn nicht gut genug kenne.. aber > zumindest bei den compilern schauts dort nicht so gut aus.. dafür gibts > auch nicht wenig zeug im netz... Für PIC14 und PIC16 mag das stimmen, aber für PIC18 gibt es den C18 Compiler zum kostenlosen download in der student version auch zur kommerziellen Nutzung kostenlos. Die Limitierungen die nach Ablauf der Probezeit eintreten sind für die meisten wohl nicht von großartiger bedeutung (resultiert nur in schlechteren Code, für den Hobby bastler ist das wohl kein Problem). Hab noch nicht wirklich viel mit dem C18 gemacht, aber ich nehme mal an da er direkt von Microchip ist wird es keine "Frickellösung" sein die sich jemand aus Not zusammengebastelt hat ;) Ausserdem gibt es ja noch diverse BASICs (wenn man sich das antun will), die sind zwar (genau wie beim AVR) auch nicht umsonst aber naja...
Marius Schmidt wrote: > Hab noch nicht wirklich viel mit dem C18 gemacht, aber ich nehme mal an > da er direkt von Microchip ist wird es keine "Frickellösung" sein die > sich jemand aus Not zusammengebastelt hat ;) Sag sowas nicht. Der C30 Compiler ist afaik ein gcc Compiler + Optimierungen von Microchip. Und genau diese machen Problem und erzeugen teilweise unsinnigen, wenn nicht sogar falschen Code.
Jörg Wunsch wrote: ... > Lenin wird der > Spruch zugeschrieben: ,,Lernen, lernen, nochmals lernen!''. War der Anlass dieser Äußerung nicht ein Blick in Walter Ulbricht seine Schul-Zeugnisse? Duck & weg... Zurück zum Thema: Nix ist vollkommen, auch nicht die AVRs. Aber mit ihnen kann man (ich) viele Dinge (kostengünstig) realisieren, auf die man sonst verzichten müsste. Also mir gefallen die kleinen preiswerten AVRs, auch wenn sie noch nicht perfekt sind. ...
@Bernd man kann auch in C "schöner" programmieren, wenn man sich eine entsprechende API baut. Arduino.cc ist dafür ein nettes Beispiel. Die haben unteranderem auch eine Abstrahierungsebene eingeführt, die es theoretisch erlauben würde, andere uCs als die bisher verbauten AVRs einzusetzen (sofern es einen GCC compiler für diese gibt). Und da man trotzdem alles in reinem C (manche Libs sind auch C++) programmiert, kann man sich jederzeit entscheiden statt "digitalWrite(PinX,HIGH)" direkt "PORTX &= (1 << PinX)" zu schreiben - was natürlich Performancevorteile hat, aber eben nicht so "schön" aussieht. Wobei sowas ja relativ ist ... ;-) Ich finde da sieht man jedenfalls gut, das C im Vergleich zu Skriptsprachen in uCs am Ende die flexiblere und portablere Lösung ist.
> Wo der 8081 z.B schreibt
1 | CPL P1.7 |
> siehts beim ARM7 so aus:
1 | 0x0008039C E59F0054 LDR R0,[PC,#0x0054] |
2 | 0x000803A0 E5901000 LDR R1,[R0] |
3 | 0x000803A4 E2211502 EOR R1,R1,#0x00800000 |
4 | 0x000803A8 E5801000 STR R1,[R0] |
> Also hat das 8051-Derivat bei gleicher Taktfrequenz die Nase vorn. So ein schmarn: Äpfel mit Birnen vergleichen. Zum einem gibt's viele ARMs die enstprechende Hardware-Register für Fast-IO haben, so dass das auch zu einem einzelnen Befehl wird. Und wenn wir schon mal bei Äpfel mit Birnen vergleichen sind, mach mal folgendes mit Deinem 8081:
1 | MLA r0, r1, r2, r3 |
Es gilt eben doch wie immer: Das richtige Werkzeug für die Aufgabe!
>arm sind nett, schnell, günstig und es gibt gute compiler >unterstützung.. dafür darfst du dich auf die suche nach einem >linker-script, startup-code usw für deinen arm7 machen.. weil arm7 ist >nicht arm7 zumindest wenn du einen lpc von nxp oder einen von atmel >nimmst gehts eigentlich ganz brauchbar... ;) Wieso Suche nach einem Linker-Skript oder Startup-Code? Wenn man den richtigen Hersteller nimmt, ist das alles nicht nötig. Ich habe gerade mit den ARM-Cortex-M3 von Luminary angefangen. Der Einstieg war leichter als mit den AVRs, da Luminary Startup-Code und Linker-Skript für den gcc liefert und zudem im Gegensatz zu NXP auch eine schöne Peripheral-Library mitliefert (kostenlos natürlich). Dadurch muss man sich zumindest am Anfang nicht mal großartig mit den Details der Peripherie auseinandersetzen. Nach nicht mal einem halben Tag hatte ich FreeRtos laufen, dazu Interrupts für Timer und USART, wobei letzterer über eine Queue gesteuert wurde. Bei einem Neueinstieg in den AVR hätte ich da länger gebraucht (erst recht bei ARM7 von NXP oder Atmel).
Michael wrote: > Ich habe gerade mit den ARM-Cortex-M3 von Luminary angefangen. Der > Einstieg war leichter als mit den AVRs Ich ziehe es vor, mich nicht auf eine Variante zu beschränken. Jenseits von 30-40KB sind mir AVRs zu umständlich - aber wenn man nur Arme oder Daumen zur Verfügung hat, wird Batteriebetrieb leicht zum Problem.
Sollte auch erwaehnt werden: die Verfuegbarkeit einer ausgezeichneten und gut gewarteten Programmierumgebung (AVR-GCC, AVR-lib etc.) war fuer mich das ausschlaggebene Argument fuer die Wahl von AVR - mehr als gleich wichtig wie die hier diskutierten Fragen zur Architektur und Leistung. Ein negativer Aspekt: die Qualitaet der Hardwaredokumentation ist bei - zumindest manchen - AVRs mehr als mangelhaft - viel Papier, in dem trotzdem einiges fehlt, und manches einfach sich als falsch herausstellt. Ich habe mit 2 Gruppen Erfahrung gesammelt ATmega 8/16... eher positiv, und AT90CANxxx eher Mist - sieht zwar beim ersten hinschaun aehnlich gut aus - aber wenn es an Detailfragen geht bekommt man sehr schnell graue Haare (besonders schlechte Erfahrung: die Dokumentation des CAN Subsystems - und hier fehlen auch weitgehend geeignete Application Notes).
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.