|
Anzeige
|
Fehler beim Compilieren
Gast
#2381713
Hallo! Beim compilieren des angehangenem C-Code, bekomme ich die angehangenem Fehler. Egal, ob ich mit win-avr, oder avrstudio5 compiliere. Liegt das Problem möglicherweise bei den Header-Dateien??? Ich habe keinerlei Erfahrung mit C, es ist für mich nur sehr wichtig, von dem C-Code ein Hex File zu bekommen. Bin für jede Hilfe sehr dankbar!!!! Steffen schrieb: > Beim compilieren des angehangenem C-Code Au Sche***e, das benutzt ja alles hornalten Krempel. Du kannst wahrscheinlich die Rückwärtskompatibilität bis zur Jungsteinzeit durch Einbinden von <compat/deprecated.h> erzwingen, aber wenn ich mir all die vielen als `volatile' deklarierten Variablen in diesem Programm zusammen mit dem coding style ansehe, dann würde ich persönlich die Finger davon lassen. Wer weiß, ob dir bei der Ausführung des Codes dann nicht dein Haus angezündet wird oder im Iran eine Rakete gestartet. Wärst du dir da völlig sicher, was beim Ausführen dieses Codes passiert? Der scheint mir gecryptet zu sein.
Gast
#2381728
Hallo Da fehlt eine Datei, wo inp() definiert wird. Deshalb sagt der Linker mit Recht, er würde inp() nicht kennen. Gruß Joachim Nimm mal die Entwicklungsumgebung, mit der dieses schauderbare Stück Spaghetti ursprünglich (2004!!!) compiliert wurde! Die Fehlermeldungen kommen alle vom "Linken Eddy", dem Linker. Bernhard Boah ... :-) Das programm erinnert mich daran, wie ich C gelernt hab (mein allerallerallererstes Projekt). Ich hatte ein BASIC Programm (MS QBASIC), welches natürlich ne ganze Menge Variablen definiert hatte. Das Programm erzeugte mittels Zählern 4 unabhängige PWMs am Parallelport, zur Steuerung von Gleichstrommotoren für einen Laser-Lissajousaufbau. Dann gab es (allerdings wesentlich mehr als hier) Subroutines, die mit "gosub / return" angefahren wurden, und alle auf den globalen Daten rumrödelten. Für ein BASIC Programm eigentlich sehr sauber. Das Programm hab ich dann 1:1 nach C umgesetzt. Variablen alle global, Subroutines als 'void func(void)', print nach printf, usw... Das Programm lief in C, gegenüber dem BASIC, rattenschnell, da compiliert, aber sah in ungefähr genau so grausam aus **grins**
Gast
#2381759
das wird nichts:
da bleibt nach dem optimierer nichts mehr übrig.
Gast
#2381767
Das ist nicht ernstgemeint, oder? Immerhin hilfreich kommentiert:
Nach dem Überfliegen dieses Kots habe ich das Bedürfnis, einen Assemblerprogrammierer zu verprügeln. Und falls ich irgendwann einen riesigen chinesischen Kompressor brauche, fällt ein Lieferant schon mal aus.
Gast
#2381798
Jörg Wunsch schrieb: > Der scheint mir gecryptet zu sein. Da weigert sich ja selbst die Codeansicht des Forums, das überhaupt anzuzeigen ;) Oliver
Gast
#2382642
Erstmal vielen dank für die Kommentare! @Jörg, auch wenns verdammt verwirrt aussieht, bin mir sicher das der Code funktioniert;-) ist für Industriemaschinen die bereits laufen, nur kommt das Programm wie die Maschine aus China, jetzt haben wir den C-code für Änderungen, die vorgenommen werden sollen, nur haperts leider schon am compilieren des Originals. Und die China-Firma gibt uns aus Unternehmenspolitischen Gründen leider keine Infos mehr:-(! Gruß Steffen
Gast
#2382646
Steffen schrieb: > @Jörg, auch wenns verdammt verwirrt aussieht, bin mir sicher das der > Code funktioniert;-) aber vermutlich nur mit dem alten compiler, wenn du jetzt einen neuen verwendest wirken sich die fehler aus. delay_cycles ist auf jeden Fall fehlerhaft, das wird so auf jeden Fall nicht gehen. Hallo, für sbi usw. kannst Du die Makros aus dem folgenden Artikel verwenden: Beitrag "sbi cbi inp / outp im neuen WinAVR- workaround" für eeprom_rb wirst Du wahrscheinlich ebenfalls ein Makro definieren müssen. Aber wie mein Vorredner bereits meinte, ob der Code noch funktionieren wird, steht in den Sternen. Gruß Frank
Gast
#2382866
@Peter: Da wirst du recht haben, versuche mal den alten Compiler zu bekommen. @Frank: Danke für den Beitrag! Frank Link schrieb: > für sbi usw. kannst Du die Makros aus dem folgenden Artikel verwenden: Oder halt <compat/deprecated.h>, wie ich oben schon schrieb.
Gast
#2383512
Danke Jörg, durch Einfügen von <compat/deprecated.h> haben sich die Fehlermeldungen schonmal stark reduziert. Jetzt sind noch folgende Fehler, wie angehangen. Gibts da noch ne Chance? Danke schonmal... @pete, mit aktuellen Compiler wirds wohl so nicht gehen! Dank dir! Ersetze mal deine Funktionsaufrufe bzw. Makros wie folgt BV() -> _BV() eeprom_wb() -> eeprom_write_byte() eeprom_rb() -> eeprom_read_byte() Mit etwas Glück reicht da ein einfaches Suchen und Ersetzen wenn die Funktionsdefinitionen kompatibel sind (ich habe das jetzt nicht überprüft). Bei solchen Aktionen kann man leicht zu viel ersetzen, deshalb ist hier eine Sicherungskopie und ein Difftool wie Winmerge gut um den Überblick zu bewahren, oder noch besser Versionskontrolle. Gruß, Reinhard PS: http://mindprod.com/jgloss/unmain.html ;)
Gast
#2385130
Danke für den Tip Reinhard, werd´ das mal probieren... Gruß Steffen Das alles wird eben nur nicht gegen solche Krücken wie die alten Delay-Schleifen helfen. Dagegen hilft es nur, diese durch saubere Nutzung von _delay_ms() zu ersetzen. Zur Not könnte man probieren, ob sich delay_cycles vielleicht direkt durch _delay_loop_2 ersetzen lässt. Insgesamt bin ich mehr als skeptisch, ob man diesen vermüllten Softwareklumpen mit etwas anderem als der original benutzten Entwicklungsumgebung mit vertretbarem Aufwand zum Laufen bekommt.
Gast
#2391298
@Jörg Nach vielen Versuchen, ist deine Aussage absolut realistisch. Die orig. Entwicklungsumgebung muss her, ansonsten steht der Aufwand in keinem Verhältnis. Danke und Gruss Steffen Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
