Important announcement: there is an English version of this forum on 
Mit Launchprog V 1.1 wird aus dem MSP430-Launchpad ein AVR910-kompatibler Programmierer. Das Original hatte noch den Bug, das AVRDUDE erst eine Aufwärmschleife drehen mußte. (siehe http://www.mikrocontroller.net/articles/Launchprog ) Da ich das ganze nicht mit dem GCC übersetzen konnte (und wollte), anbei nur ein TI-Hex-File das sich mit dem FETproLite von Elprotronic in einen MSP430G2211 brennen lässt. Zuvor muß allerdings die 16 MHz-Konstante des DCO kalibriert werden. Das dazu verwendete Launchpad muß den Uhrenquarz bestückt haben. Der Programmer selber braucht den Quarz nicht. Siehe dazu: Beitrag "MSP430G2XX DCO-Kalibrator" (Der Fehler steckt übrigens in der 910.c ... dev_ok = 0; ...) Viel Spaß damit.
Datum:
Wer zum Teufel sollte es sich antun einen ATMega16 mit grottig langsamen 9600 Baud zu programmieren? Schönes Beispiel wie man gnadenlos Zeit für Dinge vergeudet die keinen Sinn oder Mehrwert haben. Da ist mein selbstgebastelter Parallelport AVR Programmer mit eigener Software ja schon besser. Den hab ich vor 15 Jahren mal zusammengeschraubt. Und was nehm ich heute? Einen AVR ISP MKII.
Datum:
P.S.: Nunja, der schnellste einer welchen ist er wohl nicht. Für mein Thinkpad, mit paralleler Schnittstelle, habe ich schon eine gaaaanze Weile einen STK200-Kanda-Dongle (S/N #169 immerhin :-). Der AVR-Dragon ist mir für das gelegentliche Programmieren eines AVR zu fragil und empfindlich und bleibt daher meist in seinem Käfig. Da ich nur noch sehr sporadisch AVRs programmiere, mein Netbook USB-only ist, sich ein AVR ISP Mkxyz nicht lohnt, geht es halt langsam. Jedenfalls funktioniert diese Konstruktion immer noch besser, als Bit-Bang-Programmierer am emulierten RS232-USB-Anschluß.
Datum:
./. schrieb: > (Der Fehler steckt übrigens in der 910.c ... dev_ok = 0; ...) in welcher Zeile? holger schrieb: > gnadenlos Zeit für > Dinge vergeudet Vielen Dank für die aufschlussreiche Kritik! mfg mf
Datum:
// the outer while loop while (1) { //ready for some action ledg_on(); dev_ok = 1; // 0x1b is 'ESC' while ((sw = uart_getc()) == 0x1b) ; //busy becaus of some action ledg_off(); //commands taken from Serasidis' AVR910 //commands from other sources are marked separately switch (sw) { case 'T': //device type device = uart_getc(); // dev_ok = 0; //look up device in list //i do this as the device is selected //so i do not have to prove everytime //a command after 'P' is executed //as in Serasidis' original AVR910 v3.3 for (i = 0; device_codes[i][0] != 0xFF ; i++) { if(device == device_codes[i][0]) { pgm_mode = device_codes[i][1]; dev_ok = 1; break; } else dev_ok = 0; } if (dev_ok) |
Datum:
Na dann kann man den ganzen device_ok-Kram nebst der Liste der Devices komplett entfernen. Der Programmer meldet halt dann immer "OK" und er kann alle Devicecodes von 0x00 bis 0xF7. Sinn des Flag dev_ok war ja eigentlich, dass die Programmierroutinen erst nach der Wahl eines gültigen Device anspringbar sind. Kann man also auch alles raus werfen. mfg mf PS: Oder andersrum: der Zugriff wird erst "verboten", wenn ein falscher Code gewählt wird. Jetz weiß ich auch was du damit wolltest... Ich werd deinen Code mal mit ins Wiki einpflegen. Wirklich weiterentwickeln werde ich den Launchprog aber nicht, weil ich eh einen funktionierenden USBasp hab'.
Datum:
Mini Float schrieb: > PS: Oder andersrum: der Zugriff wird erst "verboten", wenn ein falscher > Code gewählt wird. Jetz weiß ich auch was du damit wolltest... Brilliant beobachtet :-)
Datum:
Hey, kannst du bitte deine CCS-Projektdateien auch ins Wiki stellen? mfg mf
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten