Forum: Mikrocontroller und Digitale Elektronik Wieso vor allem AVR µCs bei Bastlern?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Sandro (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hat es einen bestimmten Grund, dass viele Bastler AVR µCs verwenden aber 
nur wenige andere wie z.B. PIC. Oder hat sich das nur zufällig so 
eingebürgert.
Ich möchte wenn möglich keine Diskussion haben, ob PIC oder AVR besser 
ist, sondern nur eine Antwort auf meine Frage…

von Hans (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Günstig und gut dokumentiert

von Linux + Mac (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Für AVR gibt es sehr viel Open-source-Software und lizenzfreie Tools.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ Sandro (Gast)

>Hat es einen bestimmten Grund, dass viele Bastler AVR µCs verwenden aber
>nur wenige andere wie z.B. PIC.

PIC ist wahrscheinlich genauso weit im Einsatz unter Bastlern wie AVR. 
Nur weil diese Seite AVR-lastig ist, heißt das noch lange nicht dass es 
überall so ist.

von Oliver R. (orb)


Bewertung
0 lesenswert
nicht lesenswert
Für mich waren damals die Kosten für den Einstieg entscheident. Ein 
Programmiergerät für 100 DM oder 5 Widerstände am Parallelport. Bis 
jetzt hat sich kein Grund ergeben zu wechseln.

von Stephan B. (matrixstorm)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke auch das Arduino dem AVR (gegenueber PIC) einen riesen PUSH 
gegeben hat.

MfG

von asd (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Auch war ein kostenloser C Compiler bei AVR früher verfügbar, da hat 
Microchip/PIC erst nachgezogen als viele schon zu Atmel abgewandert 
waren.

von Billy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nun ja für mich waren beim Einstieg (vor ~12 Jahren) die hochsprachen 
Optimierung vorranging. Sprich gutern C-Compiler.

Außerdem gute Performance: 1-Befehl pro Takt.

Generell gefällt mir die Toolchain beim AVR besser, als die der PICs 
aber das ist Geschmackssache.

von Ulrich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da wird es mehrere Faktoren geben: Die AVRs waren so ziemlich die ersten 
mit integriertem Flash Speicher - sehr hilfreich wenn man viele Versuche 
braucht bis es funktioniert. Es gab auch schon recht früh einen guten 
freien C Compiler (GCC) für die AVRs. Der billige STK200 Programmer bzw. 
die noch billigeren Nachbauen (ggf. nur Widerstände am LPT Port) sorgen 
für eine sehr niedrige Einstiegshürde. Anders als einige japanische µC 
oder MSP430.. gibt es die größtenteils auch als DIL Version und nicht 
nur als SMD. Die Architektur ist auch relativ leicht zu verstehen und 
übersichtlich, so das auch die ASM Programmierung nicht so schwer ist.

In vieler Hinsicht sich die für Bastler wichtigen Voraussetzungen 
gegeben - fast so als wären die dafür gemacht. Dazu kommt dann noch ein 
gewisser Herdentrieb: Gute Verfügbarkeit und Projekte und 
Tutorials/Foren aus dem Netz führen dazu das Anfänger auch den AVR in 
Erwägung ziehen.

von Studentle (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Was für die AVR spricht / sprach: einfache Programmierung in C s.o. und 
1 Programmspeicher.

Bei den älteren PICs war noch ein Paging erfoderlich!

Was ich schon damit gekämpft haben...

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Falk Brunner schrieb:
> PIC ist wahrscheinlich genauso weit im Einsatz unter Bastlern wie AVR.
> Nur weil diese Seite AVR-lastig ist, heißt das noch lange nicht dass es
> überall so ist.

International gesehen stimmt das wahrscheinlich, wenn nicht sogar da der 
PIC bei den Bastlern Weltweit die Nase vorn hat.
Im deutschen Sprachraum ist der AVR im vergleich zum PIC bei den 
Bastlern sicher deutlich verbreiteter was wohl auch noch unabhängig von 
technischen Fakten sicher lange so bleiben wird.
Durch die größere Verbreitung der AVR im deutschen Sprachraum gibt es 
mehr "Einsteigeranleitungen" zum AVR in Deutsch was natürlich den 
Einstieg für viele "Deutsch-Muttersprachler" mit dem AVR leichter macht 
als mit dem PIC für den es nur in Englisch wirklich viel Literatur gibt.

In gewisser Form ein Kreislauf so lange sich die Eignung der µC nicht 
wirklich großartig unterscheidet.

Oliver R. schrieb:
> Für mich waren damals die Kosten für den Einstieg entscheident. Ein
> Programmiergerät für 100 DM oder 5 Widerstände am Parallelport. Bis
> jetzt hat sich kein Grund ergeben zu wechseln.

Einfache Programmiermöglichkeiten für die PICs mit ein paar Bauteilen 
für unter einer Mark an der seriellen Schnittstelle gabe es schon bevor 
die AVR überhaupt auf den Markt kamen.

Die AVR hatten zur Einführung einen anderen "großen" Vorteil. Die kamen 
mit einem sehr guten Preis/Leistungs Verhältniss (aus Bastlersicht) auf 
dem
Markt. Bastler brauch(t)en vor allem damals weniger viele Speziallösung 
als einen guten Individualisten. Und ein gut als Allrounder einsetzbarer 
µC kostete damals bei den AVr weniger als ein vergleichbar 
Leistungsfähiger voll ausgestatteter PIC.

Zudem gab es für die AVR recht schnell auch freie C Compiler die auf 
bezahlbaren µC brauchbare Ergebnisse lieferten. Bei den PICs war die 
versorgung mit freien Compilern damals quasi nicht vorhanden und 
überhaupt waren C Programme auf PIC nur in Verbindung mit der oberen 
Preisklasse (viel RAM/ROM) überhaupt Sinnvoll einsetzbar.

Daher hatten die AVR DAMALS einen ECHTEN Mehrwert im Vergleich zu den 
PIC und diesen dann den Rang abgelaufen. Heute ist die Situation 
natürlich völlig anders, aber drch das viel größere Angebot an 
Muttersprachlicher (online-) Literatur fangen hier immer noch mehr 
Einsteiger mit dem AVR als mit dem PIC an obwohl sich die beiden aus 
Einsteigersicht ansonsten nicht sehr viel geben...
(Wer hier häufiger liest wird wissen welche Familie ich einem Einsteiger 
empfehlen würde und auch warum... Aber das würde dann wieder zu einem 
PIC vs. AVR Thread werden)

Das aber bis vor kurzem in der Regel sich die Einsteiger nur zwischen 
PIC und AVR entschieden haben lag tatsächlich daran das es nur für diese 
beiden weit verbreitete Selbstbauanleitungen für billigste 
Programmiergeräte gab und selbst gekauft diese Sehr billig waren. Zudem 
war die Beschaffungssituation für reine Hobbyisten bei diesen beiden 
Familien im vergleich zu fast allen anderen Produkten viel besser. Als 
letzten waren das so ziemlich die ersten Mikrocontroller die man als 
Hobbyist problemlos kaufen konnte mit elektrisch Löschbaren "On Chip 
ROM".
Andere µC waren nur in der viel teureren Fensterversion nach manuellen 
Löschen mit der UV Lampe wiederschreibbar. Oder wenn man glück hatte und 
der µC das Unterstützte (Wie der SAB80C515 oder die MCS48 Serie die auf 
externen Programmspeicher umschaltbar waren) in Verbindung mit einem 
Externen (E)Eprom für die Programmentwicklung ohne teuren Emulator 
überhaupt einsetzbar.

Gruß
Carsten

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Studentle schrieb:
> Was für die AVR spricht / sprach: einfache Programmierung in C
> s.o. und 1 Programmspeicher.
> Bei den älteren PICs war noch ein Paging erfoderlich!
> Was ich schon damit gekämpft haben...

-> Ganz klar "SPRACH".
Aber darauf wollte ich nicht hinaus: EINEN Programmspeicher hatten die 
Pics auch immer schon.
Das Paging betraf das RAM, insbesondere ja die SFR...
Ist aber reine Übungssache. Da wurde viel geschrieben "Paging schwer 
schwer" aber für jemanden der sich da ernsthaft mit befasst hat war das 
nach wenigen Stunden gegessen. Es betraf in erster Linie ja nur gewisse 
SFR - beliebtes Beispiel PORTB auf Seite 0, TRISB aber auf Seite 1 - Das 
geht schnell ins Blut über, zumal man sich bei den PICs mit den damals 
nur ~34 Befehlen weit weniger merken musste als bei den AVR.

Aber das ganze Thema mit dem Paging betrifft selbst bei den kleinen µC 
wo es das heute noch gibt ja NUR diejenigen die noch in ASM schreiben. 
Sobald man in C Arbeitet spielt das gar keine Rolle mehr, da macht der C 
Compiler das schon selbstständig.

Gruß
Carsten

von Wilhelm F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die AVR und PIC sind halt programmierbare Bausteine. Ich blieb mal beim 
PIC12F675, weil ich nur zufällig an ein PICkit1 geriet, was auch als 
Programmer dient. Das versah ich noch nachträglich mit einem 
Nullkraftsockel, damit man den PIC leicht entnehmen und aufs Steckbrett 
setzen kann.

Wenn mir da jemand mit AVR vor dem PIC zuvor gekommen wäre, dann würde 
ich wahrscheinlich mit AVR basteln.

Vor dem PIC-Assembler scheue ich mich auch gar nicht, obwohl der manchen 
Leuten sehr schräg erscheint.

von Sandro (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Aber darauf wollte ich nicht hinaus: EINEN Programmspeicher hatten die
> Pics auch immer schon.
> Das Paging betraf das RAM, insbesondere ja die SFR...
Beim PIC16F788A ist es so, dass GOTO die Adresse 11bit breit liefert, 
wenn man ein mehr als 4kWord langes Programm hat muss man das PCLATH 
verwenden.
Bei PIC18 weiß Ichs jetzt nicht genau, da ich ihn nur in C programmiert 
habe, wenn ich das Datenblatt richtig verstanden habe, ist bei PIC18 der 
ROM nicht in Pages unterteilt.

von Sandro (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wilhelm F. schrieb:
> Vor dem PIC-Assembler scheue ich mich auch gar nicht, obwohl der manchen
> Leuten sehr schräg erscheint.
Mit PIC asm habe ich auch keine Probleme, aber ich habe mir kurz das 
Tutorial zu AVR-ASM angesehen und bin damit so nicht zurechtgekommen. 
Wenn man sich aber damit beschäftigen würde dürfte es auch Erlernbar 
sein…

von Wilhelm F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sandro schrieb:

> Wilhelm F. schrieb:
>> Vor dem PIC-Assembler scheue ich mich auch gar nicht, obwohl der manchen
>> Leuten sehr schräg erscheint.
> Mit PIC asm habe ich auch keine Probleme, aber ich habe mir kurz das
> Tutorial zu AVR-ASM angesehen und bin damit so nicht zurechtgekommen.
> Wenn man sich aber damit beschäftigen würde dürfte es auch Erlernbar
> sein…

Sicher, es ist eine Frage der Eingewöhnung. Besonders leicht und gut 
durchschaubar fand ich immer den 8051.

von Seano L. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Sandro schrieb:
> Hat es einen bestimmten Grund, dass viele Bastler AVR µCs
> verwenden aber
> nur wenige andere wie z.B. PIC. Oder hat sich das nur zufällig so
> eingebürgert.
Soviel ich weiss waren PIC in bei Pay-TV-Selbstbaudekodern mal führend, 
damals gab es AVR iirc noch gar nicht. Eisenbahnbastler haben auch schon 
immer mit dem PIC rumgewerkelt und tun es vermutlich heute noch.

Damals war halt noch die Zeit des EPROM-Brennens angesagt, UV-Lampe,... 
der ganze Mist, der nur genervt hat. Da war AVR mit Flash eine echte 
Offenbarung, zudem waren es RISC-Prozessoren, auch so ein 
Marketing-Zugpferd das damals viele anlockte, man kannte es von 
HIGH-End-Prozessoren (Boah! RISC in einem MC!!! Wie die MIPSe in den 
SGIs!einself!!), das war halt auch mehr Marketing anstatt dass die 
Geschwindigkeit ausschlaggebend gewesen wäre, die lahmsten MCs waren für 
die meisten Bastlerprojekte noch viel zu schnell ist heute auch nicht 
anders. Heute werden mit nem Raspberry-PI LEDs im Knightridermodus 
blinken gelassen und ne Pumpe geschaltet, früher hat man das mit ein 
zwei Logikbausteinen gemacht.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Als ich mir 2006 einen neuen Anfang mit Controllern gesucht habe waren 
AVR, PIC und MSP430 in der engeren Auswahl.
Für den AVR gab es das AVR-Studio inklusive mit WinAVR einen GCC dazu.
MPLab war auch Jahre danach noch einfach nur Mist im Vergleich und 
kostenlose, nicht eingeschränkte Compiler gab es nicht.
MSP430 konnte ich garnichts kostenloses finden.

von Sven P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Als ich mir 2006 einen neuen Anfang mit Controllern gesucht habe waren
> AVR, PIC und MSP430 in der engeren Auswahl.
Genauso gings mir auch, nur etwas früher.

Die Entscheidung brachten für mich dann zwei Punkte:
(1) Die Errata bei Microchip sind quasi immer rappelvoll und
(2) die Architektur der kleinen PIC ist scheiße.(*)


(*) Das ist oft Stein des Anstoßes.
Fairerweise muss man auch sehen, dass es die PIC mit ihrer Architektur 
schon ein paar Dekaden länger gibt, als die AVR. Aber mir war damals die 
Zeit zu schade, mich mit so einer veralteten und verbohrten CPU 
herumzuschlagen.
Und ja, ich halte RAM-Bänke und ein 'einziges' Arbeitsregister für 
ziemlich altbacken. Das war bei den AVR halt um Welten bequemer.

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte 2004 einen Arduino. Der hat zu lange zum Starten benötigt. 
Also wurde ein Parallelport-Programmer aus ein paar Widerständen und 
einem Logik-IC gemacht und mit dem "nackten" AVR losgelegt.

Hätte ich erst 2008 mit einem Arduino angefangen (er hat keinen 
Bootloader, auf den man ewig warten muß und mein PC hatte auch keinen 
Parallelport mehr) wäre ich vermutlich immer noch bei den Arduinos.

: Bearbeitet durch User
von wuji (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Damals waren die Atmegas einfach ein guter und günstiger Einstieg. 
Damals, vor etwa 8 Jahren. Heute würde ich keinen Atmega mehr anfassen.

Man bekommt für 5 oder 6 Euro ja schon komplette Evaluation-Boards mit 
Debuggerfunktion für Cortex M3 Controller. Da wär ich ja bescheuert, 
wenn ich noch nen Atmega anfassen würde. ;-)

Ich glaube der Hauptgrund für den Bastler ist, dass der Atmega von 
vielen Bastlern verwendet wird und das es ihn im Dip-Gehäuse gibt. Da 
ich jedoch bedrahtete Bauteile hasse und im SMD-Löten 5 mal schneller 
bin (so ein TQFP 100 ist in 2 Minuten per Drag-Soldering fertig gelötet, 
da habe ich noch nichtmal die Dip-Beinchen grade gebogen) , will ich gar 
keine Dips mehr.

Da die Cortexe mittlerweile für weniger als nen Euro zu haben sind, 
nutze ich schon für einfachste Blinkys die 32-Bitter. Warum auch nicht?

von chris (Gast)


Bewertung
1 lesenswert
nicht lesenswert
@ wuji

naja man kann auch mit kanonen auf psatzen ballern. warum nicht?

von Klaus I. (klauspi)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte nicht den Eindruck, dass PIC so selten ist. Am Anfang 
(Anfänger bin ich noch immer!) hatte ich auch diesen Eindruck, dass es 
für AVR einfach mehr Beispiele gibt als für PIC und AVR gebräuchlicher 
ist.

Dann habe ich noch die Programmier-Möglichkeiten verglichen und mit 
meinem hobbymässigen Ansprüchen inkl nur sporatischen Anwendungen in 
Einklang gebracht. Und für mich persönlich war dann eben LunaAVR mit 
entsprechenden Mikrocontrollern am komfortabelsten zu handhaben.

Für PIC gibt es aber auch ein PASCAL, damit habe ich aber noch keine 
Erfahrung gemacht. Wäre sicherlich interessant und ich habe das mal auf 
meine Liste gesetzt. Bei AVR habe ich damals C, Ada, BASCOM und LunaAVR 
verglichen und bin mit Luna sehr zufrieden.

von c.m. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Studentle schrieb:
>> Was für die AVR spricht / sprach: einfache Programmierung in C
>> s.o. und 1 Programmspeicher.
>> Bei den älteren PICs war noch ein Paging erfoderlich!
>> Was ich schon damit gekämpft haben...
>
> -> Ganz klar "SPRACH".
> Aber darauf wollte ich nicht hinaus: EINEN Programmspeicher hatten die
> Pics auch immer schon.
> Das Paging betraf das RAM, insbesondere ja die SFR...
> Ist aber reine Übungssache. Da wurde viel geschrieben "Paging schwer
> schwer" aber für jemanden der sich da ernsthaft mit befasst hat war das
> nach wenigen Stunden gegessen. Es betraf in erster Linie ja nur gewisse
> SFR - beliebtes Beispiel PORTB auf Seite 0, TRISB aber auf Seite 1 - Das
> geht schnell ins Blut über, zumal man sich bei den PICs mit den damals
> nur ~34 Befehlen weit weniger merken musste als bei den AVR.

war völlig egal für mich als anfänger vor… na 1.5 jahren.
ich hab zuerst von "arduino" gelesen, wo weiß ich nicht mehr, 
wahrscheinlich ein linux magazin, oder der c't - ein board, ein 
usb-kabel, ein paar leds, ein display. software gibts frei für linux und 
ist prima supported - vor allem von und für anfänger weil das ganze 
system sich an genau diese laien richtet.
der nächste schritt war ein paar µc selbst zu kaufen und was man sonst 
noch so braucht - breadboard, kabel r's, c's und einen programmer.

vielleicht sind PIC's auch toll, aber wozu sollte ich da jetzt umsteigen 
und geld und zeit reinhängen wo ich doch die avr's - wie sag ichs am 
besten - noch gar nicht "durch" habe.

von wuji (Gast)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> @ wuji
>
> naja man kann auch mit kanonen auf psatzen ballern. warum nicht?

Wenn die Kanone billiger oder genauso teuer ist wie das Luftgewehr? Wie 
teuer ist nochmal ein Debugger für die AVRs? Gibts den für 5 Euro? Was 
kostet der leistungsfähigste AVR und was ein vergleichbarer Cortex?

Man gibt da Geld für teure Antiquitäten aus. Das 
Preis-Leistungsverhältnis ist ganz schön schlecht. :-))

Und dann diese altmodischen Fuses... immer verfust sich irgendein armer 
Bastlerteufel den AVR... ^^

von Klaus I. (klauspi)


Bewertung
0 lesenswert
nicht lesenswert
wuji schrieb:
> Ich glaube der Hauptgrund für den Bastler ist, dass der Atmega von
> vielen Bastlern verwendet wird und das es ihn im Dip-Gehäuse gibt. Da
> ich jedoch bedrahtete Bauteile hasse und im SMD-Löten 5 mal schneller
> bin (so ein TQFP 100 ist in 2 Minuten per Drag-Soldering fertig gelötet,
> da habe ich noch nichtmal die Dip-Beinchen grade gebogen) , will ich gar
> keine Dips mehr.

:oD Ja, aus meiner Sicht hast Du total recht mit Deinen Gedanken. Aber 
auch Zwerge fangen halt klein an und beschäftigen sich erstmal mit den 
DIP so wie ich. Ich habe inzwischen sogar mal zwei ICs in 
MSOP(-irgendetwas?, keine Ahnung aber ganz ganz klein) gelötet, hat 
sogar letztendlich funktioniert. Für die 8-12 Pins habe ich aber eher 
Stunden gebraucht. Da sind mir die Dips doch einfacher in der Anwendung.

Wie gesagt, ich denke Dein Gedankengang ist wirklich nicht verkehrt. 
Nimmst Du eigentlich auch Auftragsarbeiten an? Bei Deiner 
Lötgeschwindigkeit pro Pin müssen wir doch gar nicht über einen hohen 
Stundenlohn reden :oP :o; das geht ja nebenbei..

von Hubert G. (hubertg)


Bewertung
0 lesenswert
nicht lesenswert
BASCOM hat auch einiges zu PRO-AVR beigetragen.
Damit kann man sich schnell was zusammenprogrammieren ohne es wesentlich 
verstehen zu müssen. Das gleiche gilt für den Arduino.

von wuji (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klaus I. schrieb:
> wuji schrieb:
>> Ich glaube der Hauptgrund für den Bastler ist, dass der Atmega von
>> vielen Bastlern verwendet wird und das es ihn im Dip-Gehäuse gibt. Da
>> ich jedoch bedrahtete Bauteile hasse und im SMD-Löten 5 mal schneller
>> bin (so ein TQFP 100 ist in 2 Minuten per Drag-Soldering fertig gelötet,
>> da habe ich noch nichtmal die Dip-Beinchen grade gebogen) , will ich gar
>> keine Dips mehr.
>
> :oD Ja, aus meiner Sicht hast Du total recht mit Deinen Gedanken. Aber
> auch Zwerge fangen halt klein an und beschäftigen sich erstmal mit den
> DIP so wie ich. Ich habe inzwischen sogar mal zwei ICs in
> MSOP(-irgendetwas?, keine Ahnung aber ganz ganz klein) gelötet, hat
> sogar letztendlich funktioniert. Für die 8-12 Pins habe ich aber eher
> Stunden gebraucht. Da sind mir die Dips doch einfacher in der Anwendung.
>
> Wie gesagt, ich denke Dein Gedankengang ist wirklich nicht verkehrt.
> Nimmst Du eigentlich auch Auftragsarbeiten an? Bei Deiner
> Lötgeschwindigkeit pro Pin müssen wir doch gar nicht über einen hohen
> Stundenlohn reden :oP :o; das geht ja nebenbei..

Die große Arbeit macht eigentlich nur das Hühnerfutter. Guck mal wie 
schnell so ein IC mit vielen Beinchen gelötet ist und wie einfach das 
geht:

http://www.youtube.com/watch?v=erb6-i54tbo

SMD ist in Wirklichkeit einfacher zu löten als bedrahtet. Das wissen nur 
viele nicht und haben zu Unrecht Angst vor SMD.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> (2) die Architektur der kleinen PIC ist scheiße.(*)

Ende der 90er hatten wir in meinem Ausbildungs-Betrieb so eine 
Daten-Blatt Sammlung aboniert, Internet wie heute war ja zu der Zeit 
noch nicht wirklich.
Da war auch der PIC16F84 drin.
Vom 6502 über den 68000er kommend habe ich mir mal das Datenblatt 
vorgenommen mit dem Ergebnis, dass ich dieses Ding nicht programmieren 
möchte.

Toll waren die ersten Dinger echt nicht.


Naja, was ich noch vergessen habe, die Lage ist inzwischen sicherlich 
anders, es kommen auch dauernd irgendwelche ARMs raus, höher, weiter, 
schneller.

Aber solange ich keinen echt guten Grund habe die Controller-Familie zu 
wechseln und somit eben auch die komplette Toolkette wechseln muss und 
alles neu lernen, solange werde ich wohl bei den AVR bleiben.

Dabei beschaffe ich mir schon gelegentlich mal Spielzeug, die 
LPXexpresso Teile sind nett, den 11C24 finde ich ja an sich ganz schick.
Aber die Entwicklungs-Umgebung von NXP dazu gefällt mir nicht wirklich 
und deren Webseite finde ich einfach nur Scheisse.

Als nächstes bekomme ich vielleicht Gelegenheit mir die Aurix von 
Infineon näher anzusehen, da ist nur die Frage ob und wann die was 
liefern.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wuji schrieb:
> Man gibt da Geld für teure Antiquitäten aus.

Och naja, im Verhältnis bekommt man viel weniger AVR als ARM, das stimmt 
schon, in dem Zusammenhang sehen die AVR32, vor allem der UC3C richtig 
nett aus.
Nur kann es einem doch ziemlich egal sein ob der Controller 2,40 oder 
4,95 kostet solange man immer nur mal einen davon verbaut.
Der Aufwand sich auf was komplett neues einzustellen ist doch viel 
schlimmer.

Wie ich schrieb, ich müsste erstmal nen richtig guten Grund für einen 
Wechsel haben, dazu zählt sicher nicht, was die AVR im Moment kosten.

Leichter fände ich es auch, wenn der neue von Atmel kommt und im 
Atmel-Studio programmiert wird, sowas wie einen Cortex M0 mit CAN.

Gegen Eclipse habe ich sowas wie eine leichte Allergie entwickelt.

von Andreas H. (ahz)


Bewertung
0 lesenswert
nicht lesenswert
Schwen Gel schrieb:
> Heute werden mit nem Raspberry-PI LEDs im Knightridermodus
> blinken gelassen und ne Pumpe geschaltet, früher hat man das mit ein
> zwei Logikbausteinen gemacht.

n1 - Made my day :-)

Sandro schrieb:
> Hat es einen bestimmten Grund, dass viele Bastler AVR µCs verwenden aber
> nur wenige andere wie z.B. PIC.

Wie kommst Du da eigentlich drauf ?
Viele Entwickler die ich kenne, setzen mehrere unterschiedliche Familien 
ein, je nach Anforderung.

Wir sind hier im Forum halt "etwas" AVR lasting ;-)

Grüße
Andreas

von Peter R. (pnu)


Bewertung
0 lesenswert
nicht lesenswert
Meiner subjektiven Meinung nach ist Struktur und Befehlssatz des AVR von 
erfrischender Einfachheit. Dazu kommt dann noch das Paket von Studio, 
ISP-Programmierung, Assembler und GCC, was doch eine recht komfortable 
Arbeitshilfe ist. Wer einen der atmega beherrschen gelernt hat, kann 
ohne Probleme  mit den andren Mitgliedern der Familie zurechtkommen.

Ich hatte mich in 8088, Z80, 6502, 8049, 8051, atmega so weit 
hineingearbeitet, dass ich es unterrichten konnte. 8051 und atmega 
hatten die am einfachsten zur erklärenden Strukturen. Atmel bot meines 
Wissens als Erster das komfortable in-system-programmieren an, was dem 
"try and look" so sehr entgegenkommt.

PICs habe ich nur per Buch kennengelernt und sie daraufhin im Geiste 
gleich das Klo hinuntergespült. Diese Schieberei mit Bänken und nur zwei 
Arbeitsregistern war mir ein Greuel. Außerdem sind die PICs so 
verschieden, dass man nicht einen Kontroller sondern jedesmal einen 
neuen Kontroller lernen muss.

von Stefan K. (stkl)


Bewertung
0 lesenswert
nicht lesenswert
Ich glaube auch, dass es sich in Zahlen wenig tut. In Berufsschulen und 
IHK-Prüfungen werden derzeit gern PICs eingesetzt wie unsere Azubi 
berichten, die Technikerschule, die einige Kollegen besuchen arbeitet 
aber z.B. wieder mit ATmega....

Im Endeffekt muss man in jede Umgebung ersteinmal investieren, wenn man 
die richtigen Geräte möchte. In meinem Regal liegen Programmieradapter 
und Debugger für bestimmt 2000€ (Atmel, Microchip, ST, Xilinx, ...) Als 
Hobbybastler bleibt man da gern bei einer Famile, wenn es keine 
triftigen Grund zum Wechsel gibt.

Kleine Komplettlösungen wie Arduino (hatte davon tatsächlich noch nie 
eins in der Hand) und Spielereien wie Bascom sind natürlich Pro-Bastler, 
im Arbeitsalltag beides weitgehend ohne Bedeutung.

AVR ist hier sehr gut und recht anfängerfreundlich dokumentiert, für 
PICs gibt es eine andere Seite mit ähnlichem Aufbau, aber wie ich finde 
einiges undurchsichtiger. Im deutschen Sprachraum also wieder ein 
kleiner Vorteil.


Ich schätze es kommt auch ein wenig darauf an, wann man in die Materie 
eingestiegen ist, sah vor ein paar Jahren sicher noch anders aus, als 
heute. Und natürlich in welcher Architektur das erste angestrebte 
Projekt bereits fertig dokumentiert auffindbar ist ;)

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
PIC >> pig >> Schwein = Schlammloch
... Das war immer mein Gedanke - auch ohne das Datenblatt zu kennen. 
Jahre Später hat sich meine Ansicht bestätigt, als ich doch mal ein 
Datenblatt in die Hand genommen habe - rein aus Interesse. Hingegen die 
PIC24 sind schon nette Teile.

Heute bin ich beim STM32 hängen geblieben. Auch für die kleinsten 
Projekte, weil ich habe die komplette Umgebung/Debugger usw. (Und die 6 
HW-Breakpoints in der CPU).

von Sandro (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klaus I. schrieb:
> Bei Deiner
> Lötgeschwindigkeit pro Pin müssen wir doch gar nicht über einen hohen
> Stundenlohn reden :oP :o; das geht ja nebenbei..
Mit ein bisschen Erfahrung ist das kein Problem mehr, ab dem dritten 
TQFP44/32 und ein bisschen Hühnerfutter hatte ich keine Probleme mehr.

wuji schrieb:
> SMD ist in Wirklichkeit einfacher zu löten als bedrahtet. Das wissen nur
> viele nicht und haben zu Unrecht Angst vor SMD.
Wir habe in der Schule mal eine Platine mit einem SMD IC gemacht, seit 
dem will ich wo's geht auf THT verzichten.

Andreas H. schrieb:
> Wie kommst Du da eigentlich drauf ?
> Viele Entwickler die ich kenne, setzen mehrere unterschiedliche Familien
> ein, je nach Anforderung.
>
> Wir sind hier im Forum halt "etwas" AVR lasting ;-)
Auf deutschen Websites findet man aber viieel mehr Projekte mit AVR

Peter R. schrieb:
> und nur zwei
> Arbeitsregistern
Aus Interesse: Welcher PIC hat 2 WREGs?

von Walter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Studentle schrieb:
>> Was für die AVR spricht / sprach: einfache Programmierung in C
>> s.o. und 1 Programmspeicher.
>> Bei den älteren PICs war noch ein Paging erfoderlich!
>> Was ich schon damit gekämpft haben...
>
> -> Ganz klar "SPRACH".
> Aber darauf wollte ich nicht hinaus: EINEN Programmspeicher hatten die
> Pics auch immer schon.
> Das Paging betraf das RAM, insbesondere ja die SFR...

als ich noch PICs programmiert habe war das anders, schau doch mal beim
PIC12C509 unter MEMORY ORGANIZATION nach, da ist der Programmspeicher 
sehr wohl unterteilt. Auch wenn es inzwischen andere PICs gibt hat mich 
das bis heute abgeschreckt wieder einen in die Hand zu nehmen

von kopfkratzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
kopfkratz
Immer wieder mal ...
Wenn man eine Hochsprache nimmt ergibt sich kein Problem mit 
Registern/Segmentierung/Havard/VonNeumann usw. usf.
Hobbybastler haben i.d.R. ein Steckbrett wo erstmal der Prototyp 
zusammengepöppelt wird, ob da nun ein AVR oder PIC werkelt ist egal 
hauptsache DIL Gehäuse.
Aktuelle AVRs haben meistens mehr Funktionalität während man bei PIC 
erstmal suchen muß welcher alles hat was man braucht.
Die Entwicklungsumgebung war mal ein Punkt aber ob Arduino oder PICKit 
ist egal.
Ob auf den Kits nun AVR 8bit, AVR 32bit, PIC 8bit, PIC 32bit, STM32 oder 
MIPS drauf ist hat mit der Entwicklung nicht viel zu tun, außer man 
braucht spezielle Dinge die nur XYZ kann :-P
AVR 8bit und PIC 8bit dürften 50:50 bei Hobbybastlern ausmachen, da es 
bei beiden Varianten passende günstige Chips gibt die alles abdecken was 
man so braucht ...
Das Hauptargument was auch mich bei AVR hat landen lassen ist ja 
mehrfach genannt worden, das ist aber Vergangenheit (snief kein legacy 
mehr snief)!
Wenn ich mal schnell was zusammenpöppeln will nehme ich Lochraster und 
DIL, SMD auf Lochraster kann man zwar z.B. auf elm-chan bewundern aber 
ich würde da immer einen "pieksenden" Käfer nehmen :-P
Also immer das nehmen was zum Projekt am besten paßt, ob das 8bit, 
128bit oder 256bit ist kommt auf die Anwendung an, ob das 1Pin, 100Pin 
oder 1000Pin hat kommt ebenfalls daruaf an usw. usf. ...
Achja man könnte aktuell ja mal am Nordpol nachfragen was die 
"Helferlein" da so in die Spielzeuge bevorzugt einbauen und warum :-P
ROFL

von Sandro (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Walter schrieb:
> als ich noch PICs programmiert habe war das anders,
Beim dem Alten PIC enthielt der Befehl für goto mur 8 bit Adresse.
Deshalb mussten die höherwertigen Adressbits ind PCLATH geschrieben 
werden. Bei den neuen PIC12 und PIC 16 enthält der CALL/GOTO-Befehl 11 
Adressbits. Beim PIC18 enthält der CALL/GOTO befehl alle Adressbits.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Einfache Programmiermöglichkeiten für die PICs mit ein paar Bauteilen
> für unter einer Mark an der seriellen Schnittstelle gabe es schon bevor
> die AVR überhaupt auf den Markt kamen.

Die brauchten meiner Erinnerung nach aber noch +12 V.  Die AVRs konnte
man dann wirklich mit reinen TTL-Pegeln von der parallelen Schnittstelle
programmieren.

Für mich war das Umstiegskriterium von PIC auf AVR aber auch die
Verfügbarkeit eines GCC.

von greg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Für mich war das Umstiegskriterium von PIC auf AVR aber auch die
> Verfügbarkeit eines GCC.

Ähnlich hier. Aber das war kein Umstieg, sondern als ich mich das erste 
mal mit MCUs beschäftigte, wurde ich durch den ganzen Wildwuchs bei PIC 
abgeschreckt. Verschiedene Architekturen, eine (zu) große 
Produktvielfalt und dann noch verschiedene kommerzielle C-Compiler. 
Manche gab es als kostenlose eingeschränkte Versionen, fast alles aber 
nur für Windows, und die Einschränkungen waren meistens nicht sehr nett. 
Beim AVR gab es dagegen auch damals schon einen gut brauchbaren GCC mit 
stabiler avr-libc, und dies schein populärer als Keil oder IAR.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Sandro schrieb:
> Beim dem Alten PIC enthielt der Befehl für goto mur 8 bit Adresse.

Bei den PICs mit 12-Bit-Befehlen hat CALL 8 und GOTO 9 Bits. Aber der 
PIC1650 von 1977, von dem die direkt abstammen, hatte sowieso nur 512 
Worte ROM. Unterprogramme und Tabellen mussten in der ersten Hälfte 
liegen. Ein 10. Bit für ROM-Paging war allerdings im Statusregister 
schon vorgesehen. RAM-Paging entfiel mangels Masse ebenfalls.

: Bearbeitet durch User
von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wuji schrieb:

> SMD ist in Wirklichkeit einfacher zu löten als bedrahtet. Das wissen nur
> viele nicht und haben zu Unrecht Angst vor SMD.

Das ist eigentlich garnicht der Punkt. Der Punkt ist vielmehr, daß man 
DIL mal eben auf ein Stück Loch- oder Streifenraster braten kann und man 
deshalb sofort loslegen kann, ohne erst 50 Euro und eine Woche 
Wartezeit) in ein PCB zu investieren (oder alternativ 10 Euro und vier 
Wochen Wartezeit).

Und wenn ein Fehler im Schaltungsdesign ist, dann ist das auf Lochraster 
immer viel leichter auszubessern.

Und wenn dann alles läuft wie es soll, dann kann man immer noch DASSELBE 
Programm auf einen IC mit SMD-Gehäuse auf einer richtigen Leiterplatte 
brutzeln.

DAS ist der Hauptvorteil der AVRs. Und offensichtlich wurde das 
endlich auch bei den Anbietern der ARM-Derivate erkannt. Leider hat 
diese Erkenntnis bisher nur geringe Früchte getrage. Die paar ARMseligen 
Gurken, die es in DIL und SMD gibt, sind lächerlich, können mit 
modernen AVRs nicht wirklich konkurrieren. Höchstens bezüglich einiger 
spezieller Hardwarefeatures, aber eben nicht im universellen Einsatz.

Die einzige ernstzunehmende Option für den ARM-Prototypenbau sind 
Adapter-PCBs. Die Dinger sind aber leider teilweise sogar teurer als der 
µC, den sie adaptieren sollen.

Nö, so geht das nicht. Und solange sich das nicht ändert, bin ich eher 
geneigt, ein Projekt notfalls auf mehreren AVRs und zusätzlicher 
Hardware zu implementieren als auf einem ARM, der das zwar allein locker 
schaffen könnte, aber das Projekt (mit einer typischen Serienstückzahl 
im ein- bis dreistelligen Bereich) dreimal so teuer werden läßt, auch 
wenn der ARM selber alleine möglicherweise sogar billiger ist als die 
zwei oder drei AVRs, die ich verbauen muß.

von Andreas H. (ahz)


Bewertung
0 lesenswert
nicht lesenswert
Peter R. schrieb:
> Diese Schieberei mit Bänken und nur zwei
> Arbeitsregistern war mir ein Greuel.

ZWEI Arbeitsregister ? Meinst Du W und f ?
Dann solltest Du vieleicht doch noch einmal das Datenblatt lesen^^

Sandro schrieb:
>> Wir sind hier im Forum halt "etwas" AVR lasting ;-)
> Auf deutschen Websites findet man aber viieel mehr Projekte mit AVR

Breaking news: Seit kurzem gibt es Webseiten ausserhalb von 
Deutschland...

Grüße
Andreas

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Bei mir wars reiner Zufall. War damals (15 Jahre her?) noch begeistert 
von den 8051ern und mir lief ein stückzahlenmässig grösseres Projekt 
über den Weg, was einen EEPROM erforderte. So kam ich zum 90S1200, 
zurück auf Assembler, aber die Architektur hat mir gefallen. Und ich bin 
dabei geblieben. Der kurze zwischenzeitliche Ausflug zum PIC hat nichts 
ausser schlaflosen Nächten und versenktem Geld gebracht, das war nie 
meiner, ich habs nie wirklich kapiert. Kommt wahrscheinlich von meiner 
Z80-Prägung, einem 6502-Säugling gehts wahrscheinlich genau andersrum.
Ich mach inzwischen auch viel mit STM32. Aber die vielen kleinen Sachen 
nach wie vor mit AVR. Hauptsächlich sind es irgendwelche Tinys und 
Mega48/88/168. Die grösseren sind mir zu teuer, da ist man mit nem ARM 
besser dran.

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
Ich wollte eigentlich PICs bestellen, konnte mich nicht sofort für einen
bestimmten Typ entscheiden und landete kurze Zeit später bei den AVRs :)

Es fing damit an, dass ich für einen DSL-Router ein paar Schaltaus- und
eingänge brauchte, um damit irgendwelche Dinge steuern zu können. Ein
paar wenige waren schon verfügbar, das reichte aber nicht. Also wollte
ich einen Mikrocontroller als I/O-Prozessor einsetzen, der mit dem
Router über eine serielle Schnittstelle kommuniziert. Das Ganze sollte
aber kein großes Projekt werden und nicht viel kosten.

Da fiel mir ein, dass mehrere Bekannte schon gute Erfahrungen mit
PIC-Controllern gemacht haben. Die waren billig, handlich und hatten
bereits fast alles auf dem Chip, was ich für mein Vorhaben benötigte.

Ich hatte zu dem Zeitpunkt schon ewig lange nichts mehr mit Elektronik
gebastelt und suchte deswegen erst einmal nach Lieferanten für diese
PICs. Dabei bin ich u.a. auf Reichelt gestoßen, der eine ganz gute
Auswahl dieser Controller hatte. Während ich mich für einen bestimmten
Typ entscheiden wollte, habe ich mir gedacht, ein ADC wäre ja auch nicht
schlecht. Und wenn man ein Bisschen mehr RAM als nur für ein paar
Variablen hätte, könnte man nicht nur die Ein- und Ausgänge bedienen,
sondern auch etwas komplexere Algorithmen zur Verarbeitung von
Sensordaten in Echtzeit implementieren. Kein Problem, auch dafür gab es
die passenden PIC-Typen.

Bevor ich mich endgültig festlegen wollte, schaute ich spaßeshalber
nach, welche anderen Mikroprozessoren und -controller Reichelt so anbot
und bin dabei auf die Atmel-AVRs gestoßen. Atmel kannte ich vom Namen
her, aber AVR, ATtiny und ATmega sagten mir gar nichts. Bald wurde mir
jedoch klar, dass die AVRs sozusagen die PICs von der Konkurrenz sind.

Da sagte ich mir: Wenn die ganze Welt PICs benutzt (das war zumindest
damals mein Eindruck), sind diese eigentlich uncool. Für's Hobby will
man ja nicht immer dem Mainstream hinterherlaufen, sondern auch mal
etwas anderes ausprobieren.

Nachdem ich dann noch festgestellt habe, dass

- die AVRs für das gleiche Geld und im gleichen Gehäuse mehr RAM hatten
  (für meine möglicherweise immer komplexer werdenden Algorithmen ;-)),

