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