mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Was sind die Vorteile und Nachteile von PICs und ATMEL Controller?


Autor: T. P. (pointhi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich programmiere zurzeit PICs und bin zufällig auf AVR-RISC Controller 
von ATMEL getrofen. Ich will später auch Robotter programmieren, oder 
Haussteuerungen reaslisieren. Auf spruth.de steht ja auch, das man sich 
auf einen einzigen Controllertypen spezialisieren soll, und nicht bei 
jeden neuen Projekt auf ein anderes "Pferd" setzt. Ich möchte daher 
wissen, in welchen Programmiersprachen die Controller programmierbar 
sind, welche Vorteile und Nachteile sie haben und Erfahrungen währen 
auch nicht so schlecht.

Ich wäre dankbar, wenn mir bei diesen "Problem" geholfen wird

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://electricstuff.co.uk/picvsavr.html

PS: Ich tippe auf maximal 5 Minuten, bis die erste Schlägerei hier los 
geht.
PSS: Ich bin für AVR, da billiger.

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.mikrocontroller.net/articles/Entscheidu...

Meiner Meinung nach sind AVRs (dank des gcc) einfacher zu handhaben.

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nee. Atmel und PICs sind praktisch dasselbe. Und ja, wenn man mal eine 
Familie hat sollte man bei der bleiben. Dh bleib bei den PIC - die sind 
schon gut. Moeglicherweise haben die auch eine bessere Auswahl an 
Compilern. Die IDE (MPLAB) ist besser, denn sie bindet fremede Compiler 
ein.

Autor: T. P. (pointhi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte keine Englischen Seiten, ich kann nicht so gut Englisch

was meinst du mit gcc?

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Microchip-Mensch kam mir am Telefon recht arrogant vor ("Wir sind 
die Größten und deshalb so gut!").
Bleibe deshalb beim guten alten ATmega.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aha wrote:
> Die IDE (MPLAB) ist besser, denn sie bindet fremede Compiler
> ein.

Häh? das AVR-Studio bindet doch auf fremde Compiler ein, z.B. den 
GNU-GCC aus dem WINAVR-Paket.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, nicht schon wieder...

> PS: Ich tippe auf maximal 5 Minuten,
> bis die erste Schlägerei hier los geht.
Vertippt: es waren 8 Minuten ;-)

Autor: T. P. (pointhi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich besitze MBLAB schon, aussagen darüber könnt ihr treffen, ich beachte 
sie aber nicht.
Warum auch, ich kenne die Vorteile und Nachteile.

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> in welchen Programmiersprachen die Controller programmierbar
sind,

In KEINER.....

Autor: zachso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also beide Controller sind in C und ASM "programmierbar", die AVR 
zusätzlich noch in BASIC.

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenn fuer beide einen Pascal compiler

Autor: Rüdiger Knörig (sleipnir)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also einen großen Vorteil der ATmel kann ich schon nennen: der Takt wird 
nicht wie beim PIC/4 geteilt. Das ist beim PIC so eine konstruktive 
Unart - einerseits hat man eine Pipeline eingebaut, andererseits hebt 
man deren Hauptvorteil (hoher Durchsatz durch Fließbandverarbeitung) 
dadurch wieder auf das man wg. Datenkohärenzproblemen die Pipeline eben 
nicht als Fließband verwendet.

Autor: T. P. (pointhi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PICs kann man z.b. in Asembler und C Programmiern. Ich suche 
hauptsächlich Prozessoren, die sich in Assembler, C, Basic, villeicht 
auch Virtual Basic oder andere Programmiersprachen die leicht erlernbar 
sind.

Ich behersche schon: Assembler  (relativ gut: ich programmiere zurzeit
                                 PICs in Assembler)

                     C          (mache noch viel Fehler)

              und    Basic      (kann die Programme noch nicht am 
Computer
                                ausführen (nur teroretisches Wissen)


(zu spät ins Forum gegeben!!!)

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist KEIN Controller bekannt, der in z.B C programmierbar wäre. Es 
gab mal einen, der verstand Basic. Alle Controller werden mit Binärcode 
programmiert.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soso, Du schiebst die Nullen und Einsen also noch von hand darein?

Autor: Noch-ein-Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pointhi:

Der AVR-gcc ist auch nicht einfacher zu bedienen als der CC5x, falls Du 
verstehst, auf was ich anspiele...

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas Pointhuber: Mein Rat, wenn du dich an die Controller gewöhnt 
hast und mit der Architektur gut klar kommst, dann bleib' dabei. Zumal 
zur Gewöhnung nicht nur die Controller selbst zählen, sondern auch der 
Umgang mit der Entwicklungsumgebung. Ein Wechsel der Architektur 
verlangt nicht nur neue Controller, sondern auch neues Programmiergerät, 
neue Entwicklungssuite, neue Libraries, neues Einarbeiten. Der Wechsel 
lohnt nur, wenn dieser wirklich einen signifikanten Vorteil bringen 
würde, diesen Vorteil sehe ich aber hier nicht, mann bekommt auch mit 
PICs so ziemlich jedes Problem erschlagen, es sei denn, die 
Rechenleistung reicht hinten und vorne nicht. Aber in so einem Falle 
wäre ein Wechsel zum AVR wenig sinnvoll, da gibt es bei ARM-kompatiblen 
Controllern wesentlich mehr Leistung. Solange das nicht gebraucht wird, 
kannst du beim PIC bleiben.

Gruß
Jadeclaw.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Pointhuber wrote:
> PICs kann man z.b. in Asembler und C Programmiern. Ich suche
> hauptsächlich Prozessoren, die sich in Assembler, C, Basic, villeicht
> auch Virtual Basic oder andere Programmiersprachen die leicht erlernbar
> sind.

Virtual Basic ?????
Was ist denn das?

Mein Tipp: Lerne C beherrschen und bleib bei der Dir vertrauten 
Controller-Familie, solange die Typen Deine Anforderungen erfüllen.
Es geht ja nicht nur darum, PIC-Assembler oder AVR-Assembler zu lernen, 
sondern auch um das Anschaffen und Lernen der Werkzeuge wie Programmer, 
Debugger etc. Und wenn Du Werkzeuge von Microchip hast, kannst Du sie 
für ziemlich alle PICs von PIC10 über PIC18 bis dsPIC33 und PIC32 
verwenden.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Pointhuber wrote:
> Ich wäre dankbar, wenn mir bei diesen "Problem" geholfen wird

Es gibt schon reichlich Threads zu diesem Thema hier, lies sie.
Helfen kann Dir keiner bei der Entscheidung, die mußt Du ganz alleine 
treffen.


Wenn Du aber schon fragst, muß es ja Sachen geben, die Dir beim PIC 
nicht so gut gefallen und die andere MCs wesentlich besser machen.

Mir hat am PIC der extrem magere Befehlssatz mit Abstand am 
schlechtesten gefallen.
Andauernd fehlen wichtige Instruktionen und man muß sie sich erst mühsam 
zusammenbasteln.
8051 und AVR lassen sich da deutlich bequemer in Assembler 
programmieren.
Ich beneide auch die armen PIC-Compilerbauer nicht, die haben schon nen 
verdammt harten Job. Oftmals sind die PIC-Compiler deswegen auch etwas 
eingeschränkt.

Das mit dem ein Interruptvektor für alle ist auch kein Ruhmesblatt.
Da ich sehr gerne mit Interrupts arbeite, will ich nicht immer erst 
mühsam die Quellen auseinanderpfitzeln müssen, das kostet ja auch 
wertvolle CPU-Zeit.


Der AVR-GCC ist leider auch etwas eingeschränkt, er kann kein double 
(64Bit-float).


Peter

Autor: nabeshima (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oft ist es ja auch so, dass man auf vorhandenen Projekten aufbaut und 
sich in Foren austauschen möchte. Ich würde einfach mal schauen, welche 
Controller in der Roboter-Community bzw für Haustechnik bevorzugt 
werden.

Ansonsten kommt es halt immer drauf an, was man machen möchte und in 
welchen Dimensionen. Ich brauche z.B. einen Controller mit extrem 
niedrigem Stromverbrauch und da sind die PICs halt etwas sparsamer.
Dann möchte ich das Projekt eventuell in kleiner bis mittelgroßer Serie 
fertigen, da spielt es dann schon eine Rolle, ob so ein Teil 0,50 € 
(PIC12F) oder 1,- € (ATTiny) kostet. PICs kann man außerdem direkt bei 
Microchip bestellen und es gibt einen Programmierservice (vielleicht 
gibts das bei Atmel auch, auf der Webseite ist davon aber nichts zu 
sehen).

Autor: Rüdiger Knörig (sleipnir)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na wenn es extrem stromsparend sein soll dann wäre doch ein 
MSP430-Derivat das Richtige? Bei der Beurteilung des Stromverbrauchs 
sollte man immer auch berücksichtigen, das ein PIC mit dem 4-fachen Takt 
laufen muß um die gleiche Leistung zu haben wie ein AVR!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich brauche z.B. einen Controller mit extrem
> niedrigem Stromverbrauch und da sind die PICs halt etwas sparsamer.
Extrem niedriger Stromverbrauch, da nehme ich einen MSP430.

> ob so ein Teil 0,50 € (PIC12F) oder 1,- € (ATTiny) kostet.
Solche Preise gibt es nicht. Das sind eher 0,5135 € oder 1,0187 €.

> es gibt einen Programmierservice (vielleicht gibts das bei Atmel auch,
> auf der Webseite ist davon aber nichts zu sehen).
Das wird von des Distris (bzw. beauftragten Unternehmen) erledigt.
Oder Just-In-time im Bestückungsautomaten.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man halbwegs wie ein richtiger Programmierer arbeiten will lautet 
die Frage richtige: Was kostet das Entwicklungssystem, einschließlich 
Debugger?

Bei Microchip bekommt man das günstiger wenn man auf Codeoptimierung des 
C-Compilers verzichtet.

http://www.mikrocontroller.net/articles/Entscheidu...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nabeshima wrote:
> Dann möchte ich das Projekt eventuell in kleiner bis mittelgroßer Serie
> fertigen, da spielt es dann schon eine Rolle, ob so ein Teil 0,50 €
> (PIC12F) oder 1,- € (ATTiny) kostet.

Welchen PIC hast Du denn mit welchem AVR bei welchem Lieferanten 
verglichen?
In der Regel sind die AVRs billiger, z.B. Reichelt:

ATTiny13: 0,80€
PIC12F508: 0,95€


Peter

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und ja, wenn man mal eine Familie hat sollte man bei der bleiben.
<SNIP> tausen ähnliche, gute Argumente </SNIP>

Und trotzdem:

Wenn ich hier die Beiträge von Thomas Pointhuber verfolge, tippe ich auf 
engagierten Amateur mit (sehr) ausbaufähigen Kenntnissen.

Auf welcher Hardware man Programieren lernt, ist egal. Natürlich hat 
jeder Mikrocontroller seine Eigenheiten, und die Entwicklungsumgebungen 
verhalten sich auch alle (etwas) anders. Trotzdem gibt es da zwischen 
PICs und AVRS mehr Gemeinsamkeiten als Unterschiede. Hat man erst einmal 
einen gemeistert, fällt der Umstieg auf einen anderen nicht mehr so 
schwer. Über einen etwas längeren Zeitraum gesehen, muß man sowieso 
umsteigen. Die Hardwarezyklen dauern nicht ewig. Ich habe mal, noch zu 
Schulzeiten, Assembler auf einem 6809 gelernt. Dem trauere ich heute 
noch nach, nutzt aber nichts, gibts halt nicht mehr.

Natürlich gibt es heute in einem Chip für 1,50 Funktionen, für die vor 
20 Jahren noch kühlschrankgroße VME-Bussysteme erforderlich waren. Die 
alle zu beherrschen und möglichst effizient einzusetzen, erfordert schon 
die Konzentration auf ein- oder zwei Controllertypen. Solange aber mehr 
die "Basics" im Vordergrund stehen

(Zitat:
>Ich will später auch Robotter programmieren, oder
>Haussteuerungen reaslisieren. Auf spruth.de steht ja auch, das man sich
>auf einen einzigen Controllertypen spezialisieren soll,
)

ist völlig egal, ob PIC oder AVR.

Meine Meinung
Oliver

Autor: nabeshima (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Na wenn es extrem stromsparend sein soll dann wäre doch ein
> MSP430-Derivat das Richtige? Bei der Beurteilung des Stromverbrauchs
> sollte man immer auch berücksichtigen, das ein PIC mit dem 4-fachen Takt
> laufen muß um die gleiche Leistung zu haben wie ein AVR!

Der MSP430 ist aber wesentlich teuer, oder?
Im Sleep verbraucht ein ATTiny mehr als doppelt so viel wie ein PIC, das 
mit dem 1/4 Takt ist aber in der Tat ärgerlich. Leider steht in den 
Atmel-Datenblättern nicht, wieviel im Betrieb mit dem internen 128 
kHz-Oszillator oder einem Uhrenquartz verbraucht wird.


> Solche Preise gibt es nicht. Das sind eher 0,5135 € oder 1,0187 €.

Das war natürlich gerundet, es kommt ja eh auf das einzelne Modell, 
Bauform, Menge usw an.

> Welchen PIC hast Du denn mit welchem AVR bei welchem Lieferanten
> verglichen?

Hab einfach bei Farnell nach dem jeweils günstigstem geschaut. Am besten 
wäre natürlich, man könnte die Preise direkt beim Hersteller 
vergleichen, aber die gibt's ja nicht bei Atmel..

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nabeshima wrote:

> Im Sleep verbraucht ein ATTiny mehr als doppelt so viel wie ein PIC,...

Allerdings haben die Sleep-Ströme kleiner Controller eher akademischen
Wert, da die Selbstentladeströme entsprechender Batterien in der Regel
um einiges größer sind.

> Leider steht in den
> Atmel-Datenblättern nicht, wieviel im Betrieb mit dem internen 128
> kHz-Oszillator oder einem Uhrenquartz verbraucht wird.

Doch, natürlich, unter "Typical Characteristics" gibt es Kurven
dafür.  32 kHz muss man extrapolieren, aber 128 kHz sind angegeben.

> Hab einfach bei Farnell nach dem jeweils günstigstem geschaut. Am besten
> wäre natürlich, man könnte die Preise direkt beim Hersteller
> vergleichen, aber die gibt's ja nicht bei Atmel..

Jeder Kunde bekommt wohl letztens bei jedem Hersteller einen ausgehan-
delten Preis, der sich an seiner Gesamt-Abnahmemenge orientiert.

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bensch (Gast)
> Datum: 09.03.2009 14:47

> Mir ist KEIN Controller bekannt, der in z.B C programmierbar wäre. Es
> gab mal einen, der verstand Basic. Alle Controller werden mit Binärcode
> programmiert.

Beitrag "AVR-ChipBasic2 - BASIC-Computer mit ATMega 644"

:)

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Z8

Aha, der war mir nicht bekannt, offensichtlich ein "Nachfolger" des 
alten 8051Basic, den ich meinte.

Aber ansonsten- Controller, die Hochsprache können- tote Hose...
Ein RISC-uC, der C kann, macht auch irgendwie keinen Sinn.

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Bensch,

der Thread ist sinnlos! :)

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn es um die Vor- bzw. Nachteile von PICs bzw. Atmels geht kommen bei 
einer solchen "was ist besser Frage" eigentlich immer die selben 
Antworten.

Als erstes ist da immer das Argument, der PIC teilt den Takt durch vier. 
Das ist erst mal richtig, ABER: die 10F, 12F und 16F PICs benötigen dann 
auch nur EINEN solchen geteilten Takt pro Befehl (außer die 
Sprungbefehle, die brauchen meist zwei). Bei den ATmels verbrauchen 
viele Befehle 2, 3 oder 4 Takte und damit ist der Geschwindigkeitvorteil 
schon höchstens noch das doppelte und nicht mehr das vierfache.

Die 18F und höher haben eine interne PLL. Den Multiplikator der PLL 
kannst du einfach auf 4 stellen und schon sind die PICs rein äußerlich 
genauso schnell (oder schneller) wie die ATmels (Du schließt also einen 
8 MHz Quarz an und arbeitest intern mit 32 MHz. Dadurch, dass der PIC 
dann wieder durch 4 teilt bist du also genauso schnell wie ein ATmel mit 
8MHz bzw. schneller, wenn man das in erstens mit berücksichtigt).

Dann das Vorurteil mit den wenigen Befehlen. Die 18F und höher haben 
bedeutend mehr Befehle. Sind es bei den 10F, 12F und 16F nur 35 (von 
denen man aber nur ca. 30 benutzt) sind es bei den 18F schon über 80. 
Hier ist dann eigentlich auch vieles dabei, was man bei den <18F 
vermisst. So gibt es zum Bsp. 3 Zeigerregister und nicht nur eins. Oder 
komfortable Tabellen Befehle. Auch Multiplikation ist integriert. Die 
18F+ können mit den ATmels durchaus mithalten. Und die >18F (24F, 32F 
33F...) erst recht.

Argument Interrupt: Was bitte ist so schlimm daran, das es nur einen 
Eintrittspunkt bei den <18F gibt? Sicher, man muss in der ISR erst mal 
eine kleine Abfrage einbauen, um den auslösenden Interrupt zu ermitteln. 
Aber das sind genau zwei Befehle pro benutztem Interrupt. Bei dem ATmel 
ist es ein Befehl. Ich sehe darin keinen großen Nachteil.

Was kommt noch? Ach ja das Banking und Paging. Das ist wirklich nervig 
bei den <18F. Ab den 18F PICs wurde das Banking etwas besser gelöst und 
das Paging ganz abgeschafft. Solltest du in C programmieren, muss dich 
das aber nicht interessieren, da dass der Compiler erledigt.

Der Preis: Als Amateurbastler in meinen Augen eher uninteressant. Mir 
ist es eigentlich egal ob ich 3,- € oder 5,-€ im Monat bezahlen muss. 
Denn mehr wie einen µC im Monat verbau ich eh nicht. Und wenn du ähnlich 
wenig baust, kannst du dir auch mal Samples von Microchip schicken 
lassen. Dann kostet es nix. Sollte man aber nicht übertreiben...
Das sieht natürlich anders aus, wenn man Serien produzieren will. Da 
spielt der Preis schon eine große Rolle...

Nun aber noch das einzige Argument, welches in meinen Augen wirklich für 
die ATmels spricht: Die Fangemeinde. Es gibt im Internet deutlich mehr 
deutschsprachige Unterstützung bei den Atmels als bei den PICs. Hier 
steht man als PIC Anwender doch etwas allein gelassen dar. Nicht das es 
keine Hilfe gibt. Die ist schon auch da, aber die Auswahl an fertigen 
Projekten wo man sich etwas abschauen kann ist bei den ATmels deutlich 
größer.

Fazit: Ich habe mit PICs <18F in Assembler angefangen und programmiere 
die so bis heute. Auch inzwischen recht umfangreiche Projekte mit über 
4000 Programmzeilen. Die 18F würde ich gerne auch mal programmieren. 
Dann aber wohl in C. Bis jetzt hab ich mich aber weder an die 18F ran 
getraut noch an C. Auf die Atmels hab ich immer mal geillert und mit der 
Anschaffung eines AVR-NET-IO von Pollin auch ein wenig damit 
rumgespielt. Einen Grund bei den PICs die Scheidung einzureichen um mich 
mit ATmels zu verheiraten sehe ich aber nicht. Letztendlich musst du es 
aber selbst entscheiden.

Gruß
Sven

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven Stefan wrote:
> Bei den ATmels verbrauchen
> viele Befehle 2, 3 oder 4 Takte und damit ist der Geschwindigkeitvorteil
> schon höchstens noch das doppelte und nicht mehr das vierfache.

Erstens: Es gibt nicht die Atmels. Was du meinst nennt sich AVRs.
Zweites: Wenn du schon damit anfängst, dann mach es auch richtig:
Was mehr als 1 Takt benötigt, sind 16bit Operationen oder Spungbefehle. 
16bit Operationen gibt es bei den von dir genannten PICs nicht. Also 
kann man das nicht vergleichen. Weiterhin benötigen ansonsten vor allem 
die Sprung und Branchbefehle mehr als einen Takt. Dies ist bei den PICs 
aber auch der Fall. Das einzige wo die 18F wirklich schneller sind ist 
die Multiplikation. Alle anderen Befehle benötigen genau 1 Takt.

> Die 18F+ können mit den ATmels durchaus mithalten.

Da stimme ich dir zu. Je nachdem wonach man schaut sind mal die einen, 
mal die anderen minimal besser. Aber letztendlich vergleichbar.

> Und die >18F (24F, 32F 33F...) erst recht.

Wenn du schon vergleichst, dann vergleiche richtig:
Die 33 und 32F haben mit den  <18F genausoviel gemeinsam wie AVR und 
AVR32. Jetzt vergleiche also mal AVR32 und 32F...

Davon mal abgesehen: Die 24F/30F/33F (alle mit mehr oder weniger dem 
selben Befehlssatz) sind echt schöne µC. Je nach Anwendung sind die 
durchaus mit einem ARM7 vergleichbar von der Rechenleistung und vor 
allem den IO Zugriffen die alle in 1 Takt erledigt werden. Es wird Zeit 
dass Reichelt die mal zu akzeptablen Preisen ins Programm aufnimmt.

> Der Preis: Als Amateurbastler in meinen Augen eher uninteressant. Mir
> ist es eigentlich egal ob ich 3,- € oder 5,-€ im Monat bezahlen muss.
> Denn mehr wie einen µC im Monat verbau ich eh nicht.

Du vielleicht nicht, ich schon. Und ob ich nun 10€ im Monat für µC 
ausgebe oder 30€ macht schon einen Unterschied.
Microchip kündigt nie Controller ab ohne einen direkt kompatiblen Ersatz 
zu  bieten. Das lassen die sich aber gut bezahlen. Ist auch klar: Kleine 
Stückzahlen kosten Geld.

> Und wenn du ähnlich
> wenig baust, kannst du dir auch mal Samples von Microchip schicken
> lassen. Dann kostet es nix.

Auch hier liegst du falsch: Samples gibts nur noch gegen Bezahlung (7,5$ 
Versandkostenpauschale).

Sorry, eigentlich wollte ich mich nicht in dieses Bashing einmischen, 
aber wenn jemand Mist schreibt, dann korrigiere ich das gerne.

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sven Stefan,

> 3 Zeigerregister und nicht nur eins.

HL, IX, IY beim Z80 (1975?)

oder Z, Y, X bei den Tinys von von AVR?

tolle Sache von µChip! Ich halt micht jetzt aber wirklich raus.

"Aber ich liebe euch doch alle" E. Milke :)

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: außer den MP430! :(

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Davon mal abgesehen: Die 24F/30F/33F (alle mit mehr oder weniger dem
> selben Befehlssatz) sind echt schöne µC. Je nach Anwendung sind die
> durchaus mit einem ARM7 vergleichbar

Leider auch was die eklatante Liste an Bugs angeht.

Von dem Dataspace-Mapping des Code-Flash könnte Atmel sich allerdings 
eine Scheibe für die AVRs abschneiden.

Die Architektur hat jedoch gewisse Designaspekte, die Einsatz im 
stromsensiblen Bereich wohl auch in Zukunft etwas erschwert. Der Core 
ist dadurch aufwendiger als nötig wäre. Beispielsweise verwirft man 
Ergebnisse indem man sie ins RAM schreibt und löscht 2 Register per 
Multiplikation. Oder geradezu zwanghaft eine Laufzeit von einem Takt für 
Befehle vorzuschreiben auch wenn darin mehrere Speicherzugriffe stecken. 
DSP lässt grüssen, klar, aber für Normalanwendung ist das übertrieben.

> Es wird Zeit
> dass Reichelt die mal zu akzeptablen Preisen ins Programm aufnimmt.

Kriegt man bei TME. Sind allerdings teils deutlich teurer als die 
konkurrierenden ARMs (C-M3).

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Auch hier liegst du falsch: Samples gibts nur noch gegen Bezahlung (7,5$
> Versandkostenpauschale).
Da war es ja gut, dass ich mich voriges Jahr noch eingedeckt hatte ;-)
>
> Sorry, eigentlich wollte ich mich nicht in dieses Bashing einmischen,
> aber wenn jemand Mist schreibt, dann korrigiere ich das gerne.
Ich lasse mich gerne korrigieren. Aber es war ja auch nicht nur Mist, 
den ich geschrieben habe. Mir gehen halt nur die Vorurteile gegen die 
PICs ein wenig auf den Zeiger. Die meisten plappern das nur nach, was 
sie irgendwann zu 16F84 Zeiten mal gelesen hatten und denken, dass sich 
bei Microchip in den letzten 20 Jahren nichts geändert hat.

Na egal. Der OP wird seine Entscheidung schon treffen und sicherlich mit 
seiner getroffenen Wahl auch glücklich werden. Man lernt ja nicht 
duzende Befehle, 100e Register und 1000e Stolperfallen nur, um das dann 
alles über Board zu werfen und mit einem anderen µC neu anzufangen der 
im Großen und Ganzen auch nicht besser oder schlechter ist.

Schönen Abend
Sven

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der größte Nachteil bei beiden Controller-Familien ist doch, dass man 
sie erst programmieren muß, damit das herauskommt, was man haben will... 
;)

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für mich haben PIC und AVR ihre Daseinsberechtigung!

Meine Diplomarbeit entstand mit einem PIC16C72 (Drehzahlregelung,
2 KW Motor, lang her).
Später Wechsel auf AVR da besser für C (hier hat PIC aufgeholt).
Heute sowohl als auch (und manchmal noch 8051).
Alles C und/oder Asembler.
Die Mini-PIC (10F2xx im SOT23-6) sind z.B. für kleine Timingaufgaben
echt klasse.

Daher "Leben und leben lassen"!

gruß hans

Autor: skorpionx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im letzten Jahr stand ich auch vor der Wahl: AVR oder PIC.  Meine 
Entscheidung fiel auf PIC. Warum?.. Mit einem PIC kann ich einfach eine 
dezentrale Intelligenz aufbauen mit dem genialen CAN-Bus. Ich will meine 
kleinen Platinen selber entwickeln.
„AVR-NET-IO von Pollin“ ist für mich …  etwas übertrieben. Dazu kaufe 
ich
lieber einen PC bei Ebay oder bei Aldi.
Meine Testplatinen laufen  schon mit dem CAN-Bus. Verbindung von PC mit 
allen
Busteilnehmer über eine PIC Schaltung mit RS232 und CAN.
Zeit Flanken werden in Interrupt generiert (delay ist etwas Primitives).
Als nächste kommt Einbindung von einem LCD und Tastatur. Das lässt sich 
auch
mit dem CAN-Bus machen. Jeder Erweiterung (Z.B. dezentrale I/O) dankt 
dem
CAN ist kein Problem.
Übrigens meine Entwicklungen mache ich unter C-Compiler –
parallel mit dem C18 von Microchip und dem SDCC . So teste ich die 
Tauglichkeit von dem freien SDCC.   Unter SDCC muss man den Pointer auf 
SFR-Variable
so definieren:
    (__data BYTE*)some_sfr .
Dieser Fehler wird auch bald behoben.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> „AVR-NET-IO von Pollin“ ist für mich …  etwas übertrieben. Dazu kaufe
> ich lieber einen PC bei Ebay oder bei Aldi.

Ich finde das immer noch etwas übertrieben und kaufe liebe eine Cray ;-)

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Komische Logig. Ein kleines Board für 20,-€ ist übertrieben. Aber ein PC 
ist ok für einfache Schaltaufgaben. Da verheizt man  die 20,- ja schan 
an Stromkosten die der PC frisst.

Sven

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als obs keine AVR mit CAN gäbe, sowas Engstirniges...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber nur grosse 64er. Bei den PICs gibt's auch 28er.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. wrote:
> Beispielsweise verwirft man
> Ergebnisse indem man sie ins RAM schreibt und löscht 2 Register per
> Multiplikation. Oder geradezu zwanghaft eine Laufzeit von einem Takt für
> Befehle vorzuschreiben auch wenn darin mehrere Speicherzugriffe stecken.
> DSP lässt grüssen, klar, aber für Normalanwendung ist das übertrieben.
Nur noch interessehalber: Wo hast du denn das her? Also ersteres mein 
ich.
Das mit der Laufzeit von einem Takt ist doch schön :-]

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. wrote:

> Nur noch interessehalber: Wo hast du denn das her?

Aus Microchips eigenem Compiler. Der macht das so. Er hat ja auch recht.

Der Multiplikationsbefehl braucht einen Takt, schreibt 2 Register und 
wenn man das richtige der beiden mit 0 multipliziert steht hinterher in 
beiden 0 drin.

Und vergleichen tut man bei PIC30, indem man subtrahiert und das 
Ergebnis nach [SP] schreibt. Der Assembler-Befehl CP ist ein Synonym für 
SUB.

> Das mit der Laufzeit von einem Takt ist doch schön :-]

