avr starterkit

AVRISP kann halt kein JTAG, HV Programming zum normalen Programmieren 
mittels USB ist es aber sehr gut geeignet.

Eine alternative wäre der AVR Dragon, der kann oben genannte Dinge aber 
irgendeinen Programmiermodus für die ganz kleinen Tinys nicht.

Man bräuchte noch ein Gehäuse zum transportieren und einen 
Nullkraftsockel zum Einlöten dann kann man die µCs sehr leicht ein- und 
auslegen.

Das AvrISPmkII ist ein reines Programmiergerät, ist also nur zu Flashen 
des Controllers geeignet. Für eine Kommunikation mit dem PC geht kein 
Weg an RS232 vorbei. Jedenfalls nicht ohne Klimmzüge.

Wenn es aber "echtes" RS232 ist funktionieren die USB/RS232 Konverter 
ohne zu murren. Auch mit dem STK500. Problematisch sind 
Programmiergeräte wie sie auf dem Pollin Board drauf sind (Ponyprog). 
Die sprechen kein RS232, sondern versuchen das ISP Protokoll der AVRs 
direkt nachzubilden. Mit einem Konverter ist das bestenfalls nur 
langsam. Programmiergeräte wie sie auf dem STK500 verbaut sind haben 
einen eigenen Controller die die Flash-Daten per RS232 häppchenweise 
entgegennehmen und das ISP Protokoll selbst abwickeln.

Also: Das AvrISPmkII kann man dazu verwenden um ohne RS232 Programme auf 
das STK500 zu übertragen. Evalboard und Programmiergerät auf dem STK500 
(zwei Teile auf einer Platine) sind mit einem Flachbandkabel verbunden. 
Das muß man nur abziehen und stattdessen den AVRisp einstöpseln. 
Datenübertragung vom STK500 zum PC geht damit aber nicht.

Mit JTAG/debugWire kann man Programme übertragen und diese dann u. a. in 
Einzelschritten ausführen lassen. Das geht aber weder mit dem STK500 
Programmierteil noch mit dem AVRisp. AVRDragon und JTAGICEmkII können 
das.

Bislang hatte ich nur mit 'intelligenten' Programmern zu tun wie das 
STK500 oder AVR-Prog (AVR910), die ich bisher ausschließlich an einem 
Konverter betrieben habe. Das STK500 habe ich allerdings nicht mehr.
Desweiteren hantiere ich laufend mit FT232 bzw. CP2102 basierten 
USB->UART Konvertern für Trace Ausgaben und zum Programmieren von 
LPC11xx/13xx/17xx/23xx/24xx und STM32. Kein PC mit dem ich zu tun habe 
hat noch eine RS232 Schnittstelle.
Probleme mit Konvertern habe ich nur an einem PC: Wenn der aus dem 
Sleepmode hochkommt, startet der Konverter nicht den ich dort für die 
LPCs benutze. Den muß ich dann einmal abziehen und gleich wieder 
einstecken.
Bei einem normalen Start geht es. Allerdings betreibe ich den an einem 
USB Hub. Vielleicht liegt es daran. Maus und Tastatur sind direkt am PC 
eingesteckt.

Als unzuverlässig würde ich externe Festplatten mit USB Anschluss 
bezeichnen. Das geht stundenweise gut, im Dauerbetrieb verlieren die 
(ich habe drei) gerne mal die Verbindung.

Benni schrieb:
> mein notebook hat übrigens auch n expresscard slot..

dann kauft ein RS232 expresscard wie z.B.
http://cgi.ebay.de/LogiLink-ExpressCard-1x-Seriell-Express-Card-RS232-/220620231470?pt=PCMCIA_Cards&hash=item335dfd932e 
und gut ist!
Damit kanns du dein STK500 über RS232 flashen.

Ich habe ein Laptop mit eine PCMCIA und eine RS232 PCMCIA Card es 
funktioniert Fehlerfre! allerdings habe ich keine Ahnung ob es mit 
"expresscard slot" genau so ist bwz. genau so Funktioniert, ich würde ja 
sagen.

