Matthias Laubnitz schrieb:> hat jemand Erfahrungen mit dem RX62N von Renesas?
Ja
Matthias Laubnitz schrieb:> Oder ein einfaches> Beispielprogramm wie Blinky.c oder ähnliches?
Bei der KPIT tool chain sind Beispiele dabei, ansonsten die Homepage von
"DJ Delorie" besuchen: http://www.delorie.com. Da gibt's auch Beispiele:
http://www.delorie.com/electronics/rx-stick/rx/rx-samples.tar.gz
Sehr wichtig ist auch renesasrulz.com.
Ansonsten einfach "RX62N" deutlich in den Titel schreiben, damit ich es
sehe ;-)
Gegenfrage: Mit welchem Stück Hardware bist Du unterwegs (Eval-Modul
etc.)?
Hey nochmal danke für deine Tips. Habe den RX62N am laufen. Mit Hlfe der
RPDL kommt man schnell voran um die Peripherie einzurichten. Nutzt du
diese auch?
Hast du Erfahrungen mit dem abspielen von Videos auf einem LCD mit dem
RX62N oder einem anderen Mikrocontroller? Oder mit der Anbindung einer
MMC Karte an den RX62N?
RPDL bzw. "driver libraries" im allgemeinen verwende ich nicht (mehr),
sondern inzwischen "Register direkt" auf allen Plattformen. Die "driver
libraries" von NXP und STM sind für mich nicht so der Bringer, bei PIC32
und RX habe ich es gar nicht mehr versucht und kann somit die Qualität
der RPDL nicht beurteilen.
Im Speziellen bei RX finde ich, dass man dort mit relativ wenig
Register-Zugriffen die Peripherie initialiseren kann. Das muss aber
jeder selbst für sich entscheiden.
Zeige doch bitte mal ein einfaches Beispiel für RPDL, z. B. für Blinken
einer LED, evtl. mit Clock-Setup und Timer-basiertem Delay.
> Hast du Erfahrungen mit dem abspielen von Videos auf einem LCD mit dem> RX62N oder einem anderen Mikrocontroller? Oder mit der Anbindung einer> MMC Karte an den RX62N?
Nein, bisher noch kein wirklicher Bedarf ;-)
Roland H. schrieb:> Zeige doch bitte mal ein einfaches Beispiel für RPDL, z. B. für Blinken> einer LED, evtl. mit Clock-Setup und Timer-basiertem Delay.
Das würde mich auch interessieren, oder noch besser, wie man einen
DMA-Kanal aktiviert oder den DTC.
Da man aber doch immer ins Datenblatt (hardware manual) sehen muß, um zu
wissen, was man macht bzw. machen kann oder muß, kann man die Register
doch gleich direkt beschreiben.
Das Schöne bei Renesas ist, dass die Datenblätter immer ausführlich und
vollständig sind. Nicht so wie bei STM.... :-)
>Das Schöne bei Renesas ist, dass die Datenblätter immer ausführlich und>vollständig sind. Nicht so wie bei STM.... :-)
Och, geht so. Mit einem STM32F4 Discovery kann man mit Tricks
ein unkomprimiertes Video ohne Ton auf einem 320x240 Display
an SPI von SD Karte am SDIO mit vollen 25fps abspielen.
> Das Schöne bei Renesas ist, dass die Datenblätter immer ausführlich> und vollständig sind. Nicht so wie bei STM.... :-)
Man zwingt mich mittlerweile leider auch mit Geld dazu statt Renesas STM
zu nehmen. Die Controller selber gingen ja noch, aber was Dokumentation
angeht koennen sie bei Renesas SEHR viel lernen.
> Och, geht so. Mit einem STM32F4 Discovery kann man mit Tricks> ein unkomprimiertes Video ohne Ton auf einem 320x240 Display> an SPI von SD Karte am SDIO mit vollen 25fps abspielen.
Was genau hat das mit der Qualitaet der Datenblaetter zutun? Mal
abgesehen davon das es mich wundern wuerde wenn ein RX das nicht
koennte. Vermutlich schneidet der 32F4 sogar eher schlechter ab wenn es
wirklich um Geschwindigkeit geht weil der so ein lahmes Flash hat.
Olaf
Also ich hab schon ein paar Projekt damit gemacht. Allerdings gilt bei
dem Teil, wie bei allen anderen Controllern auch, dass die einem nach
ca. 3 Wochen (Einarbeitung) "aus der Hand fressen" (naja -> FAST) ;-)
Beim RX62N (wahrscheinlich auch bei allen anderen 600ern) gibt ein paar
Kleinigkeiten, die eine Wissenschaft für sich sind:
1. SPI
Schönes Modul. Auch endlich mal eines, welches halbwegs DMA-tauglich ist
(nicht wie bei AVR, PIC, ...). ABER man beachte, dass die kleinste
Zugriffseinheit 16-Bit ist (Datum in Datenregister). Das kann einem
schon einige Kopfschmerzen bereiten, wenn man den SPI im DMA (DTC)
Betrieb fahren will, mit 8-Bit Daten (wird bei größeren Blöcken, die
eine ungerade Byteanzahl haben echt lustig).
=> Achtung: Kleingedruckte Nebensätze zum Thema DMA/DTC beachten!!!!!!!!
2.DTC (wenn man so will, der "kleine Bruder" vom DMA-Modul mit mehr
Features)
Das Teil ist eine Wissenschaft für sich. Aber im Gegensatz zum DMA, kann
mn damit einige schöne Dinge anstellen. LEIDER nicht wie beim DMA einen
Transfer manuell starten. Aber ansonsten ist das Teil brauchbar.
3. RTC (naja, "fast" brauchbar)
Bei einer Anwendung mit Akku brauchbar. Dank der fehlenden Speisung
durch eine Pufferbatterie nicht für andere Anwendungen (ohne Dauerstrom)
geeignet.
-> Wird von Renesas angeblich bei den RX63xxx nachgeholt (schauen wir
mal).
Bis auf PPG, Timer im PWM, USB-Host, CRC, hab ich soweit alles am
Laufen.
Die PDL ist zwar schön gemeint von Renesas, aber wenn man nicht
nachvollziehen kann, was das Teil im Hintergrund treibt (auf
Registerebene), würde ich das für einen professionellen Einsatz nicht
empfehlen. Man erspart sich einige Kopfschmerzen. Ich hatte mir die am
Anfang angesehen, aber für "meinen" Geschmack nicht das Wahre.
Über KPIT kann ich keine Aussagen machen. IAR "soll" wohl nicht schlecht
sein. Der Renesas Compiler ist soweit auch OK.
Im HEW haben die Spaßvögel ein paar unschöne Stolperfallen eingebaut:
Die Linker Sections passen (beim aktuell größten R62N mit 512K Flash)
zwar so, dass es funktioniert, aber man wundert sich irgendwann über
eine Meldung, dass die Anwendung nicht mehr ins Flash passt, obwohl man
weniger als die Hälfte belegen würde. (Also "Obacht"). Man muss die
Startadresse des Program Flash mit der im Datenblatt abgegebenen
vergleichen und passend ändern. (Obwohl man beim Project Wizard den
korrekten Controller ausgewählt hat)
Naja. Auf jeden Fall viel Spaß mit dem Teil.
Olaf schrieb:> Die Controller selber gingen ja noch, aber was Dokumentation> angeht koennen sie bei Renesas SEHR viel lernen.
Das behauptet die AVR-Fraktion auch. Ich würde sagen, es ist anders,
im Sinne von ungewohnt.
> Vermutlich schneidet der 32F4 sogar eher schlechter ab wenn es> wirklich um Geschwindigkeit geht weil der so ein lahmes Flash hat.
Das mit dem "vermutlich" ist immer so eine Sache ;-)
Zum einen gibt es den "Adaptive real-time memory accelerator", von
welchem folgendes behauptet wird:
1
Thanks to the ART Accelerator, the CPU can operate up to 168 MHz frequency
2
without wait states, thereby increasing the overall system speed and efficiency
Wenn das Flash dennoch zu langsam wäre, würde man diesen Code in das
CCM-RAM verlegen, da gilt in jedem Fall: Zero wait states, Zugriff mit
vollem CPU-Takt.
Matthias schrieb:> 3. RTC (naja, "fast" brauchbar)> Bei einer Anwendung mit Akku brauchbar. Dank der fehlenden Speisung> durch eine Pufferbatterie nicht für andere Anwendungen (ohne Dauerstrom)> geeignet.
Das habe ich nicht verstanden: Was ist der Unterschied zwischen "Akku"
und "Pufferbatterie" im Vergleich mit "Dauerstrom"?
Roland H. schrieb:> Das behauptet die AVR-Fraktion auch. Ich würde sagen, es ist anders,> im Sinne von ungewohnt.
Stimmt. Ich nenne es Suchspiel. Gewinner ist der, der sie findet - wo
auch immer.
Roland H. schrieb:> Wenn das Flash dennoch zu langsam wäre, würde man diesen Code in das> CCM-RAM verlegen,
Zur Klärung: geht das überhaupt?
Im Datenblatt wird immer von "CCM data RAM" gesprochen, welches an den
D-bus der CPU angekoppelt ist. Kann die CPU sich denn dort Instruktionen
/ Code zur Ausführung holen?
Matthias schrieb:> 1. SPI> Schönes Modul. Auch endlich mal eines, welches halbwegs DMA-tauglich ist> (nicht wie bei AVR, PIC, ...). ABER man beachte, dass die kleinste> Zugriffseinheit 16-Bit ist (Datum in Datenregister).
Das Modul heißt RSPI, wobei das R auf Renesas-spezifische Ausführung
hinweist. Ein SCI-Kanal (USART) wäre für 8bit vielleicht die bessere
Wahl.
>Das Modul heißt RSPI, wobei das R auf Renesas-spezifische Ausführung>hinweist. Ein SCI-Kanal (USART) wäre für 8bit vielleicht die bessere>Wahl.
Wenn man die automatische CS/SS Ansteuerung nicht braucht, dann ja.
Aber ich wollte bei meiner Applikation die CMD Register haben ;-)
>Das habe ich nicht verstanden: Was ist der Unterschied zwischen "Akku">und "Pufferbatterie" im Vergleich mit "Dauerstrom"?
Akku und Dauerstrom ist in dem Fall das gleiche. Der Controller hängt
direkt an Dauerstrom (hat immer Saft) und befindet sich ggf. in einem
Power_Save
Modus, damit der Akku nicht leergesaugt wird. Die RTC läuft im
Hintergrund weiter. (verbrät relativ viel Strom).
Die Pufferbatterie (z.B. CR2032) würde direkt an der RTC hängen und nur
die RTC mit Strom versorgen, wenn der Controller selber Stromlos ist.
Dabei läuft nur noch die RTC (verbraucht wenig Strom - gut, ext. RTCs
kommen bis auf ca. 130 nA herunter. Die internen in uCs brauchen schon
einige 100 uA...)
Matthias schrieb:> Aber ich wollte bei meiner Applikation die CMD Register haben ;-)
Du Schlingel!
In den SPCMDx-Registern gibt es SPB-Bits, mit denen man die Datenlänge
von 8 -> 32bit festlegen kann.
Oder hast Du dort eine Pufferbatterie angeschlossen? ;-)
Bei den STM scheint auch nicht nur die Sonne:
Beitrag "STM32F4xx - Batterie wird leer gezogen"
[Programmausfuehrung im Ram bei STM32F4
> Zur Klärung: geht das überhaupt?
Ja, das geht. Ist aber Unsinn. Die Resource die man bei einem Controller
am ehestens zuwenig hat ist das Ram. Da wird man normalerweise kein
Programm drin laufen lassen. Wenn irgendein FAE damit ankommt dann
heisst das nur das er zaehneknirschend zugeben muss das es mit dem Flash
nicht zum besten steht. :-)
Ausserdem ist das Ram ja nicht nur klein, die darin laufenden Programme
sind es ja auch. Wenn man damit zufrieden ist dann wird der Cache im
32F4 das wohl auch auffangen koennen. BTW: Auch so ein Kritikpunkt an
ST. Wieso muessen sie sich fuer alles irgendwelche absurden Namen
ausdenken?
Andererseits muss man ja zugeben das bei modernen Controllern die
Geschwindigkeit nur selten ein Problem sein wird. In der Praxis
relevanter scheint mir dagegen zu sein wieviel Mhz pro mA ich rausholen
kann. Da weiss ich jetzt garnicht welcher Prozessor da besser ist.
Olaf
Roland H. schrieb:> Zeige doch bitte mal ein einfaches Beispiel für RPDL, z. B. für Blinken> einer LED, evtl. mit Clock-Setup und Timer-basiertem Delay.
Im Anhang befindet sich mal mein aktuell lauffähiger Code mit RPDL.
Hast du vielleicht mal ein Beispiel (evtl. RSPI_Init) auf konventionelle
Art? Ich habe da immer Probleme mit den Bezeichnungen der Register. Muss
aber sagen das ich mich gar nicht groß damit beschäftigt habe weil die
ersten schnellen Erfolge mit der RPDL kamen.
Nochmals Danke für die ganzen Meinungen!
Olaf schrieb:> [Programmausfuehrung im Ram bei STM32F4>> Zur Klärung: geht das überhaupt?>> Ja, das geht.
Ich meinte nicht RAM allgemein, sondern speziell das CCM RAM.
Matthias Laubnitz schrieb:> Im Anhang befindet sich mal mein aktuell lauffähiger Code mit RPDL.
Gegen die RPDL Anweisungen sieht der C-Code ja recht verloren aus :-)
Wie wird denn so eine 'LED rot EIN'-Anweisung umgesetzt? Wird daraus:
MOV.L #xxxxxxxxH,R5
BSET #xxh,[R5]
oder werden da noch mehr CPU-Cyclen erzeugt?
Willi schrieb:> Wie wird denn so eine 'LED rot EIN'-Anweisung umgesetzt? Wird daraus:
Also wenn ich das richtig sehe sind es noch 2 Anweisungen mehr. Unnötig?
Matthias Laubnitz schrieb:> Also wenn ich das richtig sehe sind es noch 2 Anweisungen mehr. Unnötig?
Ach du Kac..! Da wird ja jedesmal eine Subroutine aufgerufen, bloß um
ein Bit zu setzen.
Ich zeig mal als Beispiel, wie der DMA-Controller eingeschaltet oder wie
ein /CS-Ausgang aktiviert werden (RX210).
;DMAC.DMAST.BIT.DMST = 1; // DMAC freigeben
00000100 FB5E002208 MOV.L #00082200H,R5
00000105 F050 BSET #00H,[R5]
;MPC.PFCSE.BIT.CS6E = 1; // CS2# freigeben 0x6000000
0000006B FB5E00C108 MOV.L #0008C100H,R5
00000070 F056 BSET #06H,[R5]
Auch hier wird jeweils nur ein Bit gesetzt, aber ohne weiteres Gegurke.
Ein Portbit würde auch so gesetzt werden.
Ok!? Ist ja interessant. Initialisierungen lassen sich relativ einfach
gestalten mit der RPDL. Diese sind ja auch nicht so zeitkritisch. Wenn
es allerdings um Programmgröße geht ist die RPDL wohl eher nicht zu
empfehlen!?
Die Codegröße wäre mir erst einmal egal, die Ausführungsgeschwindikeit
aber auf keinen Fall.
Von Deinen obigen Routinen hat mir eigentlich clock_init() gut gefallen.
Sie ist übersichlich und selbsterklärend. Aber, wenn man einmal 'seine'
Grundeinstellung gefunden hat, schreibt man es direkt. Im 'Quick Design
Guide' zu RX610, RX62N, RX621 steht ein Beispiel, wie man Deine
Einstellungen von ICLK, PCLK und BCLK ganz einfach aktivieren kann:
SYSTEM.SCKCR.LONG = (unsigned long)0x00020100;
Hier ist es nur eine einzige Einstellung, die beim Programmstart
erledigt wird. Wenn man aber beispielsweise einen DMA-Kanal
wiederkehrend per Interrupt mit neuen Start- und Zieladressen nachladen
muß, ist das direkte beschreiben der Register erheblich schneller.
Ferner sieht man genau, was passiert.
Olaf schrieb:> [Programmausfuehrung im Ram bei STM32F4>> Zur Klärung: geht das überhaupt?>> Ja, das geht. Ist aber Unsinn. Die Resource die man bei einem Controller> am ehestens zuwenig hat ist das Ram.
Ja - ehestens :-)
Mir geht bei den kleinen AVRs/MSP430 (2k/128) tatsächlich das RAM zuerst
aus. In der Mittelklasse (8k - 32k AVR) geht zuerst das Flash zur Neige.
In den Klassen darüber bin ich in diese Problemregionen noch nicht
vorgestoßen.
Das hängt ziemlich heftig mit der Architektur und dem GCC zusammen: ARM
mit thumb2 macht mir keine Probleme, da thumb2 eine hohe "Codedichte"
hat, und das Verhältnis Flash zu RAM vorteilhaft ist (im Gegensatz zu
AVR atmega).
Arg unschön wird es bei PIC32 mit dem GCC: Der erzeugt im Vergleich zu
ARM fast 1,5x soviel Code, welcher dann im Flash landet.
Ob es nun Unsinn ist, Funktionen selektiv aus dem RAM ablaufen zu
lassen, kann ich nicht wirklich belegen, da ich die Notwendigkeit noch
nicht hatte. Es ging ja um den Vergleich RX62N mit stm32f4, und es war
so gemeint, dass man dann alle "Register" der jeweiligen CPU ziehen kann
und darf, wenn es um Extrembereiche geht. Mir geht's nicht um, "meine
CPU ist besser". Mir gefällt immer die am besten, welche gerade rechts
auf dem Schreibtisch steht :-)
Willi schrieb:> Ich meinte nicht RAM allgemein, sondern speziell das CCM RAM.
Ich habe tatsächlich keinen Beleg gefunden, wo jemand beschrieben hat,
dass es tatsächlich funktioniert hat. Es gibt ein paar Behauptungen,
sonst aber nichts belastbares. Bleibt der Flash accelerator und die
Möglichkeit, Daten ins CCM zu legen, damit Code in das normale RAM
passt. M. W. hat RX62N max. 96 KB RAM. D. h. das CCM ist zusätzlich
verfügbar.
Matthias Laubnitz schrieb:> Muss> aber sagen das ich mich gar nicht groß damit beschäftigt habe weil die> ersten schnellen Erfolge mit der RPDL kamen.
Das ist das süße Gift der "driver libraries".
Matthias Laubnitz schrieb:> Hast du vielleicht mal ein Beispiel (evtl. RSPI_Init) auf konventionelle> Art?
GPIO init + toggle:
1
PORTA.DDR.BIT.B2 = 1;
2
PORTA.DDR.BIT.B3 = 1;
3
4
PORTA.DR.BIT.B2 = 1;
5
PORTA.DR.BIT.B3 = 1;
6
7
PORTA.DR.BIT.B2 = 0;
8
PORTA.DR.BIT.B3 = 0;
Willi schrieb:> Ach du Kac..! Da wird ja jedesmal eine Subroutine aufgerufen, bloß um> ein Bit zu setzen.
Alles andere hätte mich gewundert: Bei STM32 ist das nicht besser,
schlimmer noch, die Library für stm32f1 ist nicht kompatibel zu stm32f4.
Bei lpc wird inzwischen für die UART-Baudrateneinstellung uint64_t (!)
benötigt.
M. W. gibt es das in "gut" bezüglich GPIO nur für PIC32, dort gibt es
explizit zwei Möglichkeiten: Die Funktion und ein Makro (es hat ja
beides seine Berechtigung).
Matthias Laubnitz schrieb:> Initialisierungen lassen sich relativ einfach> gestalten mit der RPDL. Diese sind ja auch nicht so zeitkritisch.
Das ist richtig. Aber "GPIO pin toggle" kann schon zeitkritisch sein.
Und dann ist die große Frage, ob es sich lohnt, beides parallel
einzusetzen.
Wie schon geschrieben, ich habe bei den "späteren" CPUs konsequent auf
die "driver libraries" verzichtet. Und bei stm32 findet gerade ein
"Rückbau" statt.
Matthias Laubnitz schrieb:> Wenn> es allerdings um Programmgröße geht ist die RPDL wohl eher nicht zu> empfehlen!?
Ich kann nur mit Erfahrungen aus dem Vergleich lpc und stm32 dienen: Das
erste ohne, das zweite mit Library. Wenn (m)eine Applikation 30k auf dem
lpc belegt, dann sind es 2k mehr auf dem stm32. Nicht wirklich
dramatisch.
Willi schrieb:> Die Codegröße wäre mir erst einmal egal, die Ausführungsgeschwindikeit> aber auf keinen Fall.
So ist es. Vor allem wenn diese Problematik latent in der Applikation
lauert, und dann bei einer "harmlosen" Erweiterung getestete Programme
nicht mehr funktionieren.
Willi schrieb:> SYSTEM.SCKCR.LONG = (unsigned long)0x00020100;
Ein schönes Beispiel dafür, wie kompakt sich bei RX die Peripherie etc.
initialisieren lässt. M. W. auch etwas nachteilig, da es weniger
Optionen bietet: Die Einstellung für die "System clock" geht "nur" mit
x1, x2, x4 und x8. Wer nun USB haben will, benötigt m. W. dann einen 12
MHz Quarz, um irgendwie auf 48 MHz zu kommen. Dann hat die System clock
max. 96 MHz. Naja, Luxusprobleme.
Etwas unschön, dass hier alle Einstellungen in einen Wert verwurstelt
sind. Ist das ein Beispiel für die gute RX-Dokumentation? :-)
Am schönsten wäre das folgende, wenn es noch ein paar Konstanten für die
Werte gäbe
1
// System clock (ICLK): x8
2
SYSTEM.SCKCR.BIT.ICK = 0b0000;
3
4
// Disable BCLK Output
5
SYSTEM.SCKCR.BIT.PSTOP1 = 0b1;
6
7
// Disable SDCLK Output
8
SYSTEM.SCKCR.BIT.PSTOP0 = 0b1;
9
10
// External Bus Clock and SDRAM Clock: x1
11
SYSTEM.SCKCR.BIT.BCK = 0b0011;
12
13
// Peripheral Module Clock: x8
14
SYSTEM.SCKCR.BIT.PCK = 0b0000;
wird aber bei mir vom GCC nicht zu einer Zuweisung zusammengefasst.
Deshalb verwende ich folgende Variante:
Roland H. schrieb:>> Ich meinte nicht RAM allgemein, sondern speziell das CCM RAM.>> Ich habe tatsächlich keinen Beleg gefunden, wo jemand beschrieben hat,> dass es tatsächlich funktioniert hat. Es gibt ein paar Behauptungen,> sonst aber nichts belastbares.
Dann behaupte ich einmal, dass es nicht geht! An anderer Stelle war ein
Hinweis, dass auch der DMA-Controller nicht aufs STM32xxx-CCM zugreifen
kann.
Programme ins RAM zu packen, habe ich oft gemacht, insbesondere wenn das
ext. EPROM nur 8bit Busbreite hat und das interne RAM >= 16bit ohne
Wartezyklen ansprechbar ist. Für Interrupts bedeutete das eine deutliche
Geschwindigkeitssteigerung.
Jetzt habe ich aber keine Lust mehr darauf, weil auch Fehlerquellen
damit verbunden sind, wenn zum Beispiel relative oder abs. Verzweigungen
nach dem Kopieren ins RAM ihr Ziel nicht mehr erreichen. Das kann bei
Verwendung von LIBs leicht passieren.
Die 168MHz beim STM32F4xx sind schon verlockend aber der FLASH-Zugriff
ohne Wartezyklen ist keinesfalls garantiert. Bei einer
Programmverzweigung/Interrupt hilft dieser 'accelerator' doch kaum oder
nicht. Die 100MHz beim RX6xx sind immer vorhanden, das FLASH-ROM ist
eben so schnell.
Die Praxis muß zeigen, ob bei unterschiedlichen Taktfrequenzen beider
µCs überhaupt ein Unterschied zu erkennen ist.
Erfreulich finde ich, dass hier überhaupt RXler zu finden sind :-)
> Die 168MHz beim STM32F4xx sind schon verlockend aber der FLASH-Zugriff> ohne Wartezyklen ist keinesfalls garantiert.
Vor allem muss man bedenken was passiert wenn der Code nicht mehr in den
Cache passt. Ich könnte mir vorstellen das durch etwas rumprogrammieren
ploetzlich Programmteile die mal sehr schnell waren, langsamer werden.
Oder das es sinnvoller ist mit -O2 anstatt -O3 zu uebersetzen. Letzeres
habe ich gerade beim SH2a gemerkt.
Jedenfalls 'fühlt' sich programmierung mit Cache anders an als ohne!
Olaf
Hi,
ich hatte hier die letzten zwei Wochen einen RX621 als "Nebenjob" zum
programmieren auf dem Schreibtisch.
Auf unserem Board galt es folgende Dinge zum Laufen zu bringen:
- RSPI für Display/Tastatur
- SPI über SCIxx für F-RAM
- Async seriell (RS232) über SCI als Ausgabekonsole und für die Motoren
- I2C für DAC und Drucksensor
- Diverse GPIOs
Ich hatte das Datenblatt sowie das Online kostenlos erhältliche Buch "AN
INTRODUCTION USING THE RENESAS RX62N MICROCONTROLLER" und den HEW zur
Verfügung. Zum Buch muss ich sagen, dass man es mit Vorsicht genießen
sollte, denn in den Beispielen befinden sich diverse Fehler, die mich
viel Zeit gekostet haben. Auf das Datenblatt ist aber Verlass, ich habe
dann lieber damit gearbeitet.
Die Driver-Library habe ich mir angesehen, die Dokumentation war dann
aber so spärlich, dass ich nicht mehr wusste, was das
zusammengeklickerte Kram denn jetzt nun wirklich macht und habe dann den
Chip lieber wieder von Hand programmiert.
Der HEW wirkt gegenüber dem AtmelStudio schon ziemlich angestaubt, der
Editor macht jedenfalls nicht besonders viel Spaß.
Auf den Gag mit den Linker Sections sind wir auch gestoßen, dass muss
nun echt nicht sein, wenn man schon den Controller GENAU auswählen kann
und muss.
Aber ansonsten hat alles gut und stabil funktioniert und so konnte unser
Prototyp noch rechtzeitig auf die Messe.
Gibt es eigentlich Vorteile den GCC zu benutzen (außer den Kosten)? Wie
und womit programmiert der Rest denn hier so den RX? Wir werden den MC
jetzt jedenfalls häufiger einsetzen und die endgültige Entscheidung für
die Entwicklungstools steht noch aus.
Gruß,
Wir haben sowohl KPIT/gcc als auch HEW + Renesas Compiler im Einsatz,
klappt beides gut. Wenn du sowieso "von Hand" programmierst, ist das
auch ziemlich austauschbar, die Header-Dateien und #defines sind
kompatibel.
Oliver R. schrieb:> Wie> und womit programmiert der Rest denn hier so den RX?
Natürlich mit einem Segger J-Link mit passendem RX Adapter :-).
Den J-Link hatten wir eh schon und der Adapter war nicht teuer (genauen
Preis habe ich leider nicht mehr im Kopf).
Willi schrieb:> Erfreulich finde ich, dass hier überhaupt RXler zu finden sind :-)
A propos, kennt jemand günstige RX-Eval-Boards < 25 EUR? Der µC und ein
paar Stiftleisten würden genügen, lieber klein und kompakt.
Hi,
>> A propos, kennt jemand günstige RX-Eval-Boards < 25 EUR? Der µC und ein> paar Stiftleisten würden genügen, lieber klein und kompakt.
versuch doch unter
[[http://www2.renesas.eu/support_all/registrations/rx62n_rpb/index.html]]
ein RX62N Eval Board zu gewinnen. Mein Arbeitskollege hat gerade eins
gewonnen, so schlecht sind die Chancen wohl nicht...
Gruß,
Roland H. schrieb:> A propos, kennt jemand günstige RX-Eval-Boards < 25 EUR? Der µC und ein> paar Stiftleisten würden genügen, lieber klein und kompakt.
Versuche doch, bei einem Distributor ein, zwei,... RPBRX210 zu bekommen.
Die wurden bis vor kurzem verschenkt und sind optimal für eigene
Aufbauten. Ein Segger J-link ist integriert, und nahezu alle IO-Pins
sind frei verfügbar.
Der RX210 ist recht preisgünstig, läuft von 1,6V - 5V und hat u.a. einen
internen 50MHz Taktgeber mit +/-1% Toleranz. Ein 2-lagiges Board reicht
aus.
Je nach dem, was Du anstellen möchtest, könntest Du Dir eine eigene
Schaltung auch selber aufbauen.
Hat jemand schon mal die AN "MMC Card Device Driver for SPI"
ausprobiert? Ich verstehe nicht warum da für SPI steht aber scheinbar
eine SCI - Schnittstelle genutzt wird!
Hat jemand vielleicht ne MMC am laufen mit dem RX62N?
Ja. Hab SD/MMC Treiber und SPI-Flash am Laufen. Bei meiner
Implementierung
hab ich die High-Level Teile von elm-chan.org genommen und das LowLevel
aus elm-chan Sourcen und Renesas AN Sourcen zusammengabaut.
Der Treiber war allerdings etwas komplexer, da ich einen sauberen
Zugriff auf mehrere Devices am SPI gebraucht hab. Allerdings kann ich
sagen, dass ein geteilter Zugriff am SPI ganz schön stressig sein kann.
Besonders wenn man was anderes (egal was) mit SD/MMC kombiniert ;-)
Bei der AN wird wohl die SCI zweckentfremdet, aber ich hatte auch keinen
Plan warum die das machen. Mit RSPI geht das auch. Sogar relativ Quick
and Dirty, wie man Chan's Codebeispiel für den RX sehen kann...
Ich probiere mich gerade an der AN für MMC-Karten von Renesas.
Da tut sich gar nichts. Ich messe gerade den CLK Pin zur MMC-Karte und
der bewegt sich nicht ein bisschen.
Ich stelle ja in der R_mmc_sfr.h die I/O-Pins ein an dem ich die MMC
Card angeschlossen habe.
Nun meine Fragen:
Wo stelle ich ein welchen SCI-Channel ich nutze? Weiss der das aus den
IO-Pins?
Was bedeutet
Matthias Laubnitz schrieb:> Was bedeutet#define MMC_MSTPCR_SCI SYSTEM.MSTPCRB.BIT.MSTPB30 /* SCI
Module stop setting */ /** SET **/
> bzw. was muss ich hier einstellen (RX62N)?
Siehe Datenblatt 9.2.3
Du mußt das Bit auf '0' setzen, um das SCI1-Modul einzuschalten. Mit den
MSTPCRx-Register werden nur die Module eingeschaltet, die Strom
verbrauchen dürfen.
Ich achte momentan nicht auf Stromverbrauch und schalte alle Bits auf
'0', damit ich ungeniert auf alle Module zugreifen kann.
Vielen Dank für den Hinweis. Jetzt tut sich auch am CLK-Pin etwas. Die
Hardware habe ich nun nochmals geprüft und an allen Pins kommt das an
was soll.
Ich führe folgenden Code aus:
1
/* Initialize MMC driver. */
2
R_mmc_Init_Driver();
3
4
//---------------------------------------------
5
//---------------------------------------------
6
status=R_mmc_Init_Slot(0);
Ich bekomme immer Error -7 zurück. Hat noch jemand ne Ahnung was ich
Softwareseitig überprüfen könnte.
Matthias Laubnitz schrieb:> Ich bekomme immer Error -7 zurück. Hat noch jemand ne Ahnung was ich> Softwareseitig überprüfen könnte.
Das ist ja immer das Problem mit vorgefertigten Programmteilen, wenn es
funktioniert, freut man sich, und wenn es nicht funktioniert, kann man
sich dumm+dämlich suchen.
Wenn Du den Quelltext hast, müßtest Du kucken, wo diese Fehlermeldung
entstehen kann. Aber wäre es nicht einfacher, sich die
low-level-Routinen selber zu schreiben und stückweise zu testen? Da weiß
man, was man macht, und lernt etwas dazu.
Ich habe mal zwei Bilder von der SPI-Übertragung angehangen.
Gelb = CLK
Grün = Data IN (SD-Karte)
Violett = Data OUT (SD-Karte)
Pink = CS
Bei scope_0 ist die Leitung Data OUT (SD-Karte) vom µC abgeklemmt und in
scope_1 angeklemmt. Irgendetwas stimmt da mit dem I/O-Pin nicht. Das
Signal kommt nicht runter auf GND.
Irgendwer ein Tip oder schonmal ein ähnliches Problem gehabt?
Matthias Laubnitz schrieb:> Irgendwer ein Tip oder schonmal ein ähnliches Problem gehabt?
Zwei Ausgänge arbeiten gegeneinander; Verdrahtung ist in Ordnung?
Ja, ich hatte gerade Hsync und Vsync an einem TFT vertauscht ;-)
Ich komme gerade gar nicht mehr klar. Anbei habe ich mal mein komplettes
Projekt als rar angehangen.
Vielleicht kann ja mal jemand nen Blick drauf werfen. Hardware habe ich
zum hundertsten Mal kontrolliert. Kann auch nicht mehr ohne Errors
kompilieren.
Ich verstehe das nicht.
Matthias Laubnitz schrieb:> Ich komme gerade gar nicht mehr klar.
Oben hatte ich ja "dumm+dämlich" schon erwähnt.
Teste nur eine Sache auf einmal und die separat von solch einem
Codemonster.
Mal ein, zwei Tage Pause zu machen, schadet auch nicht.
Hi
[...]
> Bei scope_0 ist die Leitung Data OUT (SD-Karte) vom µC abgeklemmt und in> scope_1 angeklemmt. Irgendetwas stimmt da mit dem I/O-Pin nicht. Das> Signal kommt nicht runter auf GND.>> Irgendwer ein Tip oder schonmal ein ähnliches Problem gehabt?
Also hier kannst Du Dir schon ziemlich sicher sein, dass zwei Ausgänge
gegeneinander arbeiten. Wie sonst sollte es dazu kommen, dass Data Out
nicht auf GND kommt? Da fließt (zu viel) Strom und die SD-Karte kann das
nicht treiben. Und das kann eigentlich nur dann der Fall sein, wenn an
DataOut nicht an P46 angeschlossen ist.
Da wir hier aber keinen Schaltplan haben und niemand nachvollziehen
kann, was die benutzte Library denn wirklich treibt (R_IO_PORT_Set und
co.), sind das natürlich alles nur Vermutungen.
Gruß,
Oliver
Erstmal vielen Dank für die Anworten.
Ich habe mein Projekt nun nochmal neu aufgesetzt (siehe Anhang). Es
enthält jetzt nur die AN von Renesas.
Ich habe ein Problem mit dem Timer. Wie schalte ich diese ab oder wie
kann ich ihn für den 62N definieren?
Da in einem anderen Thread recht heftig über Vor- und Nachteile
gestritten wurde, habe mir darum einmal diverse Docus zu den RX62N
angesehen. War über so manche Assemblerbefehle verblüfft
(String-Befehle, repeated MAC..) sowie die Möglichkeit SDRAM extern
anzuhängen.
Eines ist mir aber sehr unangenehm aufgefallen: 1000 write/erase cycles.
Wenn ich so grob hochrechne komme ich im SW-Testentwicklungsbetrieb bei
alle 10 min eine neue Version speicher:
6 /Stunde -> 48/Tag -> 240/Woche
also nach ca. 4 wochen könnte theoretisch der Ofen aus sein.
Wie schaut es da wirklich in der Praxis aus?
Fritz schrieb:> Wie schaut es da wirklich in der Praxis aus?
Viel entspannter!
Ein Lieferant berichtete mir, dass >50.000 Zyklen probiert wurden, ohne
dass es zu Einschränkungen kam. Die Zahl 1000 scheint recht konservativ
zu sein; Renesas beliefert ja auch Automobilhersteller mit diesen µCs,
wo man sicherlich sensibler auf Fehler reagiert als bei Produzenten
"brauner/schwarzer/weißer Ware".
Suche mal nach Informationen über MONOS Flash, wie dort die
Lebenserwartungen und Programmierzyklen definiert sind. Soweit ich mich
erinnere, ist das Ende durch eine zulange Löschdauer definiert. Defekt
sind die Speicherzellen damit noch nicht.
Ich weiß nicht, wie Du Deine Software entwickelst, aber 1000
Versionszyklen habe ich wohl noch nie gebraucht. Um Breakpoints zu
setzen, muß ja das ROM nicht neu beschrieben werden. Zudem gehen meine
Entwicklungsaufbauten in der Regel auch nicht in den Verkauf. Und für
die Fertigung und nachträgliche Programmanpassungen, würden mir ca. 10
Zyklen voll reichen.
Wo ist das Probelm? :-)
> War über so manche Assemblerbefehle verblüfft> (String-Befehle, repeated MAC..) sowie die Möglichkeit SDRAM extern> anzuhängen.
Ja, da sind viele schoene Dinge eingebaut. :-)
> Wie schaut es da wirklich in der Praxis aus?
Ich habe noch nie einen Controller mit vergesslichem Flash gehabt.
Interessant vielleicht noch, ich habe hier ein Testboard mit einem
SH7045 drauf. Das ist ein relativ alter Controller (ca 2000). Der darf
laut Datenblatt sogar nur 100mal gebrannt werden. Deshalb habe ich in
meinem Makefile mal einen Counter eingebaut. Ich bin bisher bei ueber
500Brennvorgaengen ohne das es ein Problem gibt.
> Renesas beliefert ja auch Automobilhersteller mit diesen µCs,
Nicht nur Autos:
http://www.bernd-leitenberger.de/blog/2007/01/15/lapan-tubsat/
Wenn man seinen Controller in eine Erdumlaufbahn schiesst wuerde ich
mich an die Flashvorgaben halten, fuer normale Anwender ist das aber
bedeutungslos. Zumal in der Produktion ein Controller normalerweise nur
einmal gebrannt wird.
> Um Breakpoints zu setzen, muß ja das ROM nicht neu beschrieben werden.
Das scheint aber auch eine Besonderheit von Renesas zu sein. Seit ich
auch fuer STM32 entwickel erlebe ich es zwar nicht immer, aber doch
oefter das der Debugger seine Breakpoints ins Flash nachbrennt.
> Und für die Fertigung und nachträgliche Programmanpassungen, würden> mir ca. 10 Zyklen voll reichen.
Ausser du schreibst Handyfirmware. Da gibt es ja so pubertierende Kinder
die flashen dreimal am Tag eine andere noch coolere Firmware. Da braucht
man dann einen Flashcounter um solchen Leuten die Garantie zu
verweigern.
Olaf
Danke für die Antworten, kann mir vorstellen, dass die Temeratur auch
eine Rolle bei der Programmierung spielt und der Wert ist ja für den
kompletten Temperaturbereich definiert.
Olaf schrieb:>> Und für die Fertigung und nachträgliche Programmanpassungen, würden>> mir ca. 10 Zyklen voll reichen.>> Ausser du schreibst Handyfirmware. Da gibt es ja so pubertierende Kinder> die flashen dreimal am Tag eine andere noch coolere Firmware. Da braucht> man dann einen Flashcounter um solchen Leuten die Garantie zu> verweigern.
Wenn ein HW- SW- Design fertig ist und die ersten Geräte fertig sind,
kann ich mir das vortsellen, aber in der Entwicklung, überhaupt wenn man
eine neue Architektur kennen lernen will, wird man mit 10 program/erase
Cyceln wohl kaum über ein paar blinkende LEDs hinauskommen! (Ich
zumindest)
> eine neue Architektur kennen lernen will, wird man mit 10 program/erase> Cyceln wohl kaum über ein paar blinkende LEDs hinauskommen!
Da sind wir auch nicht besser. Aber die Geraete aus der Entwicklung
werden nicht verkauft.
Oh..und wenn ich so drueber nachdenke, bisher haben es auch meine
Entwicklungsmuster ohne Probleme durch den Klimaschrank (-20+80)
geschafft obwohl die oefter gebrannt wurden.
Olaf
Thread beobachten
Seitenaufteilung abschalten