M16C - Wie oft ist der Flash beschreibbar?

[Michael Dreschmann]

Hallo,

ich möchte in meinem nächsten Projekt (auf Anraten dieser NG) gerne
einen M16C Mikrocontroller verwenden. Vorzugsweise den M 30624 FGAFP,
da es den bei Reichelt gibt und er im Grunde alle meine Anforderungen
erfüllt.
Nun habe ich mir mal ein Datenblatt runtergeladen und darin steht,
dass der Flashspeicher nur 100 mal beschreibbar wäre.
Das ist ja nicht besonders viel für eine Entwicklungsphase.
Und wenn ich den Controller auf meine Platine löte, ist es ja auch
nicht mehr so einfach ihn auszutauschen, wenn der Flash-Speicher im
Eimer ist. Mal ganz abgesehn von den Kosten eines neuen Controllers...

Also, stimmt es, dass der Speicher nur 100 mal beschreibbar ist?
Oder ist das vielleicht nur der Wert, den der Hersteller garantiert
und in Wirklichkeit ist er meistens viel öfters beschreibbar?
Oder kann man den Programmcode vielleicht zum Debuggen in den RAM
laden? Von der Speicherorganisation scheind es so, als lägen Flash und
RAM im gleichen Adressraum. (Habe das Datenblatt nur grob überflogen)

Gibt es vielleicht sonst noch Wege, dieses Problem zu umgehen?

Ach, und nochwas:
Ich habe grade bei Reichelt gesehn, dass der 5V Typ am Ende mit FGAFP
gekennzeichnet ist und der 3V Typ mit FGMFP.
Im datenblatt heisst der 5V Typ aber FGPS und der 3V Typ FGLPS.
Hat das einen Grund?

Vielen Dank schon mal für Eure Antworten.

Cu, Michael

 

[Markus Zingg]

ich möchte in meinem nächsten Projekt (auf Anraten dieser NG) gerne
einen M16C Mikrocontroller verwenden. Vorzugsweise den M 30624 FGAFP,
da es den bei Reichelt gibt und er im Grunde alle meine Anforderungen
erfüllt.
Nun habe ich mir mal ein Datenblatt runtergeladen und darin steht,
dass der Flashspeicher nur 100 mal beschreibbar wäre.
Das ist ja nicht besonders viel für eine Entwicklungsphase.
Und wenn ich den Controller auf meine Platine löte, ist es ja auch
nicht mehr so einfach ihn auszutauschen, wenn der Flash-Speicher im
Eimer ist. Mal ganz abgesehn von den Kosten eines neuen Controllers...

Also, stimmt es, dass der Speicher nur 100 mal beschreibbar ist?
Oder ist das vielleicht nur der Wert, den der Hersteller garantiert
und in Wirklichkeit ist er meistens viel öfters beschreibbar?
Oder kann man den Programmcode vielleicht zum Debuggen in den RAM
laden? Von der Speicherorganisation scheind es so, als lägen Flash und
RAM im gleichen Adressraum. (Habe das Datenblatt nur grob überflogen)

Gibt es vielleicht sonst noch Wege, dieses Problem zu umgehen?

Da gibt's ne App Note dazu. Ist absolut kein Problem. Wenn ich's
richtig im Kopf habe kanst Du das Teil "in reality" ein paar zig
tausend mal flashen.

Zum Thema Speicherorganisation - da liegst Du falsch. Das INTERNE Ram
beginnt üblicherweise um 0x400 (kann glaube ich je nach CPU Typ
varieren). Flash beginnt (abhängig von der Grösse) am "oberen" Ende
also z.B. 0xA0000.

Ach, und nochwas:
Ich habe grade bei Reichelt gesehn, dass der 5V Typ am Ende mit FGAFP
gekennzeichnet ist und der 3V Typ mit FGMFP.
Im datenblatt heisst der 5V Typ aber FGPS und der 3V Typ FGLPS.
Hat das einen Grund?

Die Typen sind etwas verwirrlich. Wenn Du auf die Renesas Seite gehst
solltest Du klar kommen (sprich schauen dass Du das richtige Datenblat
runterziehst). Ich verwende im Moment den M30626FHPGP. Das ist ein
3.3V Typ hat aber 384KB Flash und 32KB Ram. Der ist ziemlich neu -
also wenn's um ein neues Design geht macht der vielleicht für Dich
auch am Meisten Sinn. Der ist im TQFP Gehäuse. Gibt auch eine sonst
identische Variante in QFP (M30626FHPFP)

Ein Nachteil der M16C's ist vielleicht deren Herkunft aus dem
"Japanischen" Sprachraum. Will sagen die Dokus sind teilweise so
komisch geschrieben dass man nie so ganz sicher sein kann was jetzt
genau gemeint ist. Auch steht in den kleingedruckten "Notes" meist das
Wichtigste. Grundsätzlich sind das aber wirklich ganz heisse Dinger

Markus

 

[Grzegorz Zalot]

Hallo Michael Dreschmann !:
....

ich möchte in meinem nächsten Projekt (auf Anraten dieser NG) gerne
einen M16C Mikrocontroller verwenden. Vorzugsweise den M 30624 FGAFP,
da es den bei Reichelt gibt und er im Grunde alle meine Anforderungen
erfüllt.
Nun habe ich mir mal ein Datenblatt runtergeladen und darin steht,
dass der Flashspeicher nur 100 mal beschreibbar wäre.
Das ist ja nicht besonders viel für eine Entwicklungsphase.
Und wenn ich den Controller auf meine Platine löte, ist es ja auch
nicht mehr so einfach ihn auszutauschen, wenn der Flash-Speicher im
Eimer ist. Mal ganz abgesehn von den Kosten eines neuen Controllers...

Also, stimmt es, dass der Speicher nur 100 mal beschreibbar ist?

Nein. Soweit ich weiss, in der Praxis mindestens 10 tausend. Unsere Versuche
koennen einige hunderte nachweisen.

Oder ist das vielleicht nur der Wert, den der Hersteller garantiert
und in Wirklichkeit ist er meistens viel öfters beschreibbar?

Genau.
....

HTH
--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl

 

[Gerald Oppen]

Michael Dreschmann schrieb:

Nun habe ich mir mal ein Datenblatt runtergeladen und darin steht,
dass der Flashspeicher nur 100 mal beschreibbar wäre.

Irgendwo hatte ich gelesen dass das ein Druckfehler sein soll
und eigentlich 100 000 bedeuten sollte.

Wenn ich wiede darüber stolpere sag ich Dir wo es steht...

Gerald

 

[Olaf Kaluza]

Michael Dreschmann <michaeldre@gmx.de> wrote:

ich möchte in meinem nächsten Projekt (auf Anraten dieser NG) gerne
einen M16C Mikrocontroller verwenden. Vorzugsweise den M 30624 FGAFP,

Jau, der ist goil.

Nun habe ich mir mal ein Datenblatt runtergeladen und darin steht,
dass der Flashspeicher nur 100 mal beschreibbar wäre.

Kommt mir auch relativ wenig vor. Aber du solltest noch etwas anderes
bedenken. Der Hersteller garantiert dir ja auch 10 oder mehr Jahre
Haltbarkeit. Selbst wenn er wirklich nur 100 mal beschreibbar ist, so
kannst du den ganz locker ein paar Tausendmal beschreiben. Bloss sind
die Daten dann halt keine 10 Jahre sondern nur noch 1 Jahr oder so
haltbar. Fuer einen Prototyp kein Problem die verkauft man ja nicht.

Olaf


--
D.i.e.s.S. (K.)

 

[Michael Dreschmann]

Hi,

danke für deine Antwort.

Selbst wenn er wirklich nur 100 mal beschreibbar ist, so
kannst du den ganz locker ein paar Tausendmal beschreiben. Bloss sind
die Daten dann halt keine 10 Jahre sondern nur noch 1 Jahr oder so
haltbar. Fuer einen Prototyp kein Problem die verkauft man ja nicht.

Das wusste ich noch gar nicht. D.h. desto öfter ich einen Flash
beschreibe (bzw. lösche) desto kürzer hält er die Daten...
Naja, dann werd ich einfach mal loslegen..

Cu, Michael

 

[Michael Dreschmann]

Hi!

erstmal vielen Dank für deine ausführliche Antwort.

Da gibt's ne App Note dazu. Ist absolut kein Problem. Wenn ich's
richtig im Kopf habe kanst Du das Teil "in reality" ein paar zig
tausend mal flashen.

na dann ist ja alles ok.

Zum Thema Speicherorganisation - da liegst Du falsch. Das INTERNE Ram
beginnt üblicherweise um 0x400 (kann glaube ich je nach CPU Typ
varieren). Flash beginnt (abhängig von der Grösse) am "oberen" Ende
also z.B. 0xA0000.