Nicht unbedingt wenn man als Chipdesigner das umsetzen und dabei 
unbedingt Strom sparen muss.

Autor: Rüdiger Knörig (sleipnir)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde auch - das macht das Taktzählen und somit die Konzipierung 
extrem zeitkritischer Routinen recht einfach, ebenso das 
"Ausbalancieren" von Ausführungs-Pfaden.

Ich weiß nicht - bei den PIC's hat mich schon die beschränktere Struktur 
gestört. Zum einen die Taktherunterteilung, welche die PIC's für einige 
Sachen zu langsam machen (bsp. ASK-Modulation im MHz-Bereich), zum 
anderen ist der Befehlssatz der AVR's doch angenehmer.
Zudem die Sache mit dem Working-Register W - das hört sich eher nach Z80 
CISC an statt einem modernen RISC.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. wrote:
>> Das mit der Laufzeit von einem Takt ist doch schön :-]
>
> Nicht unbedingt wenn man als Chipdesigner das umsetzen und dabei
> unbedingt Strom sparen muss.

Letztendlich sind das doch alles nur positive Features. OK, der 
Stromverbrauch ist nicht wirklich für Batteriebetrieb geeignet, aber 
wenn man sich die dsPICs so anschaut, dann zielen die eher in den 
Bereich Industriesteuerung und ähnliches.

