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

Als compiler emfehle ich den kostenlosen gcc-avr bzw. WinAVR.
Codeoptimierung ist mit drin.

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

>ich möchte gerne von PIC auf AVR umsteigen

Warum?

>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=p1...

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.

>Bekommt man das denn schon? Und wenn ja: wo?
http://shop.avr-praxis.de/avr-boards/stk600.html

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) ;-)