Äh, also ich meinte, dass ROM und RAM sozusagen über den selben Bus
angesprochen werden können. Nicht wie beim AVR, wo Flash und RAM/IO
völlig getrennt sind - also beide bei 0x0000 anfangen. Aber das is ja
nun egal, wenn der Flash doch öfters beschrieben werden kann.

Die Typen sind etwas verwirrlich. Wenn Du auf die Renesas Seite gehst
solltest Du klar kommen (sprich schauen dass Du das richtige Datenblat
runterziehst)

Sorry, haste da ne Adresse? Ich hab das Datenblatt auf so ner
Uni-Seite gefunden, wo die mit dem Controller ein Projekt gemacht
haben.

Ich verwende im Moment den M30626FHPGP. Das ist ein
3.3V Typ hat aber 384KB Flash und 32KB Ram.

Gibts dazu auf der Renesas Seite auch Infos? Dann schau ich mir den
natürlich auch mal an... Allerdings denke ich, dass 256K schon ne
menge Holz sind...

Da du dich ja anscheinend ganz gut mit den Dingern auskennst würde ich
gerne noch ein paar Fragen stellen, die mir beim Durchlesen des
Datenblatts so gekommen sind. Wäre toll, wenn du oder auch jemand
anderes zu der ein oder anderen Frage was sagen könnte:

1. Mikroprozessormode/Extendet-RAM Mode:
Sehe ich das richtig, dass der Controller im ľP-Mode den internen
Flash gar nicht ansprechen kann, oder heisst das nur, dass ich z.B.
keine Konstanten aus dem Flash laden kann, der Code im int. ROM aber
schon abgearbeitet wird? (Wäre super, weil ich dann praktisch 1 MB
ext. Bereich hätte, sonst fehlen ja 256K)
Ich vermute aber ehr nein, so dass ich für max. ext. Adressraum
allerdings mit "Code im Controller" den Extendet-RAM Mode brauche,
richtig?

2. BCLK:
Das ist wohl die Clock für die CPU und den ext. Bus. Sinnvollerweise
würde ich die gerne auf volle OSC Freq. stellen, also auf 16MHz, damit
ich auch die max. Performance erhalte. Das bedeutet ja dann, dass ein
kompletter ext. RAM Zugriff (ohne Waitstates) innerhalb von einem
Takt, also 62.5ns passiert. Reichen dafür die 55ns SRAM Typen oder
stehen die 55ns nur für einen Teil des Zugriffvorgangs? Das hatte
letztens schonmal jemand hier gefragt, aber zu einer richtigen klaren
Antwort kam es leider nicht, jedenfalls hab ich keine gelesen.

3. CS3:
Dann habe ich es so verstanden, dass das CS3 Signal nur für den
untersten ext. 8K Block aktiviert wird. Heisst dass, ich kann CS3 als
"Eingang" für die Adressdekodierung meiner Perepheriehardware nehmen,
so dass ich nur noch 13 Adressen zu dekodieren brauche?
Und ausserdem, dass ich für diesen 8K Block gesondert einen Waitstate
aktivieren kann?
Funktioniert das mit dem RDY Signal so, dass es einfach so lange auf
Low gehalten wird, bis die ext. Perepherie Hardware "fertig" ist, also
die Adresse/Daten lange genug anlag?

4. Programmierung:
Ist es richtig, dass ich zum Programmieren nur meinen PC an einen UART
des Controllers anschliessen muss, und ich so mit dem Boot-Code meinen
eigentlichen Code draufladen kann? Kann der Boot-Code auch
draufbleiben, wenn der Controller "Stand-Alone" laufen soll?
Erlaubt dieser Code vielleicht sogar Debugging?

Sorry für die vielen Fragen. Habe bis jetzt nur AVR gemacht und der
hatte doch einige dieser Features nicht.

Cu, Michael

 

[Michael Dreschmann]

Hi!

Irgendwo hatte ich gelesen dass das ein Druckfehler sein soll
und eigentlich 100 000 bedeuten sollte.

Na das wäre natürlich genial...

Wenn ich wiede darüber stolpere sag ich Dir wo es steht...

Nicht nötig, glaub ich dir schon. Werd jetzt einfach mal loslegen und
schaun was passiert...

Cu, Michael

 

[Dirk Ruth]

On Sat, 26 Jul 2003 00:50:09 GMT, michaeldre@gmx.de (Michael
Dreschmann) wrote:

Hi!

Irgendwo hatte ich gelesen dass das ein Druckfehler sein soll
und eigentlich 100 000 bedeuten sollte.

Na das wäre natürlich genial...

Wenn ich wiede darüber stolpere sag ich Dir wo es steht...

Nicht nötig, glaub ich dir schon. Werd jetzt einfach mal loslegen und
schaun was passiert...

unter http://www.m16c.de/ dann EVB-Board-Club -> Important Tips unter
"Every DOWNLOAD the MCU is flashed !"

"Contrary to the Data in the USER MANUAL you could Flash the MCU more
than 100 times - you could flash the M16C minimum 100.000 times. "


Tschö
Dirk

 

[Markus Zingg]

Hallo Michael

Hi!

erstmal vielen Dank für deine ausführliche Antwort.

bitte - man muss ja dem M16C etwas helfen. Das Teil ist so gut dass es
wirklich schwer zu verstehen ist warum nicht mehr Leute damit was tun.
Ok, QFP ist halt etwas schwieriger als DIL... Die Teile sind
heutzutage auch gut verfügbar (z.B. von Glyn oder Rutronik). Reichelt
hat vielleicht nicht alle Typen aber sonst kanst Du dort ja anfragen.

[snip]

Zum Thema Speicherorganisation - da liegst Du falsch. Das INTERNE Ram
beginnt üblicherweise um 0x400 (kann glaube ich je nach CPU Typ
varieren). Flash beginnt (abhängig von der Grösse) am "oberen" Ende
also z.B. 0xA0000.

Äh, also ich meinte, dass ROM und RAM sozusagen über den selben Bus
angesprochen werden können. Nicht wie beim AVR, wo Flash und RAM/IO
völlig getrennt sind - also beide bei 0x0000 anfangen. Aber das is ja
nun egal, wenn der Flash doch öfters beschrieben werden kann.

ACK - nein, das Teil hat sogesehen nur einen Adressraum. Sonst
müsstest Du mit externer Logik ein Bankswitching realisieren (d.h.
kommt auf den Typ an. Der von mir verwendete hat sowas schon eingebaut
um total 4MB zu adressieren - brauche ich aber nicht).

Die Typen sind etwas verwirrlich. Wenn Du auf die Renesas Seite gehst
solltest Du klar kommen (sprich schauen dass Du das richtige Datenblat
runterziehst)

Sorry, haste da ne Adresse? Ich hab das Datenblatt auf so ner
Uni-Seite gefunden, wo die mit dem Controller ein Projekt gemacht
haben.

http://www.renesas.com/eng/products/mpumcu/16bit/m16c/index.html

Ich verwende im Moment den M30626FHPGP. Das ist ein
3.3V Typ hat aber 384KB Flash und 32KB Ram.

Gibts dazu auf der Renesas Seite auch Infos? Dann schau ich mir den
natürlich auch mal an... Allerdings denke ich, dass 256K schon ne
menge Holz sind...

Siehe Link. Beachten musst Du auch dass wie erwähnt nur ein Adressraum
vorhanden ist. D.h. je mehr Flash desto weniger Adressraum für
Pheripherie (z.B. externes Ram etc.) Ok, das kommt nun auf den Modus
auch noch an. Mit dem 4MB Modus habe ich mich zuwenig auseinander
gesetzt.

Da du dich ja anscheinend ganz gut mit den Dingern auskennst würde ich
gerne noch ein paar Fragen stellen, die mir beim Durchlesen des
Datenblatts so gekommen sind. Wäre toll, wenn du oder auch jemand
anderes zu der ein oder anderen Frage was sagen könnte:

Es geht so Dieser Kontroller ist so vielseitig dass (zumindes ich)
den nicht komplett ausnützen kann mit ein paar mal Durchlesen des
Datenblattes. Das Konzept ist aber IMHO genial und die Dinge die ich
brauche klappen bestens. Auch die Softwareumgebung von Renesas ist
wirklich gut und hat einige positive Überraschungen zu bieten. Was ich
nicht tun würde ist mit den gepushten Produkten von IAR etc. zu
Arbeiten. Einfach NC30, TM und KD30 installieren - das reicht völlig.

1. Mikroprozessormode/Extendet-RAM Mode:
Sehe ich das richtig, dass der Controller im ľP-Mode den internen
Flash gar nicht ansprechen kann, oder heisst das nur, dass ich z.B.
keine Konstanten aus dem Flash laden kann, der Code im int. ROM aber
schon abgearbeitet wird? (Wäre super, weil ich dann praktisch 1 MB
ext. Bereich hätte, sonst fehlen ja 256K)
Ich vermute aber ehr nein, so dass ich für max. ext. Adressraum
allerdings mit "Code im Controller" den Extendet-RAM Mode brauche,
richtig?

