Hallo, ich will mit dem Renesas M16C/Tiny in die Mikrocontrollerprogrammierung einsteigen, und habe mir nun eine Toolkette zusammengestellt, bestehend aus HEW und GCC. Bei den ersten Versuchen sind mir ein paar Fragen in den Sinn gekommen: Wie groß ist ein int/long/short? Wo finde ich spezielle Befehle bzw. Erklärungen? z.b.: #define rmad1 (*(volatile union rmad1_def *) (0x0014)) etc. Mir fehlt irgendwie die richtige Dokumentation. Könnt ihr mir da evtl. ein paar Tipps geben? Vielen Dank und viele Grüße Daniel
Daniel schrieb: > Hallo, > > ich will mit dem Renesas M16C/Tiny in die Mikrocontrollerprogrammierung > einsteigen, und habe mir nun eine Toolkette zusammengestellt, bestehend > aus HEW und GCC. > Bei den ersten Versuchen sind mir ein paar Fragen in den Sinn gekommen: > > Wie groß ist ein int/long/short? * Such auf deinen Toolverzeichnissen nach einer Datei limits.h Dort stehts drinnen * Wenn diese Datei nicht existiert: Hast du schon eine Möglichkeit für eine Ausgabe? Wenn ja int main() { printf( "int: %d\n", sizeof( int ) ); printf( "long: %d\n", sizeof( long ) ); } Oder was du auch immer anstelle von printf nehmen kannst. Zur Not müsste auch ein Port gehen, an dem dir das Bitmuster (die Bytezahlen sind ja nicht gross) die Anzahl Bytes verrät. Wichtig ist eigentlich nur: sizeof verrät dir die Größe. > Wo finde ich spezielle Befehle bzw. Erklärungen? z.b.: > #define rmad1 (*(volatile union rmad1_def *) (0x0014)) Da du es hier mit einem µC zu tun hat, stehen die Chancen nicht schlecht, dass es sich hier um irgendeine vordefinierte Struktur handelt, die ein CPU-spezifisches Feature abdeckt. Besorg dir also das Datenblatt zu deiner CPU und sieh nach ob es dort etwas gibt, was sich RMAD nennt.
Danke für die schnelle Antwort! Die limits.h habe ich gefunden. Die werde ich gleich noch genauer studieren. Bezüglich der speziellen Befehle ist mein Problem nicht das rmad1, sondern das drum herum ( (*(volatile union rmad1_def *) ). Das ist eine für mich unbekannte Schreibweise. Anderes Beispiel: _timer_b1(void) _attribute_ ((interrupt)); Wo sind solche Befehle/Schreibweisen dokumentiert? Übrigens versuche ich gerade über einen I/O-Port einen Interrupt auszulösen (will da einen Taster dran hängen). Ist soetwas vorgesehen? Im Manual habe ich bei den Interrupts davon nichts gesehen.
Daniel schrieb: > Danke für die schnelle Antwort! > > Die limits.h habe ich gefunden. Die werde ich gleich noch genauer > studieren. > > Bezüglich der speziellen Befehle ist mein Problem nicht das rmad1, > sondern das drum herum ( (*(volatile union rmad1_def *) ). Das ist eine > für mich unbekannte Schreibweise. Dann wäre ein C Buch angebracht. 0x014 wird auf einen volatile union rmad1_def Pointer umgecastet, und dann mittels derferenzierung darauf zugegriffen. Anderes Beispiel: > _timer_b1(void) _attribute_ ((interrupt)); > > Wo sind solche Befehle/Schreibweisen dokumentiert? Das _attribute_ ist eine Erweiterung deines Compilers und kein Standard-C Feature. Da bringt dich dein C-Buch nicht weiter, sondern die Doku zum Compiler.
Auf den Cast wär ich wohl nie gekommen! Danke, auch für den anderen Hinweis. Ich habe inzwischen die Sache mit den Interrupts auch rausgefunden. Scheinbar haben nur einige Pins Interruptfähigkeit.
> einsteigen, und habe mir nun eine Toolkette zusammengestellt, > bestehend aus HEW und GCC. Warum? Wenn du schon den HEW benutzt, warum dann nicht auch den Compiler von Renesas? Womit ich jetzt nichts gegen den gcc sagen will. Ich nutze den auch fuer den M16C, aber halt unter Linux. > Mir fehlt irgendwie die richtige Dokumentation. Könnt ihr mir da > evtl. ein paar Tipps geben? Zu was denn? Zu dem GCC gibt es jede Menge Dokus im Netz. Zum Compiler von Rensas gibt es irgendwo bei Renesas eine Anleitung die den genau erklaert. Und zum HEW wird es vermutlich bei Renesas auch etwas geben. Allerdings ist HEW erstmal selbsterklaerend. Probleme gibt es da nur durch dessen Macken, aber die lernt man nur durch Erfahrung. > #define rmad1 (*(volatile union rmad1_def *) (0x0014)) Das ist kein Befehl sondern ein Register im Prozessor. > _timer_b1(void) attribute ((interrupt)); > Wo sind solche Befehle/Schreibweisen dokumentiert? Das ist eine Renesastypische Erweiterung ihres Compilers. Die werden in ihrem Compilerhandbuch erklaert. Und in der Tat ist das eine der wenigen Unterschiede zum GCC. Sonst kann man naemlich den Source 1:1 rueberkopieren und uebersetzen. > Übrigens versuche ich gerade über einen I/O-Port einen Interrupt > auszulösen (will da einen Taster dran hängen). Ist soetwas vorgesehen? > Im Manual habe ich bei den Interrupts davon nichts gesehen. Das weiss das Datenblatt deines Prozessors. Wir wissen es dagegen nicht, ja wir wissen noch nichtmal welchen M16C du nun benutzen willst... Olaf
Hallo Olaf, vorweg erst einmal: Ich verwende den M16C/Tiny (M30291FAVHP). Inzwischen bin ich mit den KPIT GNU Tools (http://www.kpitgnutools.com/) die ersten Schritte gegangen. Diese enthalten den GCC in Verbindung mit dem HEW. Darin kamen übrigens auch diese _attribute_-Dinger her. Der HEW-Compiler ist keine Freeware bzw. beschränkte Freeware, im Gegensatz zum GCC. Ich überlege allerdings, ob ich nicht auf Eclipse umsteigen soll. Komischerweise gibt es da auch bei KPIT ein fertiges Paket, in dem aber der M16C komischerweise nicht enthalten ist! Ich traue mir selber momentan nicht unbedingt zu Eclipse von vorn bis hinten selber zu konfigurieren, zumal ich noch nie damit gearbeitet habe... Wie genau sieht denn deine Arbeitsumgebung aus? Meine Frage zu den Dokumentationen bezog sich auf diese Bezeichnungen wie attribute etc. die ich nicht aus "normalen" C-Programmen kenne. Ich habe dazu folgende Seite bei KPIT gefunden: http://www.kpitgnutools.com/manuals/gcc.html#SEC92 . Viele Grüße Daniel
> orweg erst einmal: Ich verwende den M16C/Tiny (M30291FAVHP). Inzwischen > bin ich mit den KPIT GNU Tools (http://www.kpitgnutools.com/) die ersten > Schritte gegangen. Diese enthalten den GCC in Verbindung mit dem HEW. Hm..ich kenne dieses Kpitgedoehn nicht da ich keine Lust hatte mich zu registrieren bevor ich was runterlade. Allerdings finde ich es erstaunlich das die HEW zusammen mit GCC anbieten. Ich dachte HEW gehoert zu Renesas. Andererseits wenn man schon HEW verwenden will, dann kann man doch auch den bei Renesas runterladen und den Compiler von Renesas nehmen. Ich habe mir im uebrigen einfach den Source fuer den GCC runtergeladen und selber einen Compiler fuer M16C uebersetzt. > Darin kamen übrigens auch diese _attribute_-Dinger her. Der HEW-Compiler > ist keine Freeware bzw. beschränkte Freeware, im Gegensatz zum GCC. Der Compiler von Renesas ist auf 64kbyte Binaercode beschraenkt. Fuer die meisten Anwendungen ist das ja gar keine wirkliche Beschraenkung, besonders da viele CPUs darunter liegen, auch wenn jetzt gerade deine 96kb hat. Aber wie schon erwaehnt, der Compiler von Renesas und der GCC haben beide den C-Standard auf eigene Weise erweitert wenn es um IRQs geht. > Wie genau sieht denn deine Arbeitsumgebung aus? Ich verwende originale HEW+Renesas unter Winbloed und gcc+emacs+make unter Linux. Olaf
Danke für die Antwort Olaf. Ich wüsste selber nicht, wie ich einen gcc für M16C machen müsste. Schade finde ich es auch, dass irgendwie so wenig für Windows vorgefertigt wurde. Ich habe pro forma mal Cygwin installiert, weil ich auch mal den GCC mit Eclipse unter cygwin testen will (weiss aber noch gar nicht wie). Ist es schwierig einen GCC für M16C zu machen? Vieleicht sollte ich mich da noch einmal tiefer mit beschäftigen... Viele Grüße Daniel
> Ich wüsste selber nicht, wie ich einen gcc für M16C machen müsste. Im Prinzip in dem man mal make aufruft. :-) Gut ich geb zu, 1-2 Stellen sind etwas tricky. Aber mit etwas probieren oder lesen im Netz bekommt man das hin. Immerhin muss ja jemand der den Gcc sinvoll benutzen will auch C koennen, also sollte man auch mal in den Code des Compiler und wichtiger noch, der Libaries schauen koennen. > Schade finde ich es auch, dass irgendwie so wenig für Windows > vorgefertigt wurde. Tja, die Windowsuser sind halt fauler. Es gibt den Compiler von Renesas und den braucht man ja nur runterzuladen. Ausserdem muss man zugeben das man da auch 1-2 Vorteile hat was die Unterstuetzung von E8 und Debugging angeht. > Ist es schwierig einen GCC für M16C zu machen? Hier mal meine persoenlichen Notizen zum Thema. Die beruhen auf kopierten Commandozeilen unter Linux und ein paar Anmerkungen. Eigentlich sollte man es damit hinbekommen wenn mein genau nach dem Schema vorgeht.... 1. Binutils. Das sind Hilfsprogramme wie die der Compiler braucht. Dazu gehoert z.B der Assembler. Aktuelle Version: http://sources.redhat.com/binutils/ Auspacken tar xvjf binutils-051115.tar.bz2 cd binutils-051115 Konfigurieren fuer ein bestimmtes Target, hier im Beispiel fuer R8C/M16C/M32C. Wenn das System auf einem normalen Linux benutzt werden soll, so empfiehlt es sich ausserdem ein prefix anzugeben. Dieser wird allen erzeugten Programmen vorangestellt. Das sorgt dafuer das man spaeter problemlos den richtigen gcc aufrufen kann wenn man mehrere hat. ./configure --target=m32c-elf --program-prefix='m32c-elf-' Uebesetzen: make Installieren nach /usr/local/bin. Letzeres koennte man eventuell noch aendern. make install Als naechsten braucht man newlib. Gibt es hier: http://sources.redhat.com/newlib/ oder: cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/src login {enter "anoncvs" as the password} cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/src co newlib Das sind spezielle Anpassungen des Comilers an die Zielhardware. Hier gibt es den neuesten gcc: http://gcc.gnu.org Auspacken des Compilers: tar xvjf gcc-core-4.1-20051112.tar.bz2 Newlib und libgloss da reinkopieren: cp -r src/newlib gcc-4.1-20051112/ cp -r src/libgloss gcc-4.1-20051112/ Verzeichnis im gcc-Verzeichnis erzeugen wo der Compiler erzeugt wird mkdir m32c-elf-gcc Configurieren des Compilers.... cd m32c-elf-gcc/ ../gcc-4.1-20051112/configure --target=m32c-elf \ --program-prefix='m32c-elf-' \ --enable-languages=c \ --with-gnu-as --with-gnu-ld \ --with-newlib Uebersetzen make Falls es zu einem Fehler mit lib-gloss kam. make install-target-libgloss make make install -------------------------------------------- Siehst du, war doch garnicht so schwer. :-) Wenn man alle Kommandozeilen wie oben angegeben kopiert und genau die angegeben Programmversionen benutzt dann sollte es so durchlaufen. Allerdings gibt es mittlerweile natuerlich neuere Versionen. Es ist nicht auszuschliessen das es da auch schonmal irgendwo leicht hakt. Danach muss man sich noch ein Linkerscript selber schreiben. Das ist je nach Prozessor und Anwendung anders da hier festgelegt wird wo sich Ram/Rom befinden und wie gross das jeweils ist. Das ist vielleicht etwas umstaendlicher als unter Windows mit HEW, aber dafuer auch viel flexibler. Ich will das jetzt nicht posten weil es zu dick fuer einen Text waer, ausserdem muss es sowieso jeder an fuer sich anpassen. Bei ernsthaftem Interesse koennte ich ein Beispiel fuer einen m30290fchp auf meine Homepage legen. Ach so..und den StartUp code muss man sich noch tippern. Aber das ich schnell gemacht. Einfach nur die Variablen kopieren oder ausnullen und dann starten. Olaf
Hier noch ein paar Tips zur IRQ-Nutzung mit dem GCC: /* Typedeklaration der Vektortabelle */ typedef void (*vector_table_type)(void); /* Der Compiler muss wissen was ein IRQ ist! */ void _attribute_ ((interrupt )) timerXirq(void); /* Die eigentliche Interruptfunktion */ void timerXirq(void) { return } /* Vektortabelle wo die IRQs drin stehen */ const vector_table_type int_vecs[] = { 0, 0, // 0: BRK 0, 0, // 1: (reserved) [..] Ich hab es etwas gekuerzt, CPU-abhaengig! timerXirq, 0, // 22: Timer X 0, 0, // 23: Timer Y 0, 0, // 24: Timer Z 0, 0, // 25: INT1 0, 0, // 26: INT3 0, 0, // 27: Timer C 0, 0, // 28: Compare 0 0, 0, // 29: INT0 }; /* Tabelle installieren */ asm("fclr i"); /* Interrupts ausschalten */ // Initialisierung der Interruptvektor-Tabelle: asm("ldc #_int_vecs, intbl"); asm("ldc #0, intbh"); init_timerX(); /* Hier TimerX IRQ aktivieren */ asm("fset i"); /* Interrupts einschalten */ Ich denke damit sollte klar sein wie es funktioniert. Olaf
Danke sehr für die Zusammenfassung und die Interrupt-Erklärung (habe die Prozedur nun gut verstanden). Die Zeilen zur Erstellung eines GCC für den M16C sehen ja erstmal nicht schwer aus, aber darauf zu kommen ist das eigentliche Problem:). Ich werde das wohl jetzt mal mit meinem cygwin ausprobieren. Ich will dann Eclipse als Entwicklungsumgebung einsetzen. Ich wäre dementsprechend an Tipps interessiert, wie man dort den Linker einbindet. Vieleicht ist es besser, wenn ich erstmal Eclipse anschaue und mich dann melde, wenn ich nicht mehr weiterkomme. Ich will Dich nicht für meine Belange einspannen. Du hast mir schon gut geholfen. Viele Grüße Daniel
> Ich wäre dementsprechend an Tipps interessiert, wie man dort den > Linker einbindet. Grundsatzlich so wie man den Linker immer aufruft. Es gibt da nur eine Besonderheit. Dein Programm benoetigt ja einen StartUp-Code, der sorgt im einfachsten Falle dafuer das Variablen mit ihren initialisierten Werten gefuellt werden, also aus dem Flash ins Ram kopiert werden, setzt den Stackpointer und startet das Programm. Obwohl dort auch beliebig komplizierte Konstrukte denkbar waeren. So musst du ja z.B bei manchen M16C je nach verwendetem Gehaeuse des Controllers ein paar Bits setzen. Sowas koennte man da auch reinpacken. Ich habe auch noch eine andere Hardware, allerdings auf 68k Basis, wo die Position von Flash und Ram umgeschaltet wird. Da muss dann im Startup sehr esotherisch rumkopiert werden weil sich das Flash nach dem boot selber wegschaltet. Normalerweise ist dieser Code Teil deiner Installation und das ist auch sinnvoll wenn du Programm erzeugst die direkt unter Linux oder Windows laufen und immer die gleiche Umgebung haben. Ich weise jedoch den Linker lieber an keinen Startup vom System zu verwenden. Daher muss ich die notwendige Funktionalitaet, also z.B setzen des Stackpointers, selber in meinem Programm uebernehmen. Ich sehe das aber als Vorteil weil man da ja manchmal auf derselben Hardware unterschiedliche Wuensche hast. So kann der Stack ja verschieden gross sein je nachdem wenn du einen Heap brauchst oder nicht. Man hat dann die eigenen Intialisierung halt auch im Sourceverzeichnis seines Programms liegen und nicht in einem Libary verzeichnis des Compilers das sich in ein paar Jahren vielleicht mal geaendert hat. .-) Renesas macht das im uebrigen aehnlich. Verwirrend ist bei denen nur das sie teilweise (frueher) diesen Code in Assembler hatten, und jetzt in C. BTW: Schon den neuen M16C/6C mit integriertem USB gesehen? Olaf
Hallo, nach einer kleinen Pause wollte ich euch noch informieren, wie es bei mir weitergegangen ist. Ich habe mich erst einmal für den einfachen Weg entschieden und bin bei der KPIT Geschichte geblieben. Die ersten Programme laufen auch schon. Im Endeffekt werde ich wohl nicht mehr viel Zeit in die Entwicklungsumgebung stecken, da ich das ganze für die Arbeit brauche und ich mich da lieber auf die Programmierung konzentrieren will. Es gibt in der Tat inzwischen neuere und interessante Renesas uCs. Die Zielhardware ist aber leider der oben beschriebene M16C/29, weshalb ich mich damit erstmal zufrieden geben muss. Später geht es dann wohl eh mehr Richtung Freescale MPC und Infineon TriCore, für die ich dann wieder neue Umgebungen brauche. Viele Grüße und danke nochmal Daniel
Zitat: Olaf "Hm..ich kenne dieses Kpitgedoehn nicht da ich keine Lust hatte mich zu registrieren bevor ich was runterlade. Allerdings finde ich es erstaunlich das die HEW zusammen mit GCC anbieten. Ich dachte HEW gehoert zu Renesas." Die KPIT-Gnu Tollchain wird meines Wissens in Indien "fabriziert", lt. Renesas unterstützt KPIT sehr intensiv, daher auch die super Integration in die HEW (AVR-Studio ind WinAVR harmonieren ja auch sehr gut!). Ich habe vor kurzem das original Renesas SuperH StarterKit erhalten, selbst dort lag zusätzlich zur Renesas CD eine KPIT Gnu CD bei. Ich selbst verwende die HEW, da sich die Applicationnotes von Renesas auch auf die HEW beziehen.
"original Renesas SuperH StarterKit " Gibt es davon auch eine Fälschung? :-) 7211 oder 7286 und was machts Du damit?
Olaf schrieb: > Hm..ich kenne dieses Kpitgedoehn nicht da ich keine Lust hatte mich > zu registrieren bevor ich was runterlade. Ich habe nach langem Zögern in den sauren Apfel gebissen und mich registriert. Der Download war ziemlich problematisch wegen vieler Timeouts und seltsamem Skripting auf der KPIT Seite, aber nach mehreren Versuchen habe ich die Toolchain für den M16C (und R8C) jetzt auf der Platte. Mal sehen, inwieweit die Arbeiten damit funktionieren.
Ich verwende testweise sowohl die original Renesas HEW Toolchain als auch die KPIT Toolchain. Beides lässt sich in einer einzigen HEW-Installation nutzen und beides scheint mir ähnlich komfortabel. Ich merke eigentlich gar keinen Unterschied, ausser ein paar compilerspezifische Unterschiede (z.B. Verwendung von #interrupt).
Wenn du unter HEW den GCC verwendest, wie sieht da die Unterstuetzung des Debuggers aus? Da koennte ich mir naemlich noch am ehestens eine Einschraenkung vorstellen. Ich nutze aber den GCC unter Linux und da habe ich ja sowieso nicht den Renesas Debugger. Von daher fehlt mir da die Erfahrung. Was die Compiler angeht sehe ich da naemlich auch keinen Unterschied. Beides funktioniert gleichermassen gut. Olaf
Auch mit GCC kann ich in HEW Debuggen wie bei Verwendung des normalen Compilers. Ich kann Steppen usw., sowie Daten und Register auslesen und ändern. Viel mehr Umfang fällt mir jetzt nicht ein.
Bitte 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.