Und all diese Features verhelfen dem dsPIC zu enorm mächtigen Befehlen: 
Effektiv ist dieser also locker mal Faktor 2-10 schneller als ein 
normaler 16bit µC.
Ein Beispiel das ich selbst ausprobiert habe: Ein JPEG Bild von SD Karte 
laden, dekodieren und an einen Displaycontroller schicken. Obwohl die 
Software in C geschrieben war, und daher nichtmal die DSP Befehle des 
dsPICs genutzt werden, war dieser trotzdem mehr als 3x so schnell wie 
ein mit gleicher Taktfrequenz getakteter R32C (32bit CPU), der sogar 
noch über einen Hardwarebus verfügt an dem der Displaycontroller 
angeschlossen ist (der dsPIC macht das per Software).

Davon abgesehen lässt sich der dsPIC sehr einfach Programmieren: Die 
Einarbeitungszeit ist sehr viel kürzer als z.B. bei den ARMs mit den 
komplizierten Interrupts usw.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yep, als Bitwackler sind die phänomenal.

Ich will die damit übrigens nicht verdammen. Ist die erste Architektur, 
die MC nicht versemmelt hat. Nur haben sie sich damit beim Weg nach 
unten etwas behindert.

Bei den Interrupts - so schnell und einfach wie sie sind - stört mich 
allerdings, dass man nur sehr umständlich in generischer Weise im 
Treiber für ein evtl. mehrfach vorhandenes Funktionsmodul wie UART das 
ganze sauber mit der Interruptsteuerung koppeln kann.