Naja, es gibt den Mikroprozessor Mode. In diesem Mode kennt die CPU
nichts internes mehr - also nur noch was am externen Adress/Datebus
hängt. Dann gibts den "Memory expansion Mode". In diesem Modus teilt
sich die CPU den Adressraum mit dem externen und internen Speicher
(egal ob internes Flash oder Ram). Dieser Modus ist wirklich "nett"
wenn man Pheripherie anschliessen will und z.B. noch etwas mehr
Speicher braucht etc. Ich habe in meinem Design z.B. 2 Pheripherien
und ein externes SRAM.

2. BCLK:
Das ist wohl die Clock für die CPU und den ext. Bus. Sinnvollerweise
würde ich die gerne auf volle OSC Freq. stellen, also auf 16MHz, damit
ich auch die max. Performance erhalte. Das bedeutet ja dann, dass ein
kompletter ext. RAM Zugriff (ohne Waitstates) innerhalb von einem
Takt, also 62.5ns passiert. Reichen dafür die 55ns SRAM Typen oder
stehen die 55ns nur für einen Teil des Zugriffvorgangs? Das hatte
letztens schonmal jemand hier gefragt, aber zu einer richtigen klaren
Antwort kam es leider nicht, jedenfalls hab ich keine gelesen.

BCLK ist einfach das CPU Clock Signal welches die CPU intern verwendet
welches nach aussen geführt ist und per Software ausgeschaltet werden
kann. Die CPU unterstützt für ihre eigene Funktion die main clock, sub
clock, ring oscillator clock oder PLL clock. Damit kannst Du die CPU
z.B. intern mit 16, extern mit 8 Mhz takten. Die von mir erwähnte CPU
läuft übrigens maximal mit 24Mhz (auch eine kleine neuerung). Das geht
aber nur mit extern 12Mhz und intern PLL Clock (ok, es läuft auch mit
einem externen 24Mhz Quarz ist aber out of spec).

Natürlich sollte das RAM schnell genug sein. Mit der 16Mhz Variante
müsste 55nS ok sein. Ich verwende aber ein 16 Bit organisiertes Ram
von Samsung (K6R4016V1D-TI10) das ist 10nS schnell - also wirklich
kein Probelm. Da dieses Ram 16x256KB organisiert ist hätte ich
theoretisch 512KB Ram. Da aber der Adressraum anderweitig benutzt ist
verbleiben effektiv nur noch 320KB - hat mir aber gereicht. Wenn das
bei Dir um ein Studium Projekt oder was privates geht kann ich Dir ein
paar davon organisieren. Sonst wird dir z.B. Rutronik solche Ram's
sicher gerne verkaufen.

3. CS3:
Dann habe ich es so verstanden, dass das CS3 Signal nur für den
untersten ext. 8K Block aktiviert wird. Heisst dass, ich kann CS3 als
"Eingang" für die Adressdekodierung meiner Perepheriehardware nehmen,
so dass ich nur noch 13 Adressen zu dekodieren brauche?

Die CS Signale und deren Mapping in den Adressraum varieren von Typ zu
Typ. Bei der von mir verwendeten CPU wurde CS3 z.b. dem grösseren
Flash Adressraum "geopfert" und es stehen also nur CS0 - CS2 zur
verfügung - ein Nachteil, hat mir aber (noch) gereicht. Ich bin mir
nicht sicher ob ich Deine Frage richtig verstehe, aber ich habe z.B.
eine CF - Karte an 0x10000 gemappt, führe aber nur 4 Adresslietungen
(A0-A2 und A10) zur Karte hin. Wenn ich dann was an Adresse 0x10000
schreibe, wird CS1 (low) aktiv und die Karte "sieht" dann
logischerweise nur maximal A0 - A10 (wobei A3 - A9 fix auf GND gelegt
sind). Das externe RAM hingegen hängt bei mir an CS0 und da sind alle
Adressleitungen verbunden.

Und ausserdem, dass ich für diesen 8K Block gesondert einen Waitstate
aktivieren kann?

Bei der von mir verwendeten CPU geht das. Ich glaube aber (bin mir
hier nicht sicher) dass das ein neues (und wertvolles) Feature dieser
CPU ist. Will sagen wenn ich mich nicht irre kann das die von Dir z.Z.
Favorisierte CPU noch nicht. Das Datenblatt wird hier aber sicher
klärung bieten.

Funktioniert das mit dem RDY Signal so, dass es einfach so lange auf
Low gehalten wird, bis die ext. Perepherie Hardware "fertig" ist, also
die Adresse/Daten lange genug anlag?

Ja, mit RDY fügst Du Waitstates ein. HOLD könntest Du auch noch
verwenden. War mir aber etwas zu aufwendig (ich wollte möglichst keine
externe Glue Logik) Da die von mir verwendete CPU aber pro /CS
waistates erzeugen kann brauchte ich dieses Feature nicht.

4. Programmierung:
Ist es richtig, dass ich zum Programmieren nur meinen PC an einen UART
des Controllers anschliessen muss, und ich so mit dem Boot-Code meinen
eigentlichen Code draufladen kann? Kann der Boot-Code auch
draufbleiben, wenn der Controller "Stand-Alone" laufen soll?
Erlaubt dieser Code vielleicht sogar Debugging?

Ja, es gibt ein Tool (Flashstart) mit dem Du den Code in den
Kontroller überträgst. Dazu brauchst Du blos ein serielles Kabel an
dessen einem Ende ein MAX232 oder so die Pegel für den Kontroller
anpasst. Für die SW Entwicklung gibt's einen sogenannten "Rom
Monitor". Diese kleine Firmware programmierst Du in den Kontroller,
und die funktioniert dann zusammen mit dem KD30 Debugger. Damit ist
schon einiges an Debugging zum Nulltarif möglich. Die paar Bytes die
der Rom Monitor braucht fallen bei dem grosszügigen Flash nicht
wirklich ins Gewicht. Ist die Software fertig, flashst Du diese
einfach komplett in die CPU (überschreibst damit den RomMonitor) und
gut is. Von Glyn und Renesas selber gibt's Evaluation boards. Die sind
nicht so wahnsinnig teuer und ermöglichen einen sanften schnellen
Start. Natürlich geht's auch "the hard way"

Sorry für die vielen Fragen. Habe bis jetzt nur AVR gemacht und der
hatte doch einige dieser Features nicht.

No problemo.

Markus

 

[Michael Dreschmann]

Hi!

bitte - man muss ja dem M16C etwas helfen. Das Teil ist so gut dass es
wirklich schwer zu verstehen ist warum nicht mehr Leute damit was tun.

Bin jetzt schon mächtig gespannt.

Siehe Link. Beachten musst Du auch dass wie erwähnt nur ein Adressraum
vorhanden ist. D.h. je mehr Flash desto weniger Adressraum für
Pheripherie (z.B. externes Ram etc.) Ok, das kommt nun auf den Modus
auch noch an. Mit dem 4MB Modus habe ich mich zuwenig auseinander
gesetzt.

So, wie ich das verstanden habe, kann man dann verschiedene Blöcke des
ext. Bereichs umschalten, aber das hätte man ja auch ohne dieses
"vorgesehene Feature" mit 2, 3 IO-Pins machen können. Ich sehe
irgendwie nicht so ganz den Vorteil...
Da ich aber sowiso nicht vorhatte, die 1MB Grenze zu durchstossen, ist
das erstmal egal...
Das mit dem Flash stimmt natürlich. Ich denke da werde ich erst mal
bei dem "Reichelt-Typ" bleiben. Sonst hab ich naher noch zuwenig RAM.
Und 256K sollte ja nun wirklich erst mal reichen, das grösste was ich
bis jetzt hatte waren 8K...

Auch die Softwareumgebung von Renesas ist
wirklich gut und hat einige positive Überraschungen zu bieten. Was ich
nicht tun würde ist mit den gepushten Produkten von IAR etc. zu
Arbeiten. Einfach NC30, TM und KD30 installieren - das reicht völlig.

Über die Entwicklungsumgebung habe ich mir bisher noch gar keine
Gedanken gemacht. Ich habe einfach mal gehofft, dass es da schon
irgendwas brauchbares geben wird.
Gibts diese drei Programme (NC30, TM und KD30) umsonst? Das wär
natürlich super.

Dann gibts den "Memory expansion Mode". In diesem Modus teilt
sich die CPU den Adressraum mit dem externen und internen Speicher
(egal ob internes Flash oder Ram). Dieser Modus ist wirklich "nett"
wenn man Pheripherie anschliessen will und z.B. noch etwas mehr
Speicher braucht etc. Ich habe in meinem Design z.B. 2 Pheripherien
und ein externes SRAM.

Ok, das ist auch das was ich brauche. Also, alles klar...

Die CPU unterstützt für ihre eigene Funktion die main clock, sub
clock, ring oscillator clock oder PLL clock.

Ich glaube ring Osc. und PLL gibts bei meinem Model (M 30624) noch
nicht.

Damit kannst Du die CPU
z.B. intern mit 16, extern mit 8 Mhz takten. Die von mir erwähnte CPU
läuft übrigens maximal mit 24Mhz (auch eine kleine neuerung). Das geht
aber nur mit extern 12Mhz und intern PLL Clock (ok, es läuft auch mit
einem externen 24Mhz Quarz ist aber out of spec).

Was meinst du mit int. 16 MHz und ext. 8 MHz? Nur dass der ext.
anliegende Takt 8 MHz ist und intern verdoppelt wird, oder dass der
ganze ext. Bus dann mit 8 MHz läuft?
Das scheind der M 30624 auch noch nicht zu können, ich bin mit 16 MHz
aber erstmal zufrieden.

Natürlich sollte das RAM schnell genug sein. Mit der 16Mhz Variante
müsste 55nS ok sein. Ich verwende aber ein 16 Bit organisiertes Ram
von Samsung (K6R4016V1D-TI10) das ist 10nS schnell - also wirklich
kein Probelm. Da dieses Ram 16x256KB organisiert ist hätte ich
theoretisch 512KB Ram. Da aber der Adressraum anderweitig benutzt ist
verbleiben effektiv nur noch 320KB - hat mir aber gereicht.

Hm, zu der Adressraumorganisation hätte ich da auch noch ne kleine
Frage (Ich denke jetzt an 16 Bit, seperaten ext. Bus):
Und zwar bin ich etwas durcheinander, da ja der ext. Datenbus 16-Bit
organisiert ist, aber der ext. Adressraum mit den 20 Adressleitungen
Byteweise angesprochen werden kann. Heisst das, dass bei einem 16-Bit
Zugriff die Adressleitung 0 irrelevant wird?
Also, ich hatte vor, zwei RAMs vom Typ 512Kx8 zu verwenden. Einen an
das High-Byte und einen an das Low-Byte des Datenbusses.
Für die Bus Signale wollte ich den Modus mit RD, WRL und WRH nehmen.
RD wollte ich an beide RAMs führen, WRL an den Low-Byte RAM, WRH an
den High-Byte RAM. Die Adressleitungen vom M16C würde ich dann ab A1
an beide RAMs legen. Chipselect beider RAMs würde enabled wenn ext.
Adresse anliegt, es aber keine Adresse für ext. Perepherie ist.
Ich würde zwar etwas RAM verschwenden, da ja die letzten 256K vom
Flash-ROM belegt sind, aber das wär mir mal egal.
Ext. Perepherie wäre dann z.B. ein IDE Interface. Dieses hat nun aber
einen 16 Bit Datenbuss. Da hatte ich dann vor, dessen WR nur auf low
zu setzten, wenn WRL und WRH vom M16C low sind. RD könnte ich ja
einfach verbinden. Die Adresse für die ca. 10 Register des IDE
Interfaces würde ich dann wieder aus A1-A4 des Datenbusses vom M16C
generieren.
Entsprechend für andere ext. Perepherie.

Würde das so funktionieren?

Wenn das
bei Dir um ein Studium Projekt oder was privates geht kann ich Dir ein
paar davon organisieren. Sonst wird dir z.B. Rutronik solche Ram's
sicher gerne verkaufen.

Ist ein privates Projekt. Danke für das Angebot, aber nicht nötig.
Soviel kosten die Dinger ja auch nicht. Und bei Reichelt muss ich
sowiso bestellen.

Die CS Signale und deren Mapping in den Adressraum varieren von Typ zu
Typ. Bei der von mir verwendeten CPU wurde CS3 z.b. dem grösseren
Flash Adressraum "geopfert" und es stehen also nur CS0 - CS2 zur
verfügung - ein Nachteil, hat mir aber (noch) gereicht.

Hab's mir grade nochmal durchgelesen und denke, das müsste bei dem
M 30624 so funktionieren (mit dem CS3). Werds einfach ausprobieren.

Ich bin mir
nicht sicher ob ich Deine Frage richtig verstehe, aber ich habe z.B.
eine CF - Karte an 0x10000 gemappt, führe aber nur 4 Adresslietungen
(A0-A2 und A10) zur Karte hin. Wenn ich dann was an Adresse 0x10000
schreibe, wird CS1 (low) aktiv und die Karte "sieht" dann
logischerweise nur maximal A0 - A10 (wobei A3 - A9 fix auf GND gelegt
sind). Das externe RAM hingegen hängt bei mir an CS0 und da sind alle
Adressleitungen verbunden.

Hm, ich werde mir das einfach noch ein paar mal durchlesen... Das wird
schon. Ansonsten bau ich eben doch nen Adressdekoder ein. Ich möchte
halt ausser den paar ext. Perepheriegeräten möglichst alles voll RAM
machen.

Bei der von mir verwendeten CPU geht das. Ich glaube aber (bin mir
hier nicht sicher) dass das ein neues (und wertvolles) Feature dieser
CPU ist. Will sagen wenn ich mich nicht irre kann das die von Dir z.Z.
Favorisierte CPU noch nicht. Das Datenblatt wird hier aber sicher
klärung bieten.

Hab's grade eben nochmal gelesen. Scheind auch bei dem M 30624 zu
funkionieren.

Ja, mit RDY fügst Du Waitstates ein. HOLD könntest Du auch noch
verwenden.

Was ist denn der Unterschied zwischen RDY und HOLD?
Das habe ich irgendwie noch nicht so ganz raus.
Gibt des denn Hardware, die das RDY Signal direkt anspricht? Oder baut
man sich da einen Counter, der nachdem RD/WR auf Low ging die BCLK
zählt und erst nach ein paar Takten RDY wieder freigibt?

Ja, es gibt ein Tool (Flashstart) mit dem Du den Code in den
Kontroller überträgst.

(snip)

Ok, das ist ja wunderbar. Scheind ein richtig klasse Teil zu sein. *g*

Und vielen Dank nochmal für alle Eure guten Antworten hier.
Aber eine Frage hätte ich noch, was mir eben auffiel:
Der Controller hat ja zwei Stackpointer, einen für Interrupts und
einen für Normalbetrieb. Wo ist denn da der Sinn?

Cu, Michael

 

[Markus Zingg]

Hallo Michael

[snip]

Siehe Link. Beachten musst Du auch dass wie erwähnt nur ein Adressraum
vorhanden ist. D.h. je mehr Flash desto weniger Adressraum für
Pheripherie (z.B. externes Ram etc.) Ok, das kommt nun auf den Modus
auch noch an. Mit dem 4MB Modus habe ich mich zuwenig auseinander
gesetzt.

So, wie ich das verstanden habe, kann man dann verschiedene Blöcke des
ext. Bereichs umschalten, aber das hätte man ja auch ohne dieses
"vorgesehene Feature" mit 2, 3 IO-Pins machen können. Ich sehe
irgendwie nicht so ganz den Vorteil...

Klar, aber man spart dabei IO Pin's. Die nehmen dazu die /CS1 - /CS3
Leitungen. Hat dann ein ganz nettes Adresslayout. In der "Mitte" des
Adressraumes hat es dann 8 256KB fenster. Da das aber "Jenglisch" ist
sehe ich da auch noch nicht so ganz durch. Habe mir aber darüber nicht
den Kopf zerbrochen da ich's nicht brauche.

Da ich aber sowiso nicht vorhatte, die 1MB Grenze zu durchstossen, ist
das erstmal egal...

Gehen würde das leicht. Allerdings macht dann der C-Compiler nicht
mehr mit und das ist für mich ein No-Go. Sollte ich sowas brauchen
kommt mir ein richtiger 32 Bitter in's Haus. Will damit sagen jeder
Kontroller hat seinen Einsatz und es käme ja auch niemandem in den
Sinn mit einer "Ente" 5 Tonnen Kies zu transportieren.

[snip]

Auch die Softwareumgebung von Renesas ist
wirklich gut und hat einige positive Überraschungen zu bieten. Was ich
nicht tun würde ist mit den gepushten Produkten von IAR etc. zu
Arbeiten. Einfach NC30, TM und KD30 installieren - das reicht völlig.

Über die Entwicklungsumgebung habe ich mir bisher noch gar keine
Gedanken gemacht. Ich habe einfach mal gehofft, dass es da schon
irgendwas brauchbares geben wird.
Gibts diese drei Programme (NC30, TM und KD30) umsonst? Das wär
natürlich super.

Naja, man kann die Umgebung von Renesas runterladen und dann - so
glaube ich - ein halbes Jahr lang "evaluieren"...

[snip]

Die CPU unterstützt für ihre eigene Funktion die main clock, sub
clock, ring oscillator clock oder PLL clock.

Ich glaube ring Osc. und PLL gibts bei meinem Model (M 30624) noch
nicht.

Wie gesagt ich habe mich nur kurz mit dem Vorgänger beschäftigt weil
mir diverse Dinge an der neueren CPU gut gefallen haben (24Mhz etc.)