- sie vom GCC unterstützt werden (mit dem ich schon gute Erfahrungen auf
  dem PC und auf Industriesteuerrechnern gemacht hatte),

- nicht nur der GCC, sondern auch alle weiteren benötigten Tools auch
  für Linux verfügbar waren (Windows habe ich zu Hause keins) und

- es im Internet umfassende Howtos für den schnellen Einstieg gibt (Bau
  der Toolchain aus den Sourcen, einfache Programmiererschaltung und
  Verwendung der Tools anhand eines Beispielprogramms),

war für mich klar, dass ich mit diesen AVRs am schnellsten mein Ziel
erreichen würde. Also habe ich mir sofort ein paar 28- und 8-beinige
Käfer bestellt, einen davon mit ein paar anderen Bauteilen auf einem
Stück Lochraster zusammengepappt und innerhalb kürzester Zeit die
berühmte LED zum Blinken gebracht. Seither verwende ich die AVRs gerne
für alle möglichen kleinen Steuerungsaufgaben, weil alles, was ich dazu
brauche (Tools, Bauteil, Wissen), jederzeit fertig bereitliegt

Mit den PICs habe ich mich deswegen gar nicht mehr beschäftigt, obwohl
sie für mich wahrscheinlich ebenso gut getaugt hätten.

von Gerhard W. (gerhard86)


Bewertung
1 lesenswert
nicht lesenswert
wuji schrieb:
>> naja man kann auch mit kanonen auf psatzen ballern. warum nicht?
> Wenn die Kanone billiger oder genauso teuer ist wie das Luftgewehr?

Guter Vergleich.

Kanone: Kartusche anschleppen, in die Kanone stopfen, Zielrichtung des 
Spatzen bestimmen, solange drehen und kurbeln bis die Kanone auf den 
Spatzen ausgerichtet ist- oder besser, bis die Kanone dorthin 
ausgerichtet ist wo der Spatz vor 5min saß. Schön dass die Feuerkraft 
reichen würd um einen Plattenbau einzureißen, aber der verdammte Spatz 
ist weggeflogen.

Gammliges Luftgewehr aus den 60ern: Abknicken, 4,5mm Rundkugel rein, 
zuklappen, anlegen, bumm, Spatz hin.

->Gammliges Luftgewehr gewinnt.

von Christian B. (casandro) Flattr this


