Alternative zu Flashnnn.exe

[damaltor]

ich hab ne bluetooth tastatur... mir gehts eher um ein terminalprogramm (ich habe für winmobile keins gefunden das auch funktioniert) und um eine möglichkeit, fertige hex dateien zu flashen. schon den passenden compiler zu finden dürfte wahrscheinlich schwierig werden.

ausserdem hatte ich irgend wann mal vor, dem asuro den pda "huckepack" aufzusetzen, das würde eine einfache interaktion / eingabe-ausgabe möglichkeit geben. die ir-Schnittstelle bleibt dabei bestehen, damit eine programmierung mit dem pc möglich bleibt. irgend eine art, den transceiver auf dem asuro passend zu fixieren fällt mir schon ein...

also es ginge nur um ein terminal und gut wäre noch eine möglichkeit zu flashen. es ist einfach einfacher, mit dem pda hinterherzurennen als mit dem pc/laptop... ausserdem könnte man den pda ja auch irgendwie befestigen =)

mir fällt spontan nochwas ein: es könnte eine möglichkeit geben, ein "steuerprogramm" auf dem pda zu programmieren, das auf bestimmte ausgaben des asuro reagiert und automatisch bestimmte zeichenfolgen zurücksendet. der prozessor müsste dann nur noch verschiedene routinen (motor an/aus, leds an/aus....) haben und in der main funktion auf ein input vom pda warten... quasi ne fernsteuerung, die mitfährt =)
sorry ich träum grad...

[der_andi]

Ok, nach ner langen Arbeitswoche hammer mal wieder Zeit fürn Asuro. Der nächste versuch den Editor gangbar zu machen ist aber auch gescheitert, ich hab mich mal dran versucht die Pfadangaben in diesem cpp-config-Fenster anzupassen. Hat aber vorerst nicht geklappt. Endweder frisst er sich an Leerzeichen im Pfad oder eine der aufgerufenen Anwendungen beschwert sich über die Kommandos.
Funktioniert hats dann aber trotzdem nachdem ich lediglich "make all" eingetragen habe, das selbe was auch in der Test-all.bak aus dem Original-Asuro-Source steht.

Sollte das Tool wirklich Newbies ansprechen würde ich da mal nochmal ansetzen um das Konfigurieren zu erleichtern.

Nochmal zum Flash-Automatismus:
Das könnte man doch einfach mit ner Checkbox umsetzen, so ala "Nach dem compilieren flashen", sobald make sein ExitCode 0 übergibt wird das resultierende hex-file als default definiert und danach wechselt Asuroflash dann zum Flash-tool und wartet darauf das Asuro eingeschaltet wird, eventuell sollte man dafür die Timeout-Zeit etwas verlängern.
Quasi ein Klick und einmal einschalten reichen zum Flashen.

[damaltor]

hmm... ob man nu erst kompiliert und dann flasht (2 klicks) oder erst die ceckbox anmacht, dann kompiliert, dann die checkbox wieder ausmacht, damit nicht jeder versuch gleich geflasht wird (3 klicks) find ich eigentlich egal... aber da einige das gern wollen würde ich sagen machs ruhig mal rein; dann ist das prog "kundenfreundlicher" =)

was mir noch eingefallen ist: wenn man beim kompilieren einen fehler gemacht hat bzw. beim programmieren, dann steht ja in dem statusfenster unten die ausgabe vom kompiler. gut wäre, wenn man auf den fehler doppelklickt und er dann im c editor in die entsprechende zeile springt... aber das ist eigentlich nur azufwändige kosmetik.

[der_andi]

Ja ne, ich weis jetzt nicht obs nur mir so geht, aber ich sitze öfters vom Code und verbessere kleinigkeiten, nicht solche die Errors produzieren sondern einfach nur Tippfehler, falsche Konstanten oder anderer Schnörkerl der einfach nur Fehler im Programmablauf hervorruft, um zu testen obs denn jetzt funktioniert muss ich das Programm aber erst auf den Asuro übertragen.
Aber das ist eh nur Kleinkram für ne spätere Desingphase.

