Linker meldet "undefined reference"

[Undertaker]

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?

[ArneS]

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?

[Undertaker]

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)

[ArneS]

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!