Damit kannst Du die CPU
z.B. intern mit 16, extern mit 8 Mhz takten. Die von mir erwähnte CPU
läuft übrigens maximal mit 24Mhz (auch eine kleine neuerung). Das geht
aber nur mit extern 12Mhz und intern PLL Clock (ok, es läuft auch mit
einem externen 24Mhz Quarz ist aber out of spec).

Was meinst du mit int. 16 MHz und ext. 8 MHz? Nur dass der ext.
anliegende Takt 8 MHz ist und intern verdoppelt wird, oder dass der
ganze ext. Bus dann mit 8 MHz läuft?

Letzteres

Das scheind der M 30624 auch noch nicht zu können, ich bin mit 16 MHz
aber erstmal zufrieden.

Natürlich sollte das RAM schnell genug sein. Mit der 16Mhz Variante
müsste 55nS ok sein. Ich verwende aber ein 16 Bit organisiertes Ram
von Samsung (K6R4016V1D-TI10) das ist 10nS schnell - also wirklich
kein Probelm. Da dieses Ram 16x256KB organisiert ist hätte ich
theoretisch 512KB Ram. Da aber der Adressraum anderweitig benutzt ist
verbleiben effektiv nur noch 320KB - hat mir aber gereicht.

Hm, zu der Adressraumorganisation hätte ich da auch noch ne kleine
Frage (Ich denke jetzt an 16 Bit, seperaten ext. Bus):
Und zwar bin ich etwas durcheinander, da ja der ext. Datenbus 16-Bit
organisiert ist, aber der ext. Adressraum mit den 20 Adressleitungen
Byteweise angesprochen werden kann. Heisst das, dass bei einem 16-Bit
Zugriff die Adressleitung 0 irrelevant wird?

Das ist der Wahnsinn an dieser CPU. Ob Du's glaubst oder nicht.
Praktisch ALLES kann auf verschiedene Arten konfiguriert werden. Diese
CPU unterstützt 8 bit Datenbus oder 16 Bit Datenbus, gemultiplexten
Adress und Datenbus, getrenter Adress und Datenbus. 16 Bit Zugriffe
können auch auf zwei Arten realisiert werden.

Also, ich hatte vor, zwei RAMs vom Typ 512Kx8 zu verwenden. Einen an
das High-Byte und einen an das Low-Byte des Datenbusses.

Das klapt so sicher auch. Ich habe einen "frühen" Prototypen so
aufgebaut.

Für die Bus Signale wollte ich den Modus mit RD, WRL und WRH nehmen.
RD wollte ich an beide RAMs führen, WRL an den Low-Byte RAM, WRH an
den High-Byte RAM. Die Adressleitungen vom M16C würde ich dann ab A1
an beide RAMs legen. Chipselect beider RAMs würde enabled wenn ext.
Adresse anliegt, es aber keine Adresse für ext. Perepherie ist.
Ich würde zwar etwas RAM verschwenden, da ja die letzten 256K vom
Flash-ROM belegt sind, aber das wär mir mal egal.

So sollte das klappen. IMHO müsstest Du hier nichts verschwenden.

Ext. Perepherie wäre dann z.B. ein IDE Interface. Dieses hat nun aber
einen 16 Bit Datenbuss. Da hatte ich dann vor, dessen WR nur auf low
zu setzten, wenn WRL und WRH vom M16C low sind. RD könnte ich ja
einfach verbinden. Die Adresse für die ca. 10 Register des IDE
Interfaces würde ich dann wieder aus A1-A4 des Datenbusses vom M16C
generieren.
Entsprechend für andere ext. Perepherie.

IMHO must Du hier nicht mal speziell was unternehmen. Wenn Du
sicherstellst dass alle Zugriffe mit 16 Bit ausgeführt werden setzt
die CPU automatisch die Leitungen richtig.

Würde das so funktionieren?

Danke schon. Nachteil der /RD /WRK /WRH Methode ist dass physikalisch
auf dem Bus immer 16 Bit GELESEN werden. Das würde z.B. verunmöglichen
einen 8 Bit Registerzugriff auf einem CompactFlash zu machen was
problematisch sein KANN. Alternativ kanst Du aber eben auch /RD /WR
und /BHE und /A0 verdrahten. Die CPU macht dann automatisch die
richtige Art des Zugriffes (also 8 oder 16 Bit). Im ersten Anlauf
hatte ich's wie Du, im zweiten anders rum Geht beides.

[snip]

Die CS Signale und deren Mapping in den Adressraum varieren von Typ zu
Typ. Bei der von mir verwendeten CPU wurde CS3 z.b. dem grösseren
Flash Adressraum "geopfert" und es stehen also nur CS0 - CS2 zur
verfügung - ein Nachteil, hat mir aber (noch) gereicht.

Hab's mir grade nochmal durchgelesen und denke, das müsste bei dem
M 30624 so funktionieren (mit dem CS3). Werds einfach ausprobieren.

Definitiv. /CS3 fehlt erst ab 320 KB Flash im erweiterten Modus. Alle
"kleineren" Versionen unterstützen /CS3 - auch meine CPU wenn ich den
internen Speicher nicht in der SFR PM13 gesetzt wird.

Ich bin mir
nicht sicher ob ich Deine Frage richtig verstehe, aber ich habe z.B.
eine CF - Karte an 0x10000 gemappt, führe aber nur 4 Adresslietungen
(A0-A2 und A10) zur Karte hin. Wenn ich dann was an Adresse 0x10000
schreibe, wird CS1 (low) aktiv und die Karte "sieht" dann
logischerweise nur maximal A0 - A10 (wobei A3 - A9 fix auf GND gelegt
sind). Das externe RAM hingegen hängt bei mir an CS0 und da sind alle
Adressleitungen verbunden.

Hm, ich werde mir das einfach noch ein paar mal durchlesen... Das wird
schon.

Aber sicher

Ansonsten bau ich eben doch nen Adressdekoder ein. Ich möchte
halt ausser den paar ext. Perepheriegeräten möglichst alles voll RAM
machen.

Nein, einen Dekoder brauchst Du definitiv nicht.

Bei der von mir verwendeten CPU geht das. Ich glaube aber (bin mir
hier nicht sicher) dass das ein neues (und wertvolles) Feature dieser
CPU ist. Will sagen wenn ich mich nicht irre kann das die von Dir z.Z.
Favorisierte CPU noch nicht. Das Datenblatt wird hier aber sicher
klärung bieten.

Hab's grade eben nochmal gelesen. Scheind auch bei dem M 30624 zu
funkionieren.

Hmm, ich dachte nur ein zusätzlicher sei konfigurierbar gewesen? Hast
Du CSE auch?

Ja, mit RDY fügst Du Waitstates ein. HOLD könntest Du auch noch
verwenden.

Was ist denn der Unterschied zwischen RDY und HOLD?
Das habe ich irgendwie noch nicht so ganz raus.

/RDY fügt waitzyklein ein, /HOLD trennt die CPU vom Bus und hält sie
an. Letzeres ist für DMA.

Gibt des denn Hardware, die das RDY Signal direkt anspricht? Oder baut
man sich da einen Counter, der nachdem RD/WR auf Low ging die BCLK
zählt und erst nach ein paar Takten RDY wieder freigibt?

Naja, wie einer diese Möglichkeiten nutzt ist offen.

Ja, es gibt ein Tool (Flashstart) mit dem Du den Code in den
Kontroller überträgst.

(snip)

Ok, das ist ja wunderbar. Scheind ein richtig klasse Teil zu sein. *g*

Yep, ich bin wirklich auch ziemlich fan. Ich freue mich schon darauf
die Teile mal zu probieren welche ich noch nicht gebraucht habe. Z.b.
die AD, PWM und was da sonst noch alles in dem Ding rumschwirrt

Und vielen Dank nochmal für alle Eure guten Antworten hier.
Aber eine Frage hätte ich noch, was mir eben auffiel:
Der Controller hat ja zwei Stackpointer, einen für Interrupts und
einen für Normalbetrieb. Wo ist denn da der Sinn?

Performance. Die CPU hat ein alternativen Registersatz benutzt man
diesen nur für Interupts muss man die "normalen" Register nicht
sichern. Für den M16C hat Mitsubishi ein Realtime OS geschrieben
dessen API über Softwareinternupts (gitbs auch) implemeintiert ist.
Dabei hat dann das OS auschliesslich den alternativen Registersatz
verwenden, und die "Applikation" die normalen Register.

Nochmals, diese CPU ist sehr vielseitig und Leistungsfähig. Es gibt
Leute die sagen "komplex" - sehe ich aber nicht so. Ist eigentlich
alles leicht verständlich - nur eben Features in grosser Anzahl.

Markus

 

[Gerald Oppen]

Olaf Kaluza schrieb:

haltbar. Fuer einen Prototyp kein Problem die verkauft man ja nicht.

Bist Du sicher? ;-)

Gerald

 

[Michael Dreschmann]

