Hallo.
Ich brauche für ein STM32F4 Projekt den MP3 Decoder von HELIX.
Ich habe den gesamten Code in mein EM:BLOCKS Projekt geladen und bekomme
Fehler mit denen ich nichts anfangen kann.
Es betrift die Asmpoly_gcc.s Datei.
Im Originalzustand bekomme ich hunderte von Fehler.
Wenn ich versuche mit ".arch ARM7-tumb" was anzugeben dann wird nur noch
EORNE r4,r12,r14
mit "ERROR! tumb conditional instruction should be in IT block"
bemängelt.
Was muss ich machen/eintragen damit ich diese Datei durch den GCC
bekomme.
VG, Peter
Offensichtlich ist das eine Datei für ARMv7A, also ARM Mode. Dieser Code
läuft nicht auf STM32F4, egal was du mit dem GCC anstellst. Lies dich in
die Unterschiede zwischen ARM Mode und Thumb mode ein, und bau den Code
um...
Peter schrieb:> Also muss ich den Thumb Mode irgendwie abschalten oder wie soll> ich das> nun verstehen.
Das geht nicht. Der STM32F4 ist ein Cortex-M4, welcher nur den
Thumb-Mode kann. Du musst den Code umschreiben oder einen anderen
Controller (Cortex-A oder ARM7,9,11) verwenden.
Peter schrieb:> Wenn ich versuche mit ".arch ARM7-tumb" was anzugeben dann wird nur noch> EORNE r4,r12,r14
Eher nicht. Dir fehlen hier ein paar Zeichen.
Für welchen Befehlssatz ist der Helix Decoder denn geschrieben? EORNE
r4,r12,r14 sieht eher nach .arm32 aus
(https://www.mikrocontroller.net/articles/MP3 legt das auch nahe). Da
wird es schwierig es ohne Anpassungen für armv7-thumb zu übersetzen.
So ein Sch... da gibt es schon einen Port auf ARM und der ist nicht auf
einem M4 lauffähig.
Nun Ja, da ist dann wohl jemand mit Assembler Kenntnissen gefragt.
Leider gehöre ich nicht dazu.
In der Hoffnung das der Rest dann noch arbeitet!
Wie muss man den EORNE r4,r12,r14 Ändern?
Im Code ist alles richtig geschrieben, nur hier habe ich mich
verschreiben.
VG, Peter
Peter schrieb:> So ein Sch... da gibt es schon einen Port auf ARM und der ist nicht auf> einem M4 lauffähig.>> Nun Ja, da ist dann wohl jemand mit Assembler Kenntnissen gefragt.> Leider gehöre ich nicht dazu.
Nun ja, dann ist ein derartiges Projekt eben nichts für dich.
Du outest dich hier als Überflieger, der zwar nen Cortex M4 benutzen
will, sich nicht mal ansatzweise die Mühe machen will, den Unterschied
zwischen ARM und THUMB verstehen zu wollen. Geschweige denn, den
jeweiligen Befehlssatz mal anzuschauen.
Also, kauf dir nen fertigen MP3-Player. Das wird das Beste sein.
W.S.
Ach wer Programmiert heute den noch mit Assembler?
Assembler für 8048, 8051, 6510, 80X86 und AVR könnte ich noch lesen und
schreiben, aber seit Jahren benutze ich nur noch C.
Der Befehlssatz einen Cortex-M4 interessiert doch nur Leute die extrem
Zeitkritische Sachen machen, alles normale macht man tunlichst nicht in
ASM.
Alleine schon um portablen Code zu haben.
@c-hater:
Spätestens der Compiler würde Schreibfehler einem um die Ohren hauen,
das gibt es hier aber nicht!
@hp-freund:
Danke, für den Link.
Ich habe logischerweise nicht den C und ASM Code gleichzeitig drin.
Aber es gab da einige Links/Beiträge die mir Helfen könnten.
Den MAD Decoder werde ich später testen, wenn der HELIX läuft.
Ich suche halt einen der schnell und sauber arbeitet.
Peter schrieb:> Ach wer Programmiert heute den noch mit Assembler?
Wer mit nem Cortex M4 oder M4F tatsächlich DSP-Funktionen programmiert,
weil er es braucht und kein Geld für nen richtigen DSP im Budget hat,
der tut sowas.
Selbst Leute, die ganz gewöhnliche Jobs erledigen, sollten sowas
zumindest ansatzweise können. Der Rest sind Pappnasen und Scharlatane.
W.S.
Nun ein DSP kostet aber nicht wirklich viel mehr.
Hat dafür aber meistens weniger Schnittstellen.
Ich arbeite auch mit DSPs (TSM320.. / ADSP..) und das auch nur in C.
Grob lesen und verstehen kann ich den ARM ASM Code, nur selber was
schreiben würde ich nicht ohne weiteres können.
Da es auch irgendwie nicht nötig ist bei den heutigen C Compilern habe
ich auch nicht wirklich einen Anreiz das jetzt wegen eines Tests zu
lernen.
RT-Thread kenne ich, habe ich sogar schon mal eingesetzt.
Wirklich hübsches RTOS.
Diese Demo war mir aber nicht bekannt.
Jetzt habe ich 3 Assembler Versionen, eine davon wird hoffentlich
laufen.
Bin gerade noch am vergleichen der Dateien.
Bis jetzt gibt es nur eine Änderung auf die ich selber auch gekommen
war.
Mal sehen was die Nacht noch so bringt.
weiß zwar nicht ob es dir hilft, aber uwe hat einen mp3 Decoder in
seinen libs für dem stm32f4 drin:
http://mikrocontroller.bplaced.net/wordpress/?page_id=2180
"MP3-Decoder :
Als MP3-Decoder habe ich Helix-MP3 benutzt (der Link dazu steht im
Quellfile)"
Alle Dateien funktionieren mit kleinen Änderungen.
Wie schon gesagt es wurde genau immer das gemacht was ich selber schon
herausgefunden hatte (IT NE vor EORNE ...).
Jetzt werde ich mir die Qualität genauer ansehen.
1KHz MP3 rein und mal sehen was da an Jitter und so weiter raus kommt.
So Test eins ist durch.
Zeiten für den 1. Frame: 5ms mit der ASM Datei 20ms für die C Datei.
Wäre schon mal eine nette Laufzeit.
Aber wenn ich versuche meine komplette MP3 Datei da durch zu schieben
gibt es Probleme.
Sauberer System Absturz, irgendwann zwischen dem 2. -- 5. Frame!
Sogar ein Pointer der von mir nie wieder verändert wird ist platt.
Der wird zwar übergeben aber dadurch kann man ihn ja nicht ändern.
Der Debugger zeigt mir das da schleifen auf einmal Variablen mit bis zu
2MB RAM Platt machen wollen, obwohl die Variable nur wenige (<8)KB gross
ist.
Entweder der Code hat einen Fehler, werde ich mit einer anderen Quelle
noch mal gegen prüfen, oder das war es mit HELIX.
Der Code von http://mikrocontroller.bplaced.net sollte ja laufen.
Zumindest hat bis jetzt immer alles von da funktioniert.
Den werde ich jetzt Testen!
Thread beobachten
Seitenaufteilung abschalten