Hi, ich möchte gerne von PIC auf AVR umsteigen und habe vorher ein paar Fragen. Zu AVR-Studio: Ist AVR-Studio vom Funktionsumfang (Debugger, Register-Fenster, also all das, was man für die effiziente Fehlersuche so benötigt) mit MPLAB IDE vergleichbar? Ist der kostenlose C-Compiler bei AVR effizient? Bei Microchip bekommt man die Code-Optimierung im ansonsten kostenlosen Compiler nur gegen Bezahlung. Zum Evaluierungsboard: Als Entwicklungsumgebung wird ja oft das STK500 genannt. Bei Reichelt steht, dass es für 8-, 20- und 40-polige AVR Flash Microcontroller im DIL-Gehäuse geeignet ist. Ich hatte für den Anfang an einen ATMEGA 88-20 PU gedacht. Allerdings hat der ein DIL28-Gehäuse. Kann man mit dem STK500 keine ATMEGA88-µCs programmieren? Funktioniert das Board mit USB-Seriell-Adaptern(Prolific-Chipsatz)? Ist mit dem STK500 ein In-Circuit-Debugging möglich? Also z.B. einen Breakpoint setzen und dann während der Laufzeit die Register auslesen? Ich habe hier im Forum gelesen, dass die LEDs auf dem Board wohl angehen, wenn man den Port-Pin auf 0 setzt. Kann man das mit einem Board-Jumper invertieren? Für mich ist 0=aus und 1=an und das sollte eigentlich auch so bleiben... :) Zum ATMEGA88: Ehrlich gesagt bin ich erstaunt, wie viel Leistung man bei ATMEL für so wenig Geld bekommt (8K Flash, 1K RAM, 20 Mhz...nicht schlecht Herr Specht!). Wo ist denn da der Haken? Wie schnell kann eigentlich der interne Oszillator maximal arbeiten? Beim PIC gab es früher immer Probleme mit den Speicherbänken. Kann man den Speicher des ATMEGA in Assembler problemlos adressieren? Kann man ungefähr absehen, wie lange es diesen oder vergleichbare µC in DIP noch geben wird? Ich erwarte jetzt keine hellseherischen Qualitäten, aber auf ein Auslaufprodukt, welches inoffiziell schon abgekündigt ist, wollte ich jetzt nicht umsteigen und vielleicht gibt es da ja so etwas wie Erfahrungswerte. Vielen Dank, Heimo.
Nein AVRStudio ist micht mit MPLab vergleichbar. In der Basiskonfiguration ja. Aber MPLab erlaubt fremde Compiler unter MPLab lauften zu lassen. Der AVRSimulator faellt auch etwas gegenueber dem PIC Simulator ab. MPLab kann zB im Simulator dem PIC einen seriellen Datenstrom im richtigen Timing zufuehren. Ab Datenfile.
Moin, ich arbeite seit kurzem auch in beiden Welten, hier mein Eindruck: MPLAB und AVRStudio haben viele Parallelen in den Grundfunktionen, einige Tastenshortcuts liegen anders. Der GCC-Compiler für C ist kostenlos und eigentlich Leistungsstark. IAR macht z.B. auch einen käuflichen aber n Vergleich kann ich nicht anbieten. Mit dem Simulator bin ich zufrieden, vor allem wegen den asychronen Events bei MPLAB, also Tastendrücke, statt das ewig einzubinden und dann zu klicken, machst du einfach ein Häkchen in ein Register. Leider fehlt ein Logic-Analyser, geplante Events von aussen gehen, aber nur per kompliziertem Textfile. Zum AVR selbst: der interne Oszillator geht bis 8Mhz, Avrs haben aber keine interne Teilung (bei PICs ja Tosc/4=Tcyc), die meisten Befehle laufen in ein oder zwei Takten ab. Die über 100 Assemblerbefehle machen das Proggen in ASM recht bequem, im Gegensatz zu PICs. AVRs haben keine Bänke, die man umschalten muss, sondern Adressieren direkt, man braucht sich also kaum Gedanken machen. 3 Pointer sind vorhanden und können auf den Flash oder auf den SRAM zeigen, bei PICs der 16er Reihe ging das ja nur auf den RAM. Der Atmega88 ist soweit ich weiß der Nachfolger des Atmega8 und noch garnicht so alt. Er hat einige Vorteile bei den Interruptquellen und Hardwareschnittstellen. Von Abkündigungen hab ich noch nichts gehört, und mit dem Mega88 solltest du damit auch länger verschont bleiben. Ähnlich wie bei den PICs sind aber fast alle Atmegas mehr oder minder kompatibel. MfG The_Ghost666
P.S.: Den einzigen Nachteil, den ich in AVRs sehe, sind die Fuse-Bits. Sie arbeiten wie das Config-Word bei den PICs, aber sollte man einen falschen Oszillator angeben (z.B. extern aber keiner ist angeschlossen), so kann man den AVR ohne passende Taktquelle nicht nochmal brennen. Bei den PICs ist das ja ohne Probleme möglich. Deswegen die Fuse-Bits vorher prüfen und wissen, was sie bedeuten. Sonst muss man mit nem Funktionsgenerator oder so ran, was bei DIPs nicht das Problem ist. Aber wenn dir das bei nem SMD-Package passiert, haben wir die eher ausgelötet und neu bestückt, als sie zu reanimieren.
Es gibt auch wesentliche Hardware Unterschiede zwischen den PIC und den AVR. Der ADC des PIC ist viel schneller. Die Konfiguration des Prozessors ist beim PIC Teil des ASM, beim AVR ist die Konfiguration ausserhalb
OCD mit dem STK500 geht nicht, dann bracuhste den ICE, kost aber viel teuer. Du kannst mit dem STK500 alle 8-Bit AVRs flashen, die QFP-Typen aber nicht auf dem Board selbst, da auf dem nur Sockel für die DIL-Typen drauf sind. Diese kannste aber darauf auch HV-Flashen. Die SMD-Typen werden halt über ISP geflasht vom STK500 aus.
ich würde dir statt dem STK500 (TEUER!) das Pollin AVR Eval Board empfehlen, und vom dem gesparten Geld vielleicht noch einen Dragon für In-Circuit-Emulieren kaufen... Aber der Dragon ist nicht Pflicht. Beim AVR kann man auch ohne viele Euros loslegen... PS: Am billigsten ist nat. Lochrasterplatine und Parallel-Port-Programmer... Damit kann man für max. 10 Euro loslegen....
Habe auch einen Prgrammer für den Parallelport. Aber mal so anregung: Was ist mit dem USB-Prog? Der kann doch auch JTAG, also On-Chip-Debugging. Mit 35 Euro (?) ist er jedenfalls auch noch billiger als STK500. Sebastian
Heimi wrote: > Ich habe hier im Forum gelesen, dass die LEDs auf dem Board wohl > angehen, wenn man den Port-Pin auf 0 setzt. Kann man das mit einem > Board-Jumper invertieren? Für mich ist 0=aus und 1=an und das sollte > eigentlich auch so bleiben... :) Man zieht mit AVR's (ich glaube allgemein mit MCU's) besser, als dass man treibt.. insofern, gehen die LED's eben an, wenn man den Pin auf LOW legt.. Wenn man das im Hinterkopf hat ist's nur noch ne Frage der Zeit, bis einen das nicht mehr wundert ;)
Hi, vielen Dank für die Erklärungen soweit... bei Pollin habe ich ein "Funk-AVR-Evaluations-Board" gefunden...ist das gemeint gewesen? Kann man das Board denn mit AVRStudio nutzen oder ist da Dritthersteller-Software notwendig? Es geht mir in erster Linie um ein relativ einfaches Handling. Am liebsten hätte ich ein Entwicklungsboard, welches ich mit AVRStudio sowohl In-Circuit programmieren als auch In-Circuit debuggen kann und zwar am besten ohne für jede Idee etliche Male irgendwelche ICs oder Stecker umstecken zu müssen. Per Forumssuche habe ich noch den Hinweis auf das AVR Start Up Bundle (AT90JTAGICE-MK2 + STK500) gefunden. Das gäbe es vermutlich ab 150 Euro inklusive Mehrwertsteuer und Versand. Könnte ich das STK500 benutzen, um den ATMEGA88 zu programmieren und parallel den MK2 per Kabel sowohl mit dem PC als auch mit dem STK500 verbinden, um direkt nach der Programmierung das Programm noch im Entwicklungsboard zu testen und ggf. zu debuggen? Oder gibt es eine vom Preis her ähnliche Alternative, um den MEGA88 und eventuell andere 8-Bitter komfortabel auf einem Entwicklungs-Board quasi In-Circuit programmieren, testen und debuggen zu können?
Ja, das Funk-Board von Pollin ist das Richtige. Gab es auch mal ohne Funk, ist aber inzwischen wohl wieder ausverkauft (evtl. mal telefonisch nachfragen). Einziger Nachteil des Boards: es arbeitet nicht mit WinAVR zusammen (bei mir jedenfalls nicht - hat da jemand andere Erfahrungen?). Ich benutze zum Übertragen meiner Programme PonyProg.
>Wie schnell kann eigentlich der interne Oszillator maximal arbeiten? Intern kann man den zu 8 MHz konfgurieren. >Beim PIC gab es früher immer Probleme mit den Speicherbänken. Kann >man den Speicher des ATMEGA in Assembler problemlos adressieren? von solchen Problemen hab ich bei AVR noch nicht gehört. >Kann man ungefähr absehen, wie lange es diesen oder vergleichbare >µC in DIP noch geben wird? Ich erwarte jetzt keine hellseherischen >Qualitäten, aber auf ein Auslaufprodukt, welches inoffiziell schon >abgekündigt ist, wollte ich jetzt nicht umsteigen und vielleicht >gibt es da ja so etwas wie Erfahrungswerte. Ich glaub, da braucht Du dir erstmal noch keine Sorgen machen. ATMEL hat sogar einen neuen Boliden (ATMega1284) auch im DIL- Gehäuse angekündigt. Wenn Atmel was abkündigt, dann gibt es eigentlich immer einen kompatiblen Nachfolger. z.B Dein Mega88 wird irgendwann den Mega8 ablösen. Beide gibt es aber schon eine Weile parallel. Also ich meine, dass Du deinen Umstieg nicht bereuen wirst. Holger
>Funktioniert das Board mit USB-Seriell-Adaptern(Prolific-Chipsatz)?
STK500 ja,
Pollin-Board nein.
Heimi wrote: > Ist AVR-Studio vom Funktionsumfang (Debugger, Register-Fenster, also > all das, was man für die effiziente Fehlersuche so benötigt) mit MPLAB > IDE vergleichbar? Kenne die MPLAB-IDE leider net... Debugger bzw. Simulator hast du aber im AVR-Studio auch (der gdb-Debugger gehört zum gcc-Compiler). > Ist der kostenlose C-Compiler bei AVR effizient? Bei Microchip bekommt > man die Code-Optimierung im ansonsten kostenlosen Compiler nur gegen > Bezahlung. Der dürfte relativ effizient sein, da er eigentlich schon steinalt ist; avr-gcc ist nur ein weiteres Modul für den gcc, und mit dem wird bisweilen das ganze Linux-System übersetzt. > Als Entwicklungsumgebung wird ja oft das STK500 genannt. Bei Reichelt > steht, dass es für 8-, 20- und 40-polige AVR Flash Microcontroller im > DIL-Gehäuse geeignet ist. Ich hatte für den Anfang an einen > ATMEGA 88-20 PU gedacht. Allerdings hat der ein DIL28-Gehäuse. Kann > man mit dem STK500 keine ATMEGA88-µCs programmieren? S.o. > Funktioniert das Board mit USB-Seriell-Adaptern(Prolific-Chipsatz)? S.o. > Ist mit dem STK500 ein In-Circuit-Debugging möglich? Also z.B. einen > Breakpoint setzen und dann während der Laufzeit die Register auslesen? Das mit dem In-Circuit-Debugging ist beim AVR so ne Sache... die Breakpoints kommen als Assembler-Instruktion daher. Beim Debugging wird der AVR dementsprechend häufig neugeflasht, um die Breakpoints zu setzen und zu löschen, was der Lebensdauer natürlich nicht gerade zugute kommt. Lieber In-Circuit-Emulator benutzen. > Ich habe hier im Forum gelesen, dass die LEDs auf dem Board wohl > angehen, wenn man den Port-Pin auf 0 setzt. Kann man das mit einem > Board-Jumper invertieren? Für mich ist 0=aus und 1=an und das sollte > eigentlich auch so bleiben... :) Nö, das ist schon richtig so und damit musst du halt klarkommen. Erklärung unten. > Ehrlich gesagt bin ich erstaunt, wie viel Leistung man bei ATMEL für > so wenig Geld bekommt (8K Flash, 1K RAM, 20 Mhz...nicht schlecht Herr > Specht!). Wo ist denn da der Haken? > Wie schnell kann eigentlich der interne Oszillator maximal arbeiten? Gibt meines Wissens nach drei interen Oszis, jeweils für 1, 4 und 8 MHz. Sind aber logischerweise recht ungenau (UART!). > Beim PIC gab es früher immer Probleme mit den Speicherbänken. Kann > man den Speicher des ATMEGA in Assembler problemlos adressieren? AVR hat keine Speicherbänke. Zumindest die kleinen net. Wenns dann doch zu groß wird, wirste in irgendeinem Register noch ein zusätzliches Adressbit finden. > Kann man ungefähr absehen, wie lange es diesen oder vergleichbare > µC in DIP noch geben wird? Ich erwarte jetzt keine hellseherischen > Qualitäten, aber auf ein Auslaufprodukt, welches inoffiziell schon > abgekündigt ist, wollte ich jetzt nicht umsteigen und vielleicht > gibt es da ja so etwas wie Erfahrungswerte. Du bist halt abhängig von Atmel. Es sei denn, die gehen pleite und legen die Kopierrechte gleichzeitig ab... selbiges gilt aber auch für PIC; wenn Microchip nimmer will, stehstu genauso aufm Schlauch. Joan P. (joan) sagt: >Man zieht mit AVR's (ich glaube allgemein mit MCU's) besser, als dass >man treibt.. insofern, gehen die LED's eben an, wenn man den Pin auf LOW >legt.. Das ist aber auch asbach. Früher war das richtig so... da waren die Ports von Controllern häufig Open-Collector (--> 0 steuert durch und zieht nach Masse, 1 sperrt und wird per Pull-up nach Vcc gezogen; gleichzeitig war 1 dann auch für "Eingang" gedacht, damit erklärt sich auch, warum Taster gerne gegen Masse geschaltet werden.) Die AVRs sind da ganz locker und können pro Pin sowohl 40mA treiben als auch 40mA versenken. Der ganze Chip sollte aber nicht mehr als 300mA versenken.
Jupp wrote: >>ich möchte gerne von PIC auf AVR umsteigen > > Warum? Frag ich mich auch. Man könnte ja auch mal auf die 18F, 24F oder ds30 schauen, statt gleich die ganze Familie zu wechseln... Ist bestimmt nicht so aufwendig.
Hi, > Warum? 1. Das Preis-Leistungsverhältnis scheint mir bei Atmel im unteren Preissegment einfach besser zu sein. Für 1,70 bekommst Du bei Reichelt wie gesagt quasi 20 MIPs, 8 KB Flash und 1KB RAM. 2. Die umfangreiche Assembler-Befehlsreferenz vom ATMEGA88 fand ich auf den ersten Blick recht beeindruckend, zumindest wenn ich sie mit der eher spartanischen Befehlsreferenz von PICs mit einem ähnlichen Preis vergleiche. 3. Die Community: Hier im Forum ist Atmel nun mal der Platzhirsch, es gibt zwar andere Foren für PICs aber mir ist zumindest kein deutschsprachiges Forum bekannt, in dem man so schnell wie hier eine Lösung für ATMEL-Probleme aller Art genannt bekommt. 4. Ich wollte die PICs nicht vollständig vergessen, aber es ist wohl nicht verkehrt, wenn ich sowohl mit PICs als auch mit AVRs umgehen kann... 5. Dann die Entwicklungsumgebung. Kann mir jemand ein gutes und zu einem vernünftigen Preis verfügbares PIC-Board oder von mir aus auch eine Kombination von Evaluierungs- und ICD-Board nennen, welches meine Anforderungen erfüllt (InCircuit-Programming, InCircuit-Debuggung, Evaluieren mit vielen Tastern, LEDs und ähnlichem, alles in der Hersteller-Software integriert mit Assembler sowie C-Programmierung und ohne groß Kabel oder Käfer umstecken zu müssen)? Zugegeben, bei Atmel weiß ich bis jetzt auch noch nicht, ob es mit einem STK500+Dragon so einfach funktioniert, wie ich es gern hätte. Da hoffe ich ja noch auf eine Antwort von jemandem, der dazu etwas sagen kann. Aber nachdem ich lange Zeit mit einem selbst gebauten Brenner5 herumgehampelt habe, möchte ich jetzt mal Nägel mit Köpfen machen und mir eine vernünftige Entwicklungsumgebung gönnen. Auch da scheint Atmel vom Preis her auf den ersten Blick die Nase vorne zu haben, sofern ich mit einem STK500+Dragon mein Ziel erreiche... Aber ich bin Vorschlägen gegenüber immer offen. Wenn ihr einen Geheimtipp für PICs habt (möglichst 18er und 16er Reihe), dann immer her damit. >Das mit dem In-Circuit-Debugging ist beim AVR so ne Sache... die >Breakpoints kommen als Assembler-Instruktion daher. Beim Debugging wird >der AVR dementsprechend häufig neugeflasht, um die Breakpoints zu setzen >und zu löschen, was der Lebensdauer natürlich nicht gerade zugute kommt. >Lieber In-Circuit-Emulator benutzen. Ist das denn bei der Anzahl von Schreib-Zyklen im Flash noch von Bedeutung? Wenn ich das richtig gesehen habe, kann man den ATMEGA88 doch gute 10000 mal flashen, bevor er unzuverlässig wird. Hast Du es tatsächlich schon mal geschafft, einen ATMEGA durch ICD unbrauchbar zu machen? Ich nehme ja nicht einen µC für alle Projekte. Spätestens wenn das Projekt beendet wurde, nehme ich einfach den nächsten aus der Sortiment-Box...der benutzte µC läuft dann ja auch meist dauerhaft im Prototypen. :)
Hallo, ich habe vor kurzem mit der PIC32 Familie angefangen, die hat einen MIPS Core drin. Um das Ding auf den Markt zu kriegen gibts fast alles umsonst oder sehr billig. Auch den C32 kann man sich besorgen, zumindest in der Eval Version. Der PIC32 ist völlig neu designed und ebenso leistungsstark wie ein ARM7. Und noch ein Vorteil: Ich bestelle seit einem Jahr jeden Monat 12 Samples im Wert von je 50-60€ VK bei MC über die Homepage, kostenlos und die haben noch nie gefragt was ich damit mache. So eine Quelle müssen andere erstmal bieten :-) Im Übrigen würde ich so interessante Familien wie Cypress oder die 51er Weiterentwicklungen nicht links liegen lassen. Cypress bietet extrem hochwertige uC an mit konfigurierbarer Peripherie. Auch der Propeller ist ein Universalbaustein an den man alles anschliessen kann, Tastatur, Bildschirm, Maus usw.
PS: Ideale PICs sind 16F88 (vollgepackt mit Peripherie und nur 14 Pins), der ideale Zwerg für alles, 18F2685, 18F4685. Und die 10F.. gibts auch noch im SOT23 Gehäuse mit 6 Pins. Ja, die können wirklich rechnen, nur mit dem Debuggen wirds schwierig :-)
Heimi wrote: > 3. Die Community: Hier im Forum ist Atmel nun mal der Platzhirsch, > es gibt zwar andere Foren für PICs aber mir ist zumindest kein > deutschsprachiges Forum bekannt, in dem man so schnell wie hier > eine Lösung für ATMEL-Probleme aller Art genannt bekommt. Das ist mir auch schon aufgefallen. Hier und bei AVRFreaks ist recht hohe und kompetente Aktivität. Für den PIC ist mir nichts vergleichbar gut besuchtes bekannt. So ein Support ist pures Geld wert. Der AVR-GCC wird auch sehr gut supportet. Dagegen sehe ich das Schmarotzen von 60€ von Microchip nicht als haltberes Argument. Warscheinlich vertickt derjenige die Evalsamples dann umgehend bei Ebay. Peter
>Als Entwicklungsumgebung wird ja oft das STK500 genannt. Bei Reichelt >steht, dass es für 8-, 20- und 40-polige AVR Flash Microcontroller im >DIL-Gehäuse geeignet ist. Ich hatte für den Anfang an einen >ATMEGA 88-20 PU gedacht. Allerdings hat der ein DIL28-Gehäuse. Kann >man mit dem STK500 keine ATMEGA88-µCs programmieren? Nun, das STK500 hat auch 28pol. Fassungen. Mega8 und Mega88 kann man darin programmieren.
Christian J. wrote: > Und noch ein Vorteil: Ich bestelle seit einem Jahr jeden Monat 12 > Samples im Wert von je 50-60€ VK bei MC über die Homepage, kostenlos und > die haben noch nie gefragt was ich damit mache. So eine Quelle müssen > andere erstmal bieten :-) > Na dann hoffe ich das sie dir wegen dem Missbrauch des sampel Programms mal ne fette Rechnung stellen.
Also wer sich jetzt ein STK zulegen möchte, dem würde ich raten eher direkt auf ein STK600 zu gehen. Das neue Konzept dürfte in jedem Fall flexibler sein. Oder hat jemand schlechte Erfahrungen mit den Teilen gemacht?
Christian J. wrote: > Und noch ein Vorteil: Ich bestelle seit einem Jahr jeden Monat 12 > Samples im Wert von je 50-60€ VK bei MC über die Homepage, kostenlos und > die haben noch nie gefragt was ich damit mache. So eine Quelle müssen > andere erstmal bieten :-) <flame-an> Na danke, noch so ein Idiot, der dafür sorgt, dass es irgendwann gar keine Samples mehr an Privatleute gibt -- haste toll gemacht, weiter so. <flame-aus>
Tach ! Dass in diesem Forum diverse anonyme Spinner unterwegs sind ist ja schon bekannt, die meinen für Bastler bleibe nichts übrig. Manche glauben wirklich, dass ein Konzern wie Microchip es einen Pups interessiert, wer ihre Samples bestellt solange die ihr Zeug unters Volk bringen. Solange die an meine Adresse liefern bestelle ich die, deren Sache das irgendwann abzudrehen oder beizubehalten, bisher tun sie es seit 1,5 Jahren. Mit etwas Geschick kann man sich fast alles umsonst bestellen, sogar die ARM7 Prozessoren, direkt ab Hersteller Philips in Böblingen. Ach ja: Den Tip habe ich übrigens von einem FAE von denen, ganz offiziell: Wer PICs haben will soll sich die über das Sample Programm bestellen, dort werden Kleinmengen kostenlos abgegeben. Eine gute Strategie der Konkurrenz das Wasser abzugraben, denn wenn nur ein Bastler mal später in einer Firma die Dinger einführt haben sie ihr Geld schon wieder drin. Punkt. Christian
>Also wer sich jetzt ein STK zulegen möchte, dem würde ich raten eher >direkt auf ein STK600 zu gehen. Naja, das kostet ja schon einiges mehr als das STK500...für mich wäre eventuell erstmal auch das STK500 ausreichend. Ich hoffe ja immer noch, dass mir jemand meine wichtigste Frage beantowrten kann, nämlich ob man nun mit dem STK500 und einem gleichzeitig clever am STK500 angeschlossenen Dragon per AVR Studio vom PC aus das STK500 per RS232 programmieren als auch über den Dragon den µC auf dem STK500 In-Circuit-Debuggen kann, während quasi alles noch unverändert am PC angeschlossen ist? Ich kann mir gar nicht vorstellen, dass das noch niemand versucht hat?!? Oder mache ich irgendwo einen Denkfehler und das kann so gar nicht klappen? Das wäre für mich jedenfalls der ultimative Komfort beim Entwickeln von Projekten. Wenn ich für nur 150 Euro diesen Komfort bekommen könnte und quasi für meine Projekte nur noch den µC wechseln sowie die jeweils benötigte Peripherie am STK500 anschließen müsste, würde ich sofort zuschlagen.
Matthias wrote: > Also wer sich jetzt ein STK zulegen möchte, dem würde ich raten eher > direkt auf ein STK600 zu gehen. Das neue Konzept dürfte in jedem Fall > flexibler sein. Oder hat jemand schlechte Erfahrungen mit den Teilen > gemacht? Bekommt man das denn schon? Und wenn ja: wo? Nachtrag: Ich hab grad gesehen dass Segor es fuer 285EUR anbietet. Nochmal 100 werden fuer die Adapterplatinen faellig. Nich schlecht... also fast 400EUR. Das duerfte meine Plaene, es zu kaufen, wohl noch verzoegern. Oder gibt es das iwo guenstiger?
Ja, bekommt man schon http://watterott.net/shop/product_info.php?info=p132_ATSTK600.html Lieferzeit: ca. 1 Woche
Ma wieder typisch Segor, gleich 100EUR mehr zu verlangen. Danke fuer den Hinweis. Hmm... die Adapter hab ich nich gefunden in dem shop.
Die muss ich erst bei meinem Distri anfragen, dann werden sie in den Shop aufgenommen.
OK dann halt ich mal meine Augen offen. Wuerde es wenn dann komplett bestellen wollen.
Heimi wrote: > Ich hoffe ja immer noch, dass mir jemand meine wichtigste Frage > beantowrten kann, nämlich ob man nun mit dem STK500 und einem > gleichzeitig clever am STK500 angeschlossenen Dragon per AVR > Studio vom PC aus das STK500 per RS232 programmieren als auch > über den Dragon den µC auf dem STK500 In-Circuit-Debuggen kann, > während quasi alles noch unverändert am PC angeschlossen ist? > > Ich kann mir gar nicht vorstellen, dass das noch niemand versucht > hat?!? Oder mache ich irgendwo einen Denkfehler und das kann so > gar nicht klappen? Das wäre für mich jedenfalls der ultimative > Komfort beim Entwickeln von Projekten. > > Wenn ich für nur 150 Euro diesen Komfort bekommen könnte und > quasi für meine Projekte nur noch den µC wechseln sowie die > jeweils benötigte Peripherie am STK500 anschließen müsste, > würde ich sofort zuschlagen. Wenn du den Dragon hast, brauchst du das STK500 eigentlich nicht unbedingt. Beim ICD ist der Chip ja bereits eingebaut, folglich brauchst du nur noch eine JTAG-Verbindung von der Zielhardware zum Dragon und kannst den Controller programmieren und debuggen (Wenn er nicht mehr als 32kiB Flash hat). Es ist aber natürlich auch möglich, den Dragon mit dem STK500 zu verbinden und die dort aufgesteckten Controller per JTAG zu programmieren/debuggen. Meines Wissens lässt sich der Dragon ja auch noch mit IC-Sockeln bestücken, damit man den Chip auch gleich dort aufstecken kann. Geht aber natürlich nur für die DIL-Varianten.
Holger Krull wrote: >>Bekommt man das denn schon? Und wenn ja: wo? > http://shop.avr-praxis.de/avr-boards/stk600.html Was da an kosten fuer die Adapter noch zukommt wenn man bissel flexibel sein will... hammer ;) Aber naja jetzt weiss ich ja bescheid, thx.
Habe mich gerade auch ein wenig bei meinen Distris umgeschaut, so ein Adapter kostet knap 100 Euro. Bei einigen Typen besteht er aber aus mehreren Platinen um die unterschiedlichen Controller zu adaptieren.
Heimi wrote: > Ich hoffe ja immer noch, dass mir jemand meine wichtigste Frage > beantowrten kann, nämlich ob man nun mit dem STK500 und einem > gleichzeitig clever am STK500 angeschlossenen Dragon per AVR > Studio vom PC aus das STK500 per RS232 programmieren als auch STK500 programmieren = Oszillator einstellen, und Spannungen? -> Kein Problem! > über den Dragon den µC auf dem STK500 In-Circuit-Debuggen kann, > während quasi alles noch unverändert am PC angeschlossen ist? uC auf den Zielhardware Steckplätzen programmieren, debuggen? -> Auch kein Thema, ABER -> Resetjumper auf dem STK500 abziehen! Und bitte nicht versuchen ISP und JTAG gleichzeitig zu machen ;-) Beides gleichzeitig -> Sollte auch keine Probleme machen > Ich kann mir gar nicht vorstellen, dass das noch niemand versucht > hat?!? Oder mache ich irgendwo einen Denkfehler und das kann so > gar nicht klappen? Das wäre für mich jedenfalls der ultimative > Komfort beim Entwickeln von Projekten. Warum sollte das nicht gehen? > Wenn ich für nur 150 Euro diesen Komfort bekommen könnte und > quasi für meine Projekte nur noch den µC wechseln sowie die > jeweils benötigte Peripherie am STK500 anschließen müsste, > würde ich sofort zuschlagen. Naja, wenn Du nur Controller kleiner 32k Flash benutzt, dann reicht der Dragon. Aber prinzipiell empfehle ich für einen kommerziellen Einsatz den JTAG-ICE-MK2. Der kann auch für die AVR32 benutzt werden. Alternativ für die älteren ATMEGAS die noch vom alten JTAG-ICE unterstützt werden, gibt es das EVERTOOL Projekt (Nachbau).
Beides gleichzeitig -> Sollte auch keine Probleme machen STK500 über RS232 und Dragon über USB (nicht JTAG und ISP) ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.