Forum: PC-Programmierung DLL in LabView einbinden


von Florian B. (dabone_206)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,
ich würde gerne eine DLL in LabView einbinden. Die DLL ist in Delphi 
geschrieben und damit kenne ich mich leider nicht so aus. Meine Frage 
ist nun, kann mann diese DLL trotzdem in LabView implementieren? Mann 
kann unter Funktionsname leider nur 2 Funktionen aufrufen. Ich hab euch 
mal die Dateien angehängt eine davon müsste eine Art Header-Datei für 
die DLL sein.

Vielen dank schon mal für eure Antworten.

von Wolfgang (Gast)


Lesenswert?

Florian B. schrieb:
> Ich hab euch mal die Dateien angehängt eine davon müsste eine Art
> Header-Datei für die DLL sein.

Guck einfach mal mit einem Texteditor rein.

von bonefl@googlemail.com (Gast)


Lesenswert?

Trotzdem weiß ich nicht wie ich da ansetzen soll? Wenn man eine dieser 
Funktion aus der Text Datei einsetzt, sagt LabVIEW diese Funktion wurde 
in der DLL nicht gefunden.

von r_u_d_i (Gast)


Lesenswert?

bonefl@googlemail.com schrieb:
> Trotzdem weiß ich nicht wie ich da ansetzen soll? Wenn man eine dieser
> Funktion aus der Text Datei einsetzt, sagt LabVIEW diese Funktion wurde
> in der DLL nicht gefunden.

Wie musst du die DLL einbinden?
Gibt es da sowas wie:
Name der DLL:
und du musst da was eintragen?

Meist - so kenn ich das aus anderen Programmen,
stellt man einen doppelten Doppelpunkt dahinter, ( NAME.DLL::Funktion ) 
und dann folgt die funktion.

Die Pas Datei hat mehrere Funktionen, u.a. scheint es eine DLL für das 
Flashen zu sein und kommuniziert mit dem Bootloader.
Die Dll unterstütz Encrypting und Decrypting - zumindest geht das aus 
den Namen der Prozeduren und Funktionen hervor.

Es stehen dir auf den ersten Blick zwei funktionen parat, auf die du 
Zugriff hast aus der DLL.
1
function OpenCOM(const Port: WideString; const Application: IApplication): ICOM; stdcall; external 'AVRootloader.dll';
2
function OpenAVRootloader(const Application: IApplication): IAVRootloader; stdcall; external 'AVRootloader.dll';

OpenCom
OpenAVRRootloader

Schauh dir mal die PAS an, du weisst ja am besten, was du mit der DLL 
machen willst, sonst hättest du diese nicht.

Oder weisst du nicht, wie man die DLL in LabView  generell einbindest?
Es geht leider nicht eindeutig hervor,
"Die DLL ist in Delphi geschrieben und damit kenne ich mich leider nicht 
so aus" ob Delphi oder das Einbinden selbst das Probem ist, sorry wenn 
ich den Nagel nicht auf den Kopf traf und dir weiterhilft.

lg
rudi ;-)

von r_u_d_i (Gast)


Lesenswert?

@bonefl

sorry hab das Bild noch gar nicht gesehen.
Da steht alles drin, name der Funktion passt schon mal.
Jetztbraucht es die Parameter..void kann nicht zutreffen
.

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

mach mal ein Bild von  Parameter und Callback.
Was kann man da eintragen?
..
Schauh dir mal das Bild an.

von Florian B. (dabone_206)


Lesenswert?

r_u_d_i schrieb:
> @bonefl
>
> Jetztbraucht es die Parameter..void kann nicht zutreffen
> .

Was muss ich denn für einen Datentyp für "const Application: 
IApplication" an die Funktion übergeben?

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

kannst du bitte von Parameter und Callback ein Bild machen?

Das PAS File ist ein QuellCode.
Das könntest du im Lazarus zu einer Exe compilieren.

Die DLL Datei, die ist die Library dazu.


Es gibt sehr viele Parameter ;-)

..

von Florian B. (dabone_206)


Angehängte Dateien:

Lesenswert?

r_u_d_i schrieb:
> kannst du bitte von Parameter und Callback ein Bild machen?
>
Hier die Screenshots. Das sieht ja schon mal gut aus :) ist das Delphi?

von Florian B. (dabone_206)


Lesenswert?

Ach sorry nicht Delphi sondern Lazarus...

von r_u_d_i (Gast)


Lesenswert?

Hi Flo

du solltest dich erst mit den Funktionen und Umfang vertraut machen
und dann in LabView einbinden, so weist du dann auch,
in welcher Reihenfolge die Funktionen aus der LIB geladen werden sollen.

Denn die Pas ist für eigene Programmentwicklung und kein Header -
wenn man in Delphi / Lazarus eine Anwendung schreibt, kann man die 
"UNIT" einbinden und auf die Funktionen der Unit selbst sowie auf die 
beiden Funktionen, die aus der DLL eingebunden werden zugreifen.

Es scheint, es handelt sich um Hagens AVRRootloader ;-)


Beitrag "AVR-Bootloader mit Verschlüsselung"

AVRootloader

- unterstützt alle selbstprogramierbaren 8Bit-AVRs
- 1-Wire und 2-Wire RS232 Modus, invertierbar
- Baudraten je nach XTAL von 600 bis zu 256000 Baud per USB-RS232
- XTEA Verschlüsselung für FLASH/EEPROM Schreiben
- 16Bit CRC für die komplette Datenübertragung, Senden & Empfangen
- FLASH schreiben/löschen mit implizitem Verify
- separates FLASH Verify
- EEPROM schreiben/lesen, schreiben mit implizitem Verify
- SRAM schreiben/lesen
- Baudrate Detektion, Baudrate kann aber auch fest eingestellt werden
- WatchDog Unterstützung
- fertige PC-Software mit HEX-Editoren für EEPROM & SRAM/Registerfile/IO
Ports
- ATmega128 bei 115200 Baud in 16 sec mit Verschlüsselung 22 Sekunden
- im ZIP Datei AVRootloader.txt enthält Anleitung
- je nach Konfiguration zwischen 344 bis 906 Bytes Codegröße, letzters
mit XTEA Entschlüsselungsfunktion


mach dich erst ein bisschen Schlau darüber, das erleichtert dir den 
Umgang mit den Funktionen und deren Ablauffolge später.

Hoffe es hat ein wenig weitergeholfen.

lg
rudi ;-)

von Florian B. (dabone_206)


Lesenswert?

r_u_d_i schrieb:

