Intel-HEX-File - nibbles tauschen?

Joerg schrieb:

MS fixiert sich seit XP derart auf den Heimanwender (und deren=20 G=E4ngelung), der sich nicht mit der Materie besch=E4ftigen will, da=DF d= ie=20 sogenannten "professional"-Versionen diese Bezeichnung mMn. nicht mehr=20 verdienen. "XP Professional" ist eigentlich ein Witz, ein ziemlich=20 schlechter leider. Das geht bei der f=FCrchterlich unergonomischen GUI lo= s=20 und h=F6rt bei den Automatismen noch lange nicht auf ...

Tja, bl=F6d wer sich von MS abh=E4ngig gemacht hat. Ich seh das leider im= mer=20 wieder auf Arbeit.

Guido

Wenn es so wichtig ist, dann hast du doch wohl den Source dieses Programmes? Oder willst du mir erzaehlen, dass sich die Industrie im Bezug auf Steuerung ihrer Produktion von einem Softwarehersteller abhaengig macht den es u.U. gar nicht mehr gibt wenn die Hardware auf der sie laeuft ersetzt werden muss?

Gerrit

Problem ist, was passiert wenn die Hardware den Geist aufgibt und kein Ersatz auf dem Win3 noch laeuft zu bekommen ist?

Bis es mal nicht mehr laeuft und man einfach keine passenden Ersatzteile mehr bekommt. Dann wird das _richtig_ teuer. Aber langfristige Planung und Quartalsabschluesse sind schwer unter einen Hut zu bringen.

Gerrit

Der steht bei einem Hurricane auch draussen... Ansonsten ist so eine WLAN-Antenne auch recht klein, bevor die beim Sturm wegfliegt ist das Haus eine Ruine.

Gerrit

Xp oder nicht hat nix zu sagen. Die Software, die unter der

Stefan

Bei mir sieht das typischerweise so aus, dass ich mit einem Konsolenfenster eh schon im passenden Pfad stehe, und dann erstmal zu Fuß das GUI-Tool in dieses Verzeichnis schubsen muss (zur Maus greifen, Prompt markieren, Kopieren, in GUI-Tool wechseln, Pfad einfügen) anstatt einfach nur "tool dat.dat" zu schreiben.

Ganz einfach: für so eine Aufgabe würde ich kein GUI-Tool programmieren. Daten transformieren ist was, was danach schreit, gescriptet zu werden. Wenn es jetzt z.B. um einen Browser ginge, in dem man interaktiv Bereiche ausschneidet, als Bytes/Words/Longwords/Doubles/ASCII/Unicode anzeigt, etc., dann wäre das was anderes.....

Stefan

Kein Empfang? Auch mit externer Antenne nicht? Du schreibst von einer SMS pro Tag, so ungefähr. Da käme ich dann eher auf die Idee so ein Teil von Wavecom einzusetzen, eine SIM-Card mit SMS Flat rein und auf der anderen Seite ebenso. Ein bischen Software, SMS auslesen und ver- arbeiten.

Von der Leistung sicher, aber hast Du Dir die Preise angeschaut? Das

Hast Du mal bei

Dann bleibt für Dich nur ein Mac über ;-)

Und soll ich die Version für ARM dafür liefern? Ich verwende FLTK unter Linux auf einem ARM mit 5,7" Display. Diese Bibliothek ist so ziemlich die beste Klassenbibliothek für die Multiplattform-Programmierung, wenn viel Wert auf Portierbarkeit, Geschwindigkeit und Codegröße gelegt wird. Läuft mit gleichem Code unter Linux, Windows, Mac, BSD, ARM und sieht dann überall auch noch identisch aus:

Wer dann noch eine Datenbank braucht nimmt sqlite dazu. Alles schön statisch gelinkt und die Software kommt ohne Installer aus, läuft überall direkt von Stick und auch als 64-Bit ;-)

Hier eine Zusammenfassung:

Ich bin an sich relativ zufrieden damit.

