Einheitlicher Zugriff auf Programmiergerät aus IDE heraus

[TomA (Gast)]

Hallo Leute.

Ich schreibe mir gerade eine IDE für den SDC-Compiler und bin beim 
Download der Programme zum Target angelangt. Hier habe ich das Problem, 
dass ich den Download-Programmen eine Intel-Hex Datei übergebe und warte 
bis der Download beendet ist. Leider verliert meine IDE dabei die 
Kontrolle und die Bildschirmausgaben der Download-Programme werden 
innerhalb der IDE erst verspätet sichtbar.

Das Problem löse ich, indem ich plane den Programmen keine ganze Datei, 
sondern Bytes, Blöcke oder Hex-Records zu übergeben. Dadurch kann ich 
dann z.B: einen Progressbar innerhalb der IDE mitführen.

Bei meiner Suche nach einer Lösung bin ich auf das ATMEL Flip-Protokoll 
gestoßen, welches dafür geeignet scheint. Bevor ich beginne dies 
umzusetzen hätte ich aber zwei Fragen?

1. Gibt es eine Norm oder einen Standard für diese Aufgabe?
2. Das Flip-Protokoll ist firmenspezifisch, darf ich das einfach so 
verwenden?

Gruß Tom

[Niklas G. (erlkoenig)]

TomA schrieb:
> Das Problem löse ich, indem ich plane den Programmen keine ganze Datei,
> sondern Bytes, Blöcke oder Hex-Records zu übergeben.

Das ist ein böser Workaround.

TomA schrieb:
> Leider verliert meine IDE dabei die
> Kontrolle und die Bildschirmausgaben der Download-Programme werden
> innerhalb der IDE erst verspätet sichtbar.

Das Problem lässt sich anders lösen. Wie machst du das beim Compilieren 
oder anderen langen Prozessen, blockieren die auch deine IDE?

Starte den Programmer(-Prozess) "im Hintergrund", sodass deine IDE 
normal parallel dazu weiterlaufen und die Ausgaben abfangen und anzeigen 
kann, wie es wohl jede andere IDE auch macht. Dabei wartest du dass der 
Prozess beendet und zeigst dann ggf. eine entsprechende Meldung an. 
Indem du die Ausgabe des Programmers in einem Konsolenfenster anzeigst 
wird dem User dann auch eine ggf. vorhandene Fortschrittsanzeige 
weitergegeben.

Wie das genau geht hängt von der Programmiersprache und Betriebssystem 
ab; in C und Unix geht das über "fork()", "exec()", "dup2()" (zum 
Abfangen der Ausgabe), "waitpid()". Unter C und Windows durch 
"CreateProcess" und Angabe der richtigen Parameter. Dein GUI Framework 
wird möglicherweise einen Wrapper haben, der das in die Main/Event-Loop 
integriert, bei Gtk+ z.B. g_spawn_async_with_pipes+g_child_watch_add. 
Unter Python geht das mit dem subprocess Modul.

[TomA (Gast)]

Hallo Niklas,

ist unter Ubuntu und in C++. Werde mir was Du schreibst mal näher 
ansehen, interessehalber. Die Ausgaben der Dienstprogramme in die 
Konsole funktionieren einwandfrei (verwende EXEC), innerhalb meiner IDE 
zeige ich sie in einem eigenen Fenster an und das funktioniert nicht. 
Ist aber nicht so wichtig, da ich mit verschiedenen Arten von Download 
zu verschiedenen Geräten zu tun habe.

Um nicht jede Kombination in der IDE berücksichtigen zu müssen will ich 
aus der IDE einen einheitlichen Zugriff in der Art Flip-Protokoll. Da 
die Firmware in den Targets und Programmiergeräten auch eigene sind, 
kann ich sie entsprechend anpassen.

Da es scheinbar keine Norm/Standard gibt und die IDE nur zu meinem 
persönlichen Gebrauch ist werde ich wohl das Flip-Protokoll umsetzen 
(vielleicht noch eine Nacht darüber schlafen).

Vielen Dank für Deine Mühe und Zeit. Gruß Tom

[Niklas G. (erlkoenig)]

TomA schrieb:
> ist unter Ubuntu und in C++. Werde mir was Du schreibst mal näher
> ansehen, interessehalber.

In C++ geht das genau so wie in C.

TomA schrieb:
> (verwende EXEC)

Bewirkt "exec()" nicht dass der Prozess deiner IDE überschrieben wird?

TomA schrieb:
> innerhalb meiner IDE
> zeige ich sie in einem eigenen Fenster an und das funktioniert nicht.

Wenn du das einmal korrekt machst, funktioniert es mit Compiler, 
Flash-Tools und sonst allem was du extern aufrufst (z.B. git).

TomA schrieb:
> Um nicht jede Kombination in der IDE berücksichtigen zu müssen will ich
> aus der IDE einen einheitlichen Zugriff in der Art Flip-Protokoll.

Das Senden/Empfangen von Paketen braucht aber auch eine gewisse Zeit; 
wenn du das blockierend machst, wird die GUI deiner IDE dann ebenso 
(kurz) blockiert. Ob du jetzt eine asynchrone Kommunikation über USB 
oder UART implementierst oder externe Flash-Tools asynchron 
ansteuerst...

[TomA (Gast)]

Hallo Niklas,

das ist ja der springende Punkt. Wenn ich die Übertragung in Teile 
zerlege kann ich dazwischen die Fortschrittsanzeige aktualisieren. Damit 
ist es dann sogar möglich bei den alten Geräten, die Intel-Hex Dateien 
ohne Rückmeldung verarbeiten, eine Fortschrittsanzeige zu realisieren 
(Record für Record).

Gruß Tom.