> Es scheint, es handelt sich um Hagens AVRRootloader ;-)
>
>
> Beitrag "AVR-Bootloader mit Verschlüsselung"
>
> AVRootloader

Erstmal Danke du hast mir schon mal ein großes Stück weitergeholfen. 
Genau ich möchte den AVRootloader von Hagen gerne in LabVIEW 
integrieren.

Hab mir jetz auch erstmal Lazarus heruntergeladen und werde mich jetzt 
mal bischen in Objektorientierte Programmierung einarbeiten. Vllt finde 
ich dann auch heraus wie ich das ganze in LabVIEW bringe...

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

Hi Flo

schauh das mal an:
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"

auszug von Hagen:
"
Ja, das geht. Der Bootloader relevante Teil befindet sich auch in der
AVRootloader.dll. Du kannst diese DLL in deine Delphi Anwendung
einbinden, das sähe so aus wie im Attachment gezeigt.

Als erstes entpackst du diese ZIP zb. nach c:\programme\atmel\ mit
Ordnern. Dann startest du Delphi und öffnest das Project1.dpr im Pfad
..\AVRootlaoder\Test DLL\. Darin zeige ich wie man die AVRootloader.dll
über die Unit AVRootIntf.pas benutzen könnte. Ist alles auf ein Minimum
reduziert damit man die Funktionweise besser sehen kann. Im Grunde für
ein bischen erfahrenen Laien echt einfach.

Du benötigst später deine EXE, die AVRootloader.dll, AVRootloader.dev
und die von dir compilierte *.ACY Datei zu deiner *.HEX und *.EEP Datei.
Eine ACY Datei enthält das HEX für den FLASH (Programm) wie auch die
EEPROM Daten aus der *.EEP Datei wenn man das möchte. Die Daten im ACY
sind natürlich mit dem Paswort und XTEA verschlüselt. Im DEMO prjekt
kannst du solch eine ACY Datei ezeugen lassen und sie dann
Programmieren.

Die AVRootloade.asm habe ich so angepasst das sie für einen ATmega162 im
1-Wire-RS232 mit sicherer Verschlüsselung arbeitet. Das musst du an
deine Bedürfnisse anpassen, steht aber in der Readme drinnen wie und
was. Das Test.hex das ich mitliefere ist für einen ATmega162.

Ich würde das DEMO an deiner Stelle also soweit reduzieren das man nur
noch den "Program" Button hat. Eventuell sogar ganz ranehmen und die
Aktion gleich nach dem Start der Anwendung ausführen. Mit der normale
PC-Bootloader-Software im Ordner \AVRootloader\Windows\ kannst du nun
deine  *.ACY Dateien verschlüsselt erzeugen und sie dann mit deinem
Program in den AVRladen lassen. Also alles wie die Buttons "Connect",
"Erase", "Compile" raus. Die Methoden .GetACYFileName und
.GetEEPROMFileName liefern immer '' zurück. Nur die Methode
.GetFLASHFileName gibt den Namen deiner *.ACY Datei zurück
"


und der Anhang der dabei war. Der ist aber nicht der letzte Stand.
Der Thread ist auch sehr lang ;-)
Damit wirst du einige Zeit beschäftigt sein ;-)..

Du kannst Lazarus oder Delphi nehmen
Im Buch "Delphi for kids" gab es das Delphi 3 professional mal dazu, das 
war sehr günstig, eine Neuauflage beinhaltet Delphi 7 personal.

lg

rudi ;-)

von Bernd K. (prof7bit)


Lesenswert?

Das ist keine normale DLL, das ist eine DLL die Microsoft-COM Interfaces 
exportiert, also ohne Not extra kompliziert gemacht, bis hin zur 
Unbenutzbarkeit, natürlich auch ohne jegliche Doku :-(

Mit Lazarus/FPC kannst Du das übrigens knicken, obwohl es gemäß 
Delphi-Kompatibilität theoretisch funktionieren müsste (und ich weiß 
definitiv daß FPC sehr wohl auf COM-Objekte zugreifen kann, hab ich 
selbst schon mehrmals gemacht) scheint da ausgerechnet mit dieser einen 
DLL irgendwas schiefzulaufen es crasht irgendwo beim Reference-Counting, 
ich konnte nicht ergründen ob das die Schuld von FPC oder die Schuld von 
Delphi oder die Schuld von Hagen ist und hab dann irgendwann entnervt 
aufgegeben.

Es wird wahrscheinlich schneller gehen und weniger Nerven kosten einen 
neuen vernünftigen und ordentlich dokumentierten Bootloader samt Client 
von null an aus dem Boden zu stampfen als das proprietäre 
AVRootloader-Ding vernünftig automatisierbar und integrierbar zu machen.

Als Notbehelf kannst Du Dir ja mal die Kommandozeilenoptionen des 
GUI-Clients anschauen, diese in Verbindung mit einer automatisch 
erzeugten .ini-Datei erlauben es zumindest einen Wrapper um die .exe zu 
bauen der das Ding halbwegs steuern kann, nicht besonders elegant aber 
immerhin zumindest überhaupt irgendwie.

von r_u_d_i (Gast)


Lesenswert?

Bernd K. schrieb:
> Das ist keine normale DLL, das ist eine DLL die Microsoft-COM Interfaces
> exportiert, also ohne Not extra kompliziert gemacht, bis hin zur
> Unbenutzbarkeit, natürlich auch ohne jegliche Doku :-(

Dann nimm die Com Schnittstelle aus der Implementierung und generiere 
die Schnittstelle mit eigenen Mitteln.


>
> Mit Lazarus/FPC kannst Du das übrigens knicken,

Sorry da widerspreche ich dir aber gewaltig :)
Scheint so, dass du das noch nie probiert hast, sonst schriebest du 
sowas nicht.

Die Vorgehensweise dabei, das Interface gleich als Projektcode verwenden 
und nach Geschmack die GUI anlegen.

> ich konnte nicht ergründen ob das die Schuld von FPC oder die Schuld von
> Delphi oder die Schuld von Hagen ist und hab dann irgendwann entnervt
> aufgegeben.

.. deswegen, aha ..

>
> Es wird wahrscheinlich schneller gehen und weniger Nerven kosten einen
> neuen vernünftigen und ordentlich dokumentierten Bootloader samt Client
> von null an aus dem Boden zu stampfen als das proprietäre
> AVRootloader-Ding vernünftig automatisierbar und integrierbar zu machen.

Viel Spass ;-)

>
> Als Notbehelf kannst Du Dir ja mal die Kommandozeilenoptionen des
> GUI-Clients anschauen, diese in Verbindung mit einer automatisch
> erzeugten .ini-Datei erlauben es zumindest einen Wrapper um die .exe zu
> bauen der das Ding halbwegs steuern kann, nicht besonders elegant aber
> immerhin zumindest überhaupt irgendwie.

Frech nachgefragt:
Und du meinst, dass dieser GUI-Client dann keine Fehler machen kann wenn 
es an der Microsoft-COM Interfaces liegen sollte?...


etwas genervt, solche Post kommen dann von denen Leuten, die selber 
keine PC Software schreiben können, aber auf den anderen rumhacken, was 
alles schecht ist. Dann hättest du ja Zeit von 2008 bis 2015 genug 
gehabt
-> Delphi zu lernen
-> von Grund auf neu zu bauen

Warum ist da nichts passiert?

ha ha ha bernd ;-)

rudi ;-)

von r_u_d_i (Gast)


Lesenswert?

Bernd K. schrieb:
> Das ist keine normale DLL, das ist eine DLL die Microsoft-COM Interfaces
> exportiert, also ohne Not extra kompliziert gemacht, bis hin zur
> Unbenutzbarkeit, natürlich auch ohne jegliche Doku :-(

lesen kannst du hoffentlich noch ;-)
abgeschrieben, können buchstaben fehler drin sein:
1
function TForm1.OpenCommunication: ICOM;
2
// hier könnte ein eigenes ICOM Interface erzeugt werden mit dem 
3
// der Bootloader dann arbeitet. Dieses eigene Interface kann dann auf
4
// beliebige Hardware zugreifen, z.B. USB Geräte etc.ppp.
5
begin
6
Result := AVRootIntf.OpenCOM('\\.\COM2',Self);
7
// setze Baudrate
8
 Result.SetParams(115200);
9
end;

..

guads nächtle
;-)
..

von Bernd K. (prof7bit)


Lesenswert?

r_u_d_i schrieb:
> Frech nachgefragt:
> Und du meinst, dass dieser GUI-Client dann keine Fehler machen kann

Offensichtlich funktioniert er ja, oder? Kompiliere jedoch das 
Delphi-Beispiel mit FPC 2.6.x und es wird crashen beim Connect. Probiers 
aus! Jetzt!

Wenn Du mir sagst warum es crasht hast Du meine Anerkennung verdient.

Ich habe Hagen gefragt, er konnte nichts sachdienliches dazu sagen. Ich 
hab den Delphi-Quelltext der besagten DLL selbst ausgiebig studiert, mir 
ist kein offensichtlicher Fehler aufgefallen, es crasht tief in der FPC 
RTL, leider konnte ich die DLL selbst mangels Delphi nicht mit 
Debugsymbolen übersetzen, ebensowenig kann man die DLL mit FPC bauen 
weil sie ein einziges Konglomerat aus haarsträubenden Inkompatibilitäten 
und Delphi-Only Verstrickungen, lustig gemischt mit kurzen Einwürfen von 
x86 Inline Assembler ist. Also was hätt ich machen sollen?

Vielleicht hätt ichs noch mit C++ probieren können aber zu diesem 
Zeitpunkt war ein anderer Entschluß bereits ausgiebig gereift: Weg 
damit! Hatte eh neue Anforderungen an einen Bootloader und in Zukunft 
auch andere Controllerarchitekturen.

Ansonsten ist Dein herablassender Tonfall nicht gerechtfertigt, Du 
kannst mir auch nicht aus dem Bauch heraus Versäumnisse oder 
Unfähigkeiten unterstellen von denen Du keine Kenntnis hast, aber das 
ignoriere ich jetzt mal einstweilig, großzügig wie ich bin.

von r_u_d_i (Gast)


Lesenswert?

Bernd K. schrieb:
> Wenn Du mir sagst warum es crasht hast Du meine Anerkennung verdient.

DTR?

> Ansonsten ist Dein herablassender Tonfall .......
> aber das ignoriere ich jetzt mal einstweilig, großzügig wie ich bin.

oh ja der herablassene Tonfall - du scheinst darin geübt zu sein..
aber nicht mit delphi, asm und debuggen

..

von Bernd K. (prof7bit)


Lesenswert?

r_u_d_i schrieb:
> Bernd K. schrieb:
>> Wenn Du mir sagst warum es crasht hast Du meine Anerkennung verdient.
>
> DTR?

Ach so, Du hast keine Ahnung worüber wir hier überhaupt sprechen. Sag 
das doch gleich.

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

Bernd K. schrieb:
> r_u_d_i schrieb:
>> Bernd K. schrieb:
>>> Wenn Du mir sagst warum es crasht hast Du meine Anerkennung verdient.
>>
>> DTR?
>
> Ach so, Du hast keine Ahnung worüber wir hier überhaupt sprechen. Sag
> das doch gleich.


Du bist ein Quacksalber Bernd, nichts weiter,
ein gelangweilter am Sonntag Morgen um 2:48.


anbei deine erste Behauptung

> Mit Lazarus/FPC kannst Du das übrigens knicken,


ist Geschichte innerhalb 1 Minute

Anbei das Hagen Projekt in Lazarus:
FPC 2.6.x projekt

Wenn du das nächste mal Probleme hast,
ein simples Delphi Projekt in FPC zu überführen,

Du musst den Cross Compile hacken deaktivieren
Du musst import wählen
und du musst am Com Port die Einstellung abändern.
Sowas nennt sich : Com Port

der einzige der keinee Ahnung von etwas hat -
..spare ich mir jetzt.

Für dich hab ich das jetzt nicht gemacht,

Florian kann genau da ansetzen mit dem Projekt.

Und du dich auslachen lassen,
denn da stand von dir:


> Mit Lazarus/FPC kannst Du das übrigens knicken,


..

von r_u_d_i (Gast)


Lesenswert?

Und jetzt lass mal dein Lazarus / FPC Projekt sehen, indem es angeblich 
crashen soll. Vieleicht kannst du ja von einem Ahnungslosen etwas 
lernen.

Aber ich zweifle stark, dass es da überhaupt etwas von DIR gibt.
Sonst hättest DU gewusst über was ICH hier Rede "DTR", Quacksalber.

..

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

Bernd K. schrieb:
> r_u_d_i schrieb:
>> Bernd K. schrieb:
>>> Wenn Du mir sagst warum es crasht hast Du meine Anerkennung verdient.
>>
>> DTR?
>
> Ach so, Du hast keine Ahnung worüber wir hier überhaupt sprechen. Sag
> das doch gleich.



