Hallo an alle, ich stehe vor dem Problem, dass ich ein unter "CooCox" lauffähiges Projekt nach Eclipse übertragen möchte. Die Dateistruktur im CooCox-Projektordner unterscheidet sich gewaltig von der, den eclipse standardmässig bei einem "neuen Projekt" anlegt. So sind im vorhandenen Projekt viele include-Ordner in Unterordnern von z.B. cmsis, cmsis_boot, hardware, drivers etc. vorhanden. Man muss sich das so vorstellen, dass unterhalb der aufgeführten Ordner weitere Ordner sind, die teilweise Sourcen enthalten und teilweise header-Dateien. An dazugelinkten Libraries habe ich nur zwei gefunden (libm.a und libarm_cortexM4lf_math.a). Alles andere, zum Kompilieren und linken notwendige befindet sich im Projektordner von Coocox. Ich würde nun gerne diese Dateien in möglichst wenig zu verändernden Punkten in eclipse überführen. Ich fange jetzt erst mit eclipse an - also keinerlei Vorkenntnisse vorhanden. Ich wäre daher für ein paar Tipps sehr dankbar. Gibt es ein "Ausgangsprojekt", was möglichst wenig (wie z.B. eine "Standardumgebung" für den STM-Kern) mitbringt? Und wie schaufle ich die Sourcen rüber? Sicher: ich könnte alle .h - Dateien gnadenlos in den Ordner "include" schaffen und alle c-Dateien in den Ordner "src". Aber ist das der einzige Weg? In der vorhandenen Struktur ist durchaus Sinn drin: Die Funktionen sind in Blöcken programmiert, und diese befinden sich samt ihren header-Ordnern in diesen Unterstrukturen. Klar: kann man aufbrechen. Aber die Übersichtlichkeit leidet dann doch etwas :) Gerne höre ich mir auch Tipps wie "lies das Howto XYZ durch" an. Ich habe nur kein passendes für meine Aufgabenstellung gefunden... Gruß df8oe
Hallo Andreas, ich würde vorschlagen das Du als erstes ein compilierbares F4 eclipse Projekt erstellst. Das GNU ARM eclipse Plugin hast Du installiert?
Eclipse kommt mit jeder Sourcefile-Ordnerstruktur klar, die du ihm vorsetzt. Also leg einfach mal ein leeres Projekt an, und importier alle deine Sourcen mit der gewünschten Ordnerstruktur. Rechter Muasklick aufs Projekt, dann "Import existing sources" (oder so ähnlich), oder einfach den Ordner, in dem die Sourcen jetzt liegen, mit der Maus aus dem Explorer auf das Projekt ziehen. Du wirst dann gefragt, ob die Files kopiert oder verlinkt werden sollen, das wars. Eventuell musst du allerdings die Includepfade auf die Unterverzeichnisse, die Header enthalten, von Hand in den Projektsettings eintragen. Oliver
Wenn ich ein neues leeres C-Projekt für den STM32F40X anlege, werden bereits viele Ordner mit Dateien vorbelegt und auch Ordner erzeugt, die ich im CooCox-Projekt gar nicht habe. So existiert im neuen Projekt bereits ein Ordner "cmsis", in dem auch Sourcen vorgegeben sind. Kann ich einfach die gesamten Ordner mitsamt ihrem Inhalt löschen / entfernen (oder wenigstens die Sourcen und die Header-Files) und dann die des CooCox-Projektes importieren? Dort gibt es auch cmsis-Ordner: sogar drei.... Einen "cmsis", einen "cmsis_boot" und einen "cmsis_lib"... Ausserdem gelingt es mir nicht, eine Ordnerstruktur mitsamt Unterordnern zu importieren. Wenn ich mit Mausklick rechts Import wähle, kann ich lediglich alle Dateien, die sich unterhalb des gewählten Ordners befinden, importieren. Unterhalb dieses Ordners sind aber bis zu einer Tiefe von 6 geschachtelte Unterordner, die ihrerseits Sourcen bzw. Headerfiles enthalten. Klar: ich könnte vorher mit "find", "cp" & Co. eine "neue Ordnung" erstellen, in der alle Sourcen und Header fein säuberlich in zwei Ordnern landen und diese dann importieren. Allerdings bleibt dann noch das Problem, was ich mit den beiden Ordnern cmsis_boot und cmsis_lib mache, die es ja bei eclipse nicht gibt. In cmsis_lib befindet sich ebenfalls je ein Ordner mit C-Sources und einer mit Headerfiles... Gruß Andreas
Moin Andreas, in erster Linie kommt es nicht darauf an wie die Ordner heissen, sondern was drin ist. Ich habe mir angewöhnt die Systemdateien: startup_* ,system_ und *.ld in den Ordner System zu legen. Dann kannst Du das gesamte Projekt einfach als Dateien mit der vorhandenen Ordnerstruktur in das Projekt kopieren. Als nächstes die main.c suchen und compilieren. Ab da ist es nur noch ein includieren und excludieren um die Abhängigkeiten zu erfüllen. Ist das coocox Projekt von dir oder öffentlich zugänglich? Dann könnten wir das mal durchspielen...
Es ist öffentlich. https://github.com/cctbcn/mchf_github Ich scheitere schon daran, dass ich nicht weiss, ob ich die Ordnerstrukturen irgendwie importieren kann oder oder ob ich sie unter Umgehung von eclipse einfach per cp in den Projektordner (meinetwegen in src) kopiere. Wie Du sehen wirst, ist es ein richtiges "Gewusel" an Ordnern - und die dazugehörigen Header-Files befinden sich meistens im ebenfalls im jeweiligen Überordner befindlichen "include" - Ordner. Es scheint keine Namensdubletten zu geben - also könnte es klappen, alle .h in den neuen include Ordner zu kopieren. Aber dann wäre die Übersicht über das Projekt irgendwie futsch ;) Andreas
Die ersten Schritte: neuen workspace erstellen und Projekt importieren:
1 | mkdir workspace-mchf |
2 | cd workspace-mchf/ |
3 | git clone https://github.com/cctbcn/mchf_github.git |
4 | |
5 | beim Start von eclipse: |
6 | workspace-mchf einstellen |
7 | neues leeres ARM C Projekt erstellen: mchf |
8 | |
9 | import -> general -> file system : mchf_github |
10 | |
11 | damit sind erst mal alle Dateien im Projekt |
dann die main.c öffnen und compilieren. es sollte ein Fehler erscheinen: usbh_ioreq.h: No such file or directory
Ach so, bin einfach mal davon ausgegangen das Du linux benutzt ;-)
Ja natürlich ich benutze Linux (schon wegen "find" und "cp") in meinen Postings :) Ich wühle das mal in der Reihenfolge durch und schaue mal wie weit ich komme - danke für deinen Einsatz! Gruß Andreas
Ja natürlich ich benutze Linux (schon wegen "find" und "cp") in meinen Postings :) OK - habe die Dateien auf die beschriebene Weise importiert. Nun habe ich ja bereits einen Ordner "system" gehabt - den gibt es in meinem importierten Projekt nicht. Auch gibt es durch den Ordner "cmsis" unter "system" jetzt Konflikte mit dem bestehenden Ordner "cmsis" aus dem github-Repo. Soll/kann ich den System-Ordner LÖSCHEN?? Da alle Dateien die zum lauffähigen bin ja bereits im Repo vorhanden sind, sollte das ja richtig sein, oder nicht? Und muß ich jetzt wirklich manuell alle Ordner mit Header-Dateien händisch eintragen? Daher rühren wohl 99% der ERRORS, die ich jetzt sehe... Gruß Andreas
Erstelle am Besten noch mal ein leeres ARM C Projekt. Und importiere wie beschrieben. Dann sind nur die Dateien aus dem git drin. In dem Fall würde ich auf den Systemordner verzichten und die Struktur beibehalten.
Wenn Du dann bei der fehlenden usbh_ioreq.h angekommen bist folgt der 2. Schritt:
1 | Project -> Properties -> C/C++ Build > Settings -> Tool Settings -> Target Processor -> cortex-m4 |
2 | jeweils mit Apply für Debug und Release übernehmen. |
3 | |
4 | Project -> Properties -> C/C++ General -> Paths and Symbols -> includes -> Add -> Workspace |
5 | den Ordner /mchf/usb/usbh/core/inc wählen und alle Haken setzen |
6 | |
7 | Dieses für alle fehlenden includes wiederholen. |
8 | Evtl. die Suchfunktion benutzen. |
OK - jetzt folgt die Fleissarbeit :) Alle include-Ordner suchen und einfügen. Kann etwas dauern - aber das werde ich erstmal machen und dann bin ich auf das Ergebnis gespannt :) Es werden zwei Bibliotheken hard-gelinkt, die sich bei github im /libs - Ordner befinden (die beiden anderen sind unbenutzt). Mal sehen, wie sich das auswirkt :) Denke! Gruß Andreas
die ARMCM4.h fehlt, core_cm4.h benutzen:
1 | Project -> Properties -> C/C++ General -> Paths and Symbols -> Symbols -> Add |
2 | ARM_MATH_CM4 eintragen und beide Haken setzen |
Habe alle Pfade eingetragen (auch das Symbol gesetzt wie in deinem letzten Beitrag) - aber der Error mit der fehlenden usbh_ioreq.h bleibt. Ich habe auch mal den Haken bei "is a workspace path" entfernt und wieder gesetzt: keine Änderung die .h - Datei wird nicht gefunden - obwohl der Ordner in den includes ist :( EDIT: Ich habe mal die Fehlermeldung angeklickt. Dann wird mir ja der Quelltext angezeigt, in dem die h-Datei eingebunden werden soll, und rechts daneben ein Fenster, wo die h-Datei oben aufgeführt ist (Symbol davor ein blaues Quadrat in einem blauen Winkel). Klicke ich die "fehlende" h-Datei dort an, wird sie mir links im Fenster korrekt angezeigt ??!!?? Andreas
:
Bearbeitet durch User
Andreas R. schrieb: > obwohl der Ordner in den includes ist Hast Du alle 3 Haken gesetzt? In allen Sprachen und Konfigurationen muss die include erreichbar sein. Klick mal auf eine andere Sprache asm/c oder Konfig debug/release. Muss überall drin sein. Wenn alles drin ist baue den Index neu auf.
Stimmt - waren nicht überall drin... Neu gesetzt, neu indexiert - dieser Fehler ist jetzt weg. Nun bekomme ich eine Fehlermeldung, dass die Variable 'band_decod_mode' in ui_eeprom.c benutzt wurde bevor sie deklariert wurde. Dort wird sie auch nicht deklariert - sie wird in ui_driver.c deklariert. Das gleiche Spiel mit diversen anderen Variablen auch (insgesamt 22 ERRORS). Stimmt hier die Syntax nicht oder die Reihenfolge der Abarbeitung? Gruß Andreas
Da bin ich auch. Das Problem ist das die Zusammenführung der Dateien erst im linker stattfindet. coocox muss da ein anderes Prinzip anwenden. Es ist dann eine Art include der .c Datei. Bleibt die Frage wie Du das lösen willst. Eine Möglichkeit wäre alle fehlenden Variablen usw. in eine extra .h auszulagern und diese in beide .c inkludieren.
Warte gerne auf Dein Ergebnis. Ich tendiere aber dazu, die Deklaration in eine header-Datei auszulagern - das wäre auf jeden Fall "sauberer"... Aber eine qad-Lösung könnte zeigen, was noch für Überraschungen lauern :) Gruß Andreas
Auslagern ist eine gute Idee. Ich wollte an der Reihenfolge drehen, war aber nicht :-( Wenn Du deine ausgelagerte .h dann hier anhängst, spiele ich weiter mit.
Komme jetzt erstmal alleine weiter. Ich habe ein paar fehlende Deklarationen gefunden und die fehlen WIRKLICH! Wie der CooCox damit klarkommt und noch viel interessanter wie das hinterher funktionieren kann/soll, ist mir ein Rätsel... Ich werde auf jeden Fall hier Ergebnisse schreiben, wenn ich wieder welche habe. Evtl. komme ich auch irgendwann nicht alleine weiter :/ Du hast mir sehr geholfen! Gruß Andreas
Ok. Wichtig ist auch noch das linker script einzubinden.
Ich schau mal wie weit ich komme. Ich habe ja schon programmiert - nur halt noch nie mit der IDE Eclipse... Gruß Andreas
Moin moin, bin weiter.... Die beiden Dateien ui_eeprom.c und ui_eeprom.h unter drivers/ui sind obsolet und müssen entfernt werden. Keine Ahnung, wie der CooCox mit solchen "Leichen" umgeht - eclipse meckert (berechtigt)... Dann habe ich mal im CooCox nachgeschaut: es sind noch folgende Symbole gesetzt: STM32F407VG STM32F4XX USE_STD_PERIPH_DRIVER Die dort auch gesetzten __USE_FPU und __FPU_PRESENT sind bei eclipse wohl default gesetzt und damit überflüssig. Mit diesen Einstellungen kommt schon mal kein Compiler-Error - aber wenns ans Linken geht, läuft noch was schief. Wie binde ich das Linker Script arm-gcc-link.ld ein? Ich habe unter "Properties -> C/C++ Build -> Settings unter "Cross Arm C Linker -> General" das Script eingetragen. Keine Ahnung, ob das so richtig ist... Und wie sage ich dem Linker, dass er sie Libs aus libs/ benutzen soll? Ich habe wie oben unter "Libraries" den Pfad zu "libs/" eingetragen und die beiden Libraries (ohne das .a) eingetragen - die Libs werden aber nicht gefunden... Gruß Andreas
OK - gelöst. Prinzipiell war meine Vorgehensweise schon richtig. Das Linkerscript wird genau so eingebunden. Bei den Bibliotheken muss man das "lib" vor dem Namen weglassen und die Endung auch. Also anstelle von "libm.a" einfach "m" - und dann wird die Bibliothek gefunden. Dann erkennt eclipse auch nicht eigenständig, was für eine FPU tatsächlich vorliegt. Man muss unter "Properties -> C/C++ Build -> Settings" bei "Tool Settings -> Target Processor" FPU Type auf fpv4-sp-d16 setzen und Float ABI auf FP instructions (hard). Damit werden die bei diesem Projekt benötigten FPU-Befehle generiert. Ob das Kompilat nun läuft, weiß ich noch nicht. Zumindest gibt es keinen Error, nur einige warnings über die üblichen Flüchtigkeits-C-Fehler :) Damit ist das Problem gelöst. Gruß Andreas
Angehängte Dateien:
-
eclipse-settings.png
150 KB -
lib1.png
15 KB -
lib2.png
16 KB
Andreas R. schrieb: > Keine Ahnung, wie > der CooCox mit solchen "Leichen" umgeht - eclipse meckert > (berechtigt)... Moin, das meinte ich mit exclude. Geh einfach auf die nicht gewünschte .c -> rechte Maustaste -> Resource Configuration -> Exclude from build -> beide Haken setzen. Andreas R. schrieb: > Die dort auch gesetzten __USE_FPU und __FPU_PRESENT sind bei eclipse > wohl default gesetzt und damit überflüssig. Nein. Der linker wird sich evtl. noch beschweren. Siehe Bild 1 rechte Seite. Andreas R. schrieb: > Ich habe unter "Properties -> C/C++ Build -> Settings unter "Cross Arm C > Linker -> General" das Script eingetragen. Keine Ahnung, ob das so > richtig ist... Das ist richtig. Andreas R. schrieb: > Und wie sage ich dem Linker, dass er sie Libs aus libs/ benutzen soll? Siehe Bild 2 und 3.
Nachtrag: Das Release-Binary ist nun 254kB groß (CooCox: 316kB) Bei keinem der beiden ist irgendeine "Optimierung" aktiviert Und nicht nur dass das Binary kleiner ist - es ist auch spürbar weniger prozessorlastig in der Ausführung als das CooCox - Produkt. Die Mühe hat sich gelohnt :) Danke für deine Mithilfe! Gruß Andreas
Bitte sehr! Gegenfrage: Wie ich sehe reparierst Du auch Notebooks. Ich habe hier ein Netbook E1318T von Medion. Beim einstecken einer USB 3.0 ext. Festplatte ging es einfach aus. Sicher eine Schaltregler oder FET gestorben. Hast Du Service Unterlagen für das Gerät?
Es gibt keine Service-Unterlagen für Notebooks - wir leben in der "Wegwerf- und Konsumgesellschaft"... Jede Notebookreparatur, die über das Tauschen einer Festplatte oder eines Speicherriegels darüber hinaus geht, ist eine Forschungsarbeit. Ich habe im Laufe der Jahrzehnte Erfahrungen gesammelt, die ein effektives Vorgehen ermöglichen. Es ist aber nicht möglich, diese in kurzen Sätzen zu verfassen... Aber soviel kann ich sagen: Die USB-Anschlüsse bei Notebooks sind GENERELL kurzschlussgesichert - und zwar mit einer Polyfuse. Es brennt also weder eine Sicherung noch ein Spannungsregler urch, wenn man da aus Versehen was kurzschliesst. Vielleicht ist dein Gerät nur gnadenlos abgestürzt und Du kannst das mit Trennen vom Netzteil, Entnehmen des Akkus und Entnehmen der CMOS-Batterie für mindestens 15 Minuten beheben... Wenn nicht, sag Bescheid! Gruß Andreas
Das habe ich alles mehrfach mit allen Internet Tips durch. Leider alles ohne Erfolg. Es sollte Kurzschlussfest sein, aber .... Das einzige was passiert: wenn es eingeschaltet wird ist ein Dauerfiepen zu hören das wars :-( Keine LED, kein Lüfter nix. Egal ob Akku oder NT. Batterien hatte ich alle raus. Es lag auch mal ein paar Tage nur das blanke Motherboard auf dem Tisch. Sieht dann wohl schlecht aus :-(
Ja - riecht nach Mainboarddefekt - und da gibt es keine "allgemeine und einfache Vorgehensweise" :( Gruß Andreas PS: Hast Du mal geschaut, ob es die Buchse selbst irgendwie zerlegt hat und beim Reinschauen vielleicht schon abgebogene Pins zu sehen sind?
Angehängte Dateien:
-
E1318T.png
840 KB
Die Buchse habe ich eben noch mal kontrolliert. Sieht gut aus. Hab aber (vielleicht) etwas gefunden. Die eingekreisten FETs werden heiß, die anderen beiden bleiben kalt. Im inneren Kreis ist die Leiterbahn braun. Die Bezeichnung ist auch unter dem Mikroskop Licht/UV nicht zu lesen. Die Oberfläche sieht aus wie ein Schwamm. Bei den grossen Leiterflächen bin ich mir aber so wie so nicht sicher ob ich das löten könnte. Etwas grösser hätten die die Dinger schon lassen können. Na ja, einen Versuch war es Wert. Vielleicht finde ich mal ein günstiges MB. Ist eben nur ärgerlich für den kleinen Bastler ;-) Danke.
Miss doch einfach mal mit einem DVM. Einer der FETs geht an +Ub, der andere an Masse, und "in der Mitte" wo sich die beiden treffen musst Du die Ausgangsspannung messen. Je nachdem, wofür die Regler sind, ist das irgendwas zwischen 1.0V und 5V. Wenn Du sowas findest, dann ist die Schaltstufe i.O. Gruß Andreas
Leider nicht - Mainboard defekt :( Gruß Andreas
Ich weiss ;) Der Schaltregler ist ein http://www.ti.com/lit/ds/symlink/tps51225c.pdf Nicht im Bild. Aber wie gesagt löten ist wohl nicht :-( Trotzdem Danke, belassen wir es dabei. Wie ist dein Eindruck von eclipse? Ich finde es sehr gut.
Hi, ich melde mich doch noch mal - vom E1318T :-) Der Bastler Ehrgeiz hat mir keine Ruhe gelassen und so habe ich die beiden Mosfets doch noch gewechselt. http://de.rs-online.com/web/p/transistoren-mosfet/8270535/ Der sieht auf dem Bild wesentlich grösser aus als er in Wirklichkeit ist ;-)
Ich drück Dir die Daumen, dass das hält. Normalerweise sterben die MOSFETs, weil die Ansteuerung nicht mehr "rechteckig" ist und sie dadurch Verlustleistung erzeugen. Manchmal sofort wieder - manchmal nach Tagen... Gruß Andreas
Andreas R. schrieb: > weil die Ansteuerung nicht mehr "rechteckig" ist Kannst Du das bitte erklären?
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.