Die Register liegen ja hübsch im Block, aber die Interruptsteuerung 
leider wenig systematisch quer verteilt in einem Haufen Bitfelder im 
Interrupt-Controller. Will man den selben Code für alle UARTs verwenden, 
ist der Zugang zur Interruptsteuerung des jeweiligen Kanals arg 
umständlich.

Autor: skorpionx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber nur grosse 64er. Bei den PICs gibt's auch 28er.

Am Anfang waren meine Gedanken bei AVR. Aber das war der entscheidende
Faktor für mich. Ich kann meine Platinen selber entwickeln und zusammen 
löten…

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Aber nur grosse 64er. Bei den PICs gibt's auch 28er.

>Am Anfang waren meine Gedanken bei AVR. Aber das war der entscheidende
>Faktor für mich. Ich kann meine Platinen selber entwickeln und zusammen
>löten…

Stimmt. Das geht mit 64ern natürlich nicht....

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Matthias Lipinsky (lippy)

>Stimmt. Das geht mit 64ern natürlich nicht....

Klar, für den C64 muss man schon ziemlich viel löten ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
skorpionx wrote:
>> Aber nur grosse 64er. Bei den PICs gibt's auch 28er.
>
> Am Anfang waren meine Gedanken bei AVR.

Stimmt, CAN scheint Atmel nicht zu mögen.
Die haben auch nur das alte ATmega128-Design mit CAN gepimmt und nicht 
die besseren ATmega2560. Ich hab daher nen ATmega2560 + SJA1000 benutzen 
müssen.