Bewertung
0 lesenswert
nicht lesenswert
Also für mich war der Grund der segmentierte Arbeitsspeicher der PICs. 
Damit mag man für ganz einfache Sachen leben können 
(Steuerungsaufgaben), aber ich bin mit einem ZX80 aufgewachsen, einem 
Mikrocomputer mit 1kbyte RAM. Ich weiß, dass man damit schon einiges 
machen kann... nur halt nicht wenn man für alle 16 Bytes RAM eine Seite 
umschalten muss.

Man muss natürlich sagen, dass global betrachtet die 8052er noch viel 
populärer sind. Die sind zwar furchtbar, aber da alle Patente abgelaufen 
sind gibts tausende von Re-Implementationen. Die findet man dann in 
USB-Controllern und digitalen Bilderrahmen.

von Der Rächer der Transistormorde (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sandro schrieb:
> Hat es einen bestimmten Grund, dass viele Bastler AVR µCs verwenden aber
> nur wenige andere wie z.B. PIC.

Mmn gibt es keine nachvollziehbaren Gründe warum jemand die eine oder 
andere µP Marke bevorzugt. Es ist schlicht und ergreifend Zufall und die 
Streiterei um dieses oder jenes winzige Feature pure Psychologie.

Warum ich meine besser finde als deine ist der schlichten Tatsache 
geschuldet das ich gelernt habe damit umzugehen. Vor allem mit den 
Macken, die Sie alle haben.

Das macht mir das ganze sympathisch, ich entwickele Vertrauen in das 
ganze und habe kein Interesse daran das was ich darin investiert habe zu 
verwerfen oder mir madig machen zu lassen.

Ein Wechsel von µP X zu µP Y wäre für alle nicht schwer. Die 
Unterschiede sind größtenteils Einbildung. Nur will sich halt keiner 
grundlos nochmal mit dem Teufel beschäftigen der ja bekanntlich in den 
Details steckt.



Technologie Leader im µP Markt war meiner Meinung nach übrigens lange 
Zeit Fujitsu.

Die waren teilweise so weit vorn das Sie von jedem Fanboy gleich welcher 
Couleur geflissentlich ignoriert wurden. Erleichtert wurde das dadurch 
das deren Interesse Megastückzahlen waren und Hobbyisten von denen so 
behandelt wurden wie Linux Hacker auf nem Windows Businessfrühstück.

von Peter K. (peter_ph)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch mal mit dem Atmega8 und 16 angefangen.

Dann habe ich mich beruflich mit PICs beschäftigen müssen. Und sie haben 
mir besser gefallen. Ich finde deren Dukumentation übersichtlicher: Das 
Datenblatt und dann zu dem meisten Kapiteln gibt es die "Family 
Reference Manuals" mit weiterführenden Infos.

Die von Microchip aufgestelle und ständig weiterentwickelte Application 
Library ist auch nicht zu vergessen.

Nur wie schon jemand geschrieben hat: Das meiste ist in Englisch.

von Patrick C. (pcrom)


Bewertung
0 lesenswert
nicht lesenswert
Tsja es koenen soviel verschiedene ursachen sein sich einen Micro 
anzolernen. Bei mir ist es ungefahr so gewesen :

6502/6510 mittels Basic sprache - Weil er im meinen Commodore 64 
(+Drive) war
6502/6510 mittels Assembler sprache
8086/80286 mittels gwbasic/qbasic/turbopascal - Weil er im XT/AT rechner 
war
8086/80286 Assembler - Braucht man um auf hardware zu zu greifen
Basic Stamp/C-Control - Hobby-projecten
Z80 Assembler - Schule
68000 Assembler - Schule
C Sprache algemein - Schule

Dann bin ich beruflich angefangen als hardware/embedded software 
engineer :
- Echelon Processor mit Neuron-C weil dieser musz wegen eines Bussystem
- 80186 in C weil dieser im geschaeft schon benutzt wuerde
- Sgs Thomson Assembler weil dieser damals der beste LCD driver on board 
hatte
- PIC Assembler weil dieser damals der kleinste war (8-pin)
Nach aendrung der arbeitsgeber :
- AVR mittels C programmierung weil dieser im geschaeft schon benutzt 
wuerde
- Eine art von Script-language fuer Bluegiga Bluetooth chips
- Cypress PSoc-3 (Seit einige monaten) weil sehr viel analoges 
integriert ist

Also viele verschiedene ursachen um einen uP zu waehlen. Ich denke fuer 
bastler ist sehr wichtig im welchen period man damit angefangen ist. Vor 
einige jahren war ein boost auf Arduinos weil es da deutlich eine 
version mit sehr viele beispielen gibt. Jetzt gibt es aber wieder 
soviele verschiedene Arduinos mit scheisz-Loesungen sowie Leonardo das 
ich mir vorstellen kann das ein Anfanger es zu komplex wird und die 
meisten beispielen nicht auf seine hardware laufen.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mit Z80, 6502 und dann dem MCS51 angefangen und natürlich in 
Assembler. Die MCS51 waren einfach, logisch und mächtig, genauso wie der 
Z80 und der 65XX (der TMS320 übrigens auch :). Dann war ich das EPROM 
Brennen leid und wollte wieder was einfaches, logisches und mächtiges. 
Als ich aber die Portbeschreibung der PIC studiert hatte, war ich recht 
verwirrt und bin dann zu den AVR gekommen. Die PIC waren mir einfach zu 
umständlich, zumal es MPLAB auch noch nicht gab, ein wichtiges 
Kriterium, wenn man nicht so viel Mäuse in eine IDE investieren kann.

von F. F. (foldi)


Bewertung
0 lesenswert
nicht lesenswert
Stephan B. schrieb:
> Ich denke auch das Arduino dem AVR (gegenueber PIC) einen riesen PUSH
> gegeben hat.
>
> MfG

Das sehe ich auch so und kann es für mich bestätigen.
Vor ungefähr zwei Jahren fing ich damit an. Es war günstig, auf dem 
Netbook lief die IDE zügig und man kann mit den Beispielen und fertigen 
Libarys sofort starten und schon recht anspruchsvolle Sachen machen.

Wenn ihr, die ihr das so viele Jahre macht, mal einen Schritt zurück 
tretet und euch das wirklich vom weiten Anschaut, es ist schon nicht 
ganz einfach und man braucht Durchhaltevermögen und letztlich auch ne 
Menge Geld.
Wenn man also noch nicht weiß, ob man das überhaupt machen will und 
kann, dann sucht man nach was Günstigem zum testen (incl. IDE) und kauft 
sich nicht gleich Keil.

Vor 20 Jahren hatte ich mal einen Freund, der mit Elektronik sein Geld 
verdiente und damals wohl auch PIC hatte.  Die Preise die er mir damals 
nannte, waren für mich unerschwinglich, um das als Hobby auszuüben.
Günstige Hardware, günstige bis kostenlose Software und gute Literatur 
sind sicher die Eckpfeiler.

: Bearbeitet durch User
von Patrick (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte damals, so um die Jahrtausendwende meine ersten Gehversuche 
mit PICs unternommen - und war kläglich gescheitert (bzw. hatte 
irgendwann recht schnell die Lust verloren, weil "die Dinger nicht so 
wollten wie ich").
Gründe dafür waren u. a.:
- Die MPLAB IDE war ein absoluter Krampf hinsichtlich Bedienergonomie
- Die notwendigen Registerbankumschaltungen (Assembler!) gepaart mit 
einer, naja, nach meinem Empfinden damals nicht unbedingt 
"anfängerfreundlichen" Dokumentation ließen Erfolge à la "Das Programm 
macht genau das, was es soll" oft und lange ausbleiben
- Diverse Erratas gaben mir den Rest. Besonders "witzig": Ich wollte 
eine Hardwareschnittstelle benutzen, mit welcher der µC angepriesen 
wurde. Nachdem ich einige Tage damit zubrachte, zu versuchen, das Ding 
überhaupt zur Funktion zu bringen, lernte ich über die Existenz von 
Errata Sheets - und musste darin lesen, dass bei meinem µC die bewusste 
HW-Schnittstelle nicht funktioniert. Empfohlener Workaround: "Do not 
use". Spätestens dann fühlte ich mich als Kunde nicht wirklich ernst 
genommen...

Die ersten Gehversuche unternahm ich dann AFAIR mit einem AT90S4433 (!) 
als Bestandteil oder auf Basis eines Elektor-Projekts (Ja, damals hatte 
Elektor auch hin und wieder mal gute Schaltungen) - und es funktionierte 
einfach.

Bis zum Umstieg auf STM32 vor ein, zwei Jahren blieb ich (als Hobbyist 
und Bastler) der AVR-Familie treu, da sie praktisch immer einfach und 
problemlos funktionierten.

Ich sage nicht, dass "PICs" generell schlecht(er) sind; das sind und 
waren nur meine persönlichen Erfahrungen.

von SE (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei mir wars auch der zufall.

Erste Gehversuche hab ich mit nem 8051 gemacht.
Dieser ließ sich aber nur in einem speziellen Programmiergerät 
programmieren.
Über ein Hello World bin ich nie drüber weg gekommen.

Beim zweiten Controller-Anlauf hab ich dann irgendein ASM Tutorial für 
einen Atmel Controller gefunden.
Das ganze war in sich komplett von 0 an mit Aufbau des Programmers 
beschrieben.
Der Serialport Programmer bestand aus wenigen Bauteilen die ich sowieso 
da hatte und als Controller kam der Tiny2313 zum einsatz.

Nach und nach wurden die Controller dann Moderner, die Programmer besser 
und schneller und ich bin bei den Atmel controllern geblieben.

In der Ausbildung musste ich mich dann für die Abschlussprüfung mit 
einem PIC auseinandersetzen.
Das war natürlich ungewohnt, aber auch umständlicher.
Programmiert habe ich auch hier in Assembler.
Die Page umschaltung und der kleine Befehlssatz machte das Arbeiten 
etwas umständlicher aber es führte genauso zum Ziel.

Inzwischen bin ich auf den Stand das jeder Controller sein einsatzgebiet 
hat.
Um z.B. einen Näherungssensor zu bauen nehme ich keinen Arduino oder 
Raspberry Pi. Da reicht ein 6-Pin AVR. Das ganze gerät soll ja 
Stromsparend und klein werden.
Komplexere Aufgaben mit großem Display kann dann ein BeagleBone 
übernehmen oder ein anderes ARM Board. Da kommt kein AVR zum einsatz.

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Das ist eigentlich garnicht der Punkt. Der Punkt ist vielmehr, daß man
> DIL mal eben auf ein Stück Loch- oder Streifenraster braten kann und man
> deshalb sofort loslegen kann, ohne erst 50 Euro und eine Woche
> Wartezeit) in ein PCB zu investieren (oder alternativ 10 Euro und vier
> Wochen Wartezeit).

Was hindert mich daran, ein Discovery-Kit auf eine Lochlasterplatine zu 
stecken? Einfach Buchsenleiste drauf und fertig. Und wenn ich nicht so 
viele Pins brauche nehme ich einfach Jumper Wires. Dafür muss ich mich 
nicht jedes Mal neu um den Anschluss vom Debugger, Taktgeber, 
Test-LED/Taster kümmern, das ist nämlich auf dem Board schon drauf.

Für mich ist das viel bastelfreundlicher als so ein elender 
DIP-Einzelkäfer.

von fujii (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Antimedial schrieb:
> c-hater schrieb:
>> Das ist eigentlich garnicht der Punkt. Der Punkt ist vielmehr, daß man
>> DIL mal eben auf ein Stück Loch- oder Streifenraster braten kann und man
>> deshalb sofort loslegen kann, ohne erst 50 Euro und eine Woche
>> Wartezeit) in ein PCB zu investieren (oder alternativ 10 Euro und vier
>> Wochen Wartezeit).
>
> Was hindert mich daran, ein Discovery-Kit auf eine Lochlasterplatine zu
> stecken? Einfach Buchsenleiste drauf und fertig. Und wenn ich nicht so
> viele Pins brauche nehme ich einfach Jumper Wires. Dafür muss ich mich
> nicht jedes Mal neu um den Anschluss vom Debugger, Taktgeber,
> Test-LED/Taster kümmern, das ist nämlich auf dem Board schon drauf.
>
> Für mich ist das viel bastelfreundlicher als so ein elender
> DIP-Einzelkäfer.

Full ACK. Ich wäre ja schön blöd,wenn ich mir die Mühe machen würde 
einen einzelnen uc auf die Lochraster zu brutzeln, wenns schon fertige 
Evalkits für 5 Euro gibt, wo schon alles drauf ist (Debugger, 
Programmer, Leds, Quarz, Stiftleisten etc etc...).

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Antimedial schrieb:
> Was hindert mich daran, ein Discovery-Kit auf eine Lochlasterplatine zu
> stecken

Bei den STM32-Discovery-Kits: Das fiese Footprint. Die Abstände sind
genau so, daß es mit Punktstreifenraster keinen Spaß macht. Und das
sowohl beim STM32VLdiscovery als auch beim STM32F4discovery.


Für's Steckbrett sind die Abstände auch ungünstig und die Pins nach oben 
kann man nur mit sehr hochwerigen Kabeln nutzen, da nur halb so lang wie 
sinnvoll.

Die Zusammenstellung ist klasse, die Boards sind ganz gut. Aber mit Null 
Mehraufwand hätte man sehr gute Boards hingekommen.

von fujii (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerhard W. schrieb:
> Kanone: Kartusche anschleppen, in die Kanone stopfen, Zielrichtung des
> Spatzen bestimmen, solange drehen und kurbeln bis die Kanone auf den
> Spatzen ausgerichtet ist- oder besser, bis die Kanone dorthin
> ausgerichtet ist wo der Spatz vor 5min saß. Schön dass die Feuerkraft
> reichen würd um einen Plattenbau einzureißen, aber der verdammte Spatz
> ist weggeflogen.
>
> Gammliges Luftgewehr aus den 60ern: Abknicken, 4,5mm Rundkugel rein,
> zuklappen, anlegen, bumm, Spatz hin.
>
> ->Gammliges Luftgewehr gewinnt.

blöd nur, dass so eine Cortex-Kanone 10 Mal schneller schießt als das 
Luftgewehr. ;))

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
fujii schrieb:
> blöd nur, dass so eine Cortex-Kanone 10 Mal schneller schießt als das
> Luftgewehr. ;))

Aber nicht beim ersten Schuß.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
SE schrieb:
> Erste Gehversuche hab ich mit nem 8051 gemacht.
> Dieser ließ sich aber nur in einem speziellen Programmiergerät
> programmieren.

Die Philips/NXP 8051 LPC hatten immer schon einen seriellen Bootloader 
und konnten per RS232 programmiert werden. Bei den ARM LPC ist das noch 
genau so, inzwischen aber per USB/seriell.

SE schrieb:
> Bei mir wars auch der zufall.

Das stimmt allerdings, habe 1989 den ARM2 bekommen, da gab es AVR noch 
gar nicht. Seitdem nur ARM gemacht :-)

von fujii (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Walter Tarpan schrieb:
> fujii schrieb:
>> blöd nur, dass so eine Cortex-Kanone 10 Mal schneller schießt als das
>> Luftgewehr. ;))
>
> Aber nicht beim ersten Schuß.

sicher? Also ich hatte mein Blinky damals schneller mit einem stm32 
Discovery als mit den Atmegas. Der Atmega war nämlich ersteinmal 
verfust...

von Antimedial (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Walter Tarpan schrieb:
> Bei den STM32-Discovery-Kits: Das fiese Footprint. Die Abstände sind
> genau so, daß es mit Punktstreifenraster keinen Spaß macht. Und das
> sowohl beim STM32VLdiscovery als auch beim STM32F4discovery.

Ich hatte mit Lochrasterkarten nie Probleme.

Walter Tarpan schrieb:
> Für's Steckbrett sind die Abstände auch ungünstig und die Pins nach oben
> kann man nur mit sehr hochwerigen Kabeln nutzen, da nur halb so lang wie
> sinnvoll.

Die Pins oben nutze ich für das Oszi/Logic Analyzer. Dafür reicht die 
Länge, die Probes halten ganz gut. Die Schaltung kommt immer unten dran.

Walter Tarpan schrieb:
> Aber nicht beim ersten Schuß.

Die Peripherie ist vielleicht etwas komplexer, dafür kommt man schneller 
voran, wenn man mal eine etwas komplexere Anwendung umsetzen will. 
Allein die FPU ist Gold wert, auch wenn es sicherlich noch Leute gibt, 
die glauben, dass echte Männer nur mit Festkommaarithmetik arbeiten.

Außerdem: Auf einen Debugger möchte ich jedenfalls nicht verzichten, 
also brauche ich schon einmal mindestens ein AVR Dragon oder ein JTAG 
ICE. Das ist einfach noch einmal ein Kostenfaktor.

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
fujii schrieb:
>> Aber nicht beim ersten Schuß.
>
> sicher? Also ich hatte mein Blinky damals schneller mit einem stm32
> Discovery als mit den Atmegas. Der Atmega war nämlich ersteinmal
> verfust...

Sicher. Ich hatte den Blinky auf dem STM32-discovery vor zwei Wochen 
auch schneller als auf dem ATmega vor 9 Jahren. Aber dank des Wissens, 
das ich mit den ATmegas sammeln konnte und weil auf dem Eval-Board ein 
gescheiter Programmer dabei ist im Vergleich zu den 
Widerstands-Parallelport-Programmern damals.

Aber die Frage ist müßig. Ich habe schließlich nicht mit den STM32 
angefangen, weil ich sie nicht leiden kann, sondern weil ich auf eine 
Anwendung gestoßen bin, wo mir die ADC-Samplerate vom AVR nicht mehr 
ausreicht. Und generell wüßte ich auch keinen Grund - abgesehen von 
diesem einen Anwendungsfall - von den AVRs wegzugehen. Schon allein 
deswegen, weil ich noch eine Schublade voll von dem Zeug habe. Und weil 
die Versorgungsspannung flexibler ist. Und weil 8-Pin-Varianten 
verfügbar sind. Und weil sie allgemein gut verfügbar sind. Und 
nachbausicher. Und weil es schon viele fertige Entwürfe gibt. Und viele 
wiederverwertbare Firmwarekomponenten. Und weil der ISP-Stecker kleiner 
als der JTAG ist. Und und und.

Für jede Anwendung den richtigen Controller. Und solange die Controller, 
die man kennt für die Anwendung richtig sind, hat man wenig Gründe, 
gleichwertigen Ersatz zu suchen.

von Antimedial (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Walter Tarpan schrieb:
> Und generell wüßte ich auch keinen Grund - abgesehen von
> diesem einen Anwendungsfall - von den AVRs wegzugehen.

Da gibt es aber sehr viele. Kern und Peripherie sind einfach unendlich 
viel mächtiger. UART mit DMA ist einfach nur genial, da spare ich mir 
meistens sogar die Interrupts. Gleiches gilt für ADC und DAC. FPU hatte 
ich ja schon erwähnt.

Walter Tarpan schrieb:
> Und weil
> die Versorgungsspannung flexibler ist.

Ich komme zu 95% mit 3,3V aus. Auf dem Board sind ja auch 5V vorhanden, 
und ein 74AHT14 hat man schnell mal gesetzt, falls es doch mal nicht 
klappt. Ich bin aber auch beruflich auf 3,3V-Elektronik getrimmt.

Walter Tarpan schrieb:
> Und weil 8-Pin-Varianten
> verfügbar sind.

Das ist weniger ein typischer Anwendungszweck für 32-Bit-Prozesoren, 
gibt es aber inzwischen auch (LPC800).

Walter Tarpan schrieb:
> Und weil sie allgemein gut verfügbar sind.

Damit hatte ich auch nie Probleme.

Walter Tarpan schrieb:
> Und weil es schon viele fertige Entwürfe gibt. Und viele
> wiederverwertbare Firmwarekomponenten.

Für STM32 gibt es da inzwischen auch richtig viel.

Walter Tarpan schrieb:
> Und weil der ISP-Stecker kleiner
> als der JTAG ist.

Ich nutze SWD, das passt auch locker auf einen 6-poligen Stecker.

Walter Tarpan schrieb:
> Für jede Anwendung den richtigen Controller. Und solange die Controller,
> die man kennt für die Anwendung richtig sind, hat man wenig Gründe,
> gleichwertigen Ersatz zu suchen.

Und wenn man neu anfängt, nimmt man gleich eine Familie, die ein 
möglichst großes Spektrum abdeckt. Und da ist der STM32 eigentlich eine 
bessere Wahl, da die Familie von ganz klein (STM32F0) bis sehr mächtig 
(STM32F4) alles abdeckt und sogar halbwegs codekompatibel ist. Zumindest 
kommt man aber mit der gleichen Toolchain und der gleichen 
Programmierphilosophie zurecht.

von adenin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also, ich hatte zuerst den PIC auf der Liste, der war als er heraus kamm 
der schnellste µC. Als dann der AT90S1200 kamm bin ich dazu 
übergewechselt (1 Befehl pro Taktzyklus :-) ).
Ich mach beides in Assembler, wobei PIC Assembler 'n bisschen eigenartig 
ist.

von Stefan S. (engi)


Bewertung
1 lesenswert
nicht lesenswert
Hi, also ich kam durch Basic zum AVR. In meiner Ausbildung lernte ich 
Pascal und Delphi und ein Blick in einen Assembler oder C-Code haben 
mich sofort abgeschreckt. Jahrelang habe ich mich mit "Goembedded" für 
die PICs herumgeschlagen. Da ich aber nie verstand, wie die Quarze beim 
PIC bei "Geembedded" zu setzen sind, kam nie mehr heraus als ein 
einfaches Blinklicht. Dann höhrte ich etwas von Bascom. Demo herunter 
gezogen, Programmer (Pollin AVR Board) sowie einen Atmega8 bestellt und 
erste Demoprojekte versucht. Den ersten Atmega8 allerdings habe ich mir 
mit Ponyprog und den undurchsichtigen Fusebits zerschossen. Erst als ich 
einen ISP Programmer hatte und die Fusebits direkt aus Bascom heraus 
setzen konnte, ging es richtig vorran. Ich fühlte mich in Bascom schnell 
heimisch und die Demoprojekte liefen im Vergleich zu "Goembedded" 
problemlos. Das alles begann im Sommer diesen Jahres. Inzwischen habe 
ich die Sensorsignale meiner Wetterstation verstanden und einen eigenen 
Empfänger mit Display dafür programmiert. Einen ersten funktionsfähigen 
Eigenbausensor gibt es inzwischen ebenso. Sicher können die kleinen 8 
Bit Kontroller nicht so viel, wie die großen 32 Bit Kontroller, aber 
hier kann man sich auch oft mit über SPI, I2C, oder seriell 
ansprechbaren Modulen weiter helfen. So kann letztlich gar ein kleiner 
Atmega32 oder kleiner ein 320x240 Farbdisplay mit Touchscreen 
ansprechen. Den Möglichkeiten mit diesen kleinen Chips scheinen 
grenzenlos.

von ich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Walter Tarpan schrieb:
> Und weil der ISP-Stecker kleiner
> als der JTAG ist.

Beim STM32 reicht dir mir SWD aber auch SWDIO, SWCLK, GND und 3V3 ... 
der Punkt geht an die STMs ;-)