SIGSEGV ( 125278 )


Für dich zur Erklärung:
1
int main(void)
2
{
3
    int *ptr = (int *) 0; // Zeiger auf die Speicheradresse 0
4
    *ptr = 0; // Schreibe 0 in die gespeicherte Adresse.
5
    // Dieser Speicherbereich gehört jedoch nicht zum Programm
6
    // und ist deshalb "geschützt" (daher Schutzverletzung).
7
    return 0;
8
}

Pass die ICOM selber an.

Jetzt geh hausieren damit.

Und den Quelltext der DLL hätte ich gerne einmal gesehen,
denn du so ausgiebig studiert hast, nicht den der Beipspiel Interface 
pas Datei.


..

von r_u_d_i (Gast)


Lesenswert?

@Flo
Beim ICOM anpassen hilft dir:

http://wiki.freepascal.org/Hardware_Access/de

1
procedure RS232_connect;
2
  var
3
     ser: TBlockSerial;
4
  begin
5
       ser:=TBlockSerial.Create;
6
       try
7
          ser.Connect('/dev/ttyUSB0');
8
          Sleep(1000);
9
          ser.config(1200, 7, 'N', SB1, False, False);
10
          Write('Device: ' + ser.Device + '   Status: ' + ser.LastErrorDesc +' '+
11
          Inttostr(ser.LastError));
12
          Sleep(1000);
13
          repeat
14
                Write(IntToHex(ser.RecvByte(10000), 2), ' ');
15
          until keypressed;
16
       finally
17
              Writeln('Serielle Schnittstelle wird freigegeben...');
18
              ser.free;
19
              Writeln('Serielle Schnittstelle erfolgreich freigegeben!');
20
       end;
21
  end;

..

von r_u_d_i (Gast)


Lesenswert?

@Flo

Noch eins bevor ich Feierabend mache:
Berücksichtige unter welchem OS u FPC benutzt und für welche 
Zielplattform das Prog sein soll.

1
uses
2
 Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs, ExtCtrls,
3
4
{$IFDEF WIN32}
5
  Windows;
6
{$ENDIF}
7
8
{$IFDEF Linux}
9
  ports;
10
{$ENDIF}

1
{$IFDEF Linux}
2
function ioperm(from: Cardinal; num: Cardinal; turn_on: Integer): Integer; cdecl; external 'libc';
3
{$ENDIF}


1
{$IFDEF Unix}
2
Uses Clib;   // retrieve libc library name.
3
{$ENDIF}
4
5
{$IFDEF Unix}
6
function ioperm(from: Cardinal; num: Cardinal; turn_on: Integer): Integer; cdecl; external clib;
7
{$ENDIF}

Empfehle dir Synapse anzusehen:
http://synapse.ararat.cz/doku.php

das steht aber alles in der Wiki drin.

Feierabend.

lg
;-)

von Florian B. (dabone_206)


Lesenswert?

Bernd K. schrieb:

> Als Notbehelf kannst Du Dir ja mal die Kommandozeilenoptionen des
> GUI-Clients anschauen, diese in Verbindung mit einer automatisch
> erzeugten .ini-Datei erlauben es zumindest einen Wrapper um die .exe zu
> bauen der das Ding halbwegs steuern kann, nicht besonders elegant aber
> immerhin zumindest überhaupt irgendwie.

Hallo Bernd,
momentan sprech ich den AVRootloader über die Kommandozeile an. Das 
ganze funktioniert auch super! Aber es sieht halt immer unsauber aus 
wenn in meinem Programm irgendwelche anderen Programme aufploppen.

@Rudi:
Vielen dank das du mir schon mal so ein Beispielprojekt erstellt hast, 
werde mir dies jetz mal genauer anschauen

LG Flo

von r_u_d_i (Gast)


Lesenswert?

Florian B. schrieb:
> Vielen dank das du mir schon mal so ein Beispielprojekt erstellt hast,
> werde mir dies jetz mal genauer anschauen

Hi Flo,

vergiss die dll nicht in den Ordner zu kopieren, wo die exe dann steht.

Wenn du ICOM umbaust, reicht es nicht, nur in Unit1.pas
1
function TForm1.OpenCommunication: ICOM;
2
// hier koennte ein eigenes ICOM Interface erzeugt werden mit dem
3
// der Bootlaoder dann arbeitet. Dieses eigene Interface kann dann auf beliebige
4
// Hardware zugreifen, zb. USB Geraete etc.ppp.
5
begin
6
  Result := AVRootIntf.OpenCOM('\\.\COM2', Self);
7
// setze Baudrate
8
  Result.SetParams(115200);
9
end;

umzuschreiben. Du musstest auch in der AVRootInfc.pas das komplette ICOM 
anpassen:
1
type
2
  // RS232 encapsulation of windows COM port
3
  TCRCFlag  = (crcReset, crcSend);
4
  TCRCFlags = set of TCRCFlag;
5
6
  ICOM = interface
7
    procedure Flush; stdcall;
8
    procedure Purge; stdcall;
9
10
    procedure SetTimeout(Value: Cardinal; const ProcName: WideString = ''); stdcall;
11
    procedure SetParams(Baudrate: Cardinal; Parity: Byte = NOPARITY; Databits: Byte = 8; Stopbits: Byte = ONESTOPBIT; const ProcName: WideString = ''); stdcall;
12
    procedure SetEchoMode(Value: Bool); stdcall;
13
    function  EchoMode: Bool; stdcall;
14
15
    procedure SetDTR(Value: Bool); stdcall;
16
    procedure SetRTS(Value: Bool); stdcall;
