www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Einsteiger, Anfänger - Welche Mikrocontroller-Familie?


Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Vor vielen Jahren habe ich mich als SW-Entwickler mit Mikrocontrollern 
beschäftigen (müssen). Danach jedoch nie wieder damit zutun gehabt. 
Trotzdem haben mich diese kleinen Knechte immer fasziniert. Jetzt möchte 
ich gerne über ein kleines Projekt wieder einsteigen, fühle mich 
diesbezüglich aber mittlerweile eher als blutiger Anfänger.

Mit welcher Mikrocontroller-Familie sollte ich mich befassen?
AVR, ARM, PIC, 8051, TI etc. etc.?

Ich würde gerne vorwiegend in einer Hochsprache programmieren, 
vorzugsweise C. Schön wäre natürlich möglichst viel freie 
Entwicklungstools und die Möglichkeit des On-Chip-Debuggings mit 
Source-Code-Unterstützung (wie bei einem modernen ICE).

Wenn ich mich schon wieder neu einarbeite und lerne, dann sollte es 
schon eine Familie sein, die für kleine bis größere Projekte viel 
Potenzial bietet und eine weite Verbreitung hat. Ich würde nur ungern 
den Einarbeitungsaufwand und Lernaufwand in eine unmoderne oder 
veraltete Familie oder Architektur stecken.

Ich habe die Entwicklungs-Boards von http://www.mikroe.com entdeckt. Zum 
Einsteigen, Lernen und Testen scheinen diese ja ideal zu sein. Das 
fertige Projekt kann man ja dann auf ein kleineres Prozessormodul 
übertragen und im Endgerät einsetzen. Sehe ich das richtig?

Könnt Ihr mir bitte helfen?

Viele Grüße
Bernhard

Autor: jÜrgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach ist ein 8-bitter der 8051 Familie am besten zum 
Einsteigen... die Datenblätter sind äußerst schön gestaltet (das meiste 
ist aus Diagrammen & Blockschaltbildern zu erkennen)

Die Programmierung ist auch nicht allzuschwer...

Autor: jÜrgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso... hab ich nicht weit genug gelesen... sry...

wenn du wirklich was topaktuelles haben willst beschäftige dich mit 
einem ARM7... aber da wirst du uns im forum viel schreibarbeit bescheren 
^^

Autor: Zip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am Einfachsten und günstigsten in Sachen Tools sind AVR und PIC. Ich hab 
mal mit PIC gearbeitet, mich dann jahrelang an deren 16bit Umgebung und 
Registerbanking geaegert, dann auf AVR umgestiegen, und jetzt 10 Jahre 
spaeter aerger ich mich an den AVR. Reslistischerweise kann man beide 
als etwa  gleichwertig betrachten. Beide brauchbar und günstig.

Z.

Autor: _JoAs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein einfaches und günstiges Entwicklungsboard ist meiner Meinung nach 
das UCAN Startkit von Infineon für den XC164CM:
http://www.infineon.com/cgi-bin/ifx/portal/ep/chan...

Der XC16x-Familie ist ein 16bit-Controller und der Nachfolger für den 
C16x.

Große Vorteile:
- Sehr günstig
- Umfassendes Zubehör
- Einfach
- Wird über USB an einer Rechner gesteckt und auch das Debugging 
funktioniert darüber..

Gruß
jo

Autor: Kenner der Mikrocontroller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich empfehle den MSP430. Er hat eine 16-Bit Von Neumann-Architektur und 
ist sehr sauber und modern designet. Außerdem gibt es mit dem GCC auch 
einen exzellenten C-Compiler und man kann ihn über JTAG Debuggen.

Autor: MB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR für Immer :)

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ohne gross zu diskutieren: AVR.

Gruss

Michael

Autor: Wolf,DL2WRJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ARM,
in der Industrie wird viel der IXP4xxx verwendet. Durch die 
Beschäftigung mit dem ARM kann man dafür die Grundlagen erlernen. 
Ansonsten  AVR ist trotzdem mein Favorit.

Wolf

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist schlicht und einfach, wie groß willst du deine Projekte 
machen?

Reichen dafür 8051, AVR oder PIC? Dann such dir was in der Größe aus.
Welche Architektur du davon wählst ist Geschmacksache.
Mir kommt kein AVR oder PIC auf dem Tisch.

Wenn nicht dann geh direkt zu ARM7 und vergeß die kleineren.  Sonst 
fängst du nach einer Weile mit dem Einarbeiten von vorne an.

Gruß
Ralph

Autor: jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Sonst fängst du nach einer Weile mit dem Einarbeiten von vorne an.

Das ist sowieso nicht zu vermeiden. Das Beste dürfte immer noch sein,
einfach mit einem (nicht zu komplexen) µC anzufangen. Spätestens nach
einem Vierteljahr weiß man ganz gut, ob dies das Richtige ist.

Autor: snwoman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du dich für die PICs entscheidest, lege ich dir www.sprut.de ans 
herzen: auch wenn dort fast alles anhand der 16er-familie erklärt ist, 
kann man es 1:1 auf die moderne 18er-familie übernehmen (18er-familie 
erleichtern einem vieles und haben all die negativen eigenschaften der 
16er nicht mehr - wie z.b. die oben erwähnten bänke). ich favorisiere 
die 18er-PICs

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde auch zu den 8-Bittern (8051, AVR) raten.

Der große Vorteil ist, man kann damit schnell schnuckelige Projekte 
aufbauen ohne erst ne Platine machen zu müssen.
So ein 20-Pinner ist schnell aufn Stück Rasterplatine draufgepappt.

Und für Batteriebetrieb brauchen die Low-Voltage-Typen (1,8..5,5V) nicht 
mal nen Spannungsregler, ne Li- oder 2..3 AA-Zellen, fertig.


Dagegen ist so ein ARM7 erstmal ne Menge Hardware-Wuselei, ehe überhaupt 
was läuft.

Und wenn man nen 8-Bitter beherscht (in C), dann fängt man beim ARM auch 
nicht von vorne an.
Die zusätzlichen Eigenheiten (z.B. spurious Interrupt Handler), lernt 
man schnell.


Ich finde, das ist ja gerade der Reiz an MCs, das man viele Sachen damit 
aufbauen kann und dann gleich verwenden.
Ich hatte früher ein 8051-Board mit Boot-EPROM und SRAM, macht überhaupt 
keinen Spaß, wenn man für ein neues Projekt das alte erst einreißen muß, 
weil man nur ein Entwicklungsboard hat.
Dagegen so ein moderner 8-Bitter ist quasi das komplette 
Entwicklungsboard in einem Chip.


Peter

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sich für eine Familie zu entscheiden und dabei zu bleiben zu wollen ist 
ein Ansatz - mir ist der indes zu langweilig. Natürlich sieht das anders 
aus, wenn man hunderte bis tausende Euros in Entwicklungssysteme 
investiert. Muss man aber nicht, viel geht auch mit freien Tools.