von Kolbenfresserzirbelzikade (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Gammliges Luftgewehr aus den 60ern: Abknicken, 4,5mm Rundkugel rein,
> zuklappen, anlegen, bumm, Spatz hin.

Spatzenhasser!!

von wuji (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Beim STM32 reicht dir mir SWD aber auch SWDIO, SWCLK, GND und 3V3

3v3 brauchste nicht. Das heist man braucht nur 3 Leitungen.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Antimedial schrieb:

> Was hindert mich daran, ein Discovery-Kit auf eine Lochlasterplatine zu
> stecken?

Zum einen die Tatsache, daß typisch Buchsenleisten vorliegen, die halt 
nicht so recht zum 1/10"-Grid der Lochrasterplatinen passen.

Viel schlimmer ist aber: Wenn der Prototyp läuft, soll er ja letztlich 
doch auf einer richtigen Leiterplatte landen und dann mit dem bereits 
fertigen Programm des Prototyps laufen.

Das geht mit Discovery-Kits in aller Regeln nicht oder nur in der Form, 
daß man es selber praktisch nochmal nachbaut, was wieder unnötige Arbeit 
und Kosten verursacht.

von wuji (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Zum einen die Tatsache, daß typisch Buchsenleisten vorliegen, die halt
> nicht so recht zum 1/10"-Grid der Lochrasterplatinen passen.

Also ich habe bislang immernoch alle Discoverykits (stm32) auf eine 
Lochraster gepackt.

> Viel schlimmer ist aber: Wenn der Prototyp läuft, soll er ja letztlich
> doch auf einer richtigen Leiterplatte landen und dann mit dem bereits
> fertigen Programm des Prototyps laufen.

Warum sollte das nicht gehen? Ich schreibe häufig das Programm fürs 
Discovery und packs danach 1:1 auf die fertige Leiterplatte. 
Allerhöchstens muss ich dann vielleicht ein paar Pins umlegen, aber das 
ist nun nicht der Rede wert.

> Das geht mit Discovery-Kits in aller Regeln nicht oder nur in der Form,
> daß man es selber praktisch nochmal nachbaut, was wieder unnötige Arbeit
> und Kosten verursacht.

Versteh nicht was du meinst. ^^

von Carsten S. (dg3ycs)


Bewertung
1 lesenswert
nicht lesenswert
Hi,

Also ich denke man muss bei vielen der Meinungen hier differenzieren ob 
man nun aus der Sicht eines reinen Privatbastlers spricht oder auch 
Sicht von jemanden der das (auch) kommerziell macht.

So wurde ja hier als Beispiel für die AVR die reichhaltige Verfügbarkeit 
von OpenSource Projekten vielerorts im Netz genannt.
Für den Hobbyisten ist das Schön, er findet ein Projekt das zu seinem 
passt, holt sich den Quellcode, passt den An und FERTIG!

Aber für den kommerziellen ist das schon völlig anders. Einfach so 
Projekte aus dem Netz verwenden geht da gar nicht. Erst muss mal geklärt 
werden wie es Lizenzrechtlich aussieht.
Viele Projekte können Beispielsweise ohne Einschränkungen privat genutzt 
werden, haben aber bei kommerziellen Einsatz erhebliche Einschränkungen. 
So ist es ja häufig das Bedingung ist das man dann den veränderten Code, 
also SEINE Firmware auch wieder als Quellcode veröffentlicht was oft 
natürlich nicht tragbar ist. Oder es fallen Lizenzgebühren an.

Mal ganz abgesehen von der Frage was ist wenn man ein Projekt findet, 
der "angebliche" Ersteller sagt das man das Problemlos benutzen kann, 
sich hinterher aber rausstellt das er selbst auch nur von einer anderen 
Quelle ausgegangen ist und deren Lizenzbedingungen im Hinblick auf 
kommerzielle Verwendung aber gar nicht kannte...

ICh habe diesen Praxisschock schon öfter erlebt wenn beispielsweise 
Studenten (Oder lange Zeit "Nur Hobbyisten" ) dann die ersten 
"kommerziellen" Produkte bearbeiten sollen. Da wird auf biegen und 
brechen dann am AVR festgehalten weil das damit so einfach geht...
Und in der fertigen Lösung werkelt dann V-USB und die Augen werden ganz 
groß wenn man dann auf die Website geht und denen den Passus über den 
kommerziellen Einsatz unter die Nase hält...

Also das ganze Projekt dann von vorne Aufrollen, natürlich immer noch 
mit einem AVr - diesmal wenigstens einem USB Typ, erfordert aber neues 
Layout und gefertigte Platine - Und dann wird festgestellt das 
(zumindest damals) die nötige Funktion durch die ATMEL Lib nicht 
ausreichend unterstützt wird und die nötige Eigenleistung deshalb nicht 
in angemssener Zeit zu erbringen ist.
Also dritter Anlauf, PIC18F14K50 auf Lochraster geknallt, zwei Tage 
Später lief alles, Dann erst Layout erstellt, 10 Tage warten und das 
Projekt war fünf Studen später abgehakt.

Und GENAU DIESES V-USB "Problem" ist mir schon mehrfach über den Weg 
gelaufen. (der letzte Fall liest hier vielleicht ja gerade mit und kann 
sich noch an meinen "tiefen" Seufzer erinnern, Oder? ;-) p.s. habe es 
gerade auf dem Tisch...)

Das war jetzt nur ein Beispiel AVR vs. PIC - Gibt sicher zahlreiche 
andere Beispiele in beliebiger Kombination der Familien. Also wo dann 
beispielsweise der AVR die bessere Wahl ist

Also da liegen dann wirklich Welten zwischen dem Bastler und der 
"beruflichen" Welt.

Oder anderes ja schon angesprochenes Thema: Der Einsatz von Discovery- 
bzw. Dev. Boards:
Für den Privatbastler mit seinem Einzelstück ist es ja gar kein Problem 
tatsächlich eines der billigst Einstiegsboards zu nehmen,  die neben STM 
ja auch andere Hersteller anbieten, und dieses als ganzes in seiner 
Schaltung zu verbauen. Die Discovery-Boards sind manchmal ja sogar 
billiger als die Summe der wenigen darauf verbauten Teile in 
kleinststückzahl.
Bei hoch komplexen Dev.Boards sähe das selbst bei einem Privatbastler 
natürlich anders aus.

Für einen Kommerziellen geht das zumindest bei dieser komplexität ja GAR 
NICHT. Natürlich greift man für kleinere Stückzahlen auch hier und da 
mal auf fertig zugekaufte Boards als "Herzstück" zurück, aber dann 
handelt es sich um Boards mit Architekturen der Klasse ARM9 aufwärts mit 
externem Speicher usw. für die es sich auf grund der Komplexität einfach 
nicht Lohnt für eine kleine 20er oder vielleicht sogar 100er Serie 
selbst ein vier- bis Achtlagiges Layout zu entwerfen und SW-Mäßig bei 
Null anzufangen.
Da wird dann ein fertiges Modul zugekauft und nur noch die Periepherie 
Drumherum selbst erstellt.

c-hater schrieb:
> Viel schlimmer ist aber: Wenn der Prototyp läuft, soll er ja letztlich
> doch auf einer richtigen Leiterplatte landen und dann mit dem bereits
> fertigen Programm des Prototyps laufen.
> Das geht mit Discovery-Kits in aller Regeln nicht oder nur in der Form,
> daß man es selber praktisch nochmal nachbaut, was wieder unnötige Arbeit
> und Kosten verursacht.

Das ist aber so mittlerweile in der Proffessionellen Entwicklung 
-zumindest für kleine und mittlere Stückzahlen- doch Standard. Man geht 
von einem geeigneten Dev.Board aus das die Funktion die man möchte schon 
hat. Davon Ausgehend zeiht man sich den für sich relevanten Teil der 
Schaltung dann auf sein eigenes Design.
Das hat den Großen Vorteil das man einerseits Softwaremäßig nicht bei 
Null Anfängt und andererseits auch schon mit der Arbeit anfangen kann 
lange bevor die eigendliche Zielhardware vorliegt...

Gruß
Carsten

: Bearbeitet durch User
von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

c-hater schrieb:
> Das ist eigentlich garnicht der Punkt. Der Punkt ist vielmehr, daß man
> DIL mal eben auf ein Stück Loch- oder Streifenraster braten kann und man
> deshalb sofort loslegen kann, ohne erst 50 Euro und eine Woche
> Wartezeit) in ein PCB zu investieren (oder alternativ 10 Euro und vier
> Wochen Wartezeit).
> Und wenn ein Fehler im Schaltungsdesign ist, dann ist das auf Lochraster
> immer viel leichter auszubessern.
> Und wenn dann alles läuft wie es soll, dann kann man immer noch DASSELBE
> Programm auf einen IC mit SMD-Gehäuse auf einer richtigen Leiterplatte
> brutzeln.
>
> DAS ist der Hauptvorteil der AVRs.

NAJA - Eigendlich ist das ein Vorteil der PIC. Denn Atmel bringt ja 
schon lange nicht mehr jeden µC auch im DIL Heraus.
Microchip tut dies (bisher) noch bei ALLEN Derrivaten die mit 40 oder 
weniger PINs auskommen. Auch 16 und 32 Bit.

Jörg Wunsch schrieb:
> arsten Sch. schrieb:
>> Einfache Programmiermöglichkeiten für die PICs mit ein paar Bauteilen
>> für unter einer Mark an der seriellen Schnittstelle gabe es schon bevor
>> die AVR überhaupt auf den Markt kamen.
>
> Die brauchten meiner Erinnerung nach aber noch +12 V.  Die AVRs konnte
> man dann wirklich mit reinen TTL-Pegeln von der parallelen Schnittstelle
> programmieren.
Deshalb waren die meisten PIC einfachlösungen ja auch für SERIELLE 
Schnittstelle ;-). Da lagen ja mal halbwegs zuverlässig die +/-15V an.
Wobei ich nicht mehr weiß ob die nun im Simpel-Prommer mit 
Spannungsteiler oder mit Z-Diode stabilisiert wurden...
Heute werden bei PC mit noch vorhandener Serieller Schnittstelle ja 
selbst die 12V oft nicht mehr erreicht...

> Für mich war das Umstiegskriterium von PIC auf AVR aber auch die
> Verfügbarkeit eines GCC.
Das ist ja auch ein durchaus Nachvollziehbares Kriterium. Da hat 
Microchip lange Zeit echt "gepennt"

Gruß
Carsten

P.S.: Was mir hier irgendwie ins Auge fällt ist die Tatsache das viele 
die sich "Contra PIC" äussern nach eigener Aussage nie wirklich damit 
gearbeitet haben...

Aber dies sollte ja kein AVR vs. PIC thread werden sondern die Gründe 
für die hier "gefühlte" Übermacht der AVR etwas beleuchten. Und da sind 
sich die meisten ja Einig.
Zu Anfang des Jahrtausends bot bei den typischen Bastleranforderungen 
der AVR mehr Leistung fürs Geld und die viel frühere Unterstützung durch 
"kostenlose" C Compiler war auch ein riesen Vorteil.
Dadurch haben sehr viele gewechselt, Viele Wechsler sind dabei geblieben 
und haben mit der Zeit ein breits Spektrum an Hobbygeeigneten 
deutschsprachigen Tutorials und Beispielen geschaffen was heute noch 
viele deutschsprachige Einsteiger bei völlig anderer Ausgangslage zum 
AVR tendieren lässt.

von chris_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde sogar so weit gehen zu behaupten, dass auf Grund der 
Bastlererfahrung viele AVRs in professionelle Projekte gewandert sind. 
Außerdem sind die vielen "Hints und Tricks" im Internet auch für 
professionelle Entwickler eine große Hilfe.

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Für einen Kommerziellen geht das zumindest bei dieser komplexität ja GAR
> NICHT.

Themaverfehlung, setzen, 6. Hier ging es ausdrücklich um Bastler, kein 
Mensch hat hier behauptet, dass man das in einem Seriendesign so macht.

Im professionellen Umfeld nutzt man aber natürlich auch 
Entwicklungskits, wenn man noch kein fertiges Design auf dem Tisch hat. 
Ein ganz simples Design kann man sogar auch mal auf Lochraster aufbauen, 
und dann wird man die oben beschriebene Methode einsetzen.

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Und GENAU DIESES V-USB "Problem" ist mir schon mehrfach über den Weg
> gelaufen. (der letzte Fall liest hier vielleicht ja gerade mit und kann
> sich noch an meinen "tiefen" Seufzer erinnern, Oder? ;-) p.s. habe es
> gerade auf dem Tisch...)

Da scheint bei Euch wohl ganz gewaltig etwas mit der Einarbeitung neuer 
Mitarbeiter schiefzugehen. Normalerweise klärt man vor der 
Realisierung ab, ob die Anforderungen korrekt umgesetzt werden. Wenn man 
natürlich einen Mitarbeiter ohne die geringste Unterstützung loslaufen 
lässt, braucht man sich hinterher nicht wundern, wenn danach Unsinn raus 
kommt. Schuld ist da jedenfalls nicht der Neuling, woher soll er es denn 
wissen, wenn man ihm nichts bei bringt?

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Antimedial schrieb:
> Carsten Sch. schrieb:
>> Für einen Kommerziellen geht das zumindest bei dieser komplexität ja GAR
>> NICHT.
>
> Themaverfehlung, setzen, 6. Hier ging es ausdrücklich um Bastler, kein
> Mensch hat hier behauptet, dass man das in einem Seriendesign so macht.

Nee, nichts Themaverfehlung...
Für dich gilt: Textverständniss UNGENÜGEND,
Klassenziel nicht erreicht und Ehrenrunde drehen.

Carsten Sch. schrieb:
> Oder anderes ja schon angesprochenes Thema: Der Einsatz von Discovery-
> bzw. Dev. Boards:
> Für den Privatbastler mit seinem Einzelstück ist es ja gar kein Problem
> tatsächlich eines der billigst Einstiegsboards zu nehmen,  die neben STM
> ja auch andere Hersteller anbieten,
> [...]
> Für einen Kommerziellen geht das zumindest bei dieser komplexität ja GAR
> NICHT.

Es ging hier um die Bewertung der vorher von anderen abgegebenen 
Meinungen, da habe ich die Vorgehensweise aus der Sicht eines Bastlers 
und aus der Sicht des kommerziellen gegenübergestellt und damit 
eindeutig eine Hilfe zur Einordnung gegeben.
Denn schließlich ist eindeutig zu erkennen das hier BEIDE Fraktionen 
schreiben...

Antimedial schrieb:
> Da scheint bei Euch wohl ganz gewaltig etwas mit der Einarbeitung neuer
> Mitarbeiter schiefzugehen.

Und WIEDER:
Textverständniss UNGENÜGEND.
ICh habe nirgendwo geschrieben das es sich um meine Mitarbeiter oder 
"neue" Kollegen handelt noch das es überhaupt irgendetwas mit einem 
Beschäftigungsverhältniss zu tun hat. Ich bin nur einer derjenigen die 
man dann Fragt wenn es darum geht die Kartoffeln noch irgendwie aus dem 
Feuer zu holen...

von Antimedial (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Nee, nichts Themaverfehlung...
> Für dich gilt: Textverständniss UNGENÜGEND,
> Klassenziel nicht erreicht und Ehrenrunde drehen.

Doch, ich habe es schon verstanden. Nur hast du eben nicht begriffen, 
worum es hier ging.

Carsten Sch. schrieb:
> Es ging hier um die Bewertung der vorher von anderen abgegebenen
> Meinungen, da habe ich die Vorgehensweise aus der Sicht eines Bastlers
> und aus der Sicht des kommerziellen gegenübergestellt und damit
> eindeutig eine Hilfe zur Einordnung gegeben.
> Denn schließlich ist eindeutig zu erkennen das hier BEIDE Fraktionen
> schreiben...

Und alle haben sie auf deine große Erkenntnisse gewartet? Nein, du hast 
hier einfach nur Ooffensichtliches so hingestellt, als wärst du der 
einzig Erleuchteter, der der Welt das Licht bringt. Aber da liegst du 
eben falsch.

Carsten Sch. schrieb:
> Und WIEDER:
> Textverständniss UNGENÜGEND.
> ICh habe nirgendwo geschrieben das es sich um meine Mitarbeiter oder
> "neue" Kollegen handelt noch das es überhaupt irgendetwas mit einem
> Beschäftigungsverhältniss zu tun hat. Ich bin nur einer derjenigen die
> man dann Fragt wenn es darum geht die Kartoffeln noch irgendwie aus dem
> Feuer zu holen...

Egal, woher die Geschichte stammt: Hier ist etwas gewaltig schief 
gelaufen und das hat gar nichts mit Bastler oder Profi und Atmel oder 
Pic zu tun, sondern da ist etwas auf menschlicher Ebene in die Hose 
gegangen.

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

chris_ schrieb:
> Ich würde sogar so weit gehen zu behaupten, dass auf Grund der
> Bastlererfahrung viele AVRs in professionelle Projekte gewandert sind.

OH JA! Wobei das nicht nur für die AVR gilt.
Das ist doch der Grund warum immer niedrigpreisigere Einstiegsboards 
angeboten und Studenten mit Rabatten oder Gratisteilen umworben werden.

Man sieht ja so langsam die Auswirkungen sowohl im positiven bei denen 
die es verstanden haben und bei denen die meinten sie hätten es nicht 
nötig und mit jemanden der nicht mindestens 10k µC pro Monat abnimmt 
müsste man nicht mal reden...

Wobei sich auch die Firmen in der Umsetzung unterscheiden, einige 
konzentrieren sich wirklich nur auf Studenten und vielleicht 
großzügigerweise nach auf Schüler technischer Schulen weil die (wohl 
richtigerweise) Annehmen das sich nur in dieser Personengruppe mit 
einiger Wahrscheinlichkeit die Investitionen irgendwann deutlich 
Auszahlen.
Da muss dann der Ausweis eingeschickt werden, Verträge unterschrieben 
werden usw.

Andere handhaben das viel großzügiger und gewähren auch normalen 
Schülern und "Normal-Hobbyisten" gewisse Vergünstigungen. Entweder 
Offiziell oder Inoffiziell durch "Nichtprüfung" usw.

> Außerdem sind die vielen "Hints und Tricks" im Internet auch für
> professionelle Entwickler eine große Hilfe.

Für einige: OH JA.
Aber man muss sich auch durch viel Müll wühlen...

Gruß
Carsten

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Antimedial schrieb:
>...
Irgenwie NICHTS SINNVOLLES zum Thema, daher
-> PLONK!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ich schrieb:

> Beim STM32 reicht dir mir SWD aber auch SWDIO, SWCLK, GND und 3V3 ...
> der Punkt geht an die STMs ;-)

PDI bei den Xmegas ist dasselbe, SpyBiWire beim MSP430 auch.

JTAG hat allerdings andere Vorteile.

Carsten Sch. schrieb:

>> Die brauchten meiner Erinnerung nach aber noch +12 V.  Die AVRs konnte
>> man dann wirklich mit reinen TTL-Pegeln von der parallelen Schnittstelle
>> programmieren.

> Deshalb waren die meisten PIC einfachlösungen ja auch für SERIELLE
> Schnittstelle ;-). Da lagen ja mal halbwegs zuverlässig die +/-15V an.

Das ist allerdings noch vor der Zeit gewesen, da die AVRs aufkamen.
Ende der 1990er Jahre waren die klassischen MC1488 schon langsam
verschwunden, und aus den üblichen seriösen Schnittstellen kamen nur
noch 5 V raus.  Mein Eigenbau-PIC-Programmer wurde extern mit einer
12-V-Wandwarze befeuert.

> P.S.: Was mir hier irgendwie ins Auge fällt ist die Tatsache das viele
> die sich "Contra PIC" äussern nach eigener Aussage nie wirklich damit
> gearbeitet haben...

Ich habe, aber nur einmal.  Die Entwicklungsdauer der simplen Eieruhr
in Assembler war mir dann einfach zu schade, und ich wollte einen
Hochsprach-Compiler (naja, oder so ähnlich :) haben.  JAL war damals
noch unter aller Sau und hat nicht einmal konstante Ausdrücke zur
Compilezeit berechnet (was jeder Assembler kann), also habe ich mir
dann lieber eine Plattform gesucht, für die es einen GCC gibt.

Dass ich dadurch mal recht aktiv in die ganze Toolchain-Entwicklung um
den AVR-GCC herum selbst einsteigen würde, war eher nicht so geplant. 
;-)

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Und in der fertigen Lösung werkelt dann V-USB

V-USB ist ausdrücklich (und das steht auch so auf der Website) kein 
brauchbares kommerzielles USB Interface, da es wissentlich und 
absichtlich Spezifikationen verletzt, und es sollte auch dem dümmsten 
Neuling in der Firma klar sein, das es nicht nur Lizenzprobleme gibt, 
sondern schlicht und einfach nicht dem 'U' in USB entspricht. Wenn so 
etwas trotzdem durch die Planung bis zum Prototypen (und hoffentlich 
nicht weiter) kommt, ist das ganz klar ein Zeichen von inkompetenten 
Teamleitern und Projektplanern.