17
    procedure WriteData(Buffer: Pointer; Size: Integer; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
18
    procedure WriteByte(Value: Byte; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
19
    procedure WriteChar(Value: Char; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
20
    procedure WriteWord(Value: Word; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
21
    procedure WriteLong(Value: Cardinal; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
22
    procedure WriteCRC(const ProcName: WideString = ''); stdcall;
23
    procedure ResetCRC; stdcall;
24
25
    procedure ReadData(Buffer: Pointer; Size: Integer; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
26
    function  ReadByte(Flags: TCRCFlags = []; const ProcName: WideString = ''): Byte; stdcall;
27
    function  ReadChar(Flags: TCRCFlags = []; const ProcName: WideString = ''): Char; stdcall;
28
    function  ReadWord(Flags: TCRCFlags = []; const ProcName: WideString = ''): Word; stdcall;
29
    function  ReadLong(Flags: TCRCFlags = []; const ProcName: WideString = ''): Cardinal; stdcall;
30
    function  ReadCRC(const ProcName: WideString = ''): Bool; stdcall;
31
  end;


unter anderem auch die ganze SetDTR, SetRTS Geschichte, jede 
Schnittstelle arbeitet da anders. Unter Windows ist es nicht immer 
'erlaubt' auf Hardware zu zugreifen. Bei USB, wenn du darauf umstellst, 
achte auf das Timing, AVR verwendet da laut vielen Beiträgen Zeit 
kritische Einstellungen.

Da kann es auch passieren, dass bestimmte Befehle vom Programm dann 
gesendet werden, die kein 'Gehör' oder 'DTR' finden, oder gar die 
Schnittstelle AVR Seitig unterbrochen wird und das Programm mit einer 
Schutzverletzung quittiert.

Für solche Sachen, Fehlermeldungen abfangen, sollte die DLL Datei 
gewappnet sein, nach Aussagen von Bernd ist da nichts merkwürdiges zu 
sehen; er hatte aber keine Delphi Symbole zur Verfügung.

Es kann durchaus sein, dass im DLL Code noch ein Paar Fehler stehen,
der SRC steht aber leider nicht im Netz oder zumindest habe ich ihn 
nicht gefunden; Bernd hat eine Ausfertigung nach seinen Kommentaren 
anscheinend.

Wenn Bernd den SRC der DLL mir zukommen lässt, geschwaige überhaupt noch 
mit mir kommuniziert ;) , dann würde ich mal reinschauhen.

Hagi (Programmer von AVRootloader) ist schon einer der oberen Elite und 
seit ich denken kann, Pascalianer mit Leib und Herz und einer der 
wenigen, die einem "nervend" aber ausführlich erklären können und dies 
auch tun, wie was funktioniert, wenn man nachfragt. Schade das er sich 
etwas zurückgezogen hat, man kann es ihm aber nicht übel nehmen, man 
erntet meist Hohn bis Häme als Lohn. Er ist auch einer der wenigen die 
'harrstreubende' Technik beherschen, und ist an Optimierung im SRC durch 
ASM Inlines Meister seines Fachs, -> nicht nur meine Meinung. Andere 
wiederum bemängeln dies durch Unleserlichkeit des Code.

Warum das AVRootLoader Projekt so aprubt geendet hat, kann ich dir 
leider nicht sagen. Anscheinend kann Bernd 'ein bissal' oder auch etwas 
mehr, Lazaraus / FPC, auf der Linux Basis, zumindest gibt es ähnliches 
an  Nachkommen für Debian unter Linux FPC.

Gleichwertiges wie AVRootLoader kenne ich leider nicht, Peter D. hat 
auch 'irgendetwas' in der Richtung gemacht, und der ist auch einer der 
wenigen, die das Handwerk beherschen. Such mal danach.

Schönen Sonntag und viel Spass beim Umsetzen!
lg
rudi ;-)

von Bernd K. (prof7bit)


Lesenswert?

r_u_d_i schrieb:
> SIGSEGV

Na toll, so weit war ich auch schon.

Du bist schuld daß ich jetzt schon wieder eine Stunde Lebenszeit sinnlos 
in diesen Schrott versenkt habe, in der vagen Hoffnung der Supercoder 
Rudi hätte es auf wundersame Weise zum Laufen bekommen.

Dei gepostetes Projekt erzeugt eine SIGSEGV, allerdings bereits beim 
Aufruf von FLoader.DoConnect, zum Aufruf der OpenCommunication kommt es 
erst gar nicht (ich war damals schon erheblich weiter).

Also hör bitte auf anderer Leute Zeit zu verschwenden wenn Du nichts 
beizutragen hast.

von r_u_d_i (Gast)


Lesenswert?

Bernd K. schrieb:
> r_u_d_i schrieb:
>> SIGSEGV
>
> Na toll, so weit war ich auch schon.

> Du bist schuld daß ich jetzt schon wieder eine Stunde Lebenszeit sinnlos
> in diesen Schrott versenkt habe, in der vagen Hoffnung der Supercoder
> Rudi hätte es auf wundersame Weise zum Laufen bekommen.

Gibe me the src code please ;-)

>
> Dei gepostetes Projekt erzeugt eine SIGSEGV, allerdings bereits beim
> Aufruf von FLoader.DoConnect,

DLL im Ordner?
SIGSEGV Meldung erscheint lediglich im weissem Fenster, das Programm 
stürzt aber nciht ab. Berichtige mich, wenn du unter 'Linux' etwas 
anderes erhälst.


> zum Aufruf der OpenCommunication kommt es
> erst gar nicht (ich war damals schon erheblich weiter).


Ich wäre auch weiter, wenn ich den SRC der DLL hätte.

> Also hör bitte auf anderer Leute Zeit zu verschwenden wenn Du nichts
> beizutragen hast.

Für einen Moment dachte ich, mit Bernd könnte man das neubeleben..
e sbleiibt beim Quacksalber

schade.

Dir auch einen schönen S(ch)on(n)tag

von Bernd K. (prof7bit)


Lesenswert?

r_u_d_i schrieb:
> Wenn Bernd den SRC der DLL mir zukommen lässt, geschwaige überhaupt noch
> mit mir kommuniziert ;) , dann würde ich mal reinschauhen.

Das würd ich gerne veröffentlichen, allein schon als lehrreiches 
Anti-Beispiel, darf es aber leider nicht aus lizenzrechtlichen Gründen, 
ansonsten käme ich mit Sicherheit ich in Teufels Küche.

Nur soviel sei gesagt: Angesichts des doch recht überschaubaren 
Funktionsumfangs des Protokolls (welches man auch ohne Probleme aus dem 
asm code und notfalls auch Protokollmitschnitten ermitteln kann) wäre es 
zehn mal einfacher den PC-Client komplett from scratch neu zu entwickeln 
als zu versuchen ausgerechnet diesen Code weiterzupflegen oder 
überhaupt erstmal in eine menschenlesbare Form zu überzuführen.

Du willst also den Code überhaupt nicht sehen. Und ich übrigens will 
ihn auch schon lange nicht mehr sehen.

von Bernd K. (prof7bit)


Angehängte Dateien:

Lesenswert?

r_u_d_i schrieb:
>> Du bist schuld daß ich jetzt schon wieder eine Stunde Lebenszeit sinnlos
>> in diesen Schrott versenkt habe, in der vagen Hoffnung der Supercoder
>> Rudi hätte es auf wundersame Weise zum Laufen bekommen.
>
> Gibe me the src code please ;-)

Bitte schön.

Komplettes Projekt gezippt, hab noch nicht mal clean gemacht, also ist 
sogar noch meine .exe mit drin. Lazarus/FPC aktuelle Release-Version von 
heute (1.4.2 / 2.6.2 / 32 bit).

Anschließend können wir uns noch darauf einigen welche Version der 
AVRootInf.pas (die von Hagen oder die von Dir oder die aus Post1) oder 
welche der gefrühlt 42 in Umlauf befindlichen Versionen der DLL 
überhaupt verwendet werden sollen.

Ich verwende übrigens natürlich Windows 7 für dieses Experiment und kein 
Linux (wie kommst Du auf diese Idee?) denn die dll und Hagens 
abenteuerliche serielle Komponente (und auch manch anderer Kram da drin) 
ist durch und durch für Windows-x86 gemacht und mit wine wirds wohl kaum 
laufen wenns schon unter Windows nicht geht.

von r_u_d_i (Gast)


Lesenswert?

@Hagi
@negaH
@Hagen

erbarme dich meiner
und seiner
und gib deiner
erlaubnis uns kund

am besten aus reiner
quell deiner
src und feiner
gesprochener mund.


;-)

