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?
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.
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 :)
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. :-)
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.. :-)
erstmal vielen Dank für deine ausführliche Antwort.
na dann ist ja alles ok.
Ä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.
Sorry, haste da ne Adresse? Ich hab das Datenblatt auf so ner Uni-Seite gefunden, wo die mit dem Controller ein Projekt gemacht haben.
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:
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?
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.
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?
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. :)
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]
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).
formatting link
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.
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.
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.
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.
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.
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.
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.
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" :)
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...
Ü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. :-)
Ok, das ist auch das was ich brauche. Also, alles klar...
Ich glaube ring Osc. und PLL gibts bei meinem Model (M 30624) noch nicht.
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.
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?
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.
Hab's mir grade nochmal durchgelesen und denke, das müsste bei dem M 30624 so funktionieren (mit dem CS3). Werds einfach ausprobieren.
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.
Hab's grade eben nochmal gelesen. Scheind auch bei dem M 30624 zu funkionieren.
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?
(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?
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.
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]
Naja, man kann die Umgebung von Renesas runterladen und dann - so glaube ich - ein halbes Jahr lang "evaluieren"...
[snip]
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.)
Letzteres
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.
Das klapt so sicher auch. Ich habe einen "frühen" Prototypen so aufgebaut.
So sollte das klappen. IMHO müsstest Du hier nichts verschwenden.
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.
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]
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.
Aber sicher
Nein, einen Dekoder brauchst Du definitiv nicht.
Hmm, ich dachte nur ein zusätzlicher sei konfigurierbar gewesen? Hast Du CSE auch?
/RDY fügt waitzyklein ein, /HOLD trennt die CPU vom Bus und hält sie an. Letzeres ist für DMA.
Naja, wie einer diese Möglichkeiten nutzt ist offen.
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 :)
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.
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...
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.
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.
Sprich man müsste bei 8 Bit die Eingabe immer erst ver &0x00FF en?
Ist natürlich ein Argument. Ich werde morgen mal versuchen meine Speicherorganisation auf diese Signale auszulegen.
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...
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.
Ahso... ja, DMA, das Kapitel werde ich mir morgen auch mal durchlesen... Vielleicht lässt sich das ja auch nutzten... :-)
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?
Och, ich Moment finde ich das schon alles recht komplex. :-) Aber es scheind sich wirklich zu lohnen.
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]
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.
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).
Uhmmm - Du hast doch /CS0 - /CS3 - warum nicht ein Chipselect pro Pheripherie? Dazu sind die doch da!
Ja, EINEN. Mit CSE kannst Du dann bis zu zwei weitere definieren. Es gibt Pheripherie bei der EIN Waitstaite einfach nicht ausreicht.
Für CompactFlash - soviel kann ich dir sagen - reicht EIN Waitstate. Ich denke das sollte bei IDE Platten nicht schlechter sein.
Ja. Ich denke mal die hatten einen Anwendung mit nur einem Interupt und 50 Milionen benötigter Chips oder so....
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.
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.
(snnip)
Ok, alles klar. Danke für den Hinweis.
Da muss ich mir die Pheripherie erst nochmal genauer anschauen, ob's da Probleme gäbe.
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.
Ach so, ja, das stimmt. Geht nur einer. Für alles andere bräuchte ich dann RDY.
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...
Also abschrecken tut mich das hier sicher nicht. Ich mach ja schon gar nix anderes mehr... :) Also, vielen Dank nochmal für deine Hilfe.
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)
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)
Gern geschehen. Schick doch mal ein Link/Mail/Info wenn's was geworden ist.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.