Und man profitiert eher davon, wenn man nicht ewig beim Gleichen bleibt. 
So schlimm ist ein Umstieg nämlich garnicht.

Wie Peter schon dargelegt hat: Um mal eben ein LCD an einen CAN-Bus zu 
hängen, ist ein ARM7 zwar auch einsetzbar, aber eigentlich viel zu 
komplex. Andererseits beobachte ich hier Leute, die mit den Probleme 
kämpfen, die ein Mega128 bei der Adressierung seines für die Architektur 
eigentlich schon zu grossen Speichers aufwirft. M.a.W: AVR für die 
kleineren, ARM für die grösseren Dinge.

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dagegen ist so ein ARM7 erstmal ne Menge Hardware-Wuselei, ehe überhaupt
> was läuft.

naja, nimmt man z.b. einen atmel at91sam7xxx-typ, dann ist das auch 
nicht so viel bastelei.
@OP: wenn du mit einem kleinen 8-bitter anfängst, dann musst du dich 
zwangsläufig damit auseinandersetzen, wie man möglichst effektiven und 
resourcensparenden code schreibt. das 'gute design' einer software, wie 
modularer aufbau und portierbarkeit etc. tritt damit in den hintergrund 
zu gunsten von laufzeiteffizienz und geringem RAM-bedarf. ein grosser 
controller mit z.b. 512K flash und 64K ram bietet da mehr möglichkeiten 
(du kannst plötzlich sinnvoll 'malloc' einsetzen, ein RTOS usw.).

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wau, ich bin baff! So viel und ausführliche Resonanz auf meine Anfrage. 
Ich bin total begeistert! Vielen Dank!

Ich bitte um Verständnis, dass es jetzt noch mehr Fragen sind als 
vorher.
:-)

Mir ist klar geworden, dass es sehr viele, sehr gute Mikrocontroller 
gibt. Irgendwie scheint es aber auch eine Frage des persönlichen 
Geschmacks zu sein und das kann ich gut verstehen. Es kristallisieren 
sich für mich zwei Familien heraus, die offenbar eine große Fangemeinde 
besitzen und somit auch viel "freie" Anwendungserfahrung existiert - AVR 
und ARM. Irgendwie sind mir die ARMs sympathischer, aber das ist nur ein 
Bauchgefühl, nachdem ich mich ein wenig eingelesen habe. Die AVRs reizen 
durch Ihre Einfachheit, dem Beginn bei niedrigen Leveln und offenbar 
sehr guten "Basteleigenschaften".

Ich bin jetzt wieder auf Mikrocontroller aufmerksam geworden, da ich ein 
kleines Projekt für eine befreundete Firma lösen möchte (Hobby). Ein 
zentraler Steuerrechner soll über einen Bus (I2C?) in zwei abgesetzten 
(je 10m und mehr), identisch aufgebauten Geräten eine größere Anzahl (je 
Gerät bis zu 48) Relais steuern (über I2C I/O-Port-Expander). Der 
Steuerrechner soll über ein Display verfügen, der den 
Betriebsszustand/Einstellungen der Endgeräte anzeigt. Der Steuerrechner 
soll die Möglichkeit der Fernbedienbarkeit über eine IR-Fernbedienung 
bieten. Zu diesem Projekt hätte ich noch ein paar HW-Fragen, aber dazu 
mache ich wohl besser einen eigenen Thread auf. Das wäre mein 
Einstiegsprojekt. Sicherlich mit allen genannten Mikrocontrollern 
(leicht?) lösbar.

Ich habe im Internet gesucht und bin u.a. über MyAVR.de gestolpert. So 
habe ich mich über die AVRs/ATmegas informiert. Ich hatte mich jetzt 
schon fast entschieden, aber als ich mich über die ARM-Prozessoren 
informierte, kam mir, wie gesagt, einfach die Idee, dass es vielleicht 
eine Familie gibt, die von kleinen bis größere Projekte alles gut 
abdeckt und ich nicht jedesmal neu lernen muss oder investieren muss.

Was für mich wichtig ist, sind preisgünstige, möglichst freie aber 
leistungsfähige Tools, die auch das In-Chip-Debugging auf 
Source-Code-Level (vorzugsweise C) komfortabel beherrschen (Breakpoints, 
Conditional Breakpoints, Variablen/Registerzustand, Einzelstep etc.). 
Unterstützen das die freien Tools für AVR und ARM? Ein bisschen 
Assembler für kleine und effiziente Unterroutinen ist natürlich o.k. und 
meist notwendig.

Peter Dannegger (peda) hat für mich aber einen entscheidenden Punkt 
erwähnt: die unkomplizierte Anbindung von HW an den Prozessor. Wenn ich 
für einen ARM jedesmal eine Platine machen (lassen) muss, um man ein 
paar Relais oder Taster anzubinden, dann ist das nicht so toll. Ein 
schneller Testaufbau auf einem Steckbrett sollte schon möglich sein.

Ich habe aber vereinzelt gesehen, dass es auch von den ARM-Prozessoren 
kleine sog. Tiny-Module gibt (40pin), die man z.B. auch auf einem 
Steckbrett einsetzen kann. Oder ist das bei den ARMs schon wesentlich 
komplizierter als bei den AVRs? Muss man denn bei einem ARM immer mit 
viel Grundaufwand rechnen? Eine Batterielösung für Mini-Projekte kommt 
bei ARM wohl nicht in Frage? Welche Probleme müsste ich aufgrund des 
3.3V-Designs beim ARM erwarten?

Ich möchte natürlich zuerst gerne kleine Projekte lösen, vielleicht auch 
einmal ein paar Sensoren und eine kleine Steuerung. Aber auch größere 
Projekte z.B. die Anbindung eines Grafikdisplays für eine 
benutzerfreundliche Bedienerführung würde mich interessieren. Ich denke 
spätestens wenn es an eine MPEG-Dekodierung oder ähnliches geht, muss es 
dann doch ein leistungsfähigerer Prozessor sein. Wäre es denn so, dass 
wenn ich mit einem ARM7 klarkomme, ein Umstieg auf einen ARM9 oder höher 
dann weniger Probleme bereitet?

Wäre es ein Fehler, mit der ARM7-Architektur statt AVR einzusteigen, um 
nach oben ein wenig mehr Leistungsreserven zu haben als mit der 
AVR-Architektur? Ist der Einarbeitungsaufwand bei den ARM sehr viel 
größer als bei den AVR?

Was haltet Ihr von den Entwicklungs-Boards BigAVR oder EasyARM von 
http://www.mikroe.com ?

Für mein Projekt würde ich gerne im fertigen Gerät einen kleinen, 
preisgünstigen ARM einsetzen (wenn es das gibt). Möglichst ein 
Tiny-Modul, um den Entwicklungsaufwand rund um dem Prozessor gering zu 
halten. Ich entwickle auf einem "großen Board/Prozessor" z.B. EasyARM 
und übertrage die Firmware später in die Zielhardware. Ist das bei den 
ARMs ein Problem? Welche Bezugsquellen kennt Ihr für preisgünstige ARM 
Tiny-Module?