Rul Wagner ( entwicklerforum )
rudi ;-) ( µC.net )
..

;-)

von Bernd K. (prof7bit)


Lesenswert?

Bernd K. schrieb:
> heute (1.4.2 / 2.6.2 / 32 bit).

sorry, meinte natürlich:

1.4.2 / 2.6.4 / 32bit

von r_u_d_i (Gast)


Lesenswert?

Bernd K. schrieb:
>
> Bitte schön.

Dankeschön.

> Anschließend können wir uns noch darauf einigen welche Version der
> AVRootInf.pas (die von Hagen oder die von Dir oder die aus Post1) oder
> welche der gefrühlt 42 in Umlauf befindlichen Versionen der DLL
> überhaupt verwendet werden sollen.

Der letzte gepostete Stand von Hagen aus dem Monster Thread?


> Ich verwende übrigens natürlich Windows 7 für dieses Experiment und kein

Ok, da sind wir uns dann wenigstens einig.
Hier läuft auch Win7/64 und auch WinXPSp3.

> Linux (wie kommst Du auf diese Idee?)

Irgendwo im Netz stand Debian und PackAPP und Crypto ;-)

> denn die dll und Hagens
> abenteuerliche serielle Komponente (und auch manch anderer Kram da drin)
> ist durch und durch für Windows-x86 gemacht und mit wine wirds wohl kaum
> laufen wenns schon unter Windows nicht geht.

Gedownloadet, denke heute spät Abend mal kurz, die nächsten Tage etwas 
länger komme ich dazu, werde mal reinschauhen, was geht und was nicht 
oder an was es liegen könnte. In jedem Fall werd eich dem Monster Thread 
erstmal durchlesen :)

..
Grüsse an Hagi

;-)

von r_u_d_i (Gast)


Lesenswert?

Bernd K. schrieb:
>
> Bitte schön.
>
> Komplettes Projekt gezippt, hab noch nicht mal clean gemacht, also ist
> sogar noch meine .exe mit drin. Lazarus/FPC aktuelle Release-Version von
> heute (1.4.2 / 2.6.2 / 32 bit).

Zu früh gefreut.
Den SRC der DLL hast du nicht als pas?


- sicher konnte ich bis heut abend nicht warten -
aber jetzt - bin schon 39 minuten über der Kuchenzeit ;-)

..

von Florian B. (dabone_206)


Lesenswert?

Hallo ihr beiden.
Hätte ja nie gedacht das ich mit diesem Thread so reges interesse wecke 
;)
Aber was habt ihr jetzt eigtentlich genau vor, so das ich es auch 
verstehe?
Wollt ihr die DLL so weit kompatibel machen, so das ich diese auch in 
LabVIEW verwenden kann?

lg Flo

von Bernd K. (prof7bit)


Lesenswert?

r_u_d_i schrieb:
> Zu früh gefreut.

Ich dachte Du willst Dein Beispiel in dem Zustand in dem es bei mir 
Crasht.

> Den SRC der DLL hast du nicht als pas?

Doch, hab ich, aber ich darfs nicht posten, ich habe keine Rechte daran, 
ich bekomm den Kopf abgerissen wenn ich das tue :-(

Ich bin mir noch nichtmal mehr 100% sicher ob ich überhaupt noch jemals 
im Leben eine freie Reimplementierung davon schreiben und 
veröffentlichen darf, jetzt nachdem ich durch den Einblick in die 
Innereien nachweislich kontaminiert bin :-(

von Bernd K. (prof7bit)


Lesenswert?

Florian B. schrieb:
> Aber was habt ihr jetzt eigtentlich genau vor, so das ich es auch
> verstehe?

Die DLL von FPC-code aus nutzbar zu machen (oder wenns nicht anders geht 
vielleicht stattdessen auch mit C++). Daraus könnte man dann auch eine 
kleine Wrapper-DLL bauen die die ganze Funktionalität mit einem flachen 
C-API (anstelle von Microsoft-Component-Object-Model-Interfaces die man 
zu allem Überdruss in diesem Falle auch noch selbst implementieren 
können muss) exportiert.

Mit einem flachen C-API könnte man sie dann praktisch überall und 
ziemlich direkt verwenden und nicht nur dort wo man zufällig auch in 
vollem Umfang mit COM umgehen kann.

: Bearbeitet durch User
von r_u_d_i (Gast)


Lesenswert?

zeitlich passende MPHexEditor.pas irgendwo auf einem Rechner, im Netz?
..

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

Ich verwende mal den letzten Stand, da AVRootloader in Delphi 5 
geschrieben, denke ich brauchen wir eine zeitlich passendere ältere 
Version. Mal sehen. Bin dabei ein neues Delphi Projekt daraus zu machen.
Dann kann man wie Bernd vorgschlagen C++ oder dergleichen weitermachen.
..

von Bernd K. (prof7bit)


Lesenswert?

r_u_d_i schrieb:
> zeitlich passende MPHexEditor.pas irgendwo auf einem Rechner, im Netz?
> ..

Das ging aber schnell. Hast Du ihn erreicht und überredet? Nächste Woche 
kann ich mal nachschauen welche Komponenten da noch gefehlt haben, es 
existiert noch genau ein einziger Rechner auf dem das Dingen noch 
kompiliert werden kann.

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

Bernd K. schrieb:
> r_u_d_i schrieb:
>> zeitlich passende MPHexEditor.pas irgendwo auf einem Rechner, im Netz?
>> ..
>
> Das ging aber schnell. Hast Du ihn erreicht und überredet?

nein, am Sonntag störr eich den Herrn nicht ;-)
- ich hab mir vorrerst mal alles genauer mal angesehen.

> Nächste Woche
> kann ich mal nachschauen welche Komponenten da noch gefehlt haben,

Hauptproblem ist: WideChar Char Sysutils (CharInSet)

Delphi 5
MPHexeditor Pack zu der Zeit finden und dann auch anpassen,
da MPHexeditor nur Delphi 4,6,7.... aber nicht 5
..

> es
> existiert noch genau ein einziger Rechner auf dem das Dingen noch
> kompiliert werden kann.

ich bin gerade dabei, delphi 5 aus dem 'keller' zu holen und mir das 
attached SRC Projekt AVRootloader (mal schnell 'harrsteubend' erarbeitet 
in ASM ;-) )  zu laden, den Fehler zu debuggen, zu finden, zu patchen.. 
und dann wieder mit DE5 compilieren bzw auf FPC zu überführen.