Das ist aber nun kein Grund, auf den AVRs rumzubashen, die können nichts 
dafür. Und ob ein STM32F10X einen XMega abhängt, muss erst noch bewiesen 
werden, das kommt mir in meinem Testprojekt mit 3 Prozessorfamilien 
nicht so vor. Ohne viel Umstände komme ich bei Kleinstprojekten mit dem 
ATTiny am schnellsten zum Ziel, ich kann mit den Tools von Atmel alle 
Tinys, Megas und XMegas bearbeiten und der AVRISP MkII kann sogar noch 
die 89S51 Schlachtrösser programmieren.
Als ich mir ein PIC Assemblerlistung zum Blinken einer LED angesehen 
habe habe ich mir einfach gesagt, das ich mir das nicht antun muss, wenn 
es auch einfacher geht.

: Bearbeitet durch User
von Seano L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ist schon alt aber passend:

EEVblog #45 - Arduino, PICAXE, and idiot assembler programmers
http://www.youtube.com/watch?v=iHFm-kVTXW8

Atmel vs PIC
http://www.youtube.com/watch?v=DBftApUQ8QI

Oder sein Video über das PICkit3, wie er sich immer aufregt, dazu der 
Aussislang:
http://www.youtube.com/watch?v=LjfIS65mwn8
Die Antwort von Microchip: http://www.youtube.com/watch?v=3YUvlrVlNao

Inzwischen gibts auch ein
PICKit4 vs AVRDragon:
http://www.youtube.com/watch?v=HWlpqSrabKs
habe ich selbst noch nicht gesehen.

IIRC erwähnt er in einem der Videos dass PIC "professioneller" ist, 
nicht deren Uraltarchitektur aber die haben ein breites Angebot an exakt 
passenden MCs für Industrieaufgaben, Microchip ist in der Industrie eine 
feste Grösse, dort wird richtig Geld verdient, dort wollte Atmel auch 
immer sich breit machen, hat aber nie so richtig geklappt. Wenn mal eine 
Firma auf einem System festgenagelt ist dann wechselt die nicht gleich 
wieder, deshalb bleiben viele bei Microchip, die haben auch für alles 
eine Lösung, egal wie alt die Architektur darunter ist, das Wissen ist 
schon vorhanden, da wechselt man nicht einfach die Architektur ohne 
tieferen Grund.
MC wollte vor Jahren mal die Atmelbude kaufen, Atmel hatte immer 
Geldprobleme, lange Zeit haben die nix verdient, ist vermutlich bis 
heute so.

von greg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schwen Gel schrieb:
> Inzwischen gibts auch ein
> PICKit4 vs AVRDragon:
> Youtube-Video "EEVblog #448 - New PICkit 4 & AVR Dragon"
> habe ich selbst noch nicht gesehen.

Das war ein Aprilscherz. :)

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Schwen Gel schrieb:
> Microchip ist in der Industrie eine
> feste Grösse, dort wird richtig Geld verdient, dort wollte Atmel auch
> immer sich breit machen, hat aber nie so richtig geklappt.

Verwechsle mal nicht "Atmel" mit "AVR".
Atmel gehört auf dem Halbleitermarkt definitiv zu den BigPlayern und ist 
über die letzten Jahre gemittelt auch noch Umsatzmäßig vor Microchip 
anzusiedeln. Die haben ja noch ein wenig mehr im Programm als "nur" die 
µC. Und bei den µC auch noch mehr als nur AVR.

Wobei auch der AVR -sicherlich auch durch die Popularität bei den 
Bastlern aus denen dann Entwickler wurden- mittlerweile seinen Weg in 
viele "High Volume Produkte" gefunden hat.

> Wenn mal eine
> Firma auf einem System festgenagelt ist dann wechselt die nicht gleich
> wieder, deshalb bleiben viele bei Microchip, die haben auch für alles
> eine Lösung, egal wie alt die Architektur darunter ist, das Wissen ist
> schon vorhanden, da wechselt man nicht einfach die Architektur ohne
> tieferen Grund.
Gilt so sicher nur noch für kleinere Firmen.

Die großen sind da schon flexibler, denen geht es dann um Eignung, 
Verfügbarkeit über den Produktlebenszyklus und vor allem dem Preis.
Woebi Preis nicht nur den einzelnen µC meint sondern die gesammten 
Entwicklungskosten. Wenn für eine bestehende Infrastruktur die Firmware 
dank ableitung aus der Vorversion für das neue Produkt vielleicht in 
100Man(n)Stunden einsetzbar ist, für eine andere Architektur aber erst 
einmal von Null an in vielen vielen tausend Stunden aufgebaut werden 
muss (bei sehr komplexen Produkten) dann fließt das definitiv mit in die 
Entscheidung ein. Aber die BWLer machen die Berechnung dann schon...

Ob die im Ergebniss dann korrekt ist steht natürlich auf einem anderen 
Blatt.

greg schrieb:
> Schwen Gel schrieb:
>> Inzwischen gibts auch ein
>> PICKit4 vs AVRDragon:
>> Youtube-Video "EEVblog #448 - New PICkit 4 & AVR Dragon"
>> habe ich selbst noch nicht gesehen.
>
> Das war ein Aprilscherz. :)

JEPP ;-)
Hatten wir doch letzte Tage schon einmal in einem Thread, oder?
Wobei ein "fünkchen" Wahrheit steckt doch darin:
Für den PicKit2 gibt es eine Alternative Firmware mit der dieser dann 
die AVR Programmieren kann!
Und für den Pickit3 wäre es auch kein Problem die Firmware so abzuändern 
das er als AVR Programmer taugen würde - Ja vermutlich sogar als "ISP MK 
II" Kompatibel- vorrausgesetzt die AVR seitige Kommunikation des 
Programmers mit dem PC ist bekannt.
Die Details zum PK3 sind jedenfalls öffentlich - Schaltplan ist im 
Benutzerhandbuch drin und der QUELLCODE der Firmware liegt bei Microchip 
zum Download bereit.
Es muss nur jemand mit den nötigen Kentnissen und Zeit den Bedarf sehen!
(Microchip selbst wird es ja sicher nicht machen ;-) )

Gruß
Carsten

: Bearbeitet durch User
von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schwen Gel schrieb:
> ist in der Industrie eine
> feste Grösse, dort wird richtig Geld verdient, dort wollte Atmel auch
> immer sich breit machen, hat aber nie so richtig geklappt.

Siehe auch hier: Beitrag "Atmel AVR in der Industrie"
Atmel ist anscheinend inzwischen sogar größer als Microchip: 
http://www.elektroniknet.de/halbleiter/sonstiges/artikel/86934/

Carsten Sch. schrieb:
> Die großen sind da schon flexibler, denen geht es dann um Eignung,
> Verfügbarkeit über den Produktlebenszyklus und vor allem dem Preis.

Und den Support. Ein fähiger FAE kann gerade bei großen Kunden die 
Entscheidung für eine Plattform wesentlich beeinflussen. Gerade bei 
großen Deals spielt der menschliche Faktor noch eine gewaltige Rolle. 
Wenn der Entwicklungsleiter den Vertriebler nicht leiden kann, wird er 
unter Umständen gegen den Lieferanten entscheiden, auch wenn die 
"harten" Fakten dafür sprechen.

Versprechen und Erfahrung zu Lieferverfügbarkeit sind nur Schall und 
Rauch, da schwenken die Firmen regelmäßig um 180°. Da muss nur ein neuer 
Chef kommen, der die unrentable Fab unbedingt los haben möchte, schon 
wird der Chip abgekündigt, auch wenn mal zig Jahre Verfügbarkeit 
versprochen wurden. Wenn da nicht ein wirklich großer Kunde dahinter 
steckt (Bosch, Siemens, etc.), der Druck aufbauen kann, hat man eben 
Pech gehabt.

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Ach was für ein schöner Thread!

Endlich hat hier jede junge Mutter mal Gelegenheit zu schildern, wie sie 
zu ihrem jeweiligen Kind gekommen ist (das sie jetzt über alles liebt) 
und warum sie das der Nachbarin nicht mag. (die war ja soooo gemein zu 
mir..)


Eine Tatsache ist, daß die klassische PIC-Architektur bis auf den 
heutigen Tag von vielen überhaupt nicht verstanden wurde. Deshalb können 
diese Leute damit auch nicht umgehen. Solche Sätze wie "hat ja nur EIN 
Register" beweisen das.

Und ganz viele hier in diesem Forum haben einen inneren Widerwillen 
gegen Assembler (was sie für unter ihrer Würde halten), was sie dazu 
veranlaßt, die Verfügbarkeit eines Compilers penetrant zu fordern. Für 
größere Projekte ist das ja OK, aber bei einem µC mit 512 
Programmschritten und 64 Byte RAM?

Gerade Aufschneider und Scharlatane stellen an andere gern maßlos 
überzogene Forderungen wie z.B. Hochsprache für nen Winzig-µC.

Hier wird gern auf der Architektur der kleinen PIC's (16Fxxx) 
herumgemosert, die ganz klar darauf angelegt ist, in Assembler 
programmiert zu werden - nur da entfaltet sie ihre volle Leistung, wenn 
der Programmierer nicht zu blöd ist.

Für die nachfolgenden Familien sieht das anders aus. Die können getrost 
in C programmiert werden, womit es egal ist, ob der Programmierer die 
CPU versteht oder nicht.

Man sollte den Titel dieses Threads präzisieren: Wieso Bastler im 
deutschsprachigen Raum und speziell in diesem Forum die AVR's gegenüber 
den PIC's zu bevorzugen scheinen.

Ich tippe mal drauf, daß dies überhaupt nicht der Fall ist, sondern daß 
die AVR-Leute einfach viel mehr über ihre Eier gackern und überall viel 
mehr Traffic verursachen als der Rest der Welt. Das schafft dann den 
Eindruck größerer Präsenz und Verbreitung.

So, und weil sogar unser fast wunschloser Mod sich dargestellt hat, auch 
mein Senf dazu: Mir wurden die PIC's so ca. 1992 vorgestellt und ich hab 
deren Potential ggü. den damals allseits verbreiteten 8051ern auf den 
ersten Blick erkannt. Deshalb hab ich sie als Ergänzung nach unten zu 
den NEC und Fujitsu-Controllern genommen. Die damalige Entwicklungs-Soft 
war unter aller Sau, also hab ich mir nen Assembler selbst geschrieben, 
später auch ne IDE dazu (die ich heut noch benutze) und programmiert 
wurde das Ganze mit nem teuren Programmer von MicroChip, der sich aber 
ziemlich schnell amortisiert hatte. Später wurden dann die Brennalgos 
veröffentlicht und ich baute dazu nen Brenner für den Parallelport nebst 
Brennprogramm - mit Delphi 1, weil ich für die vielen dazugekommenen 
Flash-Typen nicht nochmal ne Breitseite von ZIF-Fassungen ausgeben 
wollte. Da hing nämlich auch der vom Brenner gewählte Algo dran. 
Logisch, daß ich bei solchem Hintergrund auch diverse Bastelprojekte mit 
PIC's gemacht habe.

Mit Atmel hatte ich auch Versuche angestellt, sowohl mit den damaligen 
ARM-Typen als auch den AT90.. und später nochmal mit ATmega8 und 129 (? 
der mit dem LCD-Interface), fand aber z.B., daß der Codespeicher mir 
viel zu schnell voll war. Kurzum, ich hatte vor knapp 10 Jahren die 
Dinger endgültig abgetan. Irgendwo liegt immer noch ne Handvoll IC's 
davon herum, zusammen mit diskreter TTL. Mit AVR's würde ich nie und 
nimmer mehr ein Projekt anfangen, die Dinger sind Historie, auch wenn 
allen ihrer Verehrer jetzt die Zornesröte hochsteigt.

W.S.

von Walter T. (nicolas)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> bei einem µC mit 512
> Programmschritten und 64 Byte RAM

Warum willst Du so einem Riesenteil mit Assembler beikommen? Nimmst Du 
auch einen Teelöffel, um die Suppe auf Deinen Teller zu bringen?

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Eine Tatsache ist, daß die klassische PIC-Architektur bis auf den
> heutigen Tag von vielen überhaupt nicht verstanden wurde. Deshalb können
> diese Leute damit auch nicht umgehen. Solche Sätze wie "hat ja nur EIN
> Register" beweisen das.

Eben, und wenn ich dann eine andere Architektur finde, die ich auf 
Anhieb verstehe, ist es dann falsch, mich für diese zu entscheiden?

W.S. schrieb:
> Gerade Aufschneider und Scharlatane stellen an andere gern maßlos
> überzogene Forderungen wie z.B. Hochsprache für nen Winzig-µC.

Wenn ich einen Winzip-uC aber in C programmieren kann, wieso sollte ich 
mich mit Assembler herum ärgern? Ich habe mal einen Attiny10 
programmiert - in C. Ich komme damit schneller an mein Ziel, und das ist 
sowohl im professionellen Umfeld als auch beim Basteln entscheidend.

W.S. schrieb:
> Hier wird gern auf der Architektur der kleinen PIC's (16Fxxx)
> herumgemosert, die ganz klar darauf angelegt ist, in Assembler
> programmiert zu werden - nur da entfaltet sie ihre volle Leistung, wenn
> der Programmierer nicht zu blöd ist.

Ach ja, ein Programmierer, der nicht in Assembler programmiert, ist also 
blöd und kein echter Mann? Ein sehr gutes Argument für eine Architektur.

W.S. schrieb:
> Mit AVR's würde ich nie und
> nimmer mehr ein Projekt anfangen, die Dinger sind Historie, auch wenn
> allen ihrer Verehrer jetzt die Zornesröte hochsteigt.

Da kann ich allerdings - aus heutiger Sicht - zustimmen. Der Zukunft 
gehört der Cortex-M.

von stumpi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Mit AVR's würde ich nie und
> nimmer mehr ein Projekt anfangen, die Dinger sind Historie, auch wenn
> allen ihrer Verehrer jetzt die Zornesröte hochsteigt.

Full ACK. Habe mittlerweile alle aus meinen Bastelkisten aussortiert. 
Seit ich auf die Cortexe umgestiegen will, würde ich die nichtmal mehr 
geschenkt haben wollen...

- Alt
- Teuer
- Lahm

Weg damit!

:D

von Holm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. ist anonymer Gast, was schon aussagt wie schlecht er sich bei 
seinem Posting fühlt. Es gibt auch Leute die Ihre Meinung sagen und mit 
Ihrem Namen dazu stehen.

Mir ist es so ziemlich Wurst ob welchen µC ich verwende, ob MSP430, 
CortexM, AVR, R8/M16 oder 6811. Wenn es einen C-Compiler dafür gibt, bin 
ich recht schnell damit fertig und ich kann mir die Dinger nach der 
günstigsten Peripherie oder Preis/Leistung aussuchen. Eine µC 
spezifische Assemblerei lernen zu müssen ist aber immer zusätzlicher 
Aufwand der sich immer dann nicht lohnt wenn das Ergebnis nicht in 
Stückzahlen von mehreren Tausend produziert werden soll. Wenn es 
zeitkritisch wird, kann man mit Sowas wie Inline Assembler auch relativ 
schnell was in ein sonst in C geschriebenes System einbauen, dazu muß 
man nicht den ganzen Prozessorbefehlssatz vorher kennen. Ich habe auch 
8048 und 8051 Derivate in Assembler programmiert, die sehen aber für 
mich von Innen deutlich wie alle Intel Prozessoren "vergriesgnaddelt" 
aus, das betrifft auch die PICs der 12 und 16er Serien.
Mit den größeren habe ich da noch nicht zu tun gehabt, aber Ein Mips 
Prozessor ist ein Mips Prozessor und da gibt es auch PICs..
Für mich sind regelmäßige Architekturen "schöner" das fängt mit 6809 an, 
geht über 68k und endet bei Sparc noch lange nicht.

Egal, meistens muß ich eine Lösung erarbeiten und liefern, bei den 
Projekten die ich so habe darf ich da meist nach meinem Gefühl gehen und 
aus Erfahrung gucke ich da nicht zuerst bei den PICs, was durchaus auch 
ein Fehler sein kann, aber wenig Schaden verursacht. Acu die Zilog Ecke 
soll sooo uninteressant nicht sein.

Angefangen habe ich mal mit 21 00 0c 06 ff 75 23 10 fc c9 wie sicher 
viele andere auch.

Gruß,

Holm

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Holm Tiffe schrieb:
> Eine µC
> spezifische Assemblerei lernen zu müssen ist aber immer zusätzlicher
> Aufwand der sich immer dann nicht lohnt wenn das Ergebnis nicht in
> Stückzahlen von mehreren Tausend produziert werden soll.

Gerade dann setzt man heute normalerweise nicht mehr auf Assembler, 
weil Wartbarkeit und Portierbarkeit eine große Rolle spielen, auch bei 
kleinen Projekten. Ein Controller ist nicht teurer, nur weil man ihn in 
C programmiert.

von Maik (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Holm Tiffe schrieb:
> Angefangen habe ich mal mit 21 00 0c 06 ff 75 23 10 fc c9 wie sicher
> viele andere auch.
1
LD HL, 0c00
2
...
3
RET
Anfang und Ende gehen noch, aber zwischendrin muß ich passen.

VG,
Maik

von Rückblick (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
> Günstig und gut dokumentiert

Boahh, da sage ich 2mal Nein! ATMELs Dokumentation ist sehr, sehr 
gewöhnungsbedürftig. Und billig sind die AVRs schon lange nicht.

Oliver R. schrieb:
> Bis
> jetzt hat sich kein Grund ergeben zu wechseln.

Du kennst MSP oder ARM? ;-)))

Der AVR hat internen Takt und der interne Flash ist leicht zu 
programmieren. Atmel war der erste mit diesen Features, die anderne 
kamen später. Auch wenn andere besser sind, bleibt der Bastler bei dem, 
was er kennt. In der Industrie sieht das ganz anders aus, aber das ist 
hier nicht das Thema.

Der Toolchain war Anfangs sehr mau. Von Atmel gab es nur ASM.

von gnd3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>
> W.S. schrieb:
> > Hier wird gern auf der Architektur der kleinen PIC's (16Fxxx)
> > herumgemosert, die ganz klar darauf angelegt ist, in Assembler
> > programmiert zu werden - nur da entfaltet sie ihre volle Leistung, wenn
> > der Programmierer nicht zu blöd ist.
>
> Ach ja, ein Programmierer, der nicht in Assembler programmiert, ist also
> blöd und kein echter Mann?

blöd vielleicht nicht, aber definitiv kein echter Mann! Seit Bären nicht 
mehr mit bloßen Händen erlegt werden, kennt man daran den Unterschied 
;)

Holm Tiffe schrieb:
> Für mich sind regelmäßige Architekturen "schöner" das fängt mit
> 6809 an, geht über 68k und endet bei Sparc noch lange nicht.

das dachte ich bis heute Morgen auch, dann hatte ich ein 
Schlüsselerlebnis:
Beitrag "Re: ATtiny45 Programmier-Service?"
und die kleinen PIC sind ja nun das krasse Gegenteil von regelmäßig. 
Anscheinend macht die Dokumentation den Unterschied.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rückblick schrieb:

> Der Toolchain war Anfangs sehr mau. Von Atmel gab es nur ASM.

Wie viele Halbleiterhersteller kennst du denn so, die ihren eigenen
Compiler schreiben?

Oder wolltest du darauf hinaus, dass sie nie einen Fremdcompiler in 
einer
irgendwie verkrüppelten Version auf ihrer Webseite kostenlos angeboten
haben?  Sowas konntest du aber von IAR (auf deren Kooperation die
AVR-Leute anfangs zu 100 % gesetzt haben) mit dem Kickstart wiederum
schon immer bekommen.  Damit kaum besser oder schlechter als das, was
viele andere Halbleiterhersteller zu ihren Controllern so mitgeben.

von Rückblick (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Wie viele Halbleiterhersteller kennst du denn so, die ihren eigenen
> Compiler schreiben?

Musst du richtig lesen: Atmel ist mit ASM gestartet. ASM ist für mich 
kein Compiler.

Heute gibt es für die gängigen µCs third party Toolchains.

von Michael S. (rbs_phoenix)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich mir angucke, was manche hier so schreiben, komme ich mir schon 
manchmal wie ein Superbrain oder Überflieger vor, da ich keinerlei 
Probleme mit PICs hatte/habe, weder in ASM oder (kostenlosem) C-Compiler 
(mit dem ich trotz der ach so schlimmen limitierten Optimierung jedes 
Programm in einen PIC bekommen habe).

von Michael_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Antimedial schrieb:
> Wenn ich einen Winzip-uC aber in C programmieren kann, wieso sollte ich
> mich mit Assembler herum ärgern? Ich habe mal einen Attiny10
> programmiert - in C. Ich komme damit schneller an mein Ziel, und das ist
> sowohl im professionellen Umfeld als auch beim Basteln entscheidend.

Weil du von etwas keine Ahnung hast, machst du es fertig? Schon komisch.
Kein Wunder, das heutzutage aufgeblasene Programme auch nicht mehr 
können.
Um ein paar LED leuchten/blinken zu lassen und die über RS232 
anzusteuern braucht es keine Hochsprache.

Die Entscheidung welcher Kontroller? Es ist eben so wie es ist.
So um 1999 hab ich wochenlang überlegt, welchen MC ich nehmen sollte um 
ein Problem zu lösen.
Die Entscheidung für AVR war goldrichtig. Wenn ich mir schon die 
Typenvielfalt ansehe, kommt mir das Grausen.
Heute wäre die Entscheidung vielleicht ganz anders.

von Auswahl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael_ schrieb:
> Wenn ich mir schon die
> Typenvielfalt ansehe, kommt mir das Grausen.

???
Du bist damit überfordert?

von Michael_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja!!!!
Bei AVR machen es die Fuses.
Schau dir die endlose Liste bei reichelt an.
Ich bin nicht grundlegend abgeneigt. Aber die Entscheidung ist eben 
gefallen.
So mit der Frau, der Automarke, der Biersorte, des MC ....


Gut, manche wechseln die wie die Hemden :-) .

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Michael Skropski schrieb:
> Wenn ich mir angucke, was manche hier so schreiben, komme ich mir schon
> manchmal wie ein Superbrain oder Überflieger vor, da ich keinerlei
> Probleme mit PICs hatte/habe