Wäre das Interrupthandling bei den ARMs wirklich so schwierig zu 
verstehen oder bekommt man das leicht in den Griff?

Ihr merkt schon, ich bin noch unentschlossen, tendiere aber irgendwie zu 
den ARMs.

Vielleicht könntet Ihr mir bitte noch ein paar Einsichten liefern und 
meine Fragen, soweit möglich, bitte beantworten.

Nochmals vielen Dank!

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bus (I2C?) in zwei abgesetzten (je 10m und mehr)

Der normale I2C hört bei ~1m auf. Es gibt zwar Verlängerungsmöglichkeit, 
aber empfehlenswert ist das eigentlich nicht. Sowas ist die Domäne von 
RS485 (single master) und CAN (multi master).

Man kann mittels solcher Module konsequent auf ARM setzen. Wenn es egal 
ist, dass ein LPC2103- oder SAM7S-Modul so ab dem zehnfachen eines Mega8 
kostet.

> MPEG-Dekodierung

Wenn das auch noch in Echtzeit erfolgen soll, dann sind alle hier im 
Forum üblichen Microcontroller aus dem Rennen. Das läuft dann auf ein 
paarhundert MHz oder Spezialhardware hinaus, in jedem Fall aber 
unfreundliche BGA-Gehäuse oder entsprechende Module.

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich würde gerne vorwiegend in einer Hochsprache programmieren,
>vorzugsweise C.

spiel erst mal ein bisschen mit assambler, z.b. mit einem pic (gratis 
tools...)...

wenn du die grundsätzliche funktionsweise verstanden hast, würd ich erst 
anfangen mit C zu programmieren...