Für kleine CAN-Knoten wird gerne der ATmega8 + MCP2515 genommen.


Peter

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Davon abgesehen lässt sich der dsPIC sehr einfach Programmieren: Die
>Einarbeitungszeit ist sehr viel kürzer als z.B. bei den ARMs mit den
>komplizierten Interrupts usw.


Kannst Du das mal näher erläutern?
Ich habe gerade das erste Wochenende mit einem Luminary ARM Cortex M3 
hinter mir (LM3S1968).
Ehrlich gesagt, kann ich mir ein einfacheres Interrupthandling nicht 
vorstellen.
Simple C-Routinen, ein Eintrag in die Vectortabelle, der Interrupt 
aktiviert, das wars. Auch verschachtelte Interrupts sind nicht 
aufwendiger.

Wie geht das noch einfacher?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dietmar wrote:

> Kannst Du das mal näher erläutern?
> Ich habe gerade das erste Wochenende mit einem Luminary ARM Cortex M3
> hinter mir (LM3S1968).

Ich habe bisher nur mit den NXP und Atmel ARMs gearbeitet, ist aber 
schon etwas her, da ich mich mit denen nicht so richtig anfreunden 
konnte.
Bei den NXP gibt es den Vectored Interrupt Controller, da gibt es 
irgendwie schnelle und langsame Interrupts, Addresse zuordnen, noch 
irgendwas anderes einstellen usw. Ganz habe ich das nie verstanden.