1
main.pas zu gross zum posten daher .attached.

anbei "nur" 10 kleine Fehler im Versuch, mit Delphi 6 zu compilieren, 
ich hab die Enterprise hier legal - damit arbeite ich auch - ( IDE 
Abhängig daher back to root -> Delphi 5 )

weiter:
CharInSet aus der Sysutil.pas ist nicht auf jeder IDE, aber MPHexeditor 
ist damit geschrieben.

ende zwischenstand,
;-)

von r_u_d_i (Gast)


Lesenswert?

CharInSet

type TSysCharSet : char;
1
function  CharInSet(C : AnsiChar; const CharSet : TSysCharSet) : Boolean; overload;
2
function  CharInSet(C : WideChar; const CharSet : TSysCharSet) : Boolean; overload;
3
...
4
function CharInSet(C : AnsiChar; const CharSet : TSysCharSet) : Boolean;
5
begin
6
  Result := C in CharSet;
7
end;
8
9
function CharInSet(C : WideChar; const CharSet : TSysCharSet) : Boolean;
10
begin
11
  Result := (C < #$0100) and (AnsiChar(C) in CharSet);
12
end;

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

Erst mal Sackgasse.
MPHexeditor wird aber für den AVRootloader benötigt.
Mal sehen wie die Woche läuft - jetzt ist erstmal Pause.


https://web.archive.org/web/20071214200414/http://www.mirkes.de/tinyhexer.htm

zitat:

Die Zeit vergeht und Dinge ändern sich...

Nach 25 Jahren Hobbyprogrammierung habe ich ganz einfach das Interesse 
verloren, das ist alles. Wer fragt fremde Leute, warum sie aufhören zu 
kegeln oder Briefmarken zu sammeln? Niemand? Aha... Also werde ich auch 
keine Fragen beantworten, warum ich mit Tiny Hexer und dem Programmieren 
aufgehört habe... Ich denke ich bin hier nichts schuldig (eigentlich 
nicht einmal diese Erklärung), ich habe nie irgendwelche Gegenleistungen 
für meine Programme und Routinen verlangt... Und es ist wie überall: Was 
nix kostet, taugt nix :-D

Q: Warum dieser urplötzliche Sinneswandel?
A: Nun ja, so urplötzlich war der nicht. Ich denke seit mehr als zwei 
Jahren darüber nach, den ganzen Programmierkrempel hinzuwerfen. 
Persönlich benötige ich kaum noch einen Hexeditor, sodass im Laufe der 
Zeit aus dem Hobby eher eine Bürde geworden ist. Und was ist schon ein 
Hobby ohne Spaß dabei? Genau: Blödsinn...

Q: Wird es denn wenigstens noch eine Open Source-Version des letzten 
Tiny Hexers geben?
A: Nein, wird es nicht. Das hat verschiedene Gründe. Tiny Hexer 
verwendet einige Routinen, die ich gekauft habe (Gekauft??? Natürlich, 
warum nicht? Briefmarkensammler kaufen auch ab und an Briefmarken^^) und 
diese kann ich nicht mit Quellen veröffentlichen. So müsste ich also 
erst einmal den Quelltext bereinigen, was wiederum Programmieren 
bedeuten würde... bäh. Ein weiterer Grund: Tiny Hexer ist im Laufe der 
letzten 11 Jahre zu einem unüberblickbaren und nur wenig dokumentierten 
Codedschungel gewachsen (ich war Hobbyprogrammierer, kein Profi!), 
sodass ich eine Menge an Fragen dazu beantworten müsste. Dazu fehlt mir 
aber ganz einfach die Lust...

Q: Und was sind deine neuen Hobbys?
A: Leute vor den Kopf stoßen hrhr

Q: Wie stehen die Chancen, dass Tiny Hexer eines Tages wieder 
aufersteht?
A: 42

Q: Aber woher kriege ich die letzte veröffentlichte Version von Tiny 
Hexer?
A: Hier (aber nur die fette Vollversion).

von r_u_d_i (Gast)


Lesenswert?

btw:
Das war bereits am 14.12.2007
Irgendwo liegt eine MPHexeditor.pas aus dieser Zeit,
die in AVRootloader eingeflossen ist. Denke, dass die
auch etwas angepasst wurde, da diese für Delphi 5
nicht vorgesehen war.

Ok Bernd, erstmal Pause.
Vieleicht sollte man das erstmal ruhen lassen.
Werde aber zeitlich weiter súchen, denke nicht das Hagen noch SRC
aufbewahrt hat. Aber mal sehen. Sind nicht mehr viele Bausteine.

Die Hoffnung stirbt zuletzt

;-)

von r_u_d_i (Gast)


Lesenswert?


von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

..


kann es mit der originalität wieder weitergehen.

BCB-6
Delphi4
Delphi4
Delphi6
Delphi7
Delphi2006
..

@Mods! Legaler Download!
http://www.softpedia.com/get/Programming/Components-Libraries/HexEdit-MS.shtml
und hier verewigt -
mal sehen wann ich die Woche dazukomme.

lg
;-)

von r_u_d_i (Gast)


Angehängte Dateien:

Lesenswert?

@bernd

