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.
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.
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.
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.
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 ;-)
@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
.
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?
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 ;-)
..
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 ;-)
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...
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 ;-)
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.
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 ;-)
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.
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.
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
..
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.
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,
..
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.
..
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
intmain(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
return0;
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.
..
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
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:
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 ;-)
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.
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
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.
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.
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
;-)
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 ;-)
..
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
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 :-(
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.
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.
..
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.
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,
;-)
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).
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
;-)
@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 ;-)
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
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.
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 !
@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.