Hi!

Naja, man kann die Umgebung von Renesas runterladen und dann - so
glaube ich - ein halbes Jahr lang "evaluieren"...

Kann man, nachem das halbe Jahr rum ist, auch wieder die Zeit
zurückdrehn oder sonstige Massnahmen ergreifen? ))
Naja wenn's gut ist kann man ja auch mal n paar € für springen
lassen...

Für die Bus Signale wollte ich den Modus mit RD, WRL und WRH nehmen.
RD wollte ich an beide RAMs führen, WRL an den Low-Byte RAM, WRH an
den High-Byte RAM. Die Adressleitungen vom M16C würde ich dann ab A1
an beide RAMs legen. Chipselect beider RAMs würde enabled wenn ext.
Adresse anliegt, es aber keine Adresse für ext. Perepherie ist.
Ich würde zwar etwas RAM verschwenden, da ja die letzten 256K vom
Flash-ROM belegt sind, aber das wär mir mal egal.

So sollte das klappen. IMHO müsstest Du hier nichts verschwenden.

Wie meinst du das? Indem ich andere RAMs und einen anderen Aufbau
verwende? Oder kann ich das sonstwie ändern?
Wenn ich bei den 8 Bit Typen bleibe bräuchte ich ja 2x 384KB, und ob's
die gibt...
Und 2x 256K + 128K gibt nen riesen Verdrahtungsaufwand..
Und wenn ich 16 Bit RAMs nehmen würde hätte ich da auch ne krumme
Zahl.

IMHO must Du hier nicht mal speziell was unternehmen. Wenn Du
sicherstellst dass alle Zugriffe mit 16 Bit ausgeführt werden setzt
die CPU automatisch die Leitungen richtig.

Ja, klar, stimmt, einfach die WRL-Leitung an die 16 Bit Adressen. Dann
könnte man sogar die vereinzelten (eigentlich alle ausser dem
Datenregister) 8 Bit Register des IDE Interfaces 8-Bit mässig lesen.

Würde das so funktionieren?

Danke schon. Nachteil der /RD /WRK /WRH Methode ist dass physikalisch
auf dem Bus immer 16 Bit GELESEN werden. Das würde z.B. verunmöglichen
einen 8 Bit Registerzugriff auf einem CompactFlash zu machen was
problematisch sein KANN.

Sprich man müsste bei 8 Bit die Eingabe immer erst ver &0x00FF en?

Alternativ kanst Du aber eben auch /RD /WR
und /BHE und /A0 verdrahten. Die CPU macht dann automatisch die
richtige Art des Zugriffes (also 8 oder 16 Bit). Im ersten Anlauf
hatte ich's wie Du, im zweiten anders rum Geht beides.

Ist natürlich ein Argument. Ich werde morgen mal versuchen meine
Speicherorganisation auf diese Signale auszulegen.

Ansonsten bau ich eben doch nen Adressdekoder ein. Ich möchte
halt ausser den paar ext. Perepheriegeräten möglichst alles voll RAM
machen.

Nein, einen Dekoder brauchst Du definitiv nicht.

Ok, mit dem CS3 bekomme ich meinen 8K Block, aber darin muss ich ja
noch bischen zwischen den verschiedenen Peripheriegeräten
unterscheiden... Aber die paar Gatter dürften nicht das Problem
werden...

(Waitstate bei CS3)
Hmm, ich dachte nur ein zusätzlicher sei konfigurierbar gewesen? Hast
Du CSE auch?

Hm, CSE find ich grade nicht, aber im CSR Register kann ich für jeden
CS einzeln nen Waitstate enablen.
Die Frage ist natürlich, ob ein Waitstate für das IDE Register
reicht... Sonst muss ich da wohl doch was mit RDY machen.

/RDY fügt waitzyklein ein, /HOLD trennt die CPU vom Bus und hält sie
an. Letzeres ist für DMA.

Ahso... ja, DMA, das Kapitel werde ich mir morgen auch mal
durchlesen... Vielleicht lässt sich das ja auch nutzten...

Aber eine Frage hätte ich noch, was mir eben auffiel:
Der Controller hat ja zwei Stackpointer, einen für Interrupts und
einen für Normalbetrieb. Wo ist denn da der Sinn?

Performance. Die CPU hat ein alternativen Registersatz benutzt man
diesen nur für Interupts muss man die "normalen" Register nicht
sichern. Für den M16C hat Mitsubishi ein Realtime OS geschrieben
dessen API über Softwareinternupts (gitbs auch) implemeintiert ist.
Dabei hat dann das OS auschliesslich den alternativen Registersatz
verwenden, und die "Applikation" die normalen Register.

Ok, dass der alternative Registersatz Sinn macht ist klar. Aber warum
brauch ich dann einen zweiten Stackpointer. Wenn ich nur einen hätte
würde der doch dann lediglich länger, oder?
Für zwei muss ich ja dann auch 2 Speicherbereiche freihalten (ok,
sollte bei den Unmengen an Speicher kein Problem sein *g*)
Übrigens, wenn ein Interrupt grade ausgeführt wird kann diesen doch
ein Interrupt mit höherer Priorität unterbrechen, richtig? Dann muss
ich also den einen Registersatz, den ich nur für die Int's benutze
trozdem bei jedem Interruptbeginn saven, oder?

Nochmals, diese CPU ist sehr vielseitig und Leistungsfähig. Es gibt
Leute die sagen "komplex" - sehe ich aber nicht so. Ist eigentlich
alles leicht verständlich - nur eben Features in grosser Anzahl.

Och, ich Moment finde ich das schon alles recht komplex.
Aber es scheind sich wirklich zu lohnen.

Cu, Michael

 

[Dirk Ruth]

On Sun, 27 Jul 2003 00:28:10 GMT, michaeldre@gmx.de (Michael
Dreschmann) wrote:

Hi!

Naja, man kann die Umgebung von Renesas runterladen und dann - so
glaube ich - ein halbes Jahr lang "evaluieren"...

Kann man, nachem das halbe Jahr rum ist, auch wieder die Zeit
zurückdrehn oder sonstige Massnahmen ergreifen? ))
Naja wenn's gut ist kann man ja auch mal n paar € für springen
lassen...

Es geht das Gerücht um, dass sich der Compiler nach einen halben Jahr
nochmals neu installieren läßt ...

Irgendwo hab ich auch schon mal eine SerienNr. für den Compiler
gesehen, aber bei dem schönen Wetter geh ich eh lieber nach drausen.


Tschö
Dirk

 

[Markus Zingg]

Hallo Michael

[snip]

Wie meinst du das? Indem ich andere RAMs und einen anderen Aufbau
verwende? Oder kann ich das sonstwie ändern?
Wenn ich bei den 8 Bit Typen bleibe bräuchte ich ja 2x 384KB, und ob's
die gibt...
Und 2x 256K + 128K gibt nen riesen Verdrahtungsaufwand..
Und wenn ich 16 Bit RAMs nehmen würde hätte ich da auch ne krumme
Zahl.

Nein, Deine 2x256 KB sind ab 0x30000 gemappt. /CS0 ist nur active low
wenn Du einen Adresse zwischen 0x30000 - 0xcffff ansprichst (das ist
bei der 256 KB Flash 20KB Ram CPU so, also die welche Du nehmen
willst). Du verdrahtest also A1 - A18 an die chips. Wenn A19 high ist
(was deine Ram Bausteine dann ja nicht sehen), "passt" der rest des
Busses so dass deine Ram Bausteine den Bereich von 0 - 2ffff sehen.
D.h. Du kannst die vollen 512 KB nutzen.

[snip]

Denke schon. Nachteil der /RD /WRK /WRH Methode ist dass physikalisch
auf dem Bus immer 16 Bit GELESEN werden. Das würde z.B. verunmöglichen
einen 8 Bit Registerzugriff auf einem CompactFlash zu machen was
problematisch sein KANN.

Sprich man müsste bei 8 Bit die Eingabe immer erst ver &0x00FF en?

Nein, das macht die CPU schon. Wenn aber die PHERIPHERIE macht ein
einem 16Bit Zugriff eventuell was anderes als bei einem 8 Bit Zugriff
und das KANN problematisch sein - KANN, hängt von der Pheripherie ab.
Beispiel, stell Dir vor Du hättest eine 8-Bit Pheripherie. Register 0
- wenn gelesen - setzt irgendeinen internen wichtigen Status zurück.
Du brauchst nun aber unbedingt den Wert in Register 1. Liest Du nun
Register 1, kriegst Du wohl dieses Byte in die CPU rein, die
pheripherie hat aber Register 0 auch gelesen und quasi ohne dass Du
Dir das unbedingt gewahr sein musst diesen einen wichtigen Status
zurückgesetzt.

Alternativ kanst Du aber eben auch /RD /WR
und /BHE und /A0 verdrahten. Die CPU macht dann automatisch die
richtige Art des Zugriffes (also 8 oder 16 Bit). Im ersten Anlauf
hatte ich's wie Du, im zweiten anders rum Geht beides.