Da will es aber einer genau wissen ;)

Der Reihe nach:

RS232 beschreibt was sich auf den Datenleitungen zwischen zwei Geräten 
abspielt. Ein UART ist Teil des Controllers/PCs mit dem du es 
softwareseitig zu tun hast. Das Ding setzt die Datenworte in ein 
serielles Signal um. Das ist aber noch nicht ganz RS232. Die Pegel 
müssen erst angepasst werden, da der UART mit 5V (oder 3.3V) Logikpegel 
arbeitet. RS232 verlangt ein Signal das z. B. mit +/- 9V arbeitet 
(3..20V). Also auch negative Spannungen. Pegelwandler wie der MAX232 
machen das. Zudem muß das ganze noch invertiert werden. Macht der MAX 
auch.
Da diese Konverter ICs auch mit Logikpegeln arbeiten kann man den 
Pegelwandler auch weglassen. Sobald eine Seite aber einen verwendet muß 
die andere das natürlich auch tun. So ist es auch beim STK500 und den 
fertigen USB Adaptern.

Warum es bei den Konvertern klemmen kann:
RS232 definiert neben den Datensignalen RX + TX noch weitere Signale zu 
Ablaufsteuerung wie RTS,CTS,DTR und noch irgendeins. Die meisten Geräte 
benutzen diese Leitungen nicht oder falls sie es doch tun, werden sie 
tatsächlich zur Ablaufsteuerung verwendet. Soweit kein Problem. Jetzt 
kommen aber manche daher und benutzen diese Signale als zusätzliche 
Datenleitungen um quasi einen mehr oder weniger universellen 
Parallelport zu realisieren. Und da knallt es dann schonmal v.a. wenn 
ein besonderes Timing eingehalten werden muß.
Ein berühmt berüchtigtes Beispiel dafür ist eben dieses Ponyprog. Dein 
begehrtes STK500 gehört aber nicht dazu. Der UART der AVRs auch nicht.

Zur Frage USB/Expresscard:
Ich würde USB nehmen weil ich da die geringsten Überraschungen erwarte 
und man so ein Teil auch mal an einen PC anstöpsel kann. Bei den 
Treibern vertrauen ich den USB Teilen auch mehr da die verbauten ICs 
weit verbreitet sind und es Treiber für praktisch alle Bestriebssysteme 
gibt.
Nur wenn du mit Frickelhardware arbeiten willst kannst du USB vergessen.

Und zu guter Letzt:
Das STK500 hat zwei RS232 Anschlüsse. Einen für das Programmiergerät und 
einen für den UART. Jeweils mit einem MAX232 dazwischen. Die lassen sich 
beide mit USB Adaptern verwenden. Aber sicherlich auch mit Expresscard.

Alle Klarheiten beseitigt?

Ein softwareseitiges Problem, ja. Verstärkt durch die Eigenart von USB. 
Wenn ein UART so benutzt wird wofür er gedacht ist, arbeitet das Ding 
autark. Man schickt ihm Daten und er macht etwas standardkonformes 
daraus. Ponyprog geht hin und setzt die Datenleitungen direkt per 
Software auf high oder low. Bei einem herkömmlichen UART funktioniert 
das auch ganz gut. USB arbeitet aber paketorientiert. Bei USB 2.0 
passiert genau jede Millisekunde etwas. Da kann man nicht zu jedem 
beliebigen Zeitpunkt den Zustand der Datenleitungen ändern. Dann kommen 
möglicherweise auch noch Eigenarten der Treiber hinzu.

Auf der Controllerseite kann man per Software praktisch jedes Protokoll 
realisieren da ein µC sich ziemlich berechenbar verhält. Auch einen UART 
kann man sich programmieren, obwohl wenn es relativ viele Ressourcen 
benötigt. Zumindest der Empfang.
PC und USB sind aber nur sehr bedingt echtzeitfähig. Damit ein 
softwaregesteuertes Protokoll zu implementieren um sich auf der anderen 
Seite einen Controller zu sparen, ist für mich gefrickel.