Hallo Gemeinde, hat schon jemand die FFT vom Chan http://elm-chan.org/works/akilcd/report_e.html in das AVR Studio 6 überführt? Wäre super, wenn mir jemand helfen könnte. Gruß Karsten
Vielleicht beschreibst du ja lieber das Problem, welches du mit dem vorhandenen Code bekommst.
Gast
#2729733
Hallo Jörg, das Problem scheint die Mischung aus Assembler und C Code im Header-File zu sein. Beim kompilieren erhalte ich eine Fehlermeldung unknown opcode 'typedef'. Ich poste das AVR Studio Projekt nachher. Aus einer anderen Quelle (siehe Anhang)hatte ich ein FFT-Code als AVR Studio 4 Projekt. Unter AVR Studio 4 geht alles. Importiere ich dieses Projekt in AVR Studio 6 erhalte ich den oben beschriebenen Fehler.Auch hier wird Assembler und C gemischt. Ich vermute, dass die Ursache in beiden Fällen indentisch ist. WinAVR war in beiden Fällen in der aktuellen Version installiert. Gruß Karsten
karsten Brandt schrieb: > Beim kompilieren erhalte ich eine Fehlermeldung > > unknown opcode 'typedef'. Ja, da wird offenbar ein Headerfile mit C-Code versucht, in eine Assemblerquellen einzubinden. Könnte man vermeiden, indem man die relevanten Teile des Headers mit
1 | |
2 | |
3 | |
schützt. > Ich poste das AVR Studio Projekt nachher. Nützt mir nichts, habe kein Windows und damit kein AVR Studio. Du musst dir also schon selbst die Mühe machen, ein paar Details mehr auszugraben. Hinweis: in der Fehlermeldung des Compilers steht eine Zeilennummer. Nachsehen, was an dieser Stelle ist und wie man es korrigieren kann. > Aus einer anderen Quelle Bitte fang' nicht an, "project hopping" zu machen. Du musst dich bemühen, die auftretenden Probleme zu verstehen, danach kannst du sie auch beseitigen. Wegrennen ist keine Lösung.
Gast
#2729924
karsten Brandt schrieb: > unknown opcode 'typedef'. Davor steht ein >#ifndef FFFT_ASM /* for c modules */ und in ffft.c steht >#define FFFT_ASM >#include "ffft.h" Der Assembler sollte das typedef also nie zu sehen bekommen. In der Richtung musst du suchen, warum das nicht funktioniert. Oliver
Es geht wohl höchstwahrscheinlich darum: Beitrag "Re: [C] AVR-Lichtorgel per FFT MEGA8 32 644" Ich habe das Projekt nach Studio6 konvertieren können. mfg
Gast
#2730726
Vielen Dank an alle, die sich hier bemühen. Der Hintergrund dieser Aktion ist, dass ich irgendeinen FFT-Code benötige, um einen Spektrumanalyser in meinem Blinky Ball zu realisieren. Ich möchte den einfach nur benutzen und das Rad nicht neu erfinden. Ob es nun reiner C-Code oder C mit Assembler ist, ist eigentlich egal. Nur unter AVR-Studio 6 solltes der Code zu kompilieren sein. Ich habe natürlich schon im www gesucht und verschiedene Ansätze zum erfolgreichen kompilieren probiert. Von Assembler programmierung habe ich nicht wirklich Ahnung. Ich fühle mich bei den Hochsprachen wohler. @Jörg: habe ich auch schon probiert, aber ohne Erfolg. @Oliver: macht denselben Effekt wie #ifndef _ASSEMBLER_ ... #endif @Lötlackl: Das Projekt war eine Möglichkeit an die FFT zu kommen. Habe das Projekt versucht zu kompilieren, ohne Erfolg. Fehler: unknown type name 'prog_int16_t'. Das muss durch PROGMEM ersetzt werden.Bei erneutem kompilieren kommen die oben beschriebenen Fehler. Natürlich habe ich die Import Funktion schon ausprobiert. Unterm Strich würde ich sagen, dass das AVR Studio 6 für solche Zwecke noch nicht ausgereift ist. Ich werde die FFT wohl in C schreiben. Ist zwar langsamer, führt aber auch zum Ziel. Mich mit der ganzen Assembler Problematik zu befassen (das beschriebene Problem findet man öfters im WEB) bringt mich von meinem eigentlichen Weg zu weit ab. Trotzdem nochmals vielen Dank für Eure Hilfe. Gruß Karsten
Gast
#2730743
karsten Brandt schrieb: > #ifndef ASSEMBLER ... #endif Da gehören jeweils zwei Unterstriche hin.
karsten Brandt schrieb: > @Jörg: habe ich auch schon probiert, aber ohne Erfolg. Dann machst du was Grundlegendes falsch. Da du dir hier aber jede Einzelheit aus der Nase ziehen lässt, kann dir niemand helfen. > Unterm Strich würde ich sagen, dass das AVR Studio 6 für solche Zwecke > noch nicht ausgereift ist. Genau. Wenn man nicht in der Lage ist, eine fix-und-fertige Lösung für das Tool seiner Wahl zu bekommen, dann ist das Tool natürlich Mist. Nein, so wirst du im Leben nicht weiter kommen.
Gast
#2731104
Die toolchain ist nicht mist. Wäre Sie Mist, würde ich Sie nicht benutzen. Ich habe an meinem Blinky Ball noch viele andere Dinge zu tun. Wer im Leben weiter kommen will, konzentriert sich auf das Wesentliche. Da ich im Moment keine Zeit und Lust habe, mich mit Assembler (bzw. mit irgendtwelchen kryptischen Einstellungen des Compilers) zu beschäftigen und mich darin zu verpusseln, nehme ich halt die reine C-Version der FFT. Das bringt mich in meinem Projekt weiter. Ausserdem: Das AVR-Studio ist für eine kostenlose Entwicklungsumgebung sehr gut. Das war auch nicht im Frage gestellt. Aber fehlerfrei ist es eben auch nicht. Meine Frage war, ob jemand die Sachen von Chan schon im AVR Studio 6 an Laufen gebracht hat. -> Die Antwort ist nein. Also Thema erledigt. K.
karsten Brandt schrieb: > Das AVR-Studio ist für eine kostenlose Entwicklungsumgebung sehr gut. > Das war auch nicht im Frage gestellt. Aber fehlerfrei ist es eben auch > nicht. Hier geht es aber nicht um Fehler einer Toolchain oder von AVR Studio, sondern darum, dass man auch von fremden Quelltexten ein Mindestmaß verstehen sollte. Ansonsten passiert es ganz schnell, dass man den größten Stuss, der aus der "Blackbox" (aufgrund bspw. eines Benutzungsfehlers) für bare Münze nimmt. > Meine Frage war, ob jemand die Sachen von Chan schon im AVR Studio 6 an > Laufen gebracht hat. -> Die Antwort ist nein. Weiter oben hat jemand das Gegenteil behauptet. Aber das siehst du ja gleich mal nicht erst, Hauptsache, man kann es auf die Nicht-Fehler- Freiheit von AVR Studio schieben, das kaschiert dann das eigene Unvermögen. Sorry. (Nicht, dass ich denke, dass AVR Studio fehlerfrei wäre, nicht im geringsten. Aber hier sitzt der Fehler vor dem Computer.)
Gast
#2731742
karsten Brandt schrieb: > -> Die Antwort ist nein. Also Thema erledigt. Jetzt habe ich nur für dich doch mal das Studio6 angeworfen (alleine der Start dauerte auf meinem Rechner schon länger, als danach das "Problem" zu lösen). ffft.S assembliert damit ohne Änderungen fehlerfrei. Da du den Rest eh selber schreiben willst, reicht das doch aus. fftest.c lässt sich auch kompilieren, wenn man weiß, wie. Das Problem liegt nicht am Studio 6.0, sondern an der neuen toochain, die zu den alten Programmen nicht mehr kompatibel ist. Dafür kann Atmel eigentlich nichts, das kommt aus der gcc-Ecke. Der Zugriff auf den Flashspeicher hat sich mit den neueren gcc's geändert. Wenn man unbedingt die neuesten Softwaretools nutzen will, muß man mit sowas rechnen. Wie man trotzdem alten Programmcode damit kompilieren kann, steht in der Doku - finden und lesen musst du die (nach deinem "freundlichen" Auftritt hier) selber. ff- viel vergnügen. Oliver
Oliver schrieb: > Der Zugriff auf den > Flashspeicher hat sich mit den neueren gcc's geändert. Wobei das, was vorher funktioniert hat, ein Bug war. Der wurde nur repariert. Dass Objekte im Flash aus Compilersicht als "const" zu behandeln sind, ist eigentlich eine Selbstverständlichkeit.
Gast
#2732067
Jörg Wunsch schrieb: > Wobei das, was vorher funktioniert hat, ein Bug war. Das hinzugefügte const-Attribut ist aber in diesem Fall nicht das Problem. karsten Brandt schrieb: > unknown type name 'prog_int16_t' Das ist sein Problem, und die Lösung dazu steht in der Doku. Oliver
Gast
#2733992
Hallo, ich finde es erstaunlich, wie manche Leute aus einer Mücke einen Elefanten machen. Echt nervig. Bei meinem Setup funktioniert es nicht, das ist Fakt. Ich habe auch nie behauptet etwas von Assembler mit C gemischt zu verstehen. Daher habe ich ja nun hier meine Frage eingestellt. Alles was bisher hier präsenitert wurde, geht eben bei meiner AVR-Studio Installation nicht. @Oliver: Das Problem mit 'prog_int16_t' ist schon längst gelöst. Steht aber oben weiter. Einfach mal lesen hilft. @Jörg: >Genau. Wenn man nicht in der Lage ist, eine fix-und-fertige Lösung >für das Tool seiner Wahl zu bekommen, dann ist das Tool natürlich >Mist. >Nein, so wirst du im Leben nicht weiter kommen. Ich finde es nett, dass Du helfen möchtest. Auf eine Frage mit einem solch unhöflichen Kommentar zu Antworten finde ich etwas gewagt. Zumal Du vom AVR-Studio keine Ahnung hast, wie Du schreibst. >Weiter oben hat jemand das Gegenteil behauptet. Aber das siehst du >ja gleich mal nicht erst, Hauptsache, man kann es auf die Nicht-Fehler- >Freiheit von AVR Studio schieben, das kaschiert dann das eigene >Unvermögen. Sorry. (Nicht, dass ich denke, dass AVR Studio >fehlerfrei wäre, nicht im geringsten. Aber hier sitzt der Fehler vor >dem Computer.) Entschuldige, aber das ist nicht richtig. Ich habe das Projekt von lötlackl heruntergeladen und mit der aktuellen Version vom AVR-Studio 6 kompilliert. Es kam eine Fehlermeldung: C:\Users\KBrandt\Downloads\Lichtorgel_S6 (1)\Lichtorgel_S6\fftest\ffft.h(25,1): unknown type name 'prog_int16_t' Also geht es bei mir nicht. Und die Projekteinstellungen sind wie Sie von Lötlackl gemacht wurden. Auch das importieren von Lötlackl's Ur-Version in AVR-Studio 6 macht dieselben Probleme. Soviel zur Importfunktion vom AVR Studio!!! Bevor Du solch völlig sinnlosen Kommentare abgibst, probiert doch bitte voher selbst das Projekt zu kompillieren. Aber ohne AVR-Studio geht das eben nicht. Ich bin durchaus in Lage, das AVR-Studio mit seiner Toolchain zu bedienen. Daher interessiert mich der Assembler-Mist überhaupt nicht mehr. Mein Ziel ist schneller mit reinem C erreicht. Sorry, dass ich eure wertvolle Zeit verschwendet habe. Thread geschlossen!! Gruß K
Karsten Brandt schrieb: > Ich bin durchaus in Lage, das AVR-Studio mit seiner Toolchain zu > bedienen. Weiß ich nicht. Ich habe mir jetzt das originale elm-chan-Projekt mal geholt und es durch einen aktuellen Compiler gejagt. Ja, das kann ich, ganz ohne dafür ein AVR Studio benutzen zu müssen. ;-) Es kommen, wie bereits beschrieben, dabei Klagen über die nicht mehr bekannten Datentypen "prog_char" und "prog_int16_t". Diese Beschwerden kann man einfach dadurch beseitigen, dass man in den vom Compiler genannten drei Zeilen "prog_char" durch "char" ersetzt und "prog_int16_t" durch "int16_t". Damit lässt sich dann alles mit dem beiliegenden Makefile compilieren. Das Makefile nützt dir vermutlich nichts, da dem Hörensagen nach Atmel Studio 6 kein externes Makefile einbinden kann, aber da du (Zitat) das AVR Studio und seine Toolchain bedienen kannst, sollte es dir wohl nicht schwer fallen, die beiden Assembler- und eine C-Quelldatei sowie zwei Headerdateien in dein eigenes Atmel-Studio- Projekt einzubinden. Ich vermute mal, dass das mit wenigen Mausklicks geht, aber hier kann ich dir wirklich nicht helfen, da ich eben Atmel Studio nicht benutze.
Gast
#2734102
Karsten Brandt schrieb: > Es kam eine Fehlermeldung: > C:\Users\KBrandt\Downloads\Lichtorgel_S6 > (1)\Lichtorgel_S6\fftest\ffft.h(25,1): unknown type name 'prog_int16_t' > Also geht es bei mir nicht. Du hast nichts verstanden, und auch die Doku immer noch nicht gelesen. Das Problem hat nichts mit dem Studio 6 zu tun, und auch nichts mit irgendwelchen Importfunktionen, sondern kommt aus deiner irrigen Annahme, daß uralter Sourcecode für alle Zeiten mit allen zukünftigen Versionen einer toolschain immer kompilierbar bleiben muß. Das ist allerdings ein grober Irrtum deinerseits. Das geht leider nicht, und das wird es auch nie geben. Wenn du die neuesten tools unbedingt verwenden willst, dann muß man mit solchen Problemen rechnen. Du kannst j auch mit WinAVR weiterarbeiten, damit geht es ja ohne Änderungen. Wenn du das Problem mit den nicht mehr vorhandenen typedefs für prog_xxx gelösst hast, und es trotzdem nicht kompiliert, dann hast du halt was anderes falsch gemacht. Denn wie ich schon oben schrieb, beherzigt man die Doku der avr-libc, in der steht: [quote] Note: DEPRECATED This typedef is now deprecated because the usage of the _progmem_ attribute on a type is not supported in GCC. However, the use of the _progmem_ attribute on a variable declaration is supported, and this is now the recommended usage. The typedef is only visible if the macro _PROG_TYPES_COMPAT_ has been defined before including <avr/pgmspace.h> (either by a #define directive, or by a -D compiler option.) [/quote] und fügt die eine Zeile >#define __PROG_TYPES_COMPAT__ hinzu, dann kompilert das ganze Projekt im Studio 6 ohne Probleme. Der bei dir auftreteden "typedef"-Fehler weist darauf hin, das du da bei deinen Reparaturversuchen in den Sourcen was vermurkst hast. Wie schon geschrieben stand, das Problme sitzt in 99% aller Fälle vor dem Rechner. Oliver
Oliver schrieb: > und fügt die eine Zeile >>#define __PROG_TYPES_COMPAT__ Oder eben gleich richtig machen, ich hab' ja geschrieben, was man dafür tun muss.
Danke für die Antwort. Ich habe die Doku für die libc, die Atmel mitliefert, gelesen. In dem PDF findet sich nichts, was auf #define _PROG_TYPES_COMPAT_ Lediglich in den Tiefen der Quellcodedatei ´findet sich der funktionierende Hinweis. Der Compiler gibt C:\Projects\6_Kanal_AVR_Lichtorgel\ffft.h(26,1): unknown type name 'prog_int16_t' aus. Ein Mouseover über die Stelle im Quelltext liedert auch keine Information. Erst wenn man eine neue Variable vom Typ prog_int16_t definiert, gibt es einen Hinweis auf die Lösung. Ich gebe zu, dass ich nicht über so viele Ecken gedacht habe. Ich bin nun um eine Erfahrung reicher. Deshalb nochmal: vielen Dank für Eure Mühe. Abschliessend muss ich zu meiner Schande gestehen, dass ich die komplette Dokumentation der libc noch nicht gelesen habe. Ist auch sehr umfangreich. Und der GNU-Compiler ist eben sehr komplex. Daher bin ich über ein Tool dankbar, dass mir die Erstellung des MAKE-Files abnimmt. Die Unterstützung für C-Programmierer ist beim AVR-Studio schon sehr gut. Auch für Erfahrungswerte wie Eure bin sehr dankbar. Gruß Karsten
Gast
#2734619
Karsten Brandt schrieb: > Lediglich in den Tiefen der Quellcodedatei ´findet sich der > funktionierende Hinweis. Die aktuelle Online-Doku gibts im Netz. Gefunden habe ich die Lösung allerdings auch erst durch ein diff über pgmspace.h zwischen der Atmel- und der WinAVR-Version. Irgend etwas musste da drinn ja anders sein. Oliver
Karsten Brandt schrieb: > Ich habe die Doku für die libc, die Atmel mitliefert, gelesen. In dem > PDF findet sich nichts, was auf > > #define _PROG_TYPES_COMPAT_ Dann musst du dich bei Atmel drüber beklagen, dass sie keine aktuelle Doku mitliefern. Die Doku sollte normalerweise direkt aus den Quelldateien gebaut werden (automatisiert mit einem Tool namens doxygen) und damit auf dem gleichen Stand sein wie die Bibliothek selbst. Offenbar ist dieser Prozess aber dort nicht so abgelaufen. Aber siehe oben, besser als PROG_TYPES_COMPAT wäre es, die drei Stellen einfach zu editieren. > Daher bin ich > über ein Tool dankbar, dass mir die Erstellung des MAKE-Files abnimmt. Im Prinzip ja. Allerdings ist beim elm-chan-Projekt halt schon ein funktionierendes dabei, dessen gesammeltes Wissen musst du beim Einbinden in Atmel Studio 6 komplett neu zusammentragen. (Bei AVR Studio 4 konnte man noch ein externes, bereits vorhandenes Makefile als Alternative benutzen.)
Gast
#3051965
Hallo zusammen, ich bin jetzt auch darüber gestolpert, aber irgendwie komme ich trotz dieses und anderer Hinweise nicht weiter. Die Doku "avr-libc-user-manual" bringt mich leider auch nicht weiter. Ich benutze die CAN-Bibliothek von Fabian G. In dieser enthalten ist u.a. folgender codeabschnitt:
1 | |
Das ist ja jetzt "DEPRECATED" Aber so richtig verstanden habe ich es nicht. In der Doku steht auch: "The typedef is only visible if the macro PROG_TYPES_COMPAT has been defined before including <avr/pgmspace.h>" Ich habe dann mal versuchsweise
1 | |
2 | |
3 | |
4 | |
5 | |
das define vor include eingefügt, aber die Fehlermeldung bleibt. Aber ich kann mir nicht vorstellen, wie ich was ändern muss, damit es auch code-konform ist und so weiterläuft, wie beabsichtigt. So tief stecke ich leider nicht in der Materie und bin auf die Hilfe von Euch angewiesen. Das haben sicher einige vor mir schon hinbekommen, aber ich bekomms nicht hin... :-(
Andreas schrieb: > #include <avr/pgmspace.h> > > prog_char _at90can_cnf[...] > Ein prog_char wurde früher benutzt um uint8_t _at90can_cnf[...] PROGMEM; zu schreiben. Mitlerweile gibt es im ganz neuen AVR-gcc noch eine andere Syntax, aber die zieht dann auch Code-Änderungen nach sich, weil die Zugriffe dann nicht mehr über pgm_read_xxx laufen, sondern direkt erfolgen. AVR-GCC-Tutorial Kapitel 15.2
Gast
#3052071
Oje, da muss ich kapitulieren, das sind böhmische Dörfer für mich. Ich habe es durchgelesen, aber wenig verstanden. Dann versucht den Code anzupassen, aber leider ohne Erfolg. Ich werde es mir wohl noch einmal zu Gemüte führen müssen... Aber danke für den Tipp und den Link, somit kann ich mich hoffentlich etwas einlesen
Versuchs mal mit:
1 | |
2 | |
3 | |
4 | |
5 | |
Hallo Andreas, in der aktuellen Version auf GitHub sind die prog_char Typen nicht mehr vorhanden: https://github.com/dergraaf/avr-can-lib Ich habe leider gerade keinen aktuellen avr-gcc da, sollte aber so funktionieren. Grüße Fabian
Ich habe es bei meiner Lichtorgel so gelöst.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Ich glaube, weiß aber nicht mehr sicher, das war alles. (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2 mfg
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.