Autor: Steven Wetzel (steven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sandro wrote:
>>Ich würde gerne vorwiegend in einer Hochsprache programmieren,
>>vorzugsweise C.
>
> spiel erst mal ein bisschen mit assambler, z.b. mit einem pic (gratis
> tools...)...
>
> wenn du die grundsätzliche funktionsweise verstanden hast, würd ich erst
> anfangen mit C zu programmieren...

Um einen Controller vernünftig programmieren zu können, muss man kein 
Assembler können. Eine Multiplikation in Assembler stellt sich 
grundlegend anders da, als in C und es hilft der Entwicklung kein wenig, 
wenn ich mir die Multiplikation in Assembler anschaue.

Weiterhin hilft es mir wenig, mich mit dem Paging beim PIC auseinander 
zu setzen. Das sind üble Altlasten und bescheren nicht selten 
stundenlanges Suchen.

Man sollte von der veralteten Meinung wegkommen, nur derjenige könne 
einen µC gut programmieren bzw. beherrschen, der Assembler kann. Das ist 
Hinterhofdenken und wirklich nicht mehr zeitgemäß.

Der Trend geht ganz klar zu grafischer Programmierung, bei der man sich 
um die Lösung kümmert und nicht um den Code. Ein Paradebeispiel ist der 
Sigma-DSP von ADI. Man kann in wenigen Minuten eine komplette 
Signalverarbeitung mit z.B. 8 Audiokanälen fertigstellen. Ich möchte 
dich mal sehen, ob du das in Assembler in weniger als einer Woche 
schaffst.

Assembler empfiehlt sich wirklich nur dann, wenn es auf das letze Byte 
ankommt oder auf das taktgenaue Timing.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steven Wetzel wrote:

> Der Trend geht ganz klar zu grafischer Programmierung, bei der man sich
> um die Lösung kümmert und nicht um den Code. Ein Paradebeispiel ist der
> Sigma-DSP von ADI. Man kann in wenigen Minuten eine komplette
> Signalverarbeitung mit z.B. 8 Audiokanälen fertigstellen.

Grafische Programmierung wird immer als super einfach dargestellt, isses 
aber nur solange, wie auch die Projekte einfach sind.

Du kannst praktisch nur solche Sachen machen, die der Entwickler der 
grafischen Tools vorausgedacht hat.

Sobald die Applikation aber ein bischen umfangreicher wird, bist Du 
schnell am Ende.

Eine mittlere Applikation aus etwa 10.000 C-Zeilen kannst Du unmöglich 
mehr grafisch überblicken.


Peter

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heuzutage kosten nano-ITX Rechnern mit alles "on-board" weniger als 
150€. Du kriegst 800MhZ CPU, Soundkarte, Ethernet, LPT, COM, Tastatur, 
VGA usw.

Alles ist auf Platine 12x12cm, kleiner als viele AVR oder ARM Projekten.

Mikrocontroller braucht man NUR für portable sachen, die brauchen wenig 
Strom . Und dafür benutzt man auf keinem fall AVR oder ARM. Sie sind zu 
hungrig auf Strom. ARM kosten komisherweise viel für was sie anbieten.

Ich empfehele dir MSP430 für Kleinigkeiten und nano-ITX VIA für grossere 
Dinge. MSP von TI hat gcc, glibc. Billigste MSP430 kostet weniger als 
zwei euro, hat DIP Gehäuse. Er ist ganz gut im Linux zu programmieren.

Auf nano-ITX läuft normalerweise Linux. Um zu programmieren, einfach 
Display und Tastatur anzuschliessen. Aber vergiss über Akku-betrieb.

Autor: snowman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich bin der meinung, dass man mit C schneller zum erfolg kommt und das 
ist gerade am anfang sehr wichtig. in einem 2. schritt kann man sich 
immer noch um assembler bemühen um codoptimierter zu programmieren oder 
um ein besseres verständnis des compilers zu bekommen.

ps: die neuen 18er-PICs haben keine bänke mehr (kein umschalten mehr). 
mich wunders immer wieder, dass diese alte gerücht so standhaft 
propagiert wird

Autor: Steven Wetzel (steven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

> Grafische Programmierung wird immer als super einfach dargestellt, isses
> aber nur solange, wie auch die Projekte einfach sind.

Ich denke nicht, dass die DSP-Projekte für den Sigma-DSPO einfach sind. 
Abgesehen davon tut man sich sehr schwer, diesen nicht im Sigmastudio zu 
programmieren. Es ist leicht, einen Vergleich zwischen Visual DSP und 
Sigmastudio anzustellen. Compressor, Limiter, Filter müssten alles in 
Biquads erledigt werden. Der Programmieraufwand ist dabei sehr hoch. In 
Sigmastudi klickt man sich wirklich seine Lösung zusammen und so, wie es 
Libraries gibt, die die Funktionen in Assembler abbilden, so geht das 
auch in einer grafischen Umgebung.

Nehmen wir eine Sensorschaltung für einen beliebigen µC, sagen wir, wir 
messen Spannung. Eine grafische Umsetzung gestaltet sich sehr einfach. 
Man nehme den ADC-Block, definiere den Eingangsbereich und den 
Anzeigeblock und definiere dortg die Art der Darstellung. UART 
gewünscht? kein Problem. Ein Klick und die UART ist drin. Was heute in 
Funktionen und Codeschnipsel verbreitet wird, lässt sich auch grafisch 
erstellen.

Warum muss man für einen MP3-Dekoder immer und immer wieder dasselbe 
schreiben? Ein fertiger Block reicht völlig aus und ob die Daten nun als 
Funktionsparameter übergeben werden oder als Leitung dargestellt werden, 
ist irrelevant.

> Du kannst praktisch nur solche Sachen machen, die der Entwickler der
> grafischen Tools vorausgedacht hat.

Du kannst alles machen, was sich Funktion nennt. Programmiert man öfters 
µCs, wird man immer wieder auf dieselben Funktionen treffen. Im Grunde 
klickt man dann erst mal das Grundgerüst zusammen und füllt dann aus. Da 
geht auch grafisch. Schon mal den Codevision AVR gesehen? Ohne auch nur 
einmal den Code anzufassen, kann man sich eine Ein-Ausgabe-Routine 
definieren und kümmert sich nur noch um die interne Verarbeitung der 
Daten.

> Sobald die Applikation aber ein bischen umfangreicher wird, bist Du
> schnell am Ende.

Das sicher. Aber dann definiert man für diese Funktion den nächsten 
grafischen Block. Überlege mal, wieviel Zeit vergeht, um erst mal das 
Grundgerüst fertig zu bekommen, d.h. Initialisierung und Ein-Ausgabe.

> Eine mittlere Applikation aus etwa 10.000 C-Zeilen kannst Du unmöglich
> mehr grafisch überblicken.

Das geht sogar sehr einfach, indem man die Funktionen gruppiert und dann 
beim Debuggen darin abtaucht, das ganze Design also hierarchisch 
aufbaut.

Der Erfolg von NI mit LabVIEW beruht eben vor allem darauf, weil man 
eben nicht mehr Programmierer sein muss, um eine Steuerung zu 
realisieren. Auch Matlab geht diesen Weg. Man erstell in Simulink ganze 
Regelkreise, auf Knopfdruck wird der dazugehörige VHDL-bzw. C-Code 
erzeugt.

Die Zukunft heißt zwangsläufig grafische Programmierung. Das sieht man 
auch an der Entwicklung:
http://en.wikipedia.org/wiki/Visual_programming_language

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die 16er gibt es immer noch und die meisten Topics drehen sich gerade um
>diese

Vermutlich, weil es dafür keinen (vernünftigen, bezahlbare) C-Compiler 
gibt.

>Der Erfolg von NI mit LabVIEW beruht eben vor allem darauf, weil man
>eben nicht mehr Programmierer sein muss, um eine Steuerung zu
>realisieren. Auch Matlab geht diesen Weg. Man erstell in Simulink ganze
>Regelkreise, auf Knopfdruck wird der dazugehörige VHDL-Code erzeugt.

Fischertechnik und Lego arbeiten auf diesem Sektor ausch schon länger.
Das muß aber noch lange nicht heissen, dass sie auch im Bereich der 
Controller sinnvoll/zweckmässig ist.
Ein gutes Quasi-Beispiel ist Bascom (ja, ich bin kein Freund davon - wer 
es mag, darf damit glücklich werden): Hier gibt es wie bei der 
grafischen Programmierung eine Menge vorgefertigter Bausteine. Leider 
ist das nicht besonders resourcenfreundlich, da man z.B. einen Timer nur 
für einen Baustein benutzen kann - in einer "normalen" 
Programmiersprache wäre es auch möglich mehr, als nur diese eine Aufgabe 
damit zu erschlagen.

>Die Zukunft heißt zwangsläufig grafische Programmierung. Das sieht man
>auch an der Entwicklung:
Auf diese Zukunft kann ich verzichten...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steven Wetzel wrote:

> Nehmen wir eine Sensorschaltung für einen beliebigen µC, sagen wir, wir
> messen Spannung. Eine grafische Umsetzung gestaltet sich sehr einfach.
> Man nehme den ADC-Block, definiere den Eingangsbereich und den
> Anzeigeblock und definiere dortg die Art der Darstellung. UART
> gewünscht? kein Problem. Ein Klick und die UART ist drin.

Sach ich doch, Du kannst nur das hinklicken, was vorher eingebaut wurde.

Das Problem ist doch nicht die UART, sondern daß ich darauf ein 
bestimmtes Protokoll implementieren muß.
Und ein Protokoll besteht nunmal aus ner Menge Text, da wüßte ich nicht, 
wie man sowas grafisch machen soll.


Und was mir am meisten an der Grafiksache fehlt ist die Zeitebene.
Man hat überhaupt keine Übersicht über den Zeitablauf.
Ich muß aber ne Menge Zeitabhängigkeiten prüfen und Zeitabläufe 
programmieren.
Prozesse dürfen nur ne bestimmte Zeit dauern bzw. müssen eine bestimmte 
Zeit nach einem anderen ausgeführt werden, oder müssen nach einer 
bestimmten Zeit abgebrochen werden.


Und so einfach nen ADC hinpappen, damit ists auch noch lange nicht 
getan.
Wenn ich z.B. nen Regelkreis programmiere, kann man das nicht so einfach 
hinschreiben, wie es in der idealen Theorie aussieht.
Ich muß auch da spezielle Bedingungen einbauen, um die Werte auf 
Gültigkeit zu prüfen, bei Änderungen ein schnelles Einschwingen zu 
erreichen, im Regelzustand ein Schwingen zu erkennen und abzubauen usw.


Das Allgemeine kann ich mir genausogut auch in C aus Bibliotheken 
zusammenklicken.
Aber sobald es speziell wird, ist Handarbeit angesagt und dabei wüßte 
ich nicht, wie ich es grafisch wuppen können soll.


Peter

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard,

ich kann deine Suche nach der Eierlegenden Wollmilchsau verstehen aber 
das ist der falsche Weg.

Für einfache Aufgaben reichen die 8 und 16 BIT MC's allemal. Also 
vielleicht nochmal zusammenfassend:

MSP-430, Freier C Compiler: http://mspgcc.sourceforge.net/
8x51, C Compiler: http://sdcc.sourceforge.net/
AVR, C Compiler: http://winavr.sourceforge.net/

Fang einfach mit irgendeiner dieser 3 Familien an. Kosten sind minimal 
und dann siehst du weiter.

Für dein Einsteigerprojekt reichts allemal.

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>MSP-430, Freier C Compiler: http://mspgcc.sourceforge.net/
>8x51, C Compiler: http://sdcc.sourceforge.net/
>AVR, C Compiler: http://winavr.sourceforge.net/

für AVR lieber ein normales GCC Compiler, der man als Standart Compiler 
unter Linux, FreeBSD, MinGW für Windows, MacOSX benutzt.


Einfach 'man gcc' in deinem Terminal eintyppen, dann '/' drücken und 
'avr' eintyppen, und press Return um ganzen list von optionen zu sehen.


Was du brauchst, ist avr-libc:
http://www.nongnu.org/avr-libc/

Ich empfehele dir Gentoo Linux, da kann man alle notwendige programme 
sehr einfach installieren:

emerge cross-avr/gcc
emerge cross-avr/binutils
emerge avrdude
emerge avr-libc

Autor: Zip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Graphische Programmierung ist gut unter 3 Gesichtspunkten.
1) Der Rechner ist massiv überdimensioniert
2) Der Benutzer hat keine Ahnung und keine Interesse
3) Der Benutzer hat satt Knete