AVRootloader als kompletter Arbeits SRC anbei als Bild attached,
oben ist die main.pas, weiter unterhab die MSHexeditor Sachen,
die zwingend Vorraussetzung sind - und - die auch jetzt passen.
super vcl ergänzung - warum mirkes aufgehört hat - seine privatsache.
@mirkes danke für MsHexEditor

mit DE6 lässt es sich compilieren, aber wie gesagt, die 10 Fehler in der 
Form ( Delphi 5 ) muss man erst wieder auf De5 zurückbauen. Einfacher 
wird es, das Projekt in De5 zu reparieren, dann auf FPC zu überführen.
Die exe startet aber die Form wird nicht angezeigt, da gleich wieder
geschlossen wird. "onClose"

Mit De5 wird es sich denke ich fehlerfrei compilieren lassen. Meine De5 
CD ist etwas verkrazt, die Installation hängt; muss ich die Woche mal 
sehen, wo ich die De5 legal entleihen/besorgen kann.

so.. ein paar stunden später also, der SRC zum damit arbeiten.

Bernd, wolltest du noch was sagen? ;-)

..

Schöne Woche!

lg
rudi ;-)

von Florian B. (dabone_206)


Lesenswert?

r_u_d_i schrieb:
> @bernd
>
> AVRootloader als kompletter Arbeits SRC

Wow wo hast du den das jetz gefunden ;)

Wenn du noch einen Licence Key auf deiner zerkratzten CD findest dann 
könntest du es hier downloaden..

http://www.nextwap.net/rar/n3xxMgPT/borland_delphi_5_professional.html

Installation funzt bei mir bis zur Key-eingabe.

lg und schönen Sonntag
Flo

von Bernd K. (prof7bit)


Lesenswert?

r_u_d_i schrieb:
> das Projekt in De5 zu reparieren, dann auf FPC zu überführen.

Das wäre begrüßenswert, dann könnte man auch Linux-Binaries davon bauen.

Allerdings wird das nicht einfach werden. Am Ende würde (bei mir 
zumindest) eh erstmal die Hälfte rausfliegen (die gesamte GUI zum 
Beispiel, die sollte man eh komplett separat machen). Als nächstes die 
CRC-Routine in Pascal anstatt in ASM, ohne diesen Unsinn wird sie auch 
nicht langsamer, und zum Schluss noch die serielle Schnittstelle 
plattformunabhängig machen, gibt ja einige fertige Komponenten dafür und 
übrigens fpc 3.0 hat die serial.pp endlich auch für Windows, die kann 
man dann eigentlich auch direkt verwenden. Die Unterstützung fur die 42 
älteren Protokollversionen kann ebenfalls ersatzlos rausfliegen, dann 
wird dieses Gestrüpp etwas übersichtlicher.

Aber ne saubere Reimplementierung from scratch in FPC wäre IMHO immer 
noch schneller zu bewerkstelligen und weniger stressig.

: Bearbeitet durch User
von Georg (Gast)


Lesenswert?

Hallo zusammen,
ich nutze ebenfalls den AVRootloader 6.

Seit Ihr damit schon weiter.....

Ich würde gerne Teile davon in eine eigene Anwendung einbinden. Ich 
benötige auch keine Verschlüssellung.

Ich möchte aus meiner Anwendung heraus lediglich die Eprom Daten 
auslesen.... visualisiert verändern und wieder im EEprom abspeichern, 
ohne das ich die Epromdaten zwischen speicher..... mehr brauche ich 
nicht.

Kann mir da einer weiter helfen auch wenn der Beitrag schon ewig alt ist 
?

DANKE !

von Bernd K. (prof7bit)


Lesenswert?

@Georg:

Da schon private Nachrichten diesbezüglich bei mir eintrudeln:

Ich habe seither (seit Jahren schon) aufgrund geänderter Interessenlage 
leider keine Anstrengungen mehr unternommen am AVRFreeLoader (freie 
Re-Implementierung von AVRootLoader) weiterzuarbeiten, es ist in einer 
sehr frühen Phase schon wieder komplett eingeschlafen, kurz nachdem ich 
damit angefangen hatte begann der Umschwung zu ARM. Ich plane auch auf 
absehbare Zeit da nicht weiterzumachen, ganz einfach mangels 
persönlichem wie beruflichem Interesse oder Verwendung. Ich müsste mich 
sowieso wieder komplett neu reinfuchsen weil schon so viel Zeit 
vergangen ist.

Ich kann leider auch Hagen's alte Delphi-Quelltexte nicht einfach so 
rausrücken ohne seine Erlaubnis, die sind aber allerdings auch nicht 
unbedingt einfach zu verwenden und den Versuch es so wie es ist nach 
FPC/Linux zu portieren hab ich schnell komplett aufgegeben, zuviel 
Windows-Only, zuviel x68-Inline-Assembler, etc.

Ich glaube mit einem Logic-Analyzer fürs Protokoll und einem Blick in 
den AVR-Assemblerquelltext (der ja offenliegt) geht es 10 mal schneller 
und einfacher. Das war damals ja auch mein ursprünglicher Plan. Das 
Protokoll an sich ist eigentlich absolut simpel. Mit nur ein klein wenig 
Verbissenheit (die ich dafür momentan leider nicht mehr aufbringen kann) 
würde es ein Leichtes sein den PC-Client (oder benötigte Teile davon) in 
nicht viel mehr als einem verregneten Wochenende neu zu implementieren!

Wenn ichs nicht vergesse werd ihn morgen mal fragen ob ich seine 
Delphi-Quellen jetzt endlich rausgeben darf, aber ich würde mir da 
erstmal keine verfrühten Hoffnungen machen. Ich kann mich erinnern daß 
ich schon einmal mit ihm darüber diskutiert habe und er hatte Gründe 
warum er das nicht tun wollte, ich weiß allerdings nicht mehr mit 
Sicherheit welche genau das waren und ob die heute immer noch gelten.

Ich würde an Deiner Stelle auch einfach mal versuchen Hagen direkt zu 
kontaktieren und diesbezüglich zu löchern, vielleicht lässt er sich ja 
mit den richtigen Argumenten überreden, er macht heutzutage auch nicht 
mehr viel mit AVR Tiny, dafür hat er jetzt viel ARM-Cortex um die Ohren, 
statt Delphi verwendet er heute Lazarus, statt Windows hat er jetzt 
Linux (sogar freiwillig!), vielleicht trennt er sich ja jetzt endlich 
mal von dem alten AVR-Zeugs und schenkt es der Öffentlichkeit. Er ist 
hier im Forum immer noch zumindest lesend aktiv und sollte also 
erreichbar sein.

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.