VBA ist inzwischen so lange Usus in der Computerwelt dass es mich ehrlich gesagt wundert warum Open Source das ignoriert hatte. Es funktioniert gut und Firmen wollen natuerlich aus guten Gruenden nicht einfach die ganzen drinsteckenden Arbeitstunden wegschmeissen. Da kauft man lieber fuer den neuen Mitarbeiter eine weitere Excel Lizenz und feddich.

Was Abhaengigkeit angeht, tja, wer Messgeraete zu bezahlbaren Konditionen braucht der hat kaum eine andere Wahl. Oder muesste einen zusaetzlichen SW-Spezialisten einstellen der das dann alles versucht an Linux zu friemeln.

I.d.R. ja, bei In-Circuit Testanlagen und so manchmal nicht. Das ruecken die Hersteller nicht raus. Abhaengigkeiten sind in diesem Metier ganz normal. Oder wuerde Dir der Hersteller Deines Autos den Source Code zum Motorcomputer rausruecken?

Und selbst wenn man den Source Code hat, da wuerde man etliche Dinge in Kauf nehmen muessen, zum Beispiel:

a. Jemand muss das umschreiben und neu compilieren. Das kostet handfest Geld.

b. Der Hersteller lehnt nun den Service des Geraetes ab, da eine unautorisierte Veraenderung an der Anlage vorgenommen wurde.

c. Es besteht das Risiko dass es nachher doch noch nicht 100% so funzt wie vorher, es gibt einen Line Stop in der Produktion, Leute muessen nach Hause geschickt werden, der Sales Forecast geht durch die Lappen, der Chef tobt, ...

Die Antwort auf diese Punkte ist meist ein resolutes "Nein, wollen wir vermeiden". Und das ist ja auch recht einfach indem man nicht umsteigt.

Bestimmt nicht darin ;-).

Keine Ahnung

Ich arbeite mit einem 200MHz AT91RM9200, Kernel 2.6.22, Framebuffer, Microwindows, FLTK für die GUI Entwicklung. Ich kann nicht sagen, dass es da irgendwie langsam geht. Die Kiste braucht ca. 12 Sekunden für die Console und weiter 8 Sekunden für die Oberfläche, Datenbank- zugriff und start aller Hintergrund-Prozesse.

Gleicher Code, egal ob auf dem Desktop oder auf dem Embedded-System. Sauberes Multitaskting, saubere Netzwerkunterstützung mit allen was dazu gehört. Völlig frei anpassbar.

Schau mal auf die Seite von

Beim Autohersteller mach ich mir da weniger Sorgen, dass es den auf einmal nicht mehr gibt. Bei irgendeiner Testsoftware fuer einen Testplatz der auf einem steinalten PC laeuft kann das durchaus anders sein.

Besser als gar nicht mehr verwenden koennen, oder?

Es war der Fall gemeint, dass es eben diesen nicht mehr gibt oder der auch fuer Geld keinen Support oder eine neue Version rausrueck. Schlag mal 'Abandonware' nach.

Bis man nicht mehr anders kann... und dann?

Gerrit

Erstmal das und die meisten Anlagen in der Industrie werden doch wohl eher von einer SPS gesteuert und der PC steht da nur zur Visualisierung.

Ach Edzard!

Isch 'abe meine Finger aber gar nicht auf der Maus. Und die Chance, daß der Filechoser zufällig gerade im richtigen Verzeichnis ist, ist praktisch 0.

Isch 'abe aber nur die exe. Oder wahlweise keinen Compiler. Oder Fltk nicht installiert.

Das ist umständlicher:

- da ist eine separate, nichtintuitive Option "-file" statt einfach von der Standardeingabe zu lesen

- der Name des Ausgabefiles ist "magisch" (und .swp ist sowieso keine besonders gute Idee IMHO)

Im Gegenzug ist die Implementierung als Filter (lesen von STDIN, schreiben auf STDOUT) einfach universell und intuitiv. Man kann es so z.B. auch einfachst in einer Pipe verwenden. Oder den output an ein existierendes .hex anhängen. Oder, oder, oder. Es hat schon einen Grund, warum so viele UNIX-Tools als Filter implementiert sind.