Z.

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmals vielen herzlichen Dank! Eure Meinungen haben mir sehr geholfen, 
eine Entscheidung zu treffen.

Wenn ich das alles so lese, dann sieht es so aus, als würde ich mich für 
AVR entscheiden. Der ARM wäre interessant, ist aber für meine 
Bedürfnisse derzeit noch völlig überdimensioniert und doch recht komplex 
für den Anfang, der "Spontanbastelfaktor" ist nicht so attraktiv.

Der TI MSP430 wäre hochinteressant und würde mir gut gefallen, da volle 
16 Bit-Architektur, moderne und leicht verständliche Architektur und es 
gibt preisgünstige aber auch leistungsfähige Typen. Leider scheint auch 
hier die "Spontanbasteleignung" (3.3V) eingeschränkt, die Cummunity ist 
eher klein und die freien Tools aus meiner aktuellen Sicht nicht so 
vielfältig, wie beim AVR. Das Angebot an "größeren" Eval-Boards (inkl. 
Display, Ports etc.) und Prozessormodulen ist auch eher gering. Ich 
bitte um Korrektur, falls ich mich irre.

Der AVR ist für meine aktuellen Projekte völlig ausreichend. Und wie 
einige bemerkten, muss ich erst wieder in Fahrt kommen, bis ich mich auf 
ein komplexeres Projekt einlassen kann. Dann kann ich ja noch immer auf 
eine leistungsfähigere Familie umsteigen, wenn ich wieder mehr Erfahrung 
habe. Der AVR bietet eine große Anwendergemeinde, viele freie Tools und 
Beispiele und auch in diesem Forum viel Unterstützung.

Was haltet Ihr von dem Entwicklungs-Board BigAVR von 
http://www.mikroe.com/en/tools/bigavr/ ?

Nicht gerade ein billiges Vergnügen, aber man kann bereits sehr viel 
ausprobieren und "spielen". Die endgültige Zielhardware im Fertiggerät 
kann ja dann ein kleinerer ATmega sein, oder sehe ich das falsch?

Für die Programmierung und das On-Chip Debugging (C - Source-Code-Level) 
benötige ich doch nur noch ein AVR-JTAG-USB, dann kann ich doch schon 
richtig mit AVR-Studio/WinAVR loslegen, oder?

Autor: Thomas S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde den ARM7 eigentliche recht einfach. Das ganze ist sehr 
zukunfts"fähig" und auch recht preiswert zu realisieren. Ich hab sehr 
lange 8051 angewendet, aber irgendwann ist da auch mal der Zug 
abgefahren. Die neueren ARM7 Derivate sind preiswert und ne ganze Ecke 
leistungsfähiger als 8 Bit Prozessoren. Wenn ich mir dann noch sowas wie 
den LPC2101..3 vom Preis her anschaue, gibts kaum noch ne ALternative.

Gruß Thomas

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es denn für den ARM7 eine komplette, komfortable 
C-Entwicklungsumgebung mit IDE/Editor und 
Source-Level-Debugger-Oberfläche wie beim AVR mit AVR-Studio/WinAVR? 
Oder muss man auf die kommerziellen Compiler/Debugger ausweichen, wenn 
man beim ARM7 diesen Komfort möchte?

Gehen wir einmal von einem (teuren) Tiny-Modul aus:
Ist denn der Aufbau von Streckbrett-Experimenten mit dem ARM7 ebenso 
einfach möglich? Stört denn unter anderem die 3.3V Architektur nicht bei 
diesen Spontanexperimenten und schränkt die Anwendbarkeit von vielen 
Bausteinen ein?

Autor: arc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gibt es denn für den ARM7 eine komplette, komfortable
> C-Entwicklungsumgebung mit IDE/Editor und
> Source-Level-Debugger-Oberfläche wie beim AVR mit AVR-Studio/WinAVR?
> Oder muss man auf die kommerziellen Compiler/Debugger ausweichen, wenn
> man beim ARM7 diesen Komfort möchte?

Wie bei MSP430, AVR oder eben auch bei den ARMs
Eclipse + CDT + entsprechende GCC-Variante.
Z.B. hier für den MSPGCC erklärt
http://inf.ntb.ch/infoportal/help/index.jsp?topic=...

> Ist denn der Aufbau von Streckbrett-Experimenten mit dem ARM7 ebenso
> einfach möglich?
Mit entsprechenden Adaptern (zumindest sind mir keine ARMs im 
DIL-Gehäuse bekannt). http://shop.mikrocontroller.net/

> Stört denn unter anderem die 3.3V Architektur nicht bei
> diesen Spontanexperimenten und schränkt die Anwendbarkeit von vielen
> Bausteinen ein?
Mittlerweile stört es eher, wenn man mit 5V arbeiten muss und dann 
modernere LCDs, OLEDs, RF-Transceiver, SDKarten, Flash-Speicher etc. 
anzubinden hat.
Auch für die Standardschnittstellen ala RS-232/485, CAN gibt es passende 
Treiberbausteine.

