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.
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.
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ß.
./. 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
1 | // the outer while loop
|
2 | while (1) |
3 | {
|
4 | //ready for some action
|
5 | ledg_on(); |
6 | dev_ok = 1; |
7 | |
8 | // 0x1b is 'ESC'
|
9 | while ((sw = uart_getc()) == 0x1b) |
10 | ;
|
11 | |
12 | //busy becaus of some action
|
13 | ledg_off(); |
14 | |
15 | //commands taken from Serasidis' AVR910
|
16 | //commands from other sources are marked separately
|
17 | switch (sw) |
18 | {
|
19 | case 'T': //device type |
20 | device = uart_getc(); |
21 | // dev_ok = 0;
|
22 | //look up device in list
|
23 | //i do this as the device is selected
|
24 | //so i do not have to prove everytime
|
25 | //a command after 'P' is executed
|
26 | //as in Serasidis' original AVR910 v3.3
|
27 | for (i = 0; device_codes[i][0] != 0xFF ; i++) |
28 | {
|
29 | if(device == device_codes[i][0]) |
30 | {
|
31 | pgm_mode = device_codes[i][1]; |
32 | dev_ok = 1; |
33 | break; |
34 | }
|
35 | else
|
36 | dev_ok = 0; |
37 | }
|
38 | if (dev_ok) |
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'.
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 :-)
Bitte 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.