Forum: Mikrocontroller und Digitale Elektronik Erste Schritte mit Renesas M16C und GCC


von Daniel (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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.

von Daniel (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

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.

von Daniel (Gast)


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von Daniel (Gast)


Lesenswert?

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

von Olaf (Gast)


Lesenswert?

> 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

von Daniel (Gast)


Lesenswert?

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

von Olaf (Gast)


Lesenswert?

> 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

von Olaf (Gast)


Lesenswert?

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

von Daniel (Gast)


Lesenswert?

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

von Olaf (Gast)


Lesenswert?

> 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

von Daniel (Gast)


Lesenswert?

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

von Gast (Gast)


Lesenswert?

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.

von Gast11 (Gast)


Lesenswert?

"original Renesas SuperH StarterKit "

Gibt es davon auch eine Fälschung? :-)

7211 oder 7286 und was machts Du damit?

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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.

von Daniel (Gast)


Lesenswert?

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).

von Olaf (Gast)


Lesenswert?

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

von Daniel (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.