Wer es braucht kann sich den Tk::FileSelect aus Tk noch da rein programmieren, auch auf die Gefahr hin, daß der GUI-Teil dann mehr Code braucht als der Rest. Oder man wickelt ein Shellscript drum herum, das "dialog --fselect" benutzt. Realistischer wäre wohl, das Tool ins Kontextmenü für .hex aufzunehmen. Und dann z.B. im mc: Cursor aufs .hex stellen, F2 drücken, "swap nibbles" auswählen, Enter.

Perl ist überall Standard, außer auf Windows. Notfalls kann man übrigens auch Binaries aus Perlskripten bauen (perlcc). Allerdings verliert man damit einen wesentlichen Vorteil: man kann die Transformationsvorschrift nicht mehr einfach on-the-fly ändern.

Es ist IMHO einfach unsinnig, jedes kleine Tool als GUI-Programm zu schreiben. Zumal wenn man es (wegen Zero Installationsvoraus- setzungen) statisch linken will. Am Ende hat man dann 10 Tools mit 10 verschiedenen File-Select-Dialogen.

Am ehesten würde man das mit Java machen. Aber das faß ich nicht an.

XL

Das ist kurzfristig gedacht. Systeme, die nicht regelmässig gepflegt und auf den aktuellen Stand gehalten werden, kosten eines Tages richtig Geld. Ich kenne solch einen Fall, einmal 245 PC auf XP bringen, von Windows 95!. Nicht das die nicht mehr liefen, aber der Server mit Netware 4 war hinüber, Hardware für Netware 4 gab es nicht mehr, Win 95 wollte aber mit Netware 6 und der Datenbank darauf nicht.

Bei Deinen geschilderten Fällen kannst Du dann die Produktion gleich schliessen, für immer. Aber das macht ja nichts, denn die Heuschrecken gehen dann zum nächsten Laden über.

Das _ist_ letzten November bei einem Kunden passiert, eine MoBo Abrauche. Es war ueberhaupt kein Problem passende Hardware bei einem Industrieanbieter zu bekommen und die Anlage lief wenige Stunden nach Auspacken selbiger wieder wie seit Anfang der 90er. Mich brauchten sie nur 15 Minuten am Telefon um den Ingenieur durch die Kalibrierung zu "coachen".

Ich kann kaum zaehlen wie oft mir gesagt wurde dass man nix mehr mit ISA Bus bekommt. Dann waren in Minuten aktuelle Anbieter gefunden, Mainboards und fertige PCs aus frischer Produktion mit bis zu acht ISA Slots. Einer aus Europa meinte "Ja aber nicht bei uns" ... das dauerte dann einige Minuten laenger und auch er hatte danach eine Telefonnummer, der Laden war sogar in bequemer Autoreichweite :-)

Du solltest mal sehen was hier noch so in Betrieb ist.

Kein Scherz. Die Dinger fliegen in Amerika echt noch Fracht. In diesen Kreisen schickt man einen defekten Motor meist nicht einfach nach Pratt&Whitney. Viel zu dekadent. Nein, man krempelt die Aermel hoch, ruft zuhause an dass es heute etwas spaeter wird und baut den entsprechenden Zylinder ab.

Daher nimmt man die Version ja auch nicht :-)

Das ist auch Quatsch, die findet man noch. Das größere Problem dabei ist der eingesetzte Prozessor und die Treiber für die Hardware. Ein Beispiel wäre das Problem mit den Borland Produkten und mit Turbo C und Turbo Pascal wurden Anwendungen ohne Ende geschrieben. Starte mal so ein Programm auf einem schnellen, heutigen Rechner. Wenn Du Glück hast geht der Patch, der im Netz rumgeistert, wenn Du Pech hast, kriegst Du die Software nicht mehr zum rennen und kannst Dir in der Bucht die letzten