Schönen Montag Morgen! (sehr widersprüchlich für viele) Ich verwende Atmel Studio 6 un den AVR ISP MK2. Programmieren von µCs geht ohne Probleme, aber nach jedem Mal programmieren muss ich die USB Verbindung zum Programmer trennen, sonst kann ich den µC nicht programmieren. Im Fenster wo man den Programmer auswählen kann ("Programm device", CTRL+SHIFT+P) steht da sonst immer "ISP MK2 (busy)" und ich kann den µC nicht programmieren. Ist das normal? Gibt es einen Workaround für das? (ohne ständig den USB ein-und-auszustecken)
Meine Erfahrung: Vermutlich beziehst du auch die Versorgungsspannung des Boards über den MK2. Wenn das Board dann mehr als 50mA braucht, dann passiert genau das. Mit separater Spannungsversorgung tritt das Problem (bei mir) nicht auf.
W.P. K. schrieb: > Meine Erfahrung: > Vermutlich beziehst du auch die Versorgungsspannung des Boards über den > MK2. Wenn das Board dann mehr als 50mA braucht, dann passiert genau das. > Mit separater Spannungsversorgung tritt das Problem (bei mir) nicht auf. Das Board auf dem der µC ist hat eine eigene Spannungsversorgung über einen 7805. Diese ist immer vorhanden. Muss ja so sein, sonst würde sich der Chip gar nicht programmieren lassen. (Target Voltage wird ja vor dem Programmieren überprüft)
:
Bearbeitet durch User
Hast du einen besonderen Grund warum du noch Studio6 verwendest? Das war eigentlich zumindest für mich eine völlig unbrauchbare und total überladene Missgeburt. Soweit ich mich erinnere hatte ich damit auch ständig Probleme, allerdings JTAG MKII. Für mal eben nur nen Chip zu brennen habe ich immer noch die 4.19 (startet viel schneller :-) Ansonsten benutze ich im Moment Studio 7, ziemlich schmerzfrei.
H.Joachim S. schrieb: > Hast du einen besonderen Grund warum du noch Studio6 verwendest? Das war > eigentlich zumindest für mich eine völlig unbrauchbare und total > überladene Missgeburt. Soweit ich mich erinnere hatte ich damit auch > ständig Probleme, allerdings JTAG MKII. > Für mal eben nur nen Chip zu brennen habe ich immer noch die 4.19 > (startet viel schneller :-) > > Ansonsten benutze ich im Moment Studio 7, ziemlich schmerzfrei. Kein wirklich "technischer" Grund, einfach nur Gewohnheit. Ich habe "damals" mit Studio 6 angefangen. Und die ganzen Treiber laufen. Never change a running system. Ja, es braucht ein wenig (viel) Zeit um zu starten, aber mein PC (und alle oft genutzten Programme) läuft sowieso 247, also ist das kein relevanter Aspekt für mich.
W.P. K. schrieb: > Vermutlich beziehst du auch die Versorgungsspannung des Boards über den > MK2. Nö. Das hat der AVRISP MkII noch nie gekonnt. Der Vcc Anschluss ist nur zur Messung von VTarget und nicht zur Speisung. Ich schiebe die Probleme des TE auch darauf, das er Studio 6 benutzt. Microchip Studio 7 hat diese Probleme jedenfalls nicht, mein MkII arbeitet daran problemlos unter Win10/64-bit.
Matthias S. schrieb: > W.P. K. schrieb: >> Vermutlich beziehst du auch die Versorgungsspannung des Boards über den >> MK2. > > Nö. Das hat der AVRISP MkII noch nie gekonnt. Der Vcc Anschluss ist nur > zur Messung von VTarget und nicht zur Speisung. Ich schiebe die Probleme > des TE auch darauf, das er Studio 6 benutzt. > Microchip Studio 7 hat diese Probleme jedenfalls nicht, mein MkII > arbeitet daran problemlos unter Win10/64-bit. Ja, ich habe auch Win10 8 bytes. Gut, dann werde ich entweder "upgraden" wenn ich das nächste mal meinen PC neu aufsetze oder ich bastle mir eine kleine Schaltung die den USB nach dem Programmieren kurz trennt. Der Programmer hat ja eine LED die den Status anzeigt. Beim Programmieren blinkt diese orange. NE555 der nach dem orangen Blinken ein paar Sekunden wartet, dann mit einem Relais die 5V vom USB trennt, zweiter 555 der ein paar Sekunden wartet und dann das Relais wieder die Verbindung schließen lässt.
:
Bearbeitet durch User
Andre G. schrieb: > Beim Programmieren blinkt diese orange. Das macht meiner nur bei falscher Resetpolarität, wenn ich also z.B. einen AT89S52 programmiert habe und dann wieder zu einem AVR wechsle. Andre G. schrieb: > NE555 der nach dem orangen Blinken ein paar Sekunden wartet Das klingt mir eher nach 'von hinten durch die Brust ins Auge'. Da muss man auch kein Betriebssystem neu aufsetzen, sondern Studio 6 deinstallieren und dann MC Studio 7 installieren.
:
Bearbeitet durch User
Matthias S. schrieb: > Das klingt mir eher nach 'von hinten durch die Brust ins Auge'. Da muss > man auch kein Betriebssystem neu aufsetzen, sondern Studio 6 > deinstallieren und dann MC Studio 7 installieren. Ja das Problem ist nur wenn 7 dann nicht läuft und ich zurück zu 6 will dann habe ich eine Sauerei mit den installierten Treibern und so ...
Andre G. schrieb: > wenn 7 dann nicht läuft Wie dir hier schon einige Poster geschrieben haben, ist Studio 7 (egal ob Atmel oder Microchip) deutlich problemloser als 6. Das Studio 5 völlig auscheidet, dürfte jedem klar sein, diese Versuchsversion war eine einzige Katastrophe. Ich habe 6 völlig übersprungen (mit AVR Studio 4.19 solange gewurschtelt), bin aber mit 7 soweit zufrieden, wenn man weiss, das man ein paar 32-bit Libraries von M$ nachinstallieren muss, falls es Probleme gibt. Aber deswegen ein OS neu zu installieren, ist Unsinn.
Matthias S. schrieb: > Wie dir hier schon einige Poster geschrieben haben, ist Studio 7 (egal > ob Atmel oder Microchip) deutlich problemloser als 6. Ich betreibe alle Versionen in div. virtuellen Maschinen mit einem (halbwegs) passenden Windows-BS. 4.18 oder 4.19 laufen für "betagte AVR's" oder HEX-File flashen sehr gut und auch schnell. Manche neueren MC's kann man portieren - muss man halt herumschauen. 6.xx war - aus meiner Sicht - noch stabil und relativ schnell. Mein Favorit. Mit Studio 7 / Microchip-Studio wird es komfortabler - aber leider auch CPU-/ Speicher-hungriger und beim Microchip-Studio teilweise auch "Kostenpflichtig". Das muss jeder für sich wissen. Bei allen müssen die Treiber für die div. "Programmer" passen. Da hilft Google aber auch - muss man halt mal herumschauen.
Ich muss demnächst sowieso so ziemlich alles auf meinem PC neu installieren weil ich meine C Festplatte austausche, also dann wäre da der passende Zeitpunkt um mich von AS6 zu trennen ... Vom "Microchip Studio" will ich möglichst die Finger lassen, unter anderem wegen diesm "teilweise kostenpflichtigen" Schwachsinn. Ist AS7 wirklich noch von Atmel oder ist da schon dieser "Microchip Schwachsinn" drin?
Andre G. schrieb: > unter > anderem wegen diesm "teilweise kostenpflichtigen" Schwachsinn Sofern du dich mit den AVR beschäftigst, ist da überhaupt nix kostenpflichtig. Projekte kann man einfach importieren aus z.B. AVR Studio 4. Ich zumindest bin noch über keine Ecke mit Kosten gestolpert, obwohl ich mittlerweile eine Menge in MC Studio 7 importiert, geschrieben und kompiliert habe. Ich gebe aber zu, das ich fürs Datenblatt durchaus in der Lage bin, mir das von MC direkt zu laden ohne die Unterstützung von MC Studio. Und einen Debugger brauche ich für AVR auch nicht, die Grütze zwischen den Ohren hat da noch immer ausgereicht.
Matthias S. schrieb: > Andre G. schrieb: >> unter >> anderem wegen diesm "teilweise kostenpflichtigen" Schwachsinn > > Sofern du dich mit den AVR beschäftigst, ist da überhaupt nix > kostenpflichtig. Projekte kann man einfach importieren aus z.B. AVR > Studio 4. > > Ich zumindest bin noch über keine Ecke mit Kosten gestolpert, obwohl ich > mittlerweile eine Menge in MC Studio 7 importiert, geschrieben und > kompiliert habe. Ich gebe aber zu, das ich fürs Datenblatt durchaus in > der Lage bin, mir das von MC direkt zu laden ohne die Unterstützung von > MC Studio. Und einen Debugger brauche ich für AVR auch nicht, die Grütze > zwischen den Ohren hat da noch immer ausgereicht. Gut, dann werde ich das dann mal probieren ...
Nur zum Programmieren schreibe ich mir einmalig ne Batch in das Projektverzeichnis mit atprogram.exe (AS7). Dann die Batch einfach nur anklicken.
1 | @echo off & setlocal |
2 | path=%path%;"C:\Program Files (x86)\Atmel\Studio\7.0\atbackend |
3 | :cls |
4 | for /f "delims=" %%s in ('dir /B /OD .\Binfiles\*.hex') do set binf=%binp%%%s
|
5 | echo Program %binf% |
6 | echo. |
7 | pause |
8 | atprogram.exe -t avrispmk2 -i ISP -d AT90CAN128 program -c -fl -f Binfiles\%binf% --verify write -fs --values FFD0FD --verify |
9 | set binf= |
10 | pause |
Peter D. schrieb: > Nur zum Programmieren schreibe ich mir einmalig ne Batch in das > Projektverzeichnis mit atprogram.exe (AS7). Dann die Batch einfach nur > anklicken. Oh, das ist cool! Dann spart man sich das Durchklicken im "Programm Device" Fenster. Sehr fein!
Achtung bei den Fusebits, die sind in der Reihenfolge: low, high, ext. Wenn Du die nicht ändern mußt, das "write..." löschen.
Peter D. schrieb: > Achtung bei den Fusebits, die sind in der Reihenfolge: low, high, ext. > Wenn Du die nicht ändern mußt, das "write..." löschen. Gut zu wissen. Nein, von den Fuse bits lasse ich (vorerst noch) die Finger.
Sorry, daß ich kurz mal etwas OT werde, da habe ich mal ne Frage: Peter D. schrieb: > Nur zum Programmieren schreibe ich mir einmalig ne Batch in das > Projektverzeichnis mit atprogram.exe (AS7). Dann die Batch einfach nur > anklicken. Welchen Vorteil bringt diese Vorgehensweise gegenüber der üblichen 1-Klick-Programmiermethode vom Microship Studio 7? Reinhard
Reinhard R. schrieb: > Welchen Vorteil bringt diese Vorgehensweise gegenüber der üblichen > 1-Klick-Programmiermethode vom Microship Studio 7? 3 Klicks :-)
Angehängte Dateien:
-
MicroshipStudio2.jpg
24 KB
Hugo H. schrieb: > 3 Klicks :-) Nöö, ich klicke genau einmal auf den eingekreisten Button --> Kompilieren und Programmieren fertig. Reinhard
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.