Autor: Steven Wetzel (steven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Sach ich doch, Du kannst nur das hinklicken, was vorher eingebaut wurde.

Wie bei einer C-Library auch.

> Das Problem ist doch nicht die UART, sondern daß ich darauf ein
> bestimmtes Protokoll implementieren muß.
> Und ein Protokoll besteht nunmal aus ner Menge Text, da wüßte ich nicht,
> wie man sowas grafisch machen soll.

Du wirst doch hoffentlich Standardprotokolle implementieren. Wie sieht 
denn heute eine typische UART-Transmission aus? UART initialisieren 
(Ports, BAUD-Rate), Daten ins Senderegister schreiben, abfragen, ob 
Daten gesendet wurden. Wie sieht es in Zukunft aus? Block nehmen, 
Leitung ziehen.


> Und was mir am meisten an der Grafiksache fehlt ist die Zeitebene.
> Man hat überhaupt keine Übersicht über den Zeitablauf.

Den hat man bei C ohnehin kaum. Diese ist compilerabhängig aber viele 
gute Compiler bieten ja dafür eine Schnittstelle.

> Ich muß aber ne Menge Zeitabhängigkeiten prüfen und Zeitabläufe
> programmieren.

Dann nimm Assembler oder einen C-Compiler, wo du genauestens die 
implementieren Funktionen aus der Lib kennst. Desweitern darfst du dann 
keine Optimierungsläufe machen.

> Prozesse dürfen nur ne bestimmte Zeit dauern bzw. müssen eine bestimmte
> Zeit nach einem anderen ausgeführt werden, oder müssen nach einer
> bestimmten Zeit abgebrochen werden.

Also Assembler.


> Wenn ich z.B. nen Regelkreis programmiere, kann man das nicht so einfach
> hinschreiben, wie es in der idealen Theorie aussieht.
> Ich muß auch da spezielle Bedingungen einbauen, um die Werte auf
> Gültigkeit zu prüfen, bei Änderungen ein schnelles Einschwingen zu
> erreichen, im Regelzustand ein Schwingen zu erkennen und abzubauen usw.

Ein Regelkreis, wie beschrieben, kann man heute in Simulink simulieren 
und sich den dazugehörigen Code ausspucken lasen. Das geht leider 
derzeit noch nicht bei kleinen µC, wobei man hier in unglaublicher 
Friemelarbeit den Code erzeugen muss und froh sein kann, wenn er das 
macht, was die Simulation zeigt.

> Das Allgemeine kann ich mir genausogut auch in C aus Bibliotheken
> zusammenklicken.
> Aber sobald es speziell wird, ist Handarbeit angesagt und dabei wüßte
> ich nicht, wie ich es grafisch wuppen können soll.

Zu allen grafischen Programmiertools gibt es immer noch die normale 
Programmierschnittstelle.

Man sollte nur von dem hohen Ross runter kommen, dass man eine 
entsprechende Persönlichkeit ist, wenn man einen µC programmieren kann. 
Heute ist es nicht wichtig, dass man programmieren kann und wie toll man 
das in Assembler schafft, sondern dass eine Lösung in kürzester Zeit 
aufweisen kann. Viele µC-Hersteller haben dies erkannt und bieten 
dementsprechend Tools an.

Steven

Autor: Yussew (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein Regelkreis, wie beschrieben, kann man heute in Simulink simulieren
> und sich den dazugehörigen Code ausspucken lasen.

Und hast du dir den Code mal angesehen? Er funktioniert zwar, ist aber 
dennoch unbrauchbar. In Basic wäre er effizienter zu programmieren.

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Man sollte nur von dem hohen Ross runter kommen, dass man eine
>entsprechende Persönlichkeit ist, wenn man einen µC programmieren kann.
Es ist schon was besonderes...

>Heute ist es nicht wichtig, dass man programmieren kann und wie toll man
>das in Assembler schafft, sondern dass eine Lösung in kürzester Zeit
>aufweisen kann.
Humbug. Wenn jemand einen Controller effizient per C oder Assembler 
programmieren kann, dann ist das auf jeden Fall besser, als wenn ein 
"Schimpanse"* irgendwelche Standard-Blöcke zusammenklicken kann, und das 
Programm zwar das gleiche wie das des "Experten" kann, dafür aber einen 
32Bit-Controller braucht, wo das andere mit einem 8bitter auskommt.

*)wie schon oben geschrieben: Lego und Fischertechnik bieten etwas 
derartiges an.

>Viele µC-Hersteller haben dies erkannt und bieten
>dementsprechend Tools an.
Wer, und welche?


>Geiz ist eben geil.Zeit ist auch Geld. Wenn ich für manche Aufgaben
>mehrer Monate, statt Stunden brauche, rechnet sich das allemal.

Wenn man aber aufgrund eines total überdimensionerten Controllers
zwar niedriege Entwicklungskosten hat, dafür aber hohe Stückkosten, wird 
dann doch mal nachgeguckt, ob sich da nicht doch etwas optimieren lässt.

>Wer seinen Lebenssinn in der Programmierung von µC sieht, anstatt in den
>Lösungen, der darf auch weiterhin in Assembler programmieren. Den Kunden
>interessiert aber das Produkt und nicht immer ist der Weg das Ziel.

Hat hier irgendwer davon gesprochen/geschrieben, dass Assembler das 
Allheilmittel ist?
Du lehnst dich ganz schön weit aus dem Fenster...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steven Wetzel wrote:

> Man sollte nur von dem hohen Ross runter kommen, dass man eine
> entsprechende Persönlichkeit ist, wenn man einen µC programmieren kann.

Man sollte von seinem hohen Roß runterkommen, daß Programmieren einfach 
ist und das einem grafische Tools die Programmierarbeit abnehmen können.


> Heute ist es nicht wichtig, dass man programmieren kann

Doch, genau das ist wichtig.


Mich kotzt das immer wieder an, wie grauenhaft Heimelektronoik 
programmiert ist.
Z.B. hatt ich mal nen Fernseher gekauft und mich gewundert, warum der 
Lieferant ihn beim Einstellen der Sender mit voller Lautstärke dröhnen 
ließ, das mir die Ohren schmerzten. Nun, im Sendermenü war eine 
Lautstärkeeinstellung nicht möglich.
Z.B. hatte ich einen Philips Videorekorder, der hätte auf der FB ein 
Grafikdisplay mit einer animierten Sanduhr haben müssen, so schnarchlahm 
war das Ding (und natürlich keine Taste gepuffert).
Dergleichen Beispiele lassen sich unendlich fortsetzen.


Programmieren ist, sich Gedanken zu machen und nen Plan (und auch ein 
kleines bischen Können). Das kann einem kein Tool der Welt abnehmen.


Man sieh ja ständig, was bei ner husch-husch Zusammenklickerei so 
rauskommt, nur der absolute Mist. Und der Kunde ärgert sich und kauft 
nie wieder ein Gerät bei dieser Firma.


Peter

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grafische Programmierung:

Ich bin Euch sehr dankbar, dass Ihr mir helft, aber die Diskussion über 
grafische Programmierung wäre doch besser in einem eigenen Thread 
aufgehoben. Das Thema ist bestimmt sehr interessant, aber es passt nicht 
so recht zu meinem aktuellen Problem und meinen Fragen. Bitte verschiebt 
das doch in einen eigenen Thread, sonst bläht sich dieser Thread unnötig 
auf. Lieben Dank!

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wieder eine Fredentführung, für die ich nicht verantwortlich bin.

@Bernhard:
Falls es dir noch nicht aufgefallen sein sollte (bzw. im Trubel um 
grafische "Programmierung" untergegangen sein sollte): Hier im Forum 
benutzt die Mehrheit AVR-Controller der Firma Atmel.
Die sind preiswert erhältlich, lassen sich mit dem AVR-GCC "komfortabel" 
in C programmieren und sind untereinander schön kompatibel (bis auf 
Controller ohne SRAM und durch unterschiedliche Namensgebung bei 
eigentlich gleichen Registern).
Andere Controller-Familien werden hier etwas stiefmütterlich behandelt 
(teils berechtigt... dafür gibt es aber auch sprut.de), aber auch bei 
entsprechenden Fragen wird hier einem geholfen.

Autor: snowman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieso bei 18er- und 30/33er-PICs berechtigt?

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rahul, der Trollige wrote:
> @Bernhard:
> Falls es dir noch nicht aufgefallen sein sollte (bzw. im Trubel um
> grafische "Programmierung" untergegangen sein sollte): Hier im Forum
> benutzt die Mehrheit AVR-Controller der Firma Atmel.
> Die sind preiswert erhältlich, lassen sich mit dem AVR-GCC "komfortabel"
> in C programmieren und sind untereinander schön kompatibel (bis auf
> Controller ohne SRAM und durch unterschiedliche Namensgebung bei
> eigentlich gleichen Registern).
> Andere Controller-Familien werden hier etwas stiefmütterlich behandelt
> (teils berechtigt... dafür gibt es aber auch sprut.de), aber auch bei
> entsprechenden Fragen wird hier einem geholfen.

Genau das ist es!
Ich würde gerne auf einem neuen, modernen und richtig "saftigen" 
Prozessor wie dem ARM7 anfangen. Wenn ich aber bei kleinsten Problemen 
erst alles selbst herausknobeln muss und ich dann ewig nicht weiter 
komme, dann macht es keinen Spaß. Oft ist weniger mehr und es haben mir 
neben Dir ja einige empfohlen "klein" anzufangen. Ich habe mich für AVR 
entschieden und werde mir jetzt als nächstes die Entwicklungs-HW 
bestellen.

Bitte noch eine wichtige Anfängerfrage, damit ich bestellen kann:

Mit einem ATmega128 Entwicklungsboard mit AVR-USB-JTAG von Olimex 
(http://www.olimex.com/dev/avr-usb-jtag.html) kann ich doch so richtig 
mit AVRStudio/WinAVR in C in einer IDE inkl. Oberfläche für 
Source-Level-Debugging loslegen, sehe ich das richtig?

Kann mir jemand eine günstige Bezugsquelle für das AVR-USB-JTAG 
empfehlen?

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mit einem ATmega128 Entwicklungsboard mit AVR-USB-JTAG von Olimex
>(http://www.olimex.com/dev/avr-usb-jtag.html) kann ich doch zunächst mit
>AVRStudio/WinAVR in C in einer IDE inkl. Oberfläche für
>Source-Level-Debugging loslegen, sehe ich das richtig?

Kennst du den Spruch mit Kanonen und Spatzen?
Das AVRStudio ist übrigens die "IDE inkl. Oberfläche für 
>Source-Level-Debugging", wenn man es auch noch mit dem AVR-GCCC 
"bekannt macht" kann man es auch als C-Editor benutzen (mir persönlich 
gefällt das Programmer's Notepad besser).
Vielen reicht der im AVR-Tutorium beschriebene Programmer (für den 
Anfang).
Praktisch sind auch das AVRISPmkII wegen seines USB-Anschlusses und das 
STK500, weil man das zum entwickeln/austesten und programmieren der 
Controller nutzen kann - auch lassen sich "totgefusete" Controller 
"wiederbeleben".

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich lobe hier nicht die grafische Programmierung in den Himmel.

Doch, tust du wohl.

>Was? Du kennst nur die Firma Atmel? Wie klein die Welt mancher Leute
>ist...

Nö, ich kenne auch ein paar andere.
Nur fallen diverse "Controller-Anbieter" nicht mehr in den Bereich, der 
für mich noch unter "Controller" fällt.
Freescale stellt auch nette "Controller" her...

>Max Planck

Höhö...und wieder ein Kieler...

>Ich schließe das mit dem wunderschön passenden Zitat von Max Planck ab:
Ich mit dem hier: "Du hast Recht, und ich meine Ruhe!"

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rahul, der Trollige wrote:
>Praktisch sind auch das AVRISPmkII wegen seines USB-Anschlusses und das
>STK500, weil man das zum entwickeln/austesten und programmieren der
>Controller nutzen kann - auch lassen sich "totgefusete" Controller
>"wiederbeleben".

Danke für die Tipps.

Ich habe mir das STK500 angesehen. Leider hat es keine 
JTAG-Schnittstelle und ist für das Gebotene relativ teuer. Es gibt 
günstigere Boards inkl. Display, LEDs, Taster etc. mit denen man zum 
Wiedereinstieg besser "spielen" kann. Wenn man viele unterschiedliche 
AVRs programmieren möchte, ist das STK500 natürlich ideal und dafür war 
es doch auch gedacht, nehme ich an.

Ist der AVRISPmkII neben dem AVR-USB-JTAG von Olimex sinnvoll oder 
notwendig?

Ich denke zwar nicht, dass ich mich gleich zu Anfang mit den Fuse-Bits 
auseinandersetzen werde. Aber habe ich das richtig verstanden, dass ich 
ein AVRISPmkII benötige, wenn ich z.B. einen ATmega128 "wiederbeleben" 
möchte?

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber habe ich das richtig verstanden, dass ich
>ein AVRISPmkII benötige, wenn ich z.B. einen ATmega128 "wiederbeleben"
>möchte?

Falsch verstanden/ausgedrückt.
Wiederbeleben kann man die Controller nur mit dem STK500 (oder einem 
anderen HV-Programmer).

Ich wüsste zwar nicht unbedingt, wofür man ein JTAGICE braucht (Kanonen 
und Spatzen...), aber damit kann man auch glücklich werden.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bejoro:

Zum "Wiederbeleben" benötigst Du nur das STK500-Mainboard, das die 
HV-Programmierung beherrscht. Das AVR JTAG mkII habe ich zwar, bin damit 
aber nicht so zufrieden. Das Olimex-Teil (Elektronikladen, EUR 49,90) 
gefällt mir viel besser.

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, dann lege ich los!
AVR-Board inkl. AVR-JTAG-USB wird bestellt. Sobald ich die ersten 
Gehversuche unternommen habe, werdet Ihr mit großer Wahrscheinlichkeit 
wieder von mir hören. ;-)

Ihr habt mir alle sehr geholfen! Vielen lieben Dank!

Ich freue mich schon auf meine ersten Programmiererfahrungen, ein 
erfreuliches und motivierendes Vorhaben, wenn man nach so langer Zeit 
wieder anfängt. Ich war mehrere Jahre SW-Entwickler bei Siemens, bis ich 
zum Manager mutierte. Ich bin aber immer im Herzen Ingenieur geblieben, 
weshalb mich dieser Wiedereinstieg motiviert und das Gehirn wieder auf 
trapp bringt.

Bitte streitet Euch nicht weiter bzgl. der Berechtigung grafischer 
Programmierung. Ich war einige Jahre u.a. Produkt- und Marketingmanager 
bei Siemens für Industriesoftware im Bereich Automatisierungstechnik und 
mache mich jetzt gerade als Unternehmensberater selbständig. Der Trend 
geht eindeutig hin zur grafischen Projektierung mit anschließender 
automatischer Codegenerierung. Viele Anwender benötigen dies natürlich 
nicht oder lehnen es ab, das ist auch völlig o.k. Das ist so ähnlich wie 
der Übergang von reiner STEP5-Programmierung zur Programmierung mittels 
Kontakt- oder Funktionsplan. Das wurde zu Anfang auch abgelehnt. Als man 
aber feststellte, dass der Industrieelektroniker keine Tipps, Tricks, 
Spielereien und detaillierten Programmierkenntnisse mehr benötigt, um 
ein Programm zu erstellen oder zu verstehen, weil er es wie einen 
Schaltplan lesen konnte, kam langsam der Umstieg.

Wer als Hersteller für Automatisierungssysteme diesen Zug der modularen, 
grafischen Projektierung und automatischen Codegenerierung verpasst, der 
wird langfristig am Markt nicht mehr erfolgreich sein können.

Es ist somit nicht die Frage, ob die grafische Programmierung kommt, 
sondern wann. Wichtig ist jedoch dabei der Reifegrad. Auch hier wird es 
einen langen Prozess der Anpassung geben, bis auch die ausgefuchsten 
Programmierer zufrieden sind.

Wie bei vielen Industriezweigen wird sich auch hierbei wieder eine 
Verschiebung der Kompetenzen ereignen, wenn sich diese Form der 
Programmierung oder besser gesagt Projektierung durchsetzt. Wir 
benötigen dann diese ausgefuchsten Entwickler nicht mehr, um die 
resultierenden Entwicklungsumgebungen zu bedienen/anzuwenden, sondern um 
diese zu entwickeln.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das STK500 u. STK501 gibt's z.Zt. bei Reichelt recht günstig.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde den Mega128 total oversized für den Einstieg, den Mega8 oder 
Mega16 finde ich optimal. Aber ich will Dir nichts vorschreiben.

Ne große CPU verleitet schnell dazu, Spaghettikode (copy&paste-Monster) 
zu fabrizieren, wo man dann hinterher nicht mehr durchblickt.

Ne kleine CPU verleitet dazu, sinnvolle Unterfunktinen zu schreiben.


Ich hab mir auch mal einen Debugger angesehen, zum Lernen ist das ja 
ganz lustig, wenn man sich mal die verschiedenen Register ansehen kann.

Aber zum praktischen Programmieren taugt sowas überhaupt nichts, sobald 
man sich was ansieht, steht die CPU und die ganze Applikation ist zum 
Teufel.

Z.B. die Gegenstelle sendet fleißig weiter an die UART, aber dort kommt 
nur Müll an, weil ja durch das Stillstehen haufenweise Daten verloren 
wurden.
Und sämtliche Zeitabläufe krepieren auch.


Ich mach dann immer Ausgaben an die Stellen rein, wo ich was wisen will 
aber auch nur dann, wenn sie von dem Erwarteten abweichen und die werden 
dann "on the fly" z.B. über die UART gesendet. D.h. die Applikation kann 
ungestört weiterlaufen.


Peter

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Ich finde den Mega128 total oversized für den Einstieg, den Mega8 oder
> Mega16 finde ich optimal. Aber ich will Dir nichts vorschreiben.
>
> Ne große CPU verleitet schnell dazu, Spaghettikode (copy&paste-Monster)
> zu fabrizieren, wo man dann hinterher nicht mehr durchblickt.
>
> Ne kleine CPU verleitet dazu, sinnvolle Unterfunktinen zu schreiben.
>
>
> Ich hab mir auch mal einen Debugger angesehen, zum Lernen ist das ja
> ganz lustig, wenn man sich mal die verschiedenen Register ansehen kann.
>
> Aber zum praktischen Programmieren taugt sowas überhaupt nichts, sobald
> man sich was ansieht, steht die CPU und die ganze Applikation ist zum
> Teufel.
>
> Z.B. die Gegenstelle sendet fleißig weiter an die UART, aber dort kommt
> nur Müll an, weil ja durch das Stillstehen haufenweise Daten verloren
> wurden.
> Und sämtliche Zeitabläufe krepieren auch.
>
>
> Ich mach dann immer Ausgaben an die Stellen rein, wo ich was wisen will
> aber auch nur dann, wenn sie von dem Erwarteten abweichen und die werden
> dann "on the fly" z.B. über die UART gesendet. D.h. die Applikation kann
> ungestört weiterlaufen.
>
>
> Peter

Peter, keine Sorge! Du darfst mir gerne viele Tipps geben. Ich fühle 
mich nicht bevormundet. Ich weiß Deine Hilfe sehr zu schätzen.

Aufgrund meiner zwar zurückliegenden, aber mehrjährigen Erfahrung als 
SW-Entwickler, ist mir die Gefahr des "Quick-and-Dirty"-Programmierens 
bekannt. Ich werde versuchen diszipliniert zu programmieren. :-)

Mein erstes Projekt bei Siemens war die Entwicklung eines BDE-Terminals 
auf Basis eines Siemens 80C535. Wir arbeiteten mit einem sehr komplexen 
und leistungsfähigem 80C535-ICE, Protokollanalyzer und natürlich 
Life-Ausgaben.

Die Kombination aus ICE/Debugger und Life-Ausgabe z.B. über UART ist aus 
meiner Sicht optimal. Nicht jeder kann sich einen Protokollanalyzer 
leisten, so kann der PC helfen, die Ausgaben zu analysieren.

Das ICE oder der JTAG-Debugger nimmt einem natürlich nicht die 
Denkarbeit ab, die Ergebnisse zu interpretieren. Eine schöne Funktion 
dieses (damals sauteuren) 80C535-ICE war die Trace-Funktion, die es auch 
erlaubte dynamische Prozesse aufzuzeichnen und zu analysieren. Das war 
aber dann auch eine sehr zeitaufwändige Arbeit.

Ich werde mir natürlich auch einen Mega16 besorgen, ist ja kein Vermögen 
und einfach aufzubauen. Ein richtig schnuckeliges Prozessorchen mit viel 
Leistung.

Autor: Bernhard Rother (bejoro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter R. wrote:
> Das STK500 u. STK501 gibt's z.Zt. bei Reichelt recht günstig.

Ich bin noch unschlüssig, aber ich glaube ich werde mich für ein 
EasyAVR4 von mikroElectronica entscheiden. 
http://www.mikroe.com/en/tools/easyavr4/

Ich weiß, das ist ein Monsterboard, aber dort kann ich zum Start viel 
ausprobieren und "spielen" und alles einsetzen/programmieren, vom 
ATmega8 bis zum ATmega644.

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.