Das ist nicht der Punkt. Mit genügend Einsatz kann man auch ein Stück 
Butter durch eine 45er Wand werfen. Aber warum sollte man? Wenn ich von 
A nach B mit erhobenem Haupt schreiten kann (AVR) warum sollte ich dann 
durch den Schlamm robben wollen (PIC)? Nur weil ich es könnte? Aus dem 
Alter bin ich raus ...

Ich habe jetzt schon eine Menge CPU/µC gesehen. Angefangen beim Z80 über 
Z8,  6502, 68HC11, x86, AVR 8-Bitter bis letztens PIC (konkret PIC18, 
aber auch PIC16 hab ich mir angeschaut). Und die PICs sind die bei 
weitem schäbigste und verkrüppeltste Architektur. Bei weitem. Lichtjahre 
Abstand.

Das geht los mit dem einzelnen Register (sogar der 6502 hat schon 
Indexregister), geht weiter mit dem Hardwarestack, dem einzelnen 
IRQ-Vektor (heh der PIC18 hat 100% mehr Interrupt-Vektoren!!1!elf!) und 
hört mit dem Banking beim RAM noch lange nicht auf. Die Architektur ist 
alt? Das ist der Z8 auch und der ist um Welten eleganter. Eleganter als 
der AVR sogar.

Auch war sich Microchip nicht zu schade den PIC18 einige neue Features 
zu spendieren. Aber für einen Stackpointer für einen Stack im RAM oder 
ein 16-Bit Indexregister (egal ob sie es nun Z oder HL nennen) hat es 
anscheinend nicht gereicht. Dabei haben sie ja mit dem FSR eine 
vergleichbare Methode zur indirekten Adressierung. Warum packen sie das 
Teil nicht einfach in die CPU, spendieren ihm noch ein INC und DEC und 
gut ist? Schwerer Fall von NIH?

Und das "nur 23 Befehle" (oder wieviele das heute sind) kannst du auch 
vergessen. Denn den ganzen Krempel drum herum (Banking, FSR - bei PIC18 
mehrere - etc mußt du ja trotzdem noch kennen).

Soweit es mich betrifft, sind die 8-Bit PICs ein Fall für die Tonne. Ich 
werde genau ein PIC Projekt nachbauen (for the records: ColorHug) - weil 
das einfacher ist als es auf vernünftiger Hardware zu reimplementieren. 
Für Neu/Eigenentwicklungen kommt mir kein PIC ins Haus.

Wer mag, kann sich das gerne antun. Aber ich betreibe mein Hobby ja, um 
Spaß zu haben. Und den habe ich mit PICs nicht. Alles IMHO, YMMV.


XL

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Axel Schwenke schrieb:
> Das ist nicht der Punkt. Mit genügend Einsatz kann man auch ein Stück
> Butter durch eine 45er Wand werfen. Aber warum sollte man? Wenn ich von
> A nach B mit erhobenem Haupt schreiten kann (AVR) warum sollte ich dann
> durch den Schlamm robben wollen (PIC)? Nur weil ich es könnte? Aus dem
> Alter bin ich raus ...
>
> Ich habe jetzt schon eine Menge CPU/µC gesehen. Angefangen beim Z80 über
> Z8,  6502, 68HC11, x86, AVR 8-Bitter bis letztens PIC (konkret PIC18,
> aber auch PIC16 hab ich mir angeschaut). Und die PICs sind die bei
> weitem schäbigste und verkrüppeltste Architektur. Bei weitem. Lichtjahre
> Abstand.

Also ich habe etwas länger Überlegt als sonst wie ich dies im halbwegs 
freundlichen Ton Schreibe, einfach weil ich mir nicht sicher bin ob der 
o.g. Beitrag eine etwas schlecht rübergebrachte "Sachliche" Antwort 
werden sollte oder nur reines Bashing ohne Verstand.

Aber dein ganzer Beitrag zeigt im Grunde nur das du da etwas bei den PIC 
ABSOLUT nicht verstanden hast. Warum auch immer...
Nur über etwas derart zu stänkern wo man die Hintergründe einfach nicht 
kapiert ist nicht unbedingt eine Empfehlung für einen. Insbesondere wenn 
das Unverständniss derart deutlich ist.

Klar - Bei den µC gibt es verschiedenste Konzepte des Aufbaus und damit 
auch unterschiedliche herangehensweisen an die Programmierung in 
Assembler.
Natürlich ähneln sich dabei einige Familien und andere sehen völlig 
anders aus.
Und genauso selbstverständlich ist es das es Anwender gibt denen die 
eine oder halt die andere, vielleicht auch die dritte Struktur am besten 
liegt und die vielleicht -obwohl sie fachlich hervorragend sind- auf 
einer der Strukturen nur schwer wirklich Effektiv in ASM programmieren 
können.
Es sind sehr wenige denen alle Architekturen gleich gut liegen. Und bei 
denen die Meinen das es doch so ist kann man das "gleich gut" nicht 
selten durch "gleich schlecht" ersetzen.

Das ist doch nichts anderes wie mit den Schulfächern, den einem liegen 
die Sprachen, dem anderen die Mathematik. Oder innerhalb eines 
Fachgebietes. Der eine ist spitze in Latein - aber nur Mittelmaß in 
Englisch usw...

Es ist also nichts dagegen Einzuwenden wenn jemand sagt das ihm die 
Architektur der Pics oder die der AVR nicht liegt. Aber von jemanden der 
meint Fachlich ausreichend Qualifiziert zu sein eine der Architekturen 
als "schlecht" zu bezeichnen sollte zumindest in der Lage sein diese 
Architektur zu verstehen - und erst nach dem er die verstanden hat dann 
seine Entscheidung treffen. Wenn die DANN gegen die Architektur ausfällt 
ist es ja OK.
Oder sich halt erst gar nicht wirklich mit der Architektur befassen, 
dann aber auch nicht glauben das er ernsthaft etwas zu dem Thema 
beitragen kann. (Da gab es doch mal ein Zitat: Wenn man keine Ahnung 
hat...) Und vor allem nicht mit angeblichen "Fachbegriffen" um sich 
schmeissen um die nicht vorhandene Ahnung zu kaschieren!

Aber um mal konkreter zu werden:
> Das geht los mit dem einzelnen Register (sogar der 6502 hat schon
> Indexregister), geht weiter mit dem Hardwarestack, dem einzelnen
> IRQ-Vektor (heh der PIC18 hat 100% mehr Interrupt-Vektoren!!1!elf!) und
> hört mit dem Banking beim RAM noch lange nicht auf.

Ok, im Einzelnen:
> Das geht los mit dem einzelnen Register
Also der PIC hat schon mal definitiv mehr als "EIN" Register. Wobei man 
sich hier wieder über die Definition des Wortes "Register" im Sinne von: 
"Was bezeichne ich hier überhaupt als Register" klarwerden müsste.
Das was man "meistens" im Sinne der "PC" Architektur mit Register 
assoziert hat der PIC nach meiner Auffassung z.B. gar nicht.

Er hat EIN auch als solches bezeichnetes Arbeitsregister. Das ist 
richtig.
Und an allen Operationen mit Datenmodifikation ist ist dieses Register 
auch beteiligt. Wobei der Wert im W Register (arbeitsregister) dann mit 
dem Inhalt jeder beliebigen Speicherzelle verknüpft (allgemein gemeint 
Logische und Aritmethische Funktionen) werden kann. Dieses 
Arbeitsregister liegt dabei von der Architektur zusammen mit dem 
SpecialFunctionRegistern und dem RAM (oft noch als General Purpose 
Register bezeichnet) in einem zusammenhängenden Speicherbereich. Ich 
lese es zwar immer seltener, aber in etwas älterer Literatur - sowohl 
Deutsch als auch englisch- wird der normale RAM deshalb auch als 
Register bezeichnet.

>(sogar der 6502 hat schon Indexregister),
Und was meinst du mit "INDEXREGISTER" Wenn man jetzt Erbsenzählerrisch 
wird gibt es ja nicht DAS Indexregister sondern derer verschiedene 
Ausführungen... Liegt ganz an der Architektur was man nun direkt 
darunter versteht...
Aber all die netten Sachen für die man die Indexregister üblicherweise 
nutzt kann der PIC auch... (Hab schon öfter gelsesn das beim PIC das FSR 
als Indexregister bezeichnet wird - wobei ich persöhnlich das nicht ganz 
treffend finde)

>geht weiter mit dem Hardwarestack
HArdwarestack haben die PICs praktisch von Anfang an (Zumindest seit der 
HErsteller Microchip heisst) Ist halt nur vom Nutzer nicht direkt 
greifbar und nur für Sprungadressen gedacht.
Und das wofür die meisten scheinbar den "allgemein Verwendbaren" 
Hardwarestack fordern macht der beim PIC überhaupt keinen Sinn.
Da ich mit jedem Register (=Speicherzelle) direkt arbeiten kann muss ich 
bei einem Interrupt oder ähnlichem Ereigniss wenn überhaupt auch nur ein 
einzelnes Register -das W Register- sichern.
Alles weitere macht man dann schon beim Programmentwurf...
Natürlich kann man das Programm auch so stricken das man unbedingt 
mehrere verschachtelte Sprünge einbaut wo auch immer wieder 
zurückgesprungen wird und man ja den vorherigen Wert des W Registers 
braucht. Aber das ist auf dem PIC eher schlechter stil und lässt sich 
oft einfach vermeiden.
Und in Fällen wo man es dann doch nicht vermeiden kann muss man sich 
halt selbst was basteln... geht auch!

> dem einzelnen IRQ-Vektor (heh der PIC18 hat 100% mehr
> InterruptVektoren!!1!elf!)

Ok, das mit dem einem IRQ Vektor bei den älteren PIC kann man 
tatsächlich als kleinen NAchteil gelten lassen. Durch die damit 
notwendige "Manuelle" Auswertung des Interruptauslösenden Ereignisses 
durch Vergleichsoperationen ist der Einsprung in die tatsächlich 
passende Interruptbearbeitung bei mehreren möglichen Interruptquellen 
tatsächlich etwas langsamer als bei einem System mit einem Vektor pro 
Ereigniss.
Allerdings kann man durch geschickte Programmierung und der 
Notwendigkeit nur ein einzelnes Register sichern zu müssen auch wieder 
Zeit gut machen.
Aber da gibt es noch ganz andere Architekturen die nur einen einigen 
Interruptvektor haben...
Aber wo schatten ist, da ist auch Licht- Dadurch das es nur einen Vektor 
gibt braucht man die Teile des Codes die für alle Interrupts gelten auch 
nur einmal implementieren. Bei den alten Controllern aus den Zeiten wo 
man sich mit einer Handvoll Bytes an Programmspeicher herumschlagen 
musste durchaus ein nennenswerter vorteil. (Heute wo Speicher Physisch 
viel Kleiner und viel viel billiger ist natürlich nicht mehr wirklich)

Aber schon dein Beitrag zum PIC18 zeigt wieder das du den Sinn absolut 
nicht verstanden hast! Es sind da nicht einfach nur ZWEI beliebige 
Interruptvektoren sondern ein Vektor für Interrupts mit hoher und ein 
Vektor für Interrupts mit niedriger Priorität! Und für fast alle 
Interruptereignisse kann man selbst festlegen ob diese hohe oder 
niedrige Priorität haben sollen.
Da ein Interrupt mit hoher Priorität einen Interrupt mit niedriger 
Priorität unterbrechen kann hat man so die Möglichkeit verschachtelter 
Interrupts.
Etwas was der AVR überhaupt nicht bietet und was man da nur mit 
Klimmzügen annähernd nachbilden kann.

Und wenn ich vor der Wahl stehe ob ich die Möglichkeit verschachtelte 
Interrups zu nutzen haben möchte, dafür aber nach dem Interrupt selbst 
noch das Ereigniss bestimmen muss - Oder ob ich viele verschiedene 
Interruptvektoren möchte bei denen aber keine Verschachtelung möglich 
ist - DANN wähle ich ganz klar ersteres!

> Die Architektur ist alt? Das ist der Z8 auch und der ist um Welten
> eleganter. Eleganter als der AVR sogar.
DAS liegt sicher im Auge des Betrachters. Wobei der Befehlssatz des Z8 
im Gegensatz zu dessen Architektur ja eng an den Z80 angelehnt ist. Es 
stecken halt abweichende Intuitionen hinter den Familien.
Wobei es fakt ist das die PIC heute sehr weit verbreitet sind und die Z8 
eher ein Nischendasein fristen. Woran es liegt kann und will ich aber 
nicht beurteilen. ICh kann nur sagen das MIR die Pic in ASM mehr lagen.

Was mit dem alter begründet wird ist ÜBLICHERWEISE die geringe Breite 
der für die Adressierung benötigten Register die bei den alten 
Architekturen das Banking nötig macht. JA - das ist wirklich ein 
Überbleibsel der alten Zeit. Da hatte man nicht so viel Speicher (sowohl 
Ram als auch ROM) und bei der Entwicklung hat man sich damals auf das 
nötigste beschränkt.
Wie schon geschrieben wurde speicher immer Billiger und die 
Anforderungen Höher und damit wurden die Register zu klein für die 
komplette Adresse. Also musste man mit Banking arbeiten. Ist halt die 
Folge der Politik das man jeweils der eingeführten Architektur treu 
bleibt.

Aber das ist doch gar kein Problem, wer damit nicht zurechtkommt muss 
sich damit doch gar nicht befassen. Einfach die alten PIC16 abseits 
liegen lassen und mit den PIC18 arbeiten. Problem gelöst. (Wobei die 
neuen PIC16 IMHO einen PIC 18 Kern haben. Es steht zwar jetzt die Tage 
ein extrem-Low-Power Projekt ins Haus und dafür setze ich seit langem 
erstmals wieder PIC16 (neue) ein, aber die Architektur habe ich noch 
nicht mal genau verglichen. Spielt auch eine Untergeordnete Rolle. Die 
werden auch in C programmiert)


> Auch war sich Microchip nicht zu schade den PIC18 einige neue Features
> zu spendieren. Aber für einen Stackpointer für einen Stack im RAM oder
> ein 16-Bit Indexregister (egal ob sie es nun Z oder HL nennen) hat es
> anscheinend nicht gereicht. Dabei haben sie ja mit dem FSR eine
> vergleichbare Methode zur indirekten Adressierung. Warum packen sie das
> Teil nicht einfach in die CPU, spendieren ihm noch ein INC und DEC und
> gut ist? Schwerer Fall von NIH?

Wie oben schon beschrieben hätte dies doch quasi keinen Sinn gemacht 
weil es einfach nicht zur Programmierphilosophie passt! Das Grundkonzept 
ist anders und das würde denen die es verstanden haben nicht viel 
bringen.
Und die es nicht verstanden haben und unbedingt das vom AVR (und einigen 
anderen -OK) gewohnte Konzept in den PIC pressen wollen würden sich 
darüber zwar vielleicht freuen, aber dennoch nur einen Mischmasch zu 
stande bringen.
Wie gesagt: Es ist nicht schlimm wenn einem das Konzept nicht liegt. 
Dann ist der PIC halt nichts für einen. So einfach ist das.
Aber das sagt erst einmal weder etwas über die allgemeine Qualität der 
Architektur noch über die des Programmierers aus. Es ist eine 
Geschmacksfrage.Anderen gefällt dieses Konzept und die mögen dann das 
AVR Konzept nicht. Zu guten Ergebnissen kann man auf beiden kommen.

> Und das "nur 23 Befehle" (oder wieviele das heute sind) kannst du auch
> vergessen. Denn den ganzen Krempel drum herum (Banking, FSR - bei PIC18
> mehrere - etc mußt du ja trotzdem noch kennen).
Ein paar mehr als 23 Befehle sind es dann üblicherweise doch! (Ich meine 
es geht mit 33 Befehlen los)
Klar -Banking und Paging ist bei den "großen" alten PIC ein Problem.
So einen der ehemaligen Flagschiffe der 16er Serie in der alten 
Architektur voll auszureizen kann je nach Programmaufbau schon mal eine 
Herausforderung werden. Wobei ich das Banking jetzt nicht einmal so 
tragisch finde. Beim RAM weiß bereits bei der Programmerstellung immer 
wo ich mich befinde und bei den SFR ist das nach kurzer Zeit ins Blut 
übergangen wenn man ernsthaft damit arbeitet. Zudem kann man ja auch 
entsprechende Makros verwenden die für die SFR gleich auf die richtige 
Bank schalten.

Beim Paging im Programmspeicher ist das wirklich eine Sache über die man 
im Fall des Falles wirklich intensiv wachen muss(te). Bei einem Code mit 
vielen Verzweigungen kann das echt Problematisch werden.
Zumal bei der Programmerstellung ja nicht einmal sofort ersichtlich war 
wo der Befehl nun direkt im Speicher landet. Ungefähre Abschätzung, 
Programmtechnische Maßnahmen (org) oder manuelle Kontrolle mit Debugger 
oder im Listing waren dann die verbleibenden Optionen.
Aber dieses Problem tritt(trat) nur auf wenn man Programme mit mehr als 
2k Speicher hatte. Also nur mit damals großen µC überhaupt möglich.
Und 2kworte in Assembler waren damals auch nicht gerade das 
durchschnittshobbyprogramm.
Das Argument lasse ich also mit kleinen Einschränkungen gelten.

Wer allerdings heute für derart große Programme noch zum Kombination 
Assembler und Pic16 der Urarchitektur greift dem ist dann auch nicht 
mehr zu helfen. Das grenzt heute durchaus an Masochismus.

Aber EINES darf man bei der ganzen Sache gar nicht vergessen:
ALLE diese oben genannten Punkte (ausser die Interrupvektoren) spielen 
für den großteil der Hobbyisten kaum noch ein Rolle.
Wirklich in ASM schreibt doch nur noch ein Minderheit große Programme.
Wirklich Sinn macht ASM doch nur noch für ganz einfache Aufgaben bei den 
kleinsten µC - Beispielsweise einfacher Ersatz von Logikschaltungen. Da 
kann ASM manchmal sogar schneller als C bei der Programmentwicklung 
sein.

Oder halt bei einigen wenigen zeitkritischen Programmteilen eines großen 
Programms die man dann allerdings eher mit Inline ASM abhandelt.

Im ersten Fall haben dann die µC gar nicht erst die Ressourcen bei denen 
man mit Banking oder Paging usw hantieren muss - Im zweiten Fall 
übernimmt auch bei den ASM Teilen der Compiler die meisten kritischen 
Punkte.
Und bei den 18F und größer ist es ja sowieso eine andere Architektur.

Ich kenne zwar durchasu auch "Experten" die heute noch auf PIC18 oder 
gar PIC24 ausschließlich in ASM teilweise große Programme erstellen. Und 
das dann mit irgendwelchen hahnebüchenden Argumenten begründen warum... 
Aber im Grunde steckt dann einfach nur die Unwilligkeit C zu lernen 
dahinter. Und damit disqualifiziert man sich zumindest im Bereich der 
größeren µC dann ja selbst. Und ich sage ganz klar: Ich habe lange Zeit 
große Programme in ASM auf verschiedenen Architekturen entwickelt, fühle 
mich immer noch Fit darin, aber eine Periepherieintensive Anwendung auf 
dem PIC18 in ASM zu schreiben würde ich mir niemals freiwillig antun. 
Dafür sind die nicht mehr gedacht. Von Dingen wie USB oder Ethernet mal 
ganz zu schweigen...

> Soweit es mich betrifft, sind die 8-Bit PICs ein Fall für die Tonne. Ich
> werde genau ein PIC Projekt nachbauen (for the records: ColorHug) - weil
> das einfacher ist als es auf vernünftiger Hardware zu reimplementieren.
Wie gesagt: Ob Pic was für dich sind oder nicht ist alleine deine 
Entscheidung. Und da kann es durchaus nachvollziehbaren und völlig 
berechtigte Argumente geben warum die für dich ungeeignet sind.
Aber die Plattform nur weil DU die nicht verstanden hast als "Müll" zu 
bezeichnen, damit disqualifizierst du dich nur selbst...

> Für Neu/Eigenentwicklungen kommt mir kein PIC ins Haus.
> Wer mag, kann sich das gerne antun. Aber ich betreibe mein Hobby ja, um
> Spaß zu haben. Und den habe ich mit PICs nicht. Alles IMHO, YMMV.

Wie gesagt - Da ist allein deine Entscheidung und wenn man diese Aussage 
Isoliert betrachtet ist daran auch nichts auszusetzen. Wenn jemanden 
eine Architektur nicht liegt und man mit anderen Architekturen auch zum 
Ziel kommen kann gibt es gerade im Hobbybereich wirklich keinen Grund 
warum man sich selbst damit belasten soll. Soweit stimme ich dir voll 
zu.

Gruß
Carsten

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Die Architektur ist
> alt? Das ist der Z8 auch und der ist um Welten eleganter. Eleganter als
> der AVR sogar.

Die Z8 Architektur war mir ebenfalls sehr positiv aufgefallen. Sie ist 
freilich einige entscheidende Jahre jünger und profitierte stark von den 
Erfahrungen der Konkurrenten. Zeitgenossen des ersten PIC und damit ein 
besserer Vergleich im Bereich reiner Microcontroller sind Fairchild F8 
und Intel 8048. Beides auch nicht gerade Musterbeispiele an Eleganz. 
Intel lernte ebenfalls und brachte den schon deutlich besser definierten 
8051, später dann den sehr eleganten und komplett abgesoffenen 8096.

