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.
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**
das wird nichts:
1 | void delay_cycles(unsigned int ddd) |
2 | {
|
3 | unsigned int delay_cyc; |
4 | for(delay_cyc = 1 ; delay_cyc <= ddd ; delay_cyc++); |
5 | }
|
da bleibt nach dem optimierer nichts mehr übrig.
Das ist nicht ernstgemeint, oder? Immerhin hilfreich kommentiert:
1 | #define UART_BAUD_RATE 19200 /* baud rate*/ |
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.
Jörg Wunsch schrieb: > Der scheint mir gecryptet zu sein. Da weigert sich ja selbst die Codeansicht des Forums, das überhaupt anzuzeigen ;) Oliver
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
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
@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.
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 ;)
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.
@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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.