Bei den dsPICs ist es im Prinzip so wie bei den AVRs:
Der Interrupthandler hat einen bestimmten Namen, dann plaziert der 
Compiler den automatisch an der richtigen Stelle. Dann nur noch 
Interrupt freigeben, fertig. Der Rest ist optional über irgendwelche 
zusätzlichen Attribute.

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt K.:

Du meinst die ARM7 bzw. die einfachen ARM9 Controller.
Die haben in der Tat eine sehr unglückliche und umständliche 
Interruptstruktur.

Mit dem Cortex-M3 hat ARM da aber mächtig aufgeräumt und einen sehr 
schönen Controllerkern entwickelt.
In der Tat ist der von der Interruptbehandlung noch einfacher als beim 
hier beliebten Atmel AVR und auch beim dsPIC.
Einige Register werden schon von der Hardware gerettet, alle anderen 
lassen sich mit einem einzigen ASM-Befehl sichern. Insofern ist der M3 
sicherlich besser durchdacht als ein dsPIC.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten wrote:

> Du meinst die ARM7 bzw. die einfachen ARM9 Controller.

Ja, genau. Der Cortex-M3 ist relativ neu, wenn ich das richtig sehe. 
Ich habe jetzt mal das Datenblatt überflogen: Der sieht nicht schlecht 
aus.
Ein weiteres Problem das ich mit den ARMs habe: Es gibt keine fertige 
GCC Toolchain für Windows, so wie es bei den AVRs ist. Weiterhin muss 
man oft die  Startup Codes und Linkerscripte selbst schreiben. Sowas 
hält vor allem Anfänger schön ab. Oder hat sich das mittlerweile 
gebessert?

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat sich gebessert. codesourcery bietet eine gcc toolchein auch für 
windows. wer damit kostengünstig anfangen will soll sich einen stm32 
primer 1 besorgen. kommt mit ride7 und gcc und 32k debug limit (grüße 
aus der marketingabteilung).