Bei den PICs, auch den 18ern mit weniger Adressierungsproblemen, kann 
beim ersten Kontakt die eigenwillige Struktur von Befehlen und die 
Assemblersprache irritieren. Das ist gewöhnungsbedürftig, mit Anklängen 
ans Archaische. Gerade Leute, die schon viele andere Architekturen 
gesehen haben, haben sich an bestimmte prinzipielle Gemeinsamkeiten 
gewöhnt, auch was die Mnemotechnik angeht. Und dazu liegt PIC mitunter 
etwas quer.

Ob man Indexregister direkt als solche bezeichnet, oder ob man sie ins F 
legt, ob man den Akku A oder W nennt, ist technisch eigentlich nicht so 
entscheidend. Der drastischste Unterschied ist aber die Lesbarkeit. Ein 
Z8, AVR oder 68xx Assembler-Programm versteht man auch ohne 
Detailkenntnisse darin in groben Zügen schnell. Bei den 8-Bit PICs sieht 
das anders aus, egal ob 12/16/18er. Das kann beim Erstkontakt schnell zu 
einem "Igitt, was ist das denn?" Effekt führen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> DAS liegt sicher im Auge des Betrachters. Wobei der Befehlssatz des Z8
> im Gegensatz zu dessen Architektur ja eng an den Z80 angelehnt ist.

Die einzige Gemeinsamkeit zwischen Z8 und Z80 ist Zilogs Eigenheit, 
einen Store als Load zu bezeichnen. Was historisch vermutlich aus der 
Notwendigkeit(?) erwuchs, die MOV Befehle von Intels 8080 beim Z80 
partout anders nennen zu müssen.

Deine Unterscheidung zwischen Befehlssatz und Architektur ist etwas 
eigenwillig. Zilog fährt mnemotechnisch eine etwas andere Schiene als 
beispielsweise Motorola das tat, aber das wars auch schon. Benenne die 
LD Befehle in MOV um, die Jumps in Branches, und jede Ähnlichkeit ist 
verschwunden.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rückblick schrieb:
> Jörg Wunsch schrieb:
>> Wie viele Halbleiterhersteller kennst du denn so, die ihren eigenen
>> Compiler schreiben?
>
> Musst du richtig lesen: Atmel ist mit ASM gestartet. ASM ist für mich
> kein Compiler.

Eben.  Du hast aber impliziert, dass andere Hersteller mit Compilern
starten würden.  Mir fällt aber auf Anhieb keiner ein, der selbst
einen schreiben würde.  3rd-party-Compiler wiederum gab es auch für
den AVR von Anfang an, und mit IAR's Kickstart-Version meiner Erinnerung
nach auch damals schon kostenlos.  Mit Einschränkungen der Nutzbarkeit
natürlich, aber das wiederum ist bei anderen Herstellern auch nie
anders gewesen.

Um nicht in der Nutzbarkeit eingeschränkte und kostenlose Compiler
hat sich kaum ein Hersteller verdient gemacht.  TI vielleicht mit dem
GCC für den MSP430, aber dessen libc beispielsweise hinkt nach wie vor
der avr-libc ein ganzes Stück hinterher.

A. K. schrieb:
> Ein Z8, AVR oder 68xx Assembler-Programm versteht man auch ohne
> Detailkenntnisse darin in groben Zügen schnell. Bei den 8-Bit PICs sieht
> das anders aus, egal ob 12/16/18er.

Das würde ich unterschreiben.  Meine Z8-Programme kann ich heute noch
lesen, meine wenigen PIC12-Programme kaum noch. ;-)

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael_ schrieb:
> Weil du von etwas keine Ahnung hast, machst du es fertig? Schon komisch.
> Kein Wunder, das heutzutage aufgeblasene Programme auch nicht mehr
> können.
> Um ein paar LED leuchten/blinken zu lassen und die über RS232
> anzusteuern braucht es keine Hochsprache.

Wer sagt, dass ich keine Ahnung habe? Ich könnte mich natürlich jedes 
Mal mit dem Assembler in einer neuen Architektur beschäftigen und würde 
sie auch verstehen. Habe ich schon oft genug machen müssen (8085, Z80, 
6502, usw). Und ich habe natürlich auch schon AVR-Assembler 
programmiert. Ich hätte es also durchaus auch so lösen können. Aber als 
Profi steht für mich die Wartbarkeit des Codes an erster Stelle. 
Außerdem programmiere ich in erster Linie größere Prozessoren in C, 
daher ist Assembler nicht in C. Ich hätte also für die Entwicklung in 
Assembler länger gebraucht. Und Zeit ist Geld. Daher kommt natürlich nur 
C in Frage.

Das C-Programm hat übrigens unter 200 Byte. Mit Timer, GPIO, ADC und 
etwas Logik. Was ist daran bitte aufgeblasen?

Natürlich braucht man dafür nicht unbedingt eine Hochsprache. Wenn es 
aber schneller und genauso gut geht, wieso nicht? Nur weil C nichts für 
echte Männer ist? Das ist ein schwaches Argument im professionellen 
Umfeld. Hier zählt Wartbarkeit, und mein jetziges Programm kann man in 
zwei Minuten überblicken, während man bei einem Assemblerprogramm 
mindestens eine Stunde bräuchte, wenn man sich nicht ständig mit dieser 
Architektur befasst.

von Sven P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Also der PIC hat schon mal definitiv mehr als "EIN" Register.
Nein, er hat genau ein Arbeitsregister, wenn man nach der Konvention 
geht, die bei praktisch allen anderen Mikroprozessoren Anwendung findet. 
Im Gegenzug, und das beschreibst du ja auch, können viele Instruktionen 
direkt im File (RAM) ausgeführt werden.
Das Prinzip hat sich aber scheinbar nicht so richtig durchgesetzt. Außer 
PIC kenne ich selbst keine andere Architektur, die so gebaut ist.


Carsten Sch. schrieb:
> Und was meinst du mit "INDEXREGISTER"
'Indexregister' ist die gängige Bezeichnung für einen 
Adressiermechanismus mit Basis und Offset. Klar, kann man 
verschiedenartig implementieren.
Das FSR beim PIC ist kein Indexregister, sondern dient der indirekten 
Adressierung. Der AVR z.B. hat auch kein Indexregister, sondern drei 
Zeigerregister für indirekte Adressierung, die zumindest mit einem 
festen Offset verrechnet werden können.

Die Indizierung muss man sich also bei beiden zusammenbauen, indem man 
die Basisadresse läd und dann den Offset dazuaddiert. Der Zugriff auf 
Datenstrukturen geht dann beim AVR etwas leichter, weil man zumindest 
einen festen Offset auf die Basis in der Instruktion kodieren kann.


Carsten Sch. schrieb:
> HArdwarestack haben die PICs praktisch von Anfang an [...]
> Und das wofür die meisten scheinbar den "allgemein Verwendbaren"
> Hardwarestack fordern macht der beim PIC überhaupt keinen Sinn.
> [...] Aber das ist auf dem PIC eher schlechter stil und lässt sich
> oft einfach vermeiden.
Der Stack ist die praktisch überall angewendete Methode, um 
wiederverwertbare Unterprogramme zu schreiben. Unterporgramme sind 
vieles, aber ganz sicher kein schlechter Stil. Das ist Praxis 
schlechthin...
Wenn man in einem Unterprogramm ein paar Werte speichern muss, dann 
nimmt man dazu normalerweise etwas Speicher vom Stack oder man sichert 
ein paar Register auf dem Stack und verwendet diese dann. Beides geht 
beim PIC so ja nicht. D.h., man muss dem Unterprogramm ein Stück 
Speicher im File fest zuweisen, welches das Unterprogramm dann nutzen 
darf. Damit aber darf das Unterprogramm freilich nicht mehr aus dem 
Interrupt aufgerufen werden. Rekursionen gehen so auch nicht. Außerdem 
müsste man mehreren Unterprogrammen mehrere getrennte Speicherbereiche 
zuteilen, wenn man aus einem Unterprogramm ein anderes nutzen möchte.

Carsten Sch. schrieb:
> Dadurch das es nur einen Vektor
> gibt braucht man die Teile des Codes die für alle Interrupts gelten auch
> nur einmal implementieren.
Die da wären?
Viel schlimmer ist, dass man für jeden Interrupt gemeinsamen Ballast 
mitschleppt, nämlich die Interruptweiche.

Carsten Sch. schrieb:
> Etwas was der AVR überhaupt nicht bietet und was man da nur mit
> Klimmzügen annähernd nachbilden kann.
Doch freilich kann man beim AVR die Interrupts nach Belieben 
verschachteln. Da man beim AVR ja einen echten Stack hat, kann man seine 
Register für den Interrupt auch auf dem Stack sichern. Indem man beim 
Eintritt in die Interruptroutine schlicht das globale I-Flag wieder 
setzt, können Interrupts sich gegenseitig unterbrechen.


Carsten Sch. schrieb:
> DAS liegt sicher im Auge des Betrachters.
Naja. Selbst der Z8 konnte schon mit Übertrag rechnen. Das kann erst der 
PIC18.
Insgesamt eignen sich die PIC halt dadurch nur sehr begrenzt für die 
Umsetzung von Hochsprachen. Beim AVR hat man daher ja z.B. auch gleich 
drei Zeigerregister, den Stack und 32 Arbeitsregister spendiert. Und 
schau mal in ein compiliertes Assembly rein, was da benutzt wird...


Carsten Sch. schrieb:
> Wie oben schon beschrieben hätte dies doch quasi keinen Sinn gemacht
> weil es einfach nicht zur Programmierphilosophie passt!
Das ist dann aber eine Philosophie, die man einzig bei Microchip findet.
Die Klimmzüge mit dem Paging hast du ja selbst schon erkannt.

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Antimedial schrieb:
> Außerdem programmiere ich in erster Linie größere Prozessoren in C,
> daher ist Assembler nicht in C.

... nicht so präsent wie C.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Das Prinzip hat sich aber scheinbar nicht so richtig durchgesetzt. Außer
> PIC kenne ich selbst keine andere Architektur, die so gebaut ist.

RCA 1802 geht entfernt in diese Richtung. Ein Akku, 32 Bytes RAM und bis 
zu 64KB schlecht ansprechbarer Hilfsdatenspeicher. ;-)

> Insgesamt eignen sich die PIC halt dadurch nur sehr begrenzt für die
> Umsetzung von Hochsprachen.

PIC18 in der zweiten Version, also mit zu einem Framepointer relativer 
Adressierung lokaler Daten, geht schon einigermassen. Freilich sind alle 
Architekturen mit einem einzelnen 8-Bit Arbeitsregister mit C etwas über 
kreuz, aber das liegt eher an C und seiner 16-Bit Mindestdefinition. 
Dass C eine grosse Vorliebe für Pointer hat wird auch nicht von jedem 
8-Bitter goutiert, ist aber auch eher als Eigenheit von C zu verstehen.

AVR hat auch seine Probleme mit Stackframes, da der Stackpointer weder 
adressierbar noch von Haus aus atomar modifizierbar ist. Böser Fehler. 
IAR, die bei der Entstehung mit Pate standen, hatte wohl von Anfang die 
Vorstellung, den Return-Stack analog zu einem reinen Hardware-Stack vom 
Activation-Stack mit den lokalen Daten zu trennen.

: Bearbeitet durch User
von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
Ein PIC16 oder PIC18 kann man eigentlich nicht mit einem AVR 
vergleichen, denn die sind eher für "kleinere" Aufgaben gedacht. Die 
echten "Mini"-Anwendungen.

Ein AVR sollte man eher mit einem PIC24 vergleichen und da schenken sich 
beide nicht viel.

Genauso kann man ein AVR auch nicht mit einem STM32 vergleichen.

Viel mehr sollte man eine Grafik machen, mit Anforderungen und den 
entsprechenden Prozessor.

kleinst: PIC10 / PIC12
kein: PIC16 / PIC18
mittel: PIC24 / AVR / 8051
groß: MIPS (PIC32) / ARM (LPC2xxx) / Cortex-Mx (STM32, LPC17xx...) 
(beliebiger Hersteller)

Und wenn man schon einen AVR kennt, dann wird man für die 
kleinst-Anwendungen keinen PIC nehmen sondern bei dem viel zu großen AVR 
bleiben.
So auch umgekehrt, wenn man aus den klein-Anwendungen (mit PIC16) kommt 
und mal etwas größeres macht, dann nimmt man erst mal weiterhin einen 
PIC.

Daher nehme ich für meine "Mini-Anwenungen" eben einen STM32, nicht weil 
ich die kleinen nicht könnte, sondern weil ich für den großen schon alle 
Bibliotheken/Programmfunktionen habe und vor allem habe ich genügend von 
denen in der Bastelkiste liegen. Ich habe mich für den "Dicken" 
entschieden, weil ich damit wirklich alles erschlagen kann (außer 
Linux-Kernel / Betriebssystem, was ich nicht will).

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> RCA 1802 geht entfernt in diese Richtung. Ein Akku, 32 Bytes RAM und bis
> zu 64KB schlecht ansprechbarer Hilfsdatenspeicher. ;-)