Wenn das Programm wie beabsichtig eine all-in-one-Lösung werden soll mit der auch Neulinge was anfangen sollen dann wäre eine Auto-Konfiguration (Per öffnen-Dialog Ausroflash zeigen wo das WinAVR-verzeichnis liegt beispielsweise) und ein auto-makefile viel wichtiger, aber dann wird daraus aber auch DAS Powertool fürn Asuro, Programm starten und loslegen, Bedienerfreundlichkeit in Reinkultur.

[damaltor]

hmmm... das ist richtig... bin dafür =)

[Osser]

Hi der_andi,

Ok, ok, will mal nicht so sein. Du bekommst deinen "Nach dem compilieren flashen" Konfig-Switch... Wer es will schaltet das Feature ein, wer es nicht will eben nicht...

Der Auto-Makefile ist bereits in der Mache. Dadurch heissen in Zukunft die Hex-Dateien auch nicht immer test.hex sondern so wie eben das Projekt benannt wird Punkt Hex.

Aber was meinst Du mit "Per öffnen-Dialog Ausroflash zeigen wo das WinAVR-verzeichnis liegt beispielsweise...", ist mir nicht ganz deutlich was das bedeuten soll.


O.

[damaltor]

ich würde das folgendermaßen verstehen: man klickt auf einen button ("compilerverzeichnis einstellen"). ein öffnen-dialog kommt auf den schirm. und in diesem muss man das winavr-verzeichnis bzw. eine bestimmte datei darin auswählen und "öffnen". und schon ist deinem flash tool das winavr verzeichnis bekannt, und alle wichtigen einstellungen können automatisiert werden =)

nachteil: funktioniert dann nur mit jeweils einem bestimmten kompiler, und auch nur wenn sich dessen ordnerstruktur nicht ändert.
vorteil: unglaublich einfache einstellung der pfade.

vielleicht sollten beide möglichkeiten offen gehalten werden ("für den standart-compiler hier klicken, für alle anderen hier klicken").

mal was anderes: wie siehts aus mit windows mobile (siehe oben)? ist sowas überhaupt möglich?

[Osser]

Hi damaltor,

für Windows Mobile brauch ich einen Emulator an den ich nicht so leicht rankommen kann. Ist aber eine interessante Idee, werd mal schaun was da möglich ist.

Die Geschichte mit dem Doppelcklick auf eine Fehlerzeile im Statusfenster sollte möglich sein (hui... ich hoffe ich kann mir alles merken was ich hier so locker verspreche).
Beim Auftreten von Fehlern sollte übrigens jetzt schon der erste Fehler automatich im Sourceeditor angezeigt werden. Funktioniert aber bei Deiner Version leider nur, wenn die aktuelle Unit geöffnet ist.
D.h. Ist der Fehler in test.c sollte das auch der aktive Tab sein, beim Ausführen von Make all. Dann wird der Cursor in die Zeile des Fehlers positioniert.
Ab der nächsten Version wird das erweitert auf alle im Projekt befindlichen Dateien.


O.

[Osser]

Hi damaltor,

in der kommenden Version muss nur noch der AVR-Pfad angepasst werden und die restlichen Skripte werden automatisch angepasst mittels enthaltener Variablen , also auch dass Makefile-Skript.
Für andere Kompiler muss auch ein anderes Make all, Make clean oder Makefile Script erstellt werden.
Im Moment verfolge ich die Strategie um alles was beim Kompilieren nötig ist in Variablen zu verfrachten, die dann flexibel in den Scripten verwendet werden können.
Das funktioniert bereits ganz gut in meiner aktuellen Version.
z.B.
AF_PRGDIR, AF_PROJECTNAME, AF_...

Dann muss auch nur eine Einstellung geändert werden um alle Scripte anzupassen.

O

[damaltor]

na das klingt doch echt gut... eben eine eierlegende wollmilchsau. =)