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…
@ 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.
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.
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.
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.
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.
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...
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
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
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.
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.
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…
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.
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.
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.
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.
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
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?
@ wuji naja man kann auch mit kanonen auf psatzen ballern. warum nicht?
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.
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.
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... ^^
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..
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.
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.
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.
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.
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
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.
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 ;)
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).
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?
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
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
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.
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.
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.
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
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ß.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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...).
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.
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. ;))
fujii schrieb: > blöd nur, dass so eine Cortex-Kanone 10 Mal schneller schießt als das > Luftgewehr. ;)) Aber nicht beim ersten Schuß.
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 :-)
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...
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.
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.
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.
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.
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.
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 ;-)
> Gammliges Luftgewehr aus den 60ern: Abknicken, 4,5mm Rundkugel rein, > zuklappen, anlegen, bumm, Spatz hin. Spatzenhasser!!
> Beim STM32 reicht dir mir SWD aber auch SWDIO, SWCLK, GND und 3V3
3v3 brauchste nicht. Das heist man braucht nur 3 Leitungen.
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.
> 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. ^^
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
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.
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.
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.
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?
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...
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.
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
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. ;-)
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
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.
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. :)
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
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.
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.
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?
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.
> 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
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
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.
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
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.
> > 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.
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.
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.
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).
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.
Michael_ schrieb: > Wenn ich mir schon die > Typenvielfalt ansehe, kommt mir das Grausen. ??? Du bist damit überfordert?
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 :-) .
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
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
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
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
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. ;-)
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.
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.
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.
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
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).
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.
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
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
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.
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.
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.
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.
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
>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.
Ic galube es nicht schrieb: > Dafür hast du bestimmt das große Firmenverdienstkreuz am Bande bekommen. Und den ST Kaffeebecher. ;-)))
Nein - Dafür habe ich einen Prozessor bekommen, den ich auch privat sehr gerne progge und somit mach mir der Job mehr Spaß.
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!
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.
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.
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.
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.
<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.
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
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.
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 ;-)
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.
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.
>Antimedial
volle Zustimmung!!
Die Projekte sollten mehr im Vordergrund stehen, als die Werkzeuge.
Eine Antwort, die so wunderbar in einen Thread passt, in dem man gezielt über Werkzeuge diskutiert. ;-)
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.
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.
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
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. ;-)
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.
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.
@ 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!
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.
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.
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
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.
Matthias Sch. schrieb: > Für die jüngeren: > https://de.wikipedia.org/wiki/Texas_Instruments_TI-99/4A Wie? Das war doch erst gestern!;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.