primer 1 läuft natürlich auch unter linux, mit openocd und ohne debug 
limit :-) gcc toolchain kann man die von codesourcery nehmen oder selber 
gcc kompilieren, funktioniert beides gut.

von der hardwareseite ist der primer 1 ok, der primer 2 hat ein paar 
hardwarebugs.

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was sind die Vorteile und Nachteile von PICs und ATMEL Controller?

Was für eine Trollfalle...

Der Threadposter hat nicht eine sinnvolle Frage gestellt...Und Schon 
gibts 60 Posts in 2 Tagen.

  Was ist eigentlich besser: Windows oder Linux?

  Für was kann ich in welcher Programmiersprache programmieren?

So, jetzt erwarte ich richtig Posts bis übermorgen!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Ein weiteres Problem das ich mit den ARMs habe: Es gibt keine fertige
> GCC Toolchain für Windows, so wie es bei den AVRs ist.

Nanu, funktioniert Martin Thomas' WinARM denn nicht mehr?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl-heinz Strunk wrote:

> Was für eine Trollfalle...

Überraschenderweise bist du der erste. Der Rest vom Thread ist bisher 
eher sachlich. Das dieser Thread dis Diskussion fördert ist ja per se 
kein Problem, auch wenn's den Initiator vielleicht nicht mehr 
interessiert. Andere schon.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie verhält sich das eigentlich mit dem Gedöhns von codesourcery und der 
Lizenz, unter der das GNU-Zeugs steht? Müssten die da nicht eigentlich 
die Quelltexte der Tools mitliefern...?

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Nanu, funktioniert Martin Thomas' WinARM denn nicht mehr?

Doch, doch, bleibt trotzdem das Problem "Linkerscript". Will oder kann 
niemand schlüssig erklären.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Nanu, funktioniert Martin Thomas' WinARM denn nicht mehr?

Die letze Version die ich hatte lief nicht, keine Ahnung was da los war. 
Irgendwas mit der echo.exe hat nicht gepasst. Am Ende habe ich alles auf 
meinem alten Rechner compiliert, auf dem noch eine ältere Version 
installiert war, die ging.
OK, das Problem lag letztendlich irgendwie an dem Rechner, (es soll da 
ein paar Probleme mit einer bestimmten Version der echo.exe gegeben 
haben), aber das hat letztendlich dazu gereicht (zusammen mit den 
Problemen mit den Startup Files usw.) mich komplett von den ARMs 
fernzuhalten. Vor allem da ich eher schnelle IOs und Peripherie brauche 
als reine Rechenleistung.

Autor: qwertz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>das Problem lag letztendlich irgendwie an dem Rechner

Was für ein Rechner ist das? auf meinem XP SP3 32-bit lief es ohne 
Probs!?


zur eigentlichen Frage: Atmel ist besser, das sieht man schon daran dass 
das fav-icon hier vom Forum ein AVR beinhaltet :p

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Weiterhin muss man oft die  Startup Codes und Linkerscripte selbst
>schreiben.


Beim Cortex M3 beschränkt sich der Startupcode allenfalls aufs Kopieren 
der initialisierten Daten vom Flash ins RAM (in C!) sowie das Löschen 
des .bss-Segments. In letzterem Fall sind das genau 7 Assemblerbefehle, 
die für alle Programme gleich sind. Das sollte keinen abhalten.

Z.B. so:
void
ResetISR(void)
{
    unsigned long *pulSrc, *pulDest;

    pulSrc = &_etext;
    for(pulDest = &_data; pulDest < &_edata; )
    {
        *pulDest++ = *pulSrc++;
    }

    __asm("    ldr     r0, =_bss\n"
          "    ldr     r1, =_ebss\n"
          "    mov     r2, #0\n"
          "    .thumb_func\n"
          "zero_loop:\n"
          "        cmp     r0, r1\n"
          "        it      lt\n"
          "        strlt   r2, [r0], #4\n"
          "        blt     zero_loop");

    main();
}


Auch das "Linkerskript" kann man - insbesondere als Anfänger - klein und 
überschaubar halten und auch immer wieder verwenden. Hier ein Beispiel 
für einen Luminary LM3S1968 mit 256KiB Flash und 64KiB Ram:
MEMORY
{
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256K
    SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 64K
}

SECTIONS
{
    .text :
    {
        KEEP(*(.isr_vector))
        *(.text*)
        *(.rodata*)
        _etext = .;
    } > FLASH

    .data : AT (ADDR(.text) + SIZEOF(.text))
    {
        _data = .;
        *(vtable)
        *(.data*)
        _edata = .;
    } > SRAM

    .bss :
    {
        _bss = .;
        *(.bss*)
        *(COMMON)
        _ebss = .;
    } > SRAM
}


Mehr braucht kein Anfänger.

Autor: marais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine Meinung, nur mein persönlicher Erfahrungsbericht:

Ich mache seit 1980 Assembler - zunächst 6502, bald auch in grösserem 
Stil, dann ab 1986 Motorola 68k, mit Derivaten (93C100, 68332) bis in 
die späten 90er Jahre. Als man damit kein Geld mehr verdienen konnte, 
bin ich auf C++ umgestiegen. Vor einem Jahr habe ich wieder mit 
uControllern angefangen und mir auch die Frage gestellt, PIC, Atmel oder 
TMS430.
Eigentlich gefällt mir der TI am Besten (ich hatte 98 mal einen 
Kurzausflug zum TMS 370 gemacht, dann aber abgebrochen - heute kennt ihn 
keiner mehr), die Architektur ist sehr geradlinig, geringer 
Stromverbrauch, sympathische Mnemonics, irre viel Peripherie und vor 
allem: Die sprichwörtlich gute TI-Dokumentation. Allerdings möchte ich 
eine halbwegs vernünftige Auswahl an Chips im DIL-Gehäuse, da ich für 
Hobbyprojekte kein SMD will. Die Pics habe ich wegen der Banking-Sache 
und des kruden Befehlssatzes früh ausgeklammert, und letztlich habe ich 
mich für Atmel entschieden.

- gute kostenlose Entwicklungsumgebung für ASM und C
- ordentlicher Befehlssatz
- viele DIL-Packages
- weit verbreitet, daher viel support im Netz zu finden
- leicht erhältlich

Um keine Zeit zu verlieren, habe ich das STK500 gekauft und in sehr 
kurzer Zeit meine ersten kleineren Sachen in ASM gemacht. Mit dem 
C-Compiler bin ich auch sofort gut zurecht gekommen (das war auf dem 68k 
mit einer richtig teuren "professionellen" Entwicklungsumgebung doch 
deutlich schwieriger). Ich bin mit dieser Wahl sehr zufrieden und bin 
froh, nach 10 Jahren Pause wieder embedded Entwicklung zu machen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.