4. Linker meldet "undefined reference"

Linker meldet "undefined reference"

  • A

    Eben nicht!!!! Bei JEDEM µC, der mir in die Finger gefallen ist, werden alle maskierbaren Interrupts durch das automatisch bei Annahme einer Anforderung gesetzte generelle Enable/Disable- Flag kaltgestellt.

    Dann hast Du das Interruptkonzept der m68k nicht verstanden. Es gibt dort nämlich kein generelles Enable/Disable- Flag ⚠

    Wäre es anders, wäre Dein Prozessor ganz großer Mist.

    a) ist das nicht MEIN Prozessor
    b) ist er für unseren Einsatzzweck zwar nicht geeignet, aber trotzdem kein Mist!

    Wenn man die ISR initialisiert (also nicht ihr Aufruf), gibt man ihr doch ein Plätzchen in der Vector- Table und den IPL

    Genau diese Aussage zeigt mir, daß Du das Interruptkonzept des m68k nicht kennst. Aber das wäre jetzt ein anderes Thema und hätte mit dem Ursprungsthema nichts mehr zu tun.

    Warum willst Du da zur Aufrufzeit hinfummeln?

    Wir haben hier Produktionscode, in dem das leider gemacht wird, weil man ein kooperatives OS einsetzt und durch die ISR keine DSR getriggert wird, die die eigentliche Arbeit der ISR übernimmt. Ich gebe zu, daß da meine Vorgänger kein durchdachtes Konzept hatten. Ist leider so. Aber damit mußt DU Dich nicht rumärgern 😉

    0
  • P

    ArneS schrieb:

    Es gibt dort nämlich kein generelles Enable/Disable- Flag ⚠

    Ich hab' nachgesehen, Du hast recht 🙂 und ich unrecht 😞 !

    ArneS schrieb:

    Aber damit mußt DU Dich nicht rumärgern 😉

    Na, gottseidank, wenigstens etwas ... 😃
    Tut mir leid wegen der Nachbohrerei, aber ich hatte wohl wirklich noch nie einen originären 68k auf dem Tisch 🙄

    0
  • U

    ArneS schrieb:

    Wir haben hier Produktionscode, in dem das leider gemacht wird, weil man ein kooperatives OS einsetzt und durch die ISR keine DSR getriggert wird, die die eigentliche Arbeit der ISR übernimmt.

    wirklich ein kooperatives OS? 😉
    meinst du mit DSR sowas wie 'deferred procedure call'?
    sowas lässt sich ja nachrüsten...
    🙂

    0
  • A

    Ich hab' nachgesehen, Du hast recht 🙂 und ich unrecht 😞

    Deswegen hatte ich ja nachgefragt, ob Du aus der i386 Welt kommst. Ich meine mich zu errinnern, daß es da die STI/CLI Anweisungen gab, die alle Interrupts sperrte/freigab. Beim 68HC11 ist das m.W. ähnlich/genauso.
    Beim Coldfire gibt es sog. Autovectorinterrupts, bei denen die CPU selbst den IPL generiert (m.W. nur für interne Peripherie - will mich da aber nicht festlegen ohne Manual) und 'normale' Vektoren, bei denen der Interruptcontroller von außen an den IPL0-2 Pins die Priorität anlegt. Der Index in die Vektortabelle liegt dann an D0-D7 an IIRC.

    Tut mir leid wegen der Nachbohrerei, aber ich hatte wohl wirklich noch nie einen originären 68k auf dem Tisch

    Das kann man hier alles auf sachlicher Ebene klären. Freut mich, daß Du Dir die Mühe gemacht hast nachzusehen. 🙂

    wirklich ein kooperatives OS? 😉
    meinst du mit DSR sowas wie 'deferred procedure call'?
    sowas lässt sich ja nachrüsten...

    Hab ich da was übersehen oder was habe ich bei kooperativem OS nicht verstanden. Das OS lässt sich für Zeitscheiben mit unterschiedlichen Prioritäten konfigurieren, aber auch so flachklopfen, daß der Programmierer mit einer Art yield() Aufrufen (wie in Windoof 3) gezielt den Scheduler aufrufen muß.
    Ja mit DSR meine ich Deferred SubRoutine. Ein Thread der von einer ISR angestoßen wird und die eigentliche Arbeit macht, die nicht zwangsläufig in der ISR ablaufen muß.
    Bei DER Software lässt sich nix mehr nachrüsten - das ist ne Wartungsleiche und gehört in den Giftschrank 👎
    3.3MB in 420 Dateien, der gcc hört bei 100kB Warnings auf weitere zu generieren, ein C/C++ Hybrid, jeder Depp meinte seine eigenen Datentype definieren zu müssen. So findet man wild durch alle Dateien sowohl 'unsigned char', 'BYTE', 'Byte' und 'intu8'. Das macht richtig Spaß 😡
    Den Typen, der mit C++ anfing das Konzept komplett zu zerbröseln, würde ich am liebsten @!%$&*@&%§.... 😡

    0
  • U

    ArneS schrieb:

    Hab ich da was übersehen oder was habe ich bei kooperativem OS nicht verstanden. Das OS lässt sich für Zeitscheiben mit unterschiedlichen Prioritäten konfigurieren...

    diese zeitscheibengesteuerten OS'se werden im allgemeinen als preemptiv bezeichnet. bei einem kooperativen OS muss jede task selber dafür sorgen, das sie nicht zuviel rechenzeit verbrät. hat beides vor- und nachteile.

    ArneS schrieb:

    Ja mit DSR meine ich Deferred SubRoutine. Ein Thread der von einer ISR angestoßen wird und die eigentliche Arbeit macht, die nicht zwangsläufig in der ISR ablaufen muß.

    ja, das verfahren ist bekannt. ich konnte nur das kürzel DSR nicht zuordnen. (ich kenn's als DPC) 😉

    ArneS schrieb:

    Den Typen, der mit C++ anfing das Konzept komplett zu zerbröseln..., würde ich am liebsten @!%$&*@&%§.... 😡

    das wäre genau mein albtraum 😮 eine software (für microcontroller) weiterpflegen, die jemand durch den einsatz von 👎 C++ 👎 verpfuscht hat.
    (ich würde so'n auftrag wahrscheinlich ablehnen, oder alles neu in vernünftigem 👍 C 👍 machen).

    0
  • A

    bzgl. OS: genau so kenne ich es auch. Man hat sich bei uns vor vielen Jahren für CMX entscheiden, das bei uns in kooperativem Betrieb läuft. Man muß in Schleifen selbst mittels eines CMX Aufrufes Rechenzeit abgeben. Sonst kommen nur noch die ISRs zum Zuge. Allerdings hat man mir auch gesagt, daß sich CMX als preemptives OS konfigurieren lässt.

    Das Tolle ist: unser Zeugs compiliert nur mit dem GCC 3.4 - und da nur in -O1. Bei -O0 oder -O2/3 fliegt einem der Compiler um die Ohren. Da wir beim GCC 3.4 meinen zwei Compilerfehler gefunden zu haben, habe ich mich nach neueren Versionen umgeschaut. Leider müssen für den Coldfire wohl spezielle Adaptierungen gemacht werden, da er nur einen abgespeckten m68k Befehlssatz kennt (und der 5307 keinen TAS Befehl 😡 ). Bin dann auf den CodeSourcery GCC gestoßen. Erst 4.1.1, jetzt 4.2.8. Nun ratet mal: unser Zeugs compiliert mit dem 4.x auch nicht. Und woran knallt es? An den C++ Erweiterungen. Zu mir meinte der C++ Fuzzi, daß er wohl Konstrukte benutze, die syntaktisch (!!!) vom 4.x moniert werden, der 3.4 da aber hindrüber wegsieht. Ich liebe es....
    Ich könnte noch seitenweise über die Verfehlungen berichten...

    das wäre genau mein albtraum 😮 eine software (für microcontroller) weiterpflegen, die jemand durch den einsatz von 👎 C++ 👎 verpfuscht hat.
    (ich würde so'n auftrag wahrscheinlich ablehnen, oder alles neu in vernünftigem 👍 C 👍 machen).

    Undertaker! Ich könnt Dich knuddeln 😃
    Ist mir jetzt schon zum zweiten mal bei einem Arbeitgeber passiert. Beim ersten war es allerdings andersrum. Da haben die Jungs streng nach Leerbuch angefangen: für alles erstmal 'ne abstrakte Klasse erstellen, selbst wenn man letztendlich nur eine Instanz benötigte.... und E-Techniker haben dann das Konzept durch mangelhaftes C komplett zerstört. Damals haben wir nach einem halben Jahr die SW in den Giftschrank gestellt und alles neu in C aufgebaut.

    Bei meinem jetzigen AG ziehe ich in meiner Freizeit ein System hoch, um die CPU-Karten und digitalen/analogen Ausgangskarten prüfen zu können. Da uCos m.E. sich schnell anpassen lässt (drei Wochenenden mit BSP für Timer, UARTs und unser externes Bussystem), habe ich mich erstmal hierfür entschieden. Wenn ich da Erfahrung gesammelt habe, werde ich versuchen eCos sammt IP-Stack auf unseren Coldfire zu packen. Aber eins nach dem anderen...

    0
  • U

    ArneS schrieb:

    Man hat sich bei uns vor vielen Jahren für CMX entscheiden, das bei uns in kooperativem Betrieb läuft. Man muß in Schleifen selbst mittels eines CMX Aufrufes Rechenzeit abgeben. Sonst kommen nur noch die ISRs zum Zuge. Allerdings hat man mir auch gesagt, daß sich CMX als preemptives OS konfigurieren lässt.

    ja, ich kenne CMX, hab das mal auf infineons (C166'ern) verwendet. ich kann mich dunkel daran erinnern, dass man durch aufruf einer api-funktion preemptives multitasking einschalten musste (per default lief es kooperativ). ich hatte von CMX einen guten eindruck, genau so wie von dem deutschen konkurrenzprodukt 'emBOS' (das hatte ich auf 'nem M16C verwendet).

    ArneS schrieb:

    Das Tolle ist: unser Zeugs compiliert nur mit dem GCC 3.4 - und da nur in -O1. Bei -O0 oder -O2/3 fliegt einem der Compiler um die Ohren. Da wir beim GCC 3.4 meinen zwei Compilerfehler gefunden zu haben, habe ich mich nach neueren Versionen umgeschaut.

    ich versuche immer um GCC's einen grossen bogen zu machen, seit mich mal ein GCC für V850 an den rand der verzweiflung getrieben hat 😞
    für embedded programmierung geht nichts über professionelle tools. die sind zwar teuer, aber mit der zeit, die man dabei spart, holt man sich das geld schnell wieder rein.

    ArneS schrieb:

    Da haben die Jungs streng nach Leerbuch angefangen: für alles erstmal 'ne abstrakte Klasse erstellen, selbst wenn man letztendlich nur eine Instanz benötigte....

    hehe, typisch. 😃 C++ programmierer sind in der regel ziemlich realitätsfern, bevorzugen akademisch korrekte lösungen und schön gemachte quelltexte. mit C++ idiomen und ähnlichem dummsinn hat man auf microcontrollern schlechte karten, aber zum glück verirren sich nicht so viele hartnäckige C++ freaks in diese branche (die coden dan doch lieber video games).

    ArneS schrieb:

    Da uCos m.E. sich schnell anpassen lässt (drei Wochenenden mit BSP für Timer, UARTs und unser externes Bussystem), habe ich mich erstmal hierfür entschieden. Wenn ich da Erfahrung gesammelt habe, werde ich versuchen eCos sammt IP-Stack auf unseren Coldfire zu packen. Aber eins nach dem anderen...

    welches nun? eCos oder uCos?

    0
  • A

    und schön gemachte quelltexte

    Das kriegt unser C++ Dödel definitiv nicht hin. Sieht nur zum K*tzen aus...
    Bei meinem Projekt schalte ich alle Warnings an und es kommen nur 5 Warnings momentan am Ende durch - davon zwei, die auf __attribute__ ((norturn)) zurückzuführen sind für die Funktionen, die mit

    while(~0) {
    ...
}

    einen uCos Thread darstellen. Der Rest sind momentan noch "unused variable" etc.
    Und es compiliert/linked/läuft mit allen drei hier vorhandenen Versionen des GCC.
    Man mag ja über den GCC für uC durchaus geteilter Meinung sein. Aber mein Chef ist halt nach eigener Aussage "eine schwäbische Krämerseele" :p
    C'est la vie...

    welches nun? eCos oder uCos?

    uCos (http://www.micrium.com) läuft zwischenzeitlich. Aber deren IP-Stack lässt sich m.E. nicht so problemlos an uCos und den benötigten Treiber (SMC 91C111 - noch so ein Tränenkapitel ) anflanschen.

    Wenn meine Applikation damit läuft, versuche ich eCos (http://ecos.sourceware.org/ zu adaptieren. Vorallem wegen der FreeBSD/OpenBSD IP-Stacks. Bräuchte dann nur noch einen vernünftigen CAN Stack und Treiber für SJA1000.
    Unsere Hardware hat insgesamt folgende Schnittstellen: Ethernet über den 91C111 für die Kommunikation mit einem Steuer-PC, 2x CAN über SJA 1000, 1x RS232 und 1x RS485 (Coldfire intern) plus noch ein proprietäres Bussystem zu Ansteuerung der externen digitalen & analogen Ausgangskarten.
    Wenn ich damit in der Firma auf keine große Gegenliebe stoße, macht sich das alles aber sicher gut in meinem Lebenslauf 😃
    Was hälst Du von uCos, ecos bzw. RTEMS?

    0
  • U

    ArneS schrieb:

    Aber deren IP-Stack lässt sich m.E. nicht so problemlos an uCos und den benötigten...

    also ich benutze als TCP/IP stack entweder OpenTCP
    --> http://sourceforge.net/projects/opentcp/
    oder meinen selbstgebastelten stack 😉
    beide laufen auch ohne RTOS o.ä. und verlangen von der unteren schicht (osi-layer 3 glaub' ich) nur eine sende- und receive-funktion für 802.3/DIX-kompatible pakete. openTCP hat zwar ein paar geringfügige bugs (im ARP z.b.) und wird, glaube ich, auch nicht mehr weiterentwickelt, aber es läuft recht zuverlässig...
    vielleicht interessiert dich auch diese seite: http://www.sics.se/~adam/uip/

    ArneS schrieb:

    ...Treiber (SMC 91C111 - noch so ein Tränenkapitel ) anflanschen.

    das kann doch nicht so schlimm sein. guckst du hier: http://www.google.de/search?q=91C111+filetype%3Ac
    ethernet driver sind eigentlich trivial. mach mal einen für WLAN, das ist spassiger 😉

    ArneS schrieb:

    Bräuchte dann nur noch einen vernünftigen CAN Stack und Treiber für SJA1000.

    nackte CAN frames?
    --> http://svn.gna.org/svn/xenomai/trunk/ksrc/drivers/can/sja1000/
    oder was anderes wie devicenet, CANOpen etc...?

    ArneS schrieb:

    Was hälst Du von uCos, ecos bzw. RTEMS?

    eCos finde ich etwas fett, obwohl man sich ja mit einem grafischen tool zusammenstückeln kann, was man braucht. hat mich etwas an den platform builder für windows-CE erinnert 😉
    die anderen beiden kenne ich nicht (hatte von uCos mal den quelltext, sah gut aus, hab's aber nie ausprobiert)
    zur zeit benutze ich das: --> http://www.tnkernel.com/ auf einem NXP LPC2378 (nachdem ich FreeRTOS evaluiert hatte, welches meiner meinung nach nicht viel taugt)
    🙂

    0
  • A

    OpenTCP kenne ich vom Hörensagen. Hab ihn auch irgendwo auf der Platte rumfliegen.
    Da der Stack, den wir in der Firma benutzen uns Probleme macht (die können natürlich wieder hausgemacht sein 😡 ), wollte ich erstmal den FreeBSD aus ecos benutzen.

    das kann doch nicht so schlimm sein

    Schon mal SMC "Doku" gelesen? Grauenhaft...

    nackte CAN frames?

    Falscher Fehler.... CANOpen natürlich 🙄

    nachdem ich FreeRTOS evaluiert hatte, welches meiner meinung nach nicht viel taugt

    Den Eindruck hatte ich auch.
    uCos sieht gut aus - besonders, da Ports für so ~30 CPUs zur Verfügung stehen und man in Application Notes alles haarklein erklärt bekommt. Der einzige Nachteil is m.E., daß es je Priorität nur einen Thread zulässt.

    ecos und auch RTEMS sind dicke Brocken - für C166 oder 8Bitter damit nicht geeignet. Aber wir haben 4MB Flash und 4MB RAM am Coldfire zur Verfügung 😃
    Deine Links werde ich mal durchforsten. Danke!

    0
Anmelden zum Antworten