Ich hab vor einiger zeit angefangen µC's zu programmieren und damit herum zu experimentieren. Leider ist mir vor kurzem durch irgendwelche unerklärlichen Umstände mein Board mit dem 80C517A (Feger-Board) eingegangen. Nun würde ich gerne auf die günstigeren ATMEL AVR's umsteigen. Auf der Suche nach einem Chip der mir gefalle würde bin ich auf den ATmega8535 gestoßen der mir sehr gefalle würde (bezüglich Ausstattung mit PWM, ADC, Timer, Preis, usw. für zukünftige Sachen). Nun würde ich gerne wissen was ihr von diesem Controller haltet oder ob ihr mir einen anderen empfehlen würdet?? Weiters wäre interessant welches Programmierinterface besser wäre: das parallele oder das serielle?? Ich freue mich schon auf eure zahlreichen kommentare.
Ich mag AVR, sehr angenehm zu programmieren. Es gibt hier aber auch andere Meinungen ->
formatting link
Also erstmal das übliche:
- Datenblätter bei
formatting link
- Gute Seite für Anfänger
formatting link
- GCC-Compiler + Programmiersoftware für Windows
formatting link
Parallele Programmierung geht nur, wenn der Chip nicht in der Schaltung ist. Ist also eher für Massenfertigung gedacht. Die Frage ist also eher seriell (SPI) oder JTAG. Für den Anfang muß es IMO kein JTAG sein.
Falls Du ein fertiges Board kaufen willst, solltest Du Dir den mega128 angucken. z.B
formatting link
formatting link
Habe keines dieser Boards selber benutzt oder auch nur gesehen.
Ansonsten finde ich den mega8 noch ganz knuffig. Ist bei Reichelt aber teurer als der mega8535 ;-(
Mehr Ressourcen haben zum Experimentieren noch nie geschadet. ;-) Nimm das Größte, das Du Dir dafür leisten kannst, nach Möglichkeit also ruhig einen ATmega128. Hast noch paar Portpins mehr, genügend ROM, um Dir auch um Floatingpoint, malloc() und printf() erstmal keine Sorgen machen zu müssen, genügend RAM für den Alltag (und die Möglichkeit, im Gegensatz zum ATmega8535 trotz vorhandenen ADCs auch noch externen RAM dranzuklemmen) usw. usf.
Wenn Du Dir das nicht leisten kannst, dann skaliere nach unten, bis es Dir gefällt. Aber wenigstens ein ATmega16 sollte wohl nicht das Thema sein, oder? Einziger Nachteil gegenüber dem ATmega8535 ist, daß man für 16 KB keine RJMP/RCALL mehr nehmen kann, der avr-gcc schaltet derzeit dann komplett auf JUMP/CALL um, was etwas Platz verschwendet. Ein identisches Programm fällt damit also größer aus als auf einem ATmega8535.
Wenn Du das Board für den TQFP des ATmega128 nicht selbst machen willst und das Dein einziges Argument ist zugunsten eines kleineren AVR, der noch als DIL erhältlich ist: Experimentierplatinen werden vielfältigst angeboten für AVRs, auch unbestückt. Keine Angst vorm SMD-Selbstlöten, das ist weniger schlimm, als es auf den ersten Blick aussieht. Du mußt es ja nicht gleich übertreiben und ein BGA-Gehäuse selbst löten wollen wie Georg Acher. ;-)
Parallel braucht kein Mensch mehr bei den heutigen Chips. Ganz zu Anfang gab's noch Chips, bei denen man bestimmte Fuses nur parallel manipulieren konnte, aber das ist bei den aktuellen AVRs Vergangenheit.
--
J"org Wunsch Unix support engineer
joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/
In article , snipped-for-privacy@gmx.at says... ...
...
Michael,
Ich würde den 8535 nicht nehmen. Atmel hat schon angekündigt, das dieser in absehbarer Zeit eingestellt wird (end of life). Mir gefällt der Mega8 sehr gut, er ist günstig, hat aber trotzdem die volle ausstattung (adc, pwm, timer, etc). Auch ist er im DIL gehäuse erhältlich, was zum Hausgebrauch einfach zu löten ist. Ich programmiere ihn mit Ponyprog und einem Simpel-Interface (1 Transistor + 3 Widerstände).
Eine sehr gute Auskunftsquelle: ist
formatting link
Markus
--
Markus Baertschi Phone: ++41 (21) 807 1677
Bas du Rossé 14b Fax : ++41 (21) 807 1678
CH-1163, Etoy Email: markus@markus.org
Switzerland Homepage: www.markus.org
"Markus Baertschi" schrieb im Newsbeitrag news: snipped-for-privacy@News.CIS.DFN.DE...
einem
sehr
für
Controller
Hallo richtig, 8535 ist abgekündigt, aber nicht der MEGA8535
Ich würde auch lieber etwas größere nehmen, ich versuche gerade die Software für ein Motortestgerät in ein Mega8535 zu kriegen, ...wird verdammt eng. Ich benutze aber auch nur Bascom AVR , mit AVR-GCC würde es bestimmt kleiner, oder ?
Da hast du recht. Die beiden recht vergleichbar bis auf die etwas mehr pins des 8535 und dem entsprechend gösseren Gehäuse.
Ich glaube nicht. Der GCC-compiler is nicht schlecht, nützt aber nicht immer alle features des AVR optimal aus. Da kommt schon mal etwas Ballast zusammen. Wenn du kompakten Code brauchst bist Du mit einem der kommerziellen Compiler besser dran (Imagecraft, Codevision). Das ist jedenfalls den Eindruck, den ich nach 2-Jährigen mitlesen auf AVRFreaks habe...
Markus
--
Markus Baertschi Phone: ++41 (21) 807 1677
Bas du Rossé 14b Fax : ++41 (21) 807 1678
CH-1163, Etoy Email: markus@markus.org
Switzerland Homepage: www.markus.org
Ist die Frage, ob Du erstmal eine Experimentierplatine haben willst und danach dann die, mit der die Motorsteuerung tatsächlich laufen soll. Zum Experimentieren ist ein großer Controller immer praktisch, für eine Serienproduktion kann man das dann optimieren, wenn alles erst einmal tut, was man sich vorgenommen hat. Wobei die Frage ist, ab welcher Seriengröße es sich denn überhaupt rechnet, die jeweils kleineren Chips zu benutzen. So riesig sind ja bei Mengenabnahme die Preisunterschiede ohnehin nicht, die Kosten für die Software und das Board dürften bei kleinen Stückzahlen allemal überwiegen.
Keine Ahnung, wie gut Bascom's Compilate und Organisation der Bibliothek ist.
--
J"org Wunsch Unix support engineer
joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/
Das deckt sich überhaupt nicht mit dem, was ich als Eindruck gewonnen habe. Zu beachten ist dabei übrigens, daß gerade auf AVRFreaks eine Menge and DAUs herumlungern, da sind Leute dabei, die nichtmal die simpelsten Grundlagen der Programmierung oder von C beherrschen und dann erwarten, daß ihnen alles löffelfertig vorgesetzt wird. Solche Leute sind wahrscheinlich in der Tat mit einem kommerziellen Compiler besser bedient, wenigstens belasten sie dann deren Support stattdessen. :-))
Die Kommerziellen glänzen mit schicken GUIs, in die alles verpackt ist, keine Frage, während ein gcc von Haus aus sowas nicht mitbringt (gehört ja auch nicht zum Compiler). Aber Entwicklungsumgebungen, an die man einen Kommandozeilencompiler anflanschen kann, gibt's einige, Eric Weddington liefert mit WinAVR das Programmer's Notepad mit, das er offenbar selbst bevorzugt. Ich habe mich in über 10 Jahren an den Emacs gut genug gewöhnt und muß mich nicht mehr umstellen, egal ob ich einen AVR programmiere, eine email oder diesen Newsartikel schreibe, irgendwas in meinem FreeBSD programmiere oder einen Brief in LaTeX schreibe. So hat jeder seine persönlichen Vorlieben.
Der gcc leidet im Umfeld des AVR ein wenig darunter, daß er praktisch ausschließlich auf eine von-Neumann-Architektur orientiert ist, so daß in einer Harvard-CPU die verschiedenen Speicherbereiche nicht ohne weiteres adressiert werden können. Die kommerziellen Compiler haben dies von vornherein berücksichtigt und können daher leichter mit Konstanten im ROM oder Daten im EEPROM umgehen. Wenn ich mir allerdings die Verrenkungen in Atmel's AVR butterfly Code ansehe, die dann teilweise doch noch zu machen sind, um den Compiler davon zu überzeugen, daß vielleicht ein bestimmter Tabellenzugriff jetzt als ROM und nicht als RAM gemeint ist, dann bin ich mir mittlerweile da gar nicht mehr so sicher, ob man das wirklich uneingeschränkt als Vorteil ansehen sollte. Beim avr-gcc muß man halt die ROM-Zugriffe explizit selbst vornehmen, dafür bekommt man dann immer exakt das, was man aufgeschrieben hat. (Der generierte Code dürfte sich kaum unterscheiden, auch der IAR muß ja am Ende [E]LPM Befehle dafür benutzen.)
Von den Kommerziellen dürfte der IAR eindeutig die Nase vorn haben, kein Wunder, wurde und wird dieser Hersteller von Atmel seit eh und je bevorzugt (und durfte bereits beim CPU-Design mitwirken, um es besser hochsprachentauglich zu machen -- aber davon haben zum Glück alle Compiler etwas). Der IAR hat einige Optimierungen, die in der Tat ein gutes Stück besser sind als der avr-gcc, insbesondere kann er JMP/CALL durch RJMP/RCALL ersetzen, was halt gerade bei 16 KB Chips einiges an Ersparnis bringen kann. (Allerdings hat Denis Chertykov vorgestern auf der Mailingliste geschrieben, daß der GNU Linker das auch könnte, er hat nur keine Zeit, das gerade zu implementieren. Wird aber sicher nur noch eine Frage der Zeit sein, bis das jemand anpackt. Möglicherweise wäre gcc damit sogar besser als IAR, da ich bei IAR den Eindruck habe, daß dort diese Optimierung nur auf Compilerebene vorgenommen werden kann. Auf Linkerebene hingegen profitieren auch alle Bibliotheksfunktionen usw. davon.)
Die anderen Compiler sind dem Vernehmen nach in der Codegenerierung gleichwertig oder eher ein bißchen schlechter als avr-gcc.
--
J"org Wunsch Unix support engineer
joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/
Oder schau Dir mal die MSP430-Familie von Texas Instruments
formatting link
(auch bei reichelt) an. In Bezug auf die "Rechenpower" wohl etwas schwachbrüstiger als die AVR's (imho aber voll ausreichend) dafür aber Weltmeister im Stromsparen, z.B. eine ständig mitlaufende Uhr (real time clock) kann man mit 2-3uA Stromverbrauch realisieren, PWM, ADC usw. auch alles drauf. Als Parallele zum 8535 kann man wohl den MSP430F133 betrachten. Kann per Boostraploader über eine normale RS232 programmiert werden, JTAG ist auch vorhanden, C-Compiler MSPGCC ...
Es gibt Dutzende von Applicationnotes (siehe Website) samt Beispielen, etliche Veröffentlichungen und Freewareprojekte. Ist zwar nicht ganz so umfangreich wie beim AVR, aber doch dicke ausreichend. Übrigens der MSP430 wurde urspruenglich in .de entwickelt und irgendwann von ti gekauft (soviel zum Lokalpatriotismus :-).
snipped-for-privacy@despammed.com (Aguja) wrote in :
Ich habe mich damit noch nicht selbst im Detail beschäftigt, in der mspgcc mailingliste war da aber mal eine Diskussion, da hatte jemand ein paar Benchmarks auf beiden laufen lassen und auch Taktzeiten usw durchgerechnet, wobei die Atmegas besser abschnitten. Kann aber auch am damals noch nicht so ganz ausgereiften mspgcc gelegen haben...
Atmel selbst zieht auch einen Vergleich:
formatting link
Der MSP ist also wegen dem maximal möglichen Takt langsamer und braucht angeblich 20% mehr Flashplatz für Programme...; andere "Nachteile" fallen imho nicht ins Gewicht; man kann diese ja auch umgehen ;-). z.B. kein ADC in den 20pol Varianten; na klar per software und den on chip comparator bekommt man sogar 12bit hin; die JTAG fuse brauch ich einfach nicht zu zerstören; andererseits ist man aber auf der sehr sicheren Seite, das das JTAG disabled ist, damit kann damit kein Unsinn mehr angestellt werden; kein interner EEPROM (stimmt imho so nicht) usw usf :-)
Einige der Features, die negativ fuer den MSP430 aufgeführt werden, sind aber mit der neuen 15x Serie behoben (brown out protection). Andererseits sind auch die Atmels jetzt stromsparender geworden.
Toller Vergleich, oder hab ichs mit den Augen? Multiplikation und Division hab ich jedenfalls nicht in der Tabelle gesehen. Und da braucht der AVR immerhin 34 Takte für eine 8bit*8bit Multiplikation, bis hin zu 255 Takten für eine 16bit/16bit Division. Da helfen auch
Die ATmega-Serie, welche die z.T. schon abgekündigten Controller der AVR-Reihe ersetzen (z.T. pinkompatibel zu den Vorgängertypen), haben alle Hardware-Multiplikation on chip.
Oh, gut zu wissen. Ich sag aber trotzdem nicht "sorry, mein Fehler", weil ich eben die genannte AN unter atmel.com -> mega128 -> more application notes gefunden hab :-)
Das ist ein fauler Vergleich. Einen Comparator hat selbst der dümmste alte AT90S1200 ebenfalls schon. Ist aber doch undendlich mühevoller, und Portpins verbrauchst Du außerdem dafür.
Sicher ist der ADC weder überragend schnell noch überragend genau. Andererseits sind 10 Bit Auflösung meist schon mehr, als die Umgebung eines Controllers bei laufendem Takt überhaupt an S+N/N vertragen kann (nicht umsonst gibt's auch einen sleep mode, der sich `ADC noise reduction' nennt). Gerade ein Punkt macht diese umschaltbaren ADCs richtig hübsch: man kann eine Quasi-Analogeingabe simpelst mit einem Poti realisieren, für die man sonst irgendwelche umständlichen (und teureren) Schaltermimiken bräuchte. Denke mal an eine Teemaschinensteuerung, bei der man die Brühzeit einstellbar haben möchte. Da bietet sich sowas an. (Wollte ich mal bauen aus einer alten, kaputten Teemaschine, aber die hat dann leider jemand entsorgt, bevor der Plan in die Phase der Ernsthaftigkeit gelangt ist.)
Das ist wohl eher für ,,heiße'' Einsätze interessant, bei denen man seine Daten mit lock bits schützen will (aber mit gesetztem lock bit kann ich sie verständlicherweise auch beim AVR nicht mehr modifizieren).
Doch doch, das stimmt (leider) schon. Du hast nur reprogrammierbaren Flash ROM (hat der ATmega ja auch), aber einzelzellenbeschreibbaren EEPROM hat der MSP430 wohl nicht. Außer der Einzelzellen- Beschreibbarkeit wird bei Atmel die duration des EEPROMs auch um den Faktor 10 höher angegeben als die des Flash ROMs. Das kann für Fälle, in denen man häufig Daten zwischenspeichern will, schon wichtig werden. (OK, auch die 100000 Zyklen bekommt man kaputtgenuddelt, wenn man sich einen dummen Algorithmus aussucht.)
--
J"org Wunsch Unix support engineer
joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/
Ja, die MSP430 sind in erster Linie auf Stromsparen ausgelegt.
Das sie schwachbrüstiger sind, kann aber eigentlich nicht sein, wenn man bedenkt, daß es 16-Bit-Controller sind, der AVR aber nur 8-Bit. Zumindest bei gleichem Takt sollte der MSP430 beim Integerrechnen deutlich schneller sein?! Der MSP430 hat vorallem einen Riesennachteil: max. 64kB Adressraum. Für RAM und ROM. Das wird schnell eng. Ansonsten aber ein guter µC.
Grüße,
Sebastian
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
div8u: sub drem8u,drem8u ;clear remainder and carry ldi dcnt8u,8 ;init loop counter d8u_1: rol dd8u ;shift left dividend rol drem8u ;shift dividend into remainder sub drem8u,dv8u ;remainder = remainder - divisor brcc d8u_3 ;if result negative add drem8u,dv8u ; restore remainder d8u_3: dec dcnt8u ;decrement counter breq d8u_1 ;if done rol dd8u,8 ;shift left dividend com dres8u ret
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.