Ist natürlich ein Argument. Ich werde morgen mal versuchen meine
Speicherorganisation auf diese Signale auszulegen.

Für's RAM ist's kein Thema, bei Pheripherie kommts darauf an. Bei CF's
must Du entweder immer 16 Bit zugriffe ausführen und dann tatsächlich
Operationen durchführen (z.B. Statusregister und Komandoregister) oder
eben einen sauberen 8 Bit Zugriff implementieren. ACHTUNG, das ist
aber beim M16C so dass nur entweder der ganze Buss mit 16 Bit läuft
oder 8-Bit. Du kannst also nicht pro /CS Area wählen (wäre ganz nett
wenn das ginge).

Ansonsten bau ich eben doch nen Adressdekoder ein. Ich möchte
halt ausser den paar ext. Perepheriegeräten möglichst alles voll RAM
machen.

Nein, einen Dekoder brauchst Du definitiv nicht.

Ok, mit dem CS3 bekomme ich meinen 8K Block, aber darin muss ich ja
noch bischen zwischen den verschiedenen Peripheriegeräten
unterscheiden... Aber die paar Gatter dürften nicht das Problem
werden...

Uhmmm - Du hast doch /CS0 - /CS3 - warum nicht ein Chipselect pro
Pheripherie? Dazu sind die doch da!

(Waitstate bei CS3)
Hmm, ich dachte nur ein zusätzlicher sei konfigurierbar gewesen? Hast
Du CSE auch?

Hm, CSE find ich grade nicht, aber im CSR Register kann ich für jeden
CS einzeln nen Waitstate enablen.

Ja, EINEN. Mit CSE kannst Du dann bis zu zwei weitere definieren. Es
gibt Pheripherie bei der EIN Waitstaite einfach nicht ausreicht.

Die Frage ist natürlich, ob ein Waitstate für das IDE Register
reicht... Sonst muss ich da wohl doch was mit RDY machen.

Für CompactFlash - soviel kann ich dir sagen - reicht EIN Waitstate.
Ich denke das sollte bei IDE Platten nicht schlechter sein.

/RDY fügt waitzyklein ein, /HOLD trennt die CPU vom Bus und hält sie
an. Letzeres ist für DMA.

Ahso... ja, DMA, das Kapitel werde ich mir morgen auch mal
durchlesen... Vielleicht lässt sich das ja auch nutzten...

Aber eine Frage hätte ich noch, was mir eben auffiel:
Der Controller hat ja zwei Stackpointer, einen für Interrupts und
einen für Normalbetrieb. Wo ist denn da der Sinn?

Performance. Die CPU hat ein alternativen Registersatz benutzt man
diesen nur für Interupts muss man die "normalen" Register nicht
sichern. Für den M16C hat Mitsubishi ein Realtime OS geschrieben
dessen API über Softwareinternupts (gitbs auch) implemeintiert ist.
Dabei hat dann das OS auschliesslich den alternativen Registersatz
verwenden, und die "Applikation" die normalen Register.

Ok, dass der alternative Registersatz Sinn macht ist klar. Aber warum
brauch ich dann einen zweiten Stackpointer. Wenn ich nur einen hätte
würde der doch dann lediglich länger, oder?
Für zwei muss ich ja dann auch 2 Speicherbereiche freihalten (ok,
sollte bei den Unmengen an Speicher kein Problem sein *g*)
Übrigens, wenn ein Interrupt grade ausgeführt wird kann diesen doch
ein Interrupt mit höherer Priorität unterbrechen, richtig? Dann muss
ich also den einen Registersatz, den ich nur für die Int's benutze
trozdem bei jedem Interruptbeginn saven, oder?

Ja. Ich denke mal die hatten einen Anwendung mit nur einem Interupt
und 50 Milionen benötigter Chips oder so....

Nochmals, diese CPU ist sehr vielseitig und Leistungsfähig. Es gibt
Leute die sagen "komplex" - sehe ich aber nicht so. Ist eigentlich
alles leicht verständlich - nur eben Features in grosser Anzahl.

Och, ich Moment finde ich das schon alles recht komplex.
Aber es scheind sich wirklich zu lohnen.

Naja, ich habe nichts gegen den Ausdruck "komplex" solange er nicht
abschreckt. Man kann beim M16C wirklich Zug um Zug vorgehen, also
Feature um Feature betrachten und zu nutzen beginnen und so gesehen
muss es nicht "komplex" im Sinne von "viel zu aufwendig" oder so
gesehen werden. In diesem Sinne finde ich den Ausdruck "flexibel" oder
"vielfältig" besser angebracht.

Markus

 

[Michael Dreschmann]

Hi!

Nein, Deine 2x256 KB sind ab 0x30000 gemappt. /CS0 ist nur active low
wenn Du einen Adresse zwischen 0x30000 - 0xcffff ansprichst (das ist
bei der 256 KB Flash 20KB Ram CPU so, also die welche Du nehmen
willst). Du verdrahtest also A1 - A18 an die chips. Wenn A19 high ist
(was deine Ram Bausteine dann ja nicht sehen), "passt" der rest des
Busses so dass deine Ram Bausteine den Bereich von 0 - 2ffff sehen.
D.h. Du kannst die vollen 512 KB nutzen.

Jetzt weiss ich, was du meinst...
Ich musste mir das ein paar mal durchlesen...
Du gehst davon aus, dass ich nur 512KB als ext. RAM nutzen möchte.
Der ext. verfügbare Adressraum geht ja aber von 0x6000 bis 0xBFFFF.
Das sind 744KB und die würde ich auch gerne bis auf die 8KB (welche ja
durch CS3 selektiert werden und für ext. Geräte sein sollen) nutzen.
Deshalb war mein Gedanke, einfach 2x 512x8 zu nehmen. auch wenn dann
1024KB - 744KB = 280KB ungenutzt blieben.

Sprich man müsste bei 8 Bit die Eingabe immer erst ver &0x00FF en?

Nein, das macht die CPU schon. Wenn aber die PHERIPHERIE macht ein
einem 16Bit Zugriff eventuell was anderes als bei einem 8 Bit Zugriff
und das KANN problematisch sein - KANN, hängt von der Pheripherie ab.

(snnip)

Ok, alles klar. Danke für den Hinweis.

Ist natürlich ein Argument. Ich werde morgen mal versuchen meine
Speicherorganisation auf diese Signale auszulegen.

Für's RAM ist's kein Thema, bei Pheripherie kommts darauf an. Bei CF's
must Du entweder immer 16 Bit zugriffe ausführen und dann tatsächlich
Operationen durchführen (z.B. Statusregister und Komandoregister) oder
eben einen sauberen 8 Bit Zugriff implementieren. ACHTUNG, das ist
aber beim M16C so dass nur entweder der ganze Buss mit 16 Bit läuft
oder 8-Bit. Du kannst also nicht pro /CS Area wählen (wäre ganz nett
wenn das ginge).

Da muss ich mir die Pheripherie erst nochmal genauer anschauen, ob's
da Probleme gäbe.

Ok, mit dem CS3 bekomme ich meinen 8K Block, aber darin muss ich ja
noch bischen zwischen den verschiedenen Peripheriegeräten
unterscheiden... Aber die paar Gatter dürften nicht das Problem
werden...

Uhmmm - Du hast doch /CS0 - /CS3 - warum nicht ein Chipselect pro
Pheripherie? Dazu sind die doch da!

Wie oben erwähnt würde ich die Bereiche von CS0 bis CS2 gerne für RAM
nutzten. Deshalb muss ich da nocheinmal die Adresse anschauen.
Übrigens: CS0 hat ja laut Datenblatt einen internen Pull-Up. CS1-CS3
nicht. Könnte ich jetzt einfach CS0 bis CS2 zusammenschalteten und
somit meinen RAM aktivieren? Das wäre ja dann genau der komplette
externe Bereich ohne die 8KB am Anfang. Vorrausgesetzt, der Pull-Up
von CS0 reicht auch für CS1 und CS2.

Hm, CSE find ich grade nicht, aber im CSR Register kann ich für jeden
CS einzeln nen Waitstate enablen.

Ja, EINEN. Mit CSE kannst Du dann bis zu zwei weitere definieren. Es
gibt Pheripherie bei der EIN Waitstaite einfach nicht ausreicht.

Ach so, ja, das stimmt. Geht nur einer. Für alles andere bräuchte ich
dann RDY.

Die Frage ist natürlich, ob ein Waitstate für das IDE Register
reicht... Sonst muss ich da wohl doch was mit RDY machen.

Für CompactFlash - soviel kann ich dir sagen - reicht EIN Waitstate.
Ich denke das sollte bei IDE Platten nicht schlechter sein.

Hm, ich weiss nur, dass es bei dem Hmepg Projekt mit manchen Platten
Probleme gab. Und da wurde nur ein AVR bei 8 MHz eingesetzt.
Naja, ein Praxistest wird's zeigen...

Naja, ich habe nichts gegen den Ausdruck "komplex" solange er nicht
abschreckt. Man kann beim M16C wirklich Zug um Zug vorgehen, also
Feature um Feature betrachten und zu nutzen beginnen und so gesehen
muss es nicht "komplex" im Sinne von "viel zu aufwendig" oder so
gesehen werden. In diesem Sinne finde ich den Ausdruck "flexibel" oder
"vielfältig" besser angebracht.

Also abschrecken tut mich das hier sicher nicht. Ich mach ja schon gar
nix anderes mehr...
Also, vielen Dank nochmal für deine Hilfe.

Cu, Michael

 

[Markus Zingg]

On Sun, 27 Jul 2003 14:21:27 GMT, michaeldre@gmx.de (Michael
Dreschmann) wrote:

Hi!

Nein, Deine 2x256 KB sind ab 0x30000 gemappt. /CS0 ist nur active low
wenn Du einen Adresse zwischen 0x30000 - 0xcffff ansprichst (das ist
bei der 256 KB Flash 20KB Ram CPU so, also die welche Du nehmen
willst). Du verdrahtest also A1 - A18 an die chips. Wenn A19 high ist
(was deine Ram Bausteine dann ja nicht sehen), "passt" der rest des
Busses so dass deine Ram Bausteine den Bereich von 0 - 2ffff sehen.
D.h. Du kannst die vollen 512 KB nutzen.

Jetzt weiss ich, was du meinst...
Ich musste mir das ein paar mal durchlesen...
Du gehst davon aus, dass ich nur 512KB als ext. RAM nutzen möchte.
Der ext. verfügbare Adressraum geht ja aber von 0x6000 bis 0xBFFFF.
Das sind 744KB und die würde ich auch gerne bis auf die 8KB (welche ja
durch CS3 selektiert werden und für ext. Geräte sein sollen) nutzen.
Deshalb war mein Gedanke, einfach 2x 512x8 zu nehmen. auch wenn dann
1024KB - 744KB = 280KB ungenutzt blieben.

Ach so - ja, das habe ich tatsächlich falsch verstanden.

Hmmm - Müsste schon gehen, Du musst dann aber für die Pheripherie
vermutlich Glue - Logik verwenden. Das ist Dir aber sicher schon klar.

(snip)

Uhmmm - Du hast doch /CS0 - /CS3 - warum nicht ein Chipselect pro
Pheripherie? Dazu sind die doch da!

Wie oben erwähnt würde ich die Bereiche von CS0 bis CS2 gerne für RAM
nutzten. Deshalb muss ich da nocheinmal die Adresse anschauen.
Übrigens: CS0 hat ja laut Datenblatt einen internen Pull-Up. CS1-CS3
nicht. Könnte ich jetzt einfach CS0 bis CS2 zusammenschalteten und
somit meinen RAM aktivieren? Das wäre ja dann genau der komplette
externe Bereich ohne die 8KB am Anfang. Vorrausgesetzt, der Pull-Up
von CS0 reicht auch für CS1 und CS2.

Naja, sonst kannst Du /CS1 und /CS2 einen eigenen Pullup spendieren.
Das macht sowieso Sinn, weil sonst "läuft" Dir die Pheripherie nach
dem Reset davon. /CS1 und grösser sind nach dem Reset tristate und das
bedeutet die Pheripherie läuft Amok, schliest den Buss kurz und
braucht eine riesen Menge Strom. Klar, ist normalerweise nur für ein
paar Mikrosekunden - normallerweise, aber NICHT beim Debuggen. Wie
Du vielleicht gemerkt hast spreche ich aus Erfahrung ) Wenn der
Debugger beim Programmstart steht, ist die CPU im Reset - und obiges
speilt eine grosse Rolle - kann Dir den Spannungsregler verbraten oder
so. Ganz so schlimm war's bei mir nicht, wurde aber ganz schön heiss
bis ich's gemerkt hatte )

Zusammenschalten sollte IMHO gehen - wenn's nicht klappt kanst Du ja
immernoch ein Gatter nehmen.

(snip)

Also, vielen Dank nochmal für deine Hilfe.

Gern geschehen. Schick doch mal ein Link/Mail/Info wenn's was geworden
ist.

Markus

 

[Michael Dreschmann]

Hi!

Naja, sonst kannst Du /CS1 und /CS2 einen eigenen Pullup spendieren.
Das macht sowieso Sinn, weil sonst "läuft" Dir die Pheripherie nach
dem Reset davon. /CS1 und grösser sind nach dem Reset tristate und das
bedeutet die Pheripherie läuft Amok, schliest den Buss kurz und

Ja, deswegen wollte ich ja /CS1 und /CS2 mit /CS0 verkoppeln. Dann
wären die mit /CS0 auch gleichzeitig hochgezogen. Oder meintest du,
dass /CS0 nach dem RESET nicht gleich nen Pull-Up hat, weils ja in dem
Moment ein normaler Portpin ist. Das ist natürlich ein Argument. Dann
führe ich die am besten extrern zusammen und spendieren denen noch nen
Pull-Up.

Gern geschehen. Schick doch mal ein Link/Mail/Info wenn's was geworden
ist.

Auf jeden Fall. Könnte aber nochwas dauern.

Zu dem Flashen nochmal grade:
Sehe ich das jetzt richtig, dass ich die 4 Leitungen des UART1 über
einen MAX232 mit der seriellen Schnittstelle des PC's verbinden muss,
und CNVss auf +5V, /CE auf +5V und /EPM auf GND legen muss?
Für CNVss kann man ja nen Jumper zu +5V nehmen.
/CE ist ja /WR des ext. Busses und den könnte ich ja somit auch per
Pullup einfach auf +5V legen, sollte ja dann auch im Normalbetrieb
gehen.
Aber /EPM ist im Normalbetrieb ja /HOLD und sollte per Pull-Up auf +5V
gezogen werden. Mach ich da dann am Besten auch nen Jumper nach Masse
für den Programmiermodus dran? (Das steht nämlich in keinem Beispiel
in den Datenblättern so eingezeichnet)
Btw.: Brauchen /RD, /WR und /BHE nen Pull-Up im normalen Betrieb?

Cu, Michael

 

[Markus Zingg]

On Sun, 27 Jul 2003 17:30:12 GMT, michaeldre@gmx.de (Michael
Dreschmann) wrote:

Hi!

Naja, sonst kannst Du /CS1 und /CS2 einen eigenen Pullup spendieren.
Das macht sowieso Sinn, weil sonst "läuft" Dir die Pheripherie nach
dem Reset davon. /CS1 und grösser sind nach dem Reset tristate und das
bedeutet die Pheripherie läuft Amok, schliest den Buss kurz und

Ja, deswegen wollte ich ja /CS1 und /CS2 mit /CS0 verkoppeln. Dann
wären die mit /CS0 auch gleichzeitig hochgezogen. Oder meintest du,
dass /CS0 nach dem RESET nicht gleich nen Pull-Up hat, weils ja in dem
Moment ein normaler Portpin ist. Das ist natürlich ein Argument. Dann
führe ich die am besten extrern zusammen und spendieren denen noch nen
Pull-Up.

Yep, extern - so habe ich das gedacht.

Gern geschehen. Schick doch mal ein Link/Mail/Info wenn's was geworden
ist.

Auf jeden Fall. Könnte aber nochwas dauern.

Zu dem Flashen nochmal grade:
Sehe ich das jetzt richtig, dass ich die 4 Leitungen des UART1 über
einen MAX232 mit der seriellen Schnittstelle des PC's verbinden muss,
und CNVss auf +5V, /CE auf +5V und /EPM auf GND legen muss?
Für CNVss kann man ja nen Jumper zu +5V nehmen.
/CE ist ja /WR des ext. Busses und den könnte ich ja somit auch per
Pullup einfach auf +5V legen, sollte ja dann auch im Normalbetrieb
gehen.
Aber /EPM ist im Normalbetrieb ja /HOLD und sollte per Pull-Up auf +5V
gezogen werden. Mach ich da dann am Besten auch nen Jumper nach Masse
für den Programmiermodus dran? (Das steht nämlich in keinem Beispiel
in den Datenblättern so eingezeichnet)
Btw.: Brauchen /RD, /WR und /BHE nen Pull-Up im normalen Betrieb?

Ich habe Dir ein Schema meines Programmierkabels per e-mail geschickt.
Ich hätte auch noch ein Schema (und Board?) eines "mini Cores" für
erste Versuche etc.

Ich habe mir EINEN Chip auf so ein Kärtchen gelötet wobei mehr oder
weniger alle Pin's auf 1.27 Raster Buchsenleisten geführt sind. Auf
diese Weise kann ich den Chip "billig" in verschiedenen Designs für
Versuche nutzen ohne immer gliech einen zu verbraten.

Schick mir ne e-mail wenn Du interesse hast.

HTH

Markus