Und weil wir gerade so schön nostalgisch sind: der TMS9900 hatte auch 
alle Register im RAM liegen (der Zeiger darauf war der 'Workspace 
Pointer'), besonders praktisch war da die Anweisung 'BLWP @Adresse', 
damit konnte man den gesamten Registersatz wechseln.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:
> Ein PIC16 oder PIC18 kann man eigentlich nicht mit einem AVR
> vergleichen, denn die sind eher für "kleinere" Aufgaben gedacht. Die
> echten "Mini"-Anwendungen.

Historisch passt das nicht wirklich. Der ersten AVRs adressierten exakt 
das gleiche Marktsegment wie die PIC16. Grösser als die PIC16 ist AVR 
nur weil dank fehlendem Banking nach oben hin ausbaufähig, während 
Microchip dazu erst die 18er und 30/24er rausbringen musste.

AVR deckt also schlicht einen grösseren Bereich ab, als die diversen 
PIC-Varianten es jeweils tun.

> Ein AVR sollte man eher mit einem PIC24 vergleichen und da schenken sich
> beide nicht viel.

Wobei du dich wohl auf die ohne Klimmzüge mögliche Programm/Datengrösse 
beziehst. Bei anderen Kriterien kommt man zu einem völlig anderen 
Ergebnis.

: Bearbeitet durch User
von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wobei du dich wohl auf die ohne Klimmzüge mögliche Programm/Datengrösse
> beziehst. Bei anderen Kriterien kommt man zu einem völlig anderen
> Ergebnis.

Ja, hauptsächlich. Die Peripherie ist bei den PIC's/AVR identisch 
leistungsfähig. Nur dass bei z.B. zwei verschiedenen PIC24 das gleiche 
HW-Modul unterschiedliche Bits zur Ansteuerung verwendet ist mehr als 
ein wenig unglücklich. Ich bin da auch schon mal auf die schnauze 
gefallen, was auch maßgeblich der Auslößer war "Nie wieder PIC" (hat 
mich ein Tag gekostet).

: Bearbeitet durch User
von Frohen Advent (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:
> Genauso kann man ein AVR auch nicht mit einem STM32 vergleichen.

Warum nicht? Mega32 gegen M0 oder M1 passt schon. Nur stinkt der Mega 
dabei megamäßig ab.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Frohen Advent schrieb:
> Warum nicht? Mega32 gegen M0 oder M1 passt schon.

Der Cortex M1 ist eine Prozessorbeschreibung für FPGAs.
Nicht alles was hinkt eignet sich für einen Vergleich.

von Markus M. (mmvisual)


Bewertung
1 lesenswert
nicht lesenswert
Mega Bastler Preise:
http://such001.reichelt.de/index.html?&ACTION=446&LA=446&SEARCH=mega32&OFFSET=16&SORT=artnr&SHOW=1

STM32 Bastler Preise:
http://such001.reichelt.de/index.html?&ACTION=446&LA=446&SEARCH=stm32&OFFSET=16&SORT=artnr&SHOW=1

>Nur stinkt der Mega dabei megamäßig ab.

YEP, die paar cent kann sich ein Bastler auch noch leisten.
Einzige, die direkte Steckbrettauglichkeit.

von Frohen Advent (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, ja, ja, ...


Markus Müller schrieb:
> Genauso kann man ein AVR auch nicht mit einem STM32 vergleichen.

Warum nicht? Mega32 gegen M0 oder M3 passt schon. Nur stinkt der Mega
dabei megamäßig ab.

von Markus M. (mmvisual)


Bewertung
-1 lesenswert
nicht lesenswert
Mega Industrie Preise:
http://at.mouser.com/Search/Refine.aspx?Keyword=MEGA32&Ns=Pricing|0&FS=True

STM32 Industrie Preise:
http://at.mouser.com/Search/Refine.aspx?Keyword=STM32F&Ns=Pricing|0&FS=True

LPC Industrie Preise:
http://at.mouser.com/Semiconductors/Embedded-Processors-Controllers/_/N-6hpef?Keyword=LPC1&Ns=Pricing|0&FS=True

Winner is .... ST (NXP) mit ARM-Prozessoren!
Und das Zählt hauptsächlich in der Industrie.
Ich bin maßgeblich auch dafür verantwortlich dass in einer Firma ein 
STM32 eingeführt wurde - seither werden keine neuen Projekte mehr mit 
einem Mega erstellt! - Und alle anderen Entwickler sind über diese 
Entscheidung glücklich und zufrieden und das schon seit vielen Jahren.

: Bearbeitet durch User
von Ic galube es nicht (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Ich bin maßgeblich auch dafür verantwortlich dass in einer Firma ein
>STM32 eingeführt wurde

Dafür hast du bestimmt das große Firmenverdienstkreuz am Bande bekommen.

von Frohen Advent (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ic galube es nicht schrieb:
> Dafür hast du bestimmt das große Firmenverdienstkreuz am Bande bekommen.

Und den ST Kaffeebecher. ;-)))

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
Nein - Dafür habe ich einen Prozessor bekommen, den ich auch privat sehr 
gerne progge und somit mach mir der Job mehr Spaß.

von anonymous (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:
> Ich bin maßgeblich auch dafür verantwortlich dass in einer Firma ein
> STM32 eingeführt wurde

Schlimm - wieder so einer der seine Kollegen terrorisiert!

Markus Müller schrieb:
> Und alle anderen Entwickler sind über diese
> Entscheidung glücklich

Und luegen/heucheln muessen Sie auch noch deswegen...


Frohes Fest!

von Antimedial (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Markus Müller schrieb:
> Winner is .... ST (NXP) mit ARM-Prozessoren!

Ich kann das für hohe fünf/sechsstellige Jahrestückzahlen bestätigen. 
Wobei sich die Cortex-Hersteller nicht viel geben, da kommt es eher 
darauf an, wie groß das Gesamtauftragsvolumen ist. Wenn man dann noch 
ein paar Hunderttausend Schaltregler abnimmt, kommt der Hersteller schon 
preislich noch etwas entgegen.

A. K. schrieb:
> Wobei du dich wohl auf die ohne Klimmzüge mögliche Programm/Datengrösse
> beziehst. Bei anderen Kriterien kommt man zu einem völlig anderen
> Ergebnis.

Man merkt hier, dass viele Leute so tief in ihrer Assembler- und 
Registerwelt fest halten, dass sie anscheinend kaum in der Lage sind, 
komplexere Anwendungen zu erschließen. Womöglich sind die Leute noch nie 
über ein LED-Blinkbeispiel oder über den Austausch von zwei Byte über 
die UART hinaus gekommen.

von Sven P. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Mouser und Industriepreise ist jetzt aber auch ziemlich lächerlich.

Man möge auch mal die Errata der Bausteine vergleichen. Das war für mich 
außerdem eine gute Entscheidungshilfe.

von Michael S. (rbs_phoenix)


Bewertung
-1 lesenswert
nicht lesenswert
Axel Schwenke schrieb:
> Das ist nicht der Punkt. Mit genügend Einsatz kann man auch ein Stück
> Butter durch eine 45er Wand werfen. Aber warum sollte man? Wenn ich von
> A nach B mit erhobenem Haupt schreiten kann (AVR) warum sollte ich dann
> durch den Schlamm robben wollen (PIC)? Nur weil ich es könnte? Aus dem
> Alter bin ich raus ...

Ich würde mich als Hobby-Bastler ansehen. Da zählt für mich, dass ich 
eine oder mehrere Aufgabe(n) habe, die ein µC erledigen können muss. 
Also mach ich MPLAB auf, programmiere los, dann ist das Programm 
irgendwann fertig, ich flashe es auf den PIC und fertig ist die Laube. 
Ich bin bisher weder an eine Speicherplatzgrenze noch an 
Geschwindigkeitsproblemen gescheitert. Und wenn, dann änder ich das 
Projekt in MPLAB, wechsle den Compiler, änder ein paar stellen im Code 
und nehme eben einen anderen PIC (oder gar Familie -> 16bit/32bit PIC) 
und flashe den neuen PIC mit der gleichen IDE und dem gleichen Tool - 
dem PICKIT3 (was ich bisher allerdings noch nie musste).

Wieso sollte ich nun zu AVR wandern? Nur weil ich da ggf. 10 Zeilen 
C-Code spare und die AVR dann im Endeffekt 10% schneller sind (obwohl 
mir die Geschwindigkeit vorher auch gereicht hat) ?

Wieso ist der (8bit)PIC denn absoluter Müll und nur zum verbrennen gut? 
Weil man im Endeffekt Leistungstechnisch ein wenig unter dem heiligen 
AVR ist und somit den AVR bis zum Letzten besser ausquetschen kann, als 
z.B. ein PIC18? Einfach den nächst größeren/leistungsfähigeren µC zu 
nehmen ist wohl zu einfach, daher muss mindestens bis zu 95% der 
Leistung ausgebeutet werden. Oder ist das so, weil man statt DDRx TRISx 
schreiben muss, wo TRISx auch noch auf einer Kilometerweit entfernten 
Bank liegt (der Compiler setzt sogar das eine Bit von alleine!)? Oder 
diese ach so dermaßen verachtungsvolle Architektur, von der man bei 
C-Programmen rein garnichts mitbekommt?

Wenns danach geht, wieso nehmen wir dann nicht alle ein Cortex-M4? Da 
hat man noch mehr Platz und ist noch schneller. Dadurch können wir auch 
einfach alle Zahlen als real (64bit Gleitkommazahl) deklarieren, selbst 
wenn es eine Zählvariable ist, die von 0 bis 7 zählt. Speicher haben wir 
doch genug und schnell genug sind wir auch noch, da wir ja mit >200MHz 
Takten können. Reicht doch, um ein paar Taster zu entprellen und danach 
ein paar Relais zu schalten oder einen Schrittmotor zu drehen.

Ich bin ganz froh darüber, dass ich bei den PICs gelandet bin.
1. Wenn ein PIC18 nicht mehr reicht, nehm ich einfach ein PIC24/dsPIC 
oder danach einen PIC32 und muss weder die IDE, noch den Programmer, 
noch den Hersteller (und damit auch die Datenblattstruktur und 
Bezeichnungen der Register) wechseln.
2. Würde mir das Lobpreisen meines Herstellers und die Hassreden gegen 
PICs nach einer Zeit tierisch auf den Nerv gehen.

von Moby (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Matthias Sch. schrieb:
> A. K. schrieb:
>die Anweisung 'BLWP @Adresse',
> damit konnte man den gesamten Registersatz wechseln.

Das ist das Einzige was mir am AVR noch fehlt. Diese ganze 
Registerretterei beim Interrupteintritt ist doch dermaßen von 
überflüssig. Und das Flagregister könnte auch automatisch gesichert 
werden. Ansonsten bin ich mit AVRs rundum glücklich:  einfach, schnell, 
sparsam- mehr als genug für die allermeisten Hobbyprojekte.

von Sven P. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
<rant>

Michael Skropski schrieb:
> 2. Würde mir das Lobpreisen meines Herstellers und die Hassreden gegen
> PICs nach einer Zeit tierisch auf den Nerv gehen.

Genauso geht es anderen Leuten tierisch auf den Nerv, wenn man wieder 
und wieder gefragt wird, warum diese oder jene Prozessorfamilie so und 
so verbreitet ist oder auch nicht und womit man einsteigen sollte. Und 
wenn man dann wieder und wieder die Gründe zu erklären versucht.
Und wenn dabei wieder und wieder herauskommt, dass zum Beispiel der 
(kleine) PIC diese und jene Eigenschaft hat, die zum Beispiel der AVR, 
der Z8, der MSP und der ARM nicht haben. Und wenn man noch vermutet, 
dass es sich dabei offenbar um Schwächen der Architektur handelt, weil 
der (kleine) PIC heute der einzige Prozessor ist, der noch so gebaut ist 
und faktisch alle anderen Hersteller die Punkte auch erkannt haben und 
mit verbesserten Architekturen darauf reagiert haben. Und wenn selbst 
Microchip diese Eigenheiten in den größeren PIC-Familien aufgegeben und 
verbessert hat.

Und wenn dann wieder jemand kommt und sagt: Aber...

Das ist ermüdend.


Und wenn ich jetzt sage: "Ich rate jedem Einsteiger davon ab, mit PIC14 
oder PIC16 einzusteigen" dann kommt jetzt garantiert der nächste, der 
sich all die Dinge, die oben diskutiert wurden, wieder schönredet und 
einen Anfänger auf den PIC14/16 loslässt.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Matthias Sch. schrieb:
> Und weil wir gerade so schön nostalgisch sind: der TMS9900 hatte auch
> alle Register im RAM liegen (der Zeiger darauf war der 'Workspace
> Pointer'), besonders praktisch war da die Anweisung 'BLWP @Adresse',
> damit konnte man den gesamten Registersatz wechseln.

Das ebenso arbeitende Interrupt-Modell des 9900 gehörte zu dessen 
stärksten Seiten. Mit den 16 separaten Interrupts mit jeweils einem 
solchen Kontext unterschied der sich wohltuend vom den anderen 
Mikroprozessoren. Als TI dann den 9995 brachte, die erste wirklich gute 
Implementierung, haben sie ausgerechnet dies bös kastriert, also grad 
das verschlechtert was diese Kiste besser konnte als die anderen.

: Bearbeitet durch User
von Michael_ (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Antimedial schrieb:
> Man merkt hier, dass viele Leute so tief in ihrer Assembler- und
> Registerwelt fest halten, dass sie anscheinend kaum in der Lage sind,
> komplexere Anwendungen zu erschließen. Womöglich sind die Leute noch nie
> über ein LED-Blinkbeispiel oder über den Austausch von zwei Byte über
> die UART hinaus gekommen.

Wenn du das beruflich machst, hast du Recht. Da hast du Werkzeuge, 
Mittel und Zeit, die ein Bastler nicht hat. Bezahlen mußt du es auch 
nicht.
Der Überschrift nach geht es hier um Bastler und deren Entscheidung für 
ein Prozessorsystem.

von Der Rächer der Transistormorde (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Michael Skropski schrieb:
> Wieso sollte ich ...

Die ganze Diskussion ist für die Tonne. Typisches Fanboyz Geschwafel 
aber lustig zu beobachten.

Geht schon bei der Frage los:
Wieso Hobby Bastler dieses oder jenes bevorzugen kann nur ein Vollidiot 
behaupten (auch wenn er es als Frage verkleidet) Bild Zeitungs Niveau 
wie die ganze Diskussion.

Das geilste ist das Errata Argument. Wenn die eine Firma davon weniger 
hat wird im Hirn von Karl Kleindoof Hobbybastler die magische Fähigkeit 
dieser Firma auch weniger zu machen assoziiert.

Dem ist aber nicht so, woher auch? Wer heute bei X ist arbeitet morgen 
bei Y und führt da dann die Prozesse ein die er bei A B C ... X gelernt 
hat.

Bei dieser leidigen Apple Gehirnwäsche war ds auch nicht anders, der 
Laden macht genau so viel Mist (oder wenig Mist) wie jedder andere auch.

Nur die "Fehlerkultur" ist da eine andere und die ganzen Volltrottel 
(aka Fonboyz) fallen da auch noch drauf rein.



Anderes herum kann man natürlich genau so Fragen warum sich im PIC 
Bereich so viele Profis tummeln ;-)

von Sven P. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Der Rächer der Transistormorde schrieb:
> Das geilste ist das Errata Argument. Wenn die eine Firma davon weniger
> hat wird im Hirn von Karl Kleindoof Hobbybastler die magische Fähigkeit
> dieser Firma auch weniger zu machen assoziiert.
Nö.

Aber wenn ich als Bastler - denn nur darum geht es hier - die Wahl 
zwischen vier oder fünf Prozessorfamilien habe, die für mich faktisch 
dasselbe leisten, dann werde ich mir die stressfreieste aussuchen.
Und das ist leider nicht diejenige, bei der ich zu jedem Baustein 
erstmal zehn Seiten nach Die-Revision gegliederter Errata aufdröseln 
muss um dann festzustellen, dass ich bei Reichelt garnicht weiß, welche 
ich bekomme.

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael_ schrieb:
> Wenn du das beruflich machst, hast du Recht. Da hast du Werkzeuge,
> Mittel und Zeit, die ein Bastler nicht hat. Bezahlen mußt du es auch
> nicht.

Auch als Bastler kann man etwas anderes tun als sich in Assembler und 
Registern zu verwirklichen. Es gibt durchaus Bastler, die wahnsinnig 
beeindruckende Werke schaffen. Die wenigsten werden sich aber in 
unendlichen Diskussionen über einzelne Assemblerbefehle ihrer 
Lieblingsarchitektur aufhalten.

Es geht gar nicht um die Verfügbarkeit von Werkzeugen, sondern um die 
Einstellung zum Hobby. Manche sehen es eben als Selbstverwirklung an, 
wenn sie ihren Controller bis auf jedes Register kennen. Und das ist ja 
auch als Hobby in Ordnung. Es wird nur sehr merkwürdig, wenn sie dann 
anderen erklären möchten, dass jede andere Art, ihr Hobby (oder sogar 
ihren Beruf) auszuüben, als falsch zu betrachten. Dabei geht es anderen 
eben mehr um die Anwendung und die Ergebnisse und nicht um irgendwelche 
tiefgehenden philosophischen Gedanken über eine Prozessorarchitektur.

von Jaxoc (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Antimedial
volle Zustimmung!!
Die Projekte sollten mehr im Vordergrund stehen, als die Werkzeuge.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Eine Antwort, die so wunderbar in einen Thread passt, in dem man gezielt 
über Werkzeuge diskutiert. ;-)

von Wilhelm F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kann sein, daß ich auch mal bei AVR gelandet wäre, wenn ich nicht zuvor 
schon Werkzeuge und Bausteine für PIC und 8051 besessen hätte. Wobei das 
PICkit1 mir mal zufällig über den Weg lief, und ich den PIC und MPLAB 
aber auch lange vorher an der FH kennen lernte.

Denn ich habe auch keine große Lust, alles und jedes, was es am Markt 
gibt, mal eben zu kaufen und einzuarbeiten oder auszuprobieren.

Also spielt bei mir etwas der Zufall mit. Als ich überhaupt in die µC 
einstieg, landete ich genau so zufällig beim 8051, eben weil ich dafür 
im Buchladen ein sehr gutes Buch fand, welches den Standard-8031 
erklärt. Die Wahl der µC-Familie kam eben nicht über die bestimmten 
Leistungsmerkmale eines µC, sondern von dem, der das didaktisch beste 
Buch schrieb, welches mir persönlich am besten gefiel.

Ich spreche aber auch vom Hobby, und möchte bei Bausteinauswahlen gerne 
ziemlich universell bleiben, nicht für jedes Vorhaben einen neuen 
Baustein.

Da hier über PIC gesprochen wird:

Es gibt am Markt sogar noch kleine PIC10Fxxx, und die haben überhaupt 
noch nicht mal einen Stack und gar keinen Interrupt!!! Das ist damit 
aber kein Müll, anscheinend gibt es Leute, die damit aus kommen, und er 
für die Aufgabenstellung reicht. Bei den Speichergrößen bleibt der 
Spaghetticode garantiert auch im Rahmen.

Einen Vergleich "wer hat den längsten dicksten" halte ich deshalb für 
nicht angebracht: Wenn ich diesen mal brauche, kaufe ich ihn halt eben, 
egal von welchem Hersteller. Denn immerhin ist man ja in der Lage, sich 
in neue Dinge einzuarbeiten.

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jaxoc schrieb:
> Die Projekte sollten mehr im Vordergrund stehen, als die Werkzeuge.

Das würde ich gar nicht mal so sagen. Wenn es jemand als sein Hobby 
ansieht, jedes Register auswendig zu kennen, dann ist das ja völlig in 
Ordnung.

A. K. schrieb:
> Eine Antwort, die so wunderbar in einen Thread passt, in dem man gezielt
> über Werkzeuge diskutiert. ;-)

Das ist aber genau der Punkt. Für viele Bastler, die sich um die 
Anwendung kümmern, ist es egal, ob sie nun einen PIC, AVR, STM32 oder 
sonst etwas nehmen. Sie wollen nur ihr Ziel mit möglichst wenig Aufwand 
erreichen. Und dann spielt die Dokumentation (inkl. verfügbarer 
Beispiele), die Toolchain und die Peripherie eine viel größere Rolle als 
die Prozessorarchitektur. Und da kommen wir wieder zum Schluss, dass die 
Integration von WINAVR in das AVR-Studio sowie BASCOM und in jüngster 
Vergangenheit der Arduino-Ansatz wohl entscheidend für die Verbreitung 
von AVR bei Bastlern ist.

Im professionellen Umfeld sieht man einen ähnlichen Trend. Die meisten 
Hersteller bemühen sich inzwischen um die Bereitstellung kostenloser 
Toolchains und umfangreicher Standardbibliotheken, weil dies die 
Einstiegshürden absenkt und Entwicklungszeit verkürzt und damit ein 
gewichtiges Entscheidungskriterium für einen professionellen Entwickler 
ist.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Wilhelm F. schrieb:
> aber kein Müll, anscheinend gibt es Leute, die damit aus kommen, und er
> für die Aufgabenstellung reicht.

Ab und zu postet hier mal jemand die Frage, womit er diese oder jene 
eigentlich simple Aufgabe lösen kann. Die man früher beispielsweise mit 
2 Logik-ICs und einem NE555 gelöst hätte. Wenn du das in grosser Zahl 
brauchst, dann bist du mit solchen Zwergen bedient. Und sparst neben 
Platz auch noch Strom.

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Antimedial schrieb:
> Das ist aber genau der Punkt.

Ihr habt ja an sich Recht. Aber weshalb soll es nicht erlaubt sein, auch 
mal gezielt und feinsinnig über Werkzeuge zu diskutieren, ohne dass 
immer wieder mal jemand reinschmeckt und die Diskussion für unsinnig 
erklärt, weil Werkzeuge doch keine wesentliche Rolle spielten und man 
ohnehin alles mit jedem Hammer erschlagen kriegt, wenn der nur gross 
genug ist. ;-)

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Aber weshalb soll es nicht erlaubt sein, auch
> mal gezielt und feinsinnig über Werkzeuge zu diskutieren, ohne dass
> immer wieder mal jemand reinschmeckt und die Diskussion für unsinnig
> erklärt, weil Werkzeuge doch keine wesentliche Rolle spielten

Klar kann man darüber mal diskutieren, nur muss man eben auch verstehen, 
dass solche Diskussionen für die meisten Bastler wahrscheinlich gar 
keine Relevanz haben.

von Wilhelm F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Wilhelm F. schrieb:
>> aber kein Müll, anscheinend gibt es Leute, die damit aus kommen, und er
>> für die Aufgabenstellung reicht.
>
> Ab und zu postet hier mal jemand die Frage, womit er diese oder jene
> eigentlich simple Aufgabe lösen kann. Die man früher beispielsweise mit
> 2 Logik-ICs und einem NE555 gelöst hätte.

Genau die Diskussionen beobachte ich hier auch immer wieder. Da wird 
aber auch regelmäßig angeführt, daß jemand keinen PC und keine 
Programmierung und keinen Programmieradapter will, und alle 
Einarbeitungen auch nicht.

Nun, ich kann es ein wenig nachvollziehen, es gärte bei mir auch gut 
drei Jahre, mich zu einem PC und Einführung in Mikroprozessoren durch zu 
ringen. Ich sah aber, daß Mikroprozessor in der Elektronik immer 
verbreiteter wurde, und am Ende gewann dann meine Neugier.

Die ersten Versuche, einen 8031 ans Laufen zu bekommen, gelangen mir 
sogar völlig ohne PC noch. Ich bastelte mir die Programmierhardware 
selbst. Sogar bis hin zu einem batteriegepufferten SRAM in der 
Schaltung, um nicht bei einem Fehler bei Eingabe eines Bytes immer ein 
ganzes EPROM zu verwerfen. Es führt aber nicht besonders weit. Irgendwo 
in der Größenordnung Hundert Byte ist man damit fast am Ende. 
Assembliert wurde mit Bleistift auf Papier.

Ich weiß nicht, wie die Gruppe der Bastler heute im Detail aus sieht: 
Sind es immer Leute, die schon eine Elektroniker-Ausbildung haben, worin 
auch Mikroprozessor vor kam? Oder auch mal ein ganz fachfremder 
Nichttechniker, der es sich als neuestes Hobby suchte?

Bei mir war es so, daß ich in der Ausbildung überhaupt gar nichts mit 
Rechentechnik zu tun bekam. Die Relais-Schaltwerke waren Schaltwerke, da 
wurde auch nichts gerechnet. Es gab nach der Ausbildung mal einen 
Weiterbildungslehrgang mit Telex-Übertragungstechnik. Die Teilnehmer 
verdrehten aber auch nur die Augen auf Grund des fremden Zeugs. Noch 
später bekamen einige einen 8085-Lehrgang. Dort stiegen viele mitten 
drin aus, das war denen noch suspekter. Der Handwerker, der beim Kunden 
Anlagen montiert, brauchte es auch gar nicht. Dort wird auch niemand je 
in die Situation kommen, selbst Code zu schreiben. Das war vom Betrieb 
etwas unglücklich gewählt, die Handwerker mit Mikroprozessortechnik zu 
behelligen. So beschäftigte ich mich lange nur mit praktischen Aufbauten 
von z.B. TTL-Gattergräbern. µC war mir völlig suspekt. Auch mußte ich ja 
extra nur fürs Hobby einen PC kaufen, weil man sonst keinen Code 
schreiben und assemblieren konnte, und auch kein EPROM brennen. Der 
normale Haushalt hatte ja zu der Zeit noch gar keinen PC, und Internet 
gabs auch nicht.

> Wenn du das in grosser Zahl
> brauchst, dann bist du mit solchen Zwergen bedient. Und sparst neben
> Platz auch noch Strom.

Der Preis muß attraktiv sein. Mikropower, damit experimentierte ich mit 
dem PIC12F675 mal ein wenig, und werde ihn für ausgesprochene 
Low-Power-Anwendungen mal im Auge behalten. Aber so ein PIC10 ohne Stack 
und Interrupt wird für mich im Hobby nicht in Frage kommen. Da legt man 
bei Einzelstücken die paar Cent besser drauf.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ Antimedial (Gast)

>dass solche Diskussionen für die meisten Bastler wahrscheinlich gar
>keine Relevanz haben.

Nicht ist so relevant und wird so sehr millionenfach durchgekaut wie das 
Irrelevante!

von Michael_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wilhelm F. schrieb:
> Also spielt bei mir etwas der Zufall mit. Als ich überhaupt in die µC
> einstieg, landete ich genau so zufällig beim 8051, eben weil ich dafür
> im Buchladen ein sehr gutes Buch fand, welches den Standard-8031
> erklärt. Die Wahl der µC-Familie kam eben nicht über die bestimmten
> Leistungsmerkmale eines µC, sondern von dem, der das didaktisch beste
> Buch schrieb, welches mir persönlich am besten gefiel.

Deinen letzten Satz kann ich nur zustimmen.
Etwa 1997 wollte ich nach meiner Z80 Zeit wieder etwas mit "modernen" 
Prozessoren machen.
AVR gab es noch nicht und ich hab mir im guten Glauben Das 8051er 
Lehrbuch von Elektor gekauft.
Das war voll der Griff daneben und ich hab da nie wieder ernsthaft daran 
gedacht, etwas selbst mit dieser Familie zu machen.
Sehr praxisfremd aufgeblasen, sicher von einem Berufsschullehrer.
Seitdem steht der Schinken unbenutzt im Regal.
Zum Glück gab es 1999 dann die ersten AVR.
Wilhelm, ich hoffe nicht, das es das Buch war was du so hilfreich 
fandest.

von chris_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vor den AVRs habe ich mich mit vielen anderen Prozessoren beschäftigt. 
Kurz bevor ich einen AVR in die Hand bekam, habe ich mir ein sehr 
einfaches PIC-Board besorgt. Leider war dort kein C-Compiler dabei und 
die 100.ste Assemblervariante wollte ich nicht mehr lernen. Da ich mich 
zu der Zeit auch für Roboter interessierte, habe ich mir einen Asuro 
gekauft:
http://de.wikipedia.org/wiki/ASURO
Der hatte einen Atmega8 und der C-Compiler war dabei, damit war das 
Thema PIC erledigt.
Mittlerweile habe ich auch einige ARM-Derivate, allerdings dürfte ein 
AVR in Punkto Einfachheit und Robustheit der Hardware kaum zu schlagen 
sein:
http://www.roboterclub-freiburg.de/atmega_sound/atmegaSID.html
Vor kurzem Musste ich mich beruflich mit einem MC von Freescale 
herumschlagen. Desen Datenblatt war sage und schreibe 7000 Seiten lang. 
Das ist natürlich eine andere Klasse als die AVRs, nichts desto trotz 
zieht es mich im privaten zu den "übersichtlichen" Kontrollern.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Das ebenso arbeitende Interrupt-Modell des 9900 gehörte zu dessen
> stärksten Seiten. Mit den 16 separaten Interrupts mit jeweils einem
> solchen Kontext unterschied der sich wohltuend vom den anderen
> Mikroprozessoren.

Es war wirklich schade, das der TI99, auf dem ich den 9900 
programmierte, so eine krank konstruierte Kiste war, mit kastriertem 
8-bit RAM und seriellen ROMs(!). Die Büchse hatte ein schönes Gehäuse 
mit guter Tastatur und eben dem interessanten Prozessor. Hätte TI die 
Schüssel doch bloss ein bisschen offener konstruiert, dann hätte man 
sich da richtig austoben können.
Für die jüngeren:
https://de.wikipedia.org/wiki/Texas_Instruments_TI-99/4A

von Antimedial (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wilhelm F. schrieb:
> µC war mir völlig suspekt.

Ich hatte mal einen Kollegen, der inzwischen fast 70 und in Rente ist. 
Der ist bis zum Ende voll am Ball geblieben und hat sich immer wieder 
mit der neuesten Technologie beschäftigt. Kürzlich habe ich ihn wieder 
getroffen und er hat mir ganz stolz erzählt, dass er sich kürzlich mit 
dem STM32 beschäftigt hat und fleißig damit programmiert und total 
begeistert von den Möglichkeiten neuer µCs ist. Ich habe ihm dann noch 
ein paar Kniffe beim Debuggen beigebracht - welche er mit einem Leuchten 
in den Augen gleich genutzt hat. Und er ärgert sich fast darüber, dass 
es zu seinen aktiven Zeiten noch nicht diese Möglichkeiten gab.

Das ist eben noch ein echter Vollblut-Ingenieur.

von F. F. (foldi)


Bewertung
0 lesenswert
nicht lesenswert
Matthias Sch. schrieb:

> Für die jüngeren:
> https://de.wikipedia.org/wiki/Texas_Instruments_TI-99/4A

Wie? Das war doch erst gestern!;-)

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]
  • [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.