Naja, aber das andere Tool konnte ja auch mal flashen! Es hat nur irgendwann man verlernt das es das kann. :-/
Der Fall ich aber jetzt geklaert. Ich hab mal alles auf meinen Rervelaptop mit echter RS232 kopiert und da funktioniert das Flashtool.
Die Dinger laufen also ganz eindeutig nicht mit einem USB->RS232 konverter. Ich verstehe zwar nicht wieso es am Anfang funktioniert hat, aber immerhin bestaetigt mich das darin das USB->RS232 grundsaetzlich von uebel ist.
Es gibt aber auch R8C mit zwei RS232. Aber das wird ja wohl irgendwo im Handbuch stehen.
Das Programm sagt nein. Aber egal, hauptsache man weiss erstmal woran es liegt. Wenn es dann eines Tages nochmal ein vernuenftiges Flashprogramm gibt kann man damit arbeiten.
Vielleicht interssiert es ja einen, aber ich hab es jetzt mit einer CF-RS232 Karte laufen. Sowas ist kompatibler!
Da war ich wohl zu optimistisch. Die mitgelieferte Hilfe ist ein Trauerspiel, ein Handbuch ist nirgends aufzufinden.
Ich kann machen was ich will, aber der Druck auf 'GO' ist immer das letzte was ich machen kann. Dann hilft es nur den KD30 zu toeten. Er stopt sogar mit der Ausfuehrung an gesetzten Breakpoints, aber man kann einfach nichts mehr machen. ARGH!
Wie schon geschrieben: Den Interruptvektor gesetzt und die Interrupts auch freigegeben? Letzteres hatte mich einige Zeit gekostet bei der Inbetriebnahme des Boards meiner Diplomarbeit.
Grüße, Andre (und ja, die Doku ist leider nicht der Hit :-/)
Eine sehr interessante Frage. Ich habs gerade mal ausprobiert.
Es geht eine ganze Weile gut, so 20-30Befehle lang. Dann kommt der Befehl: jsr.a _init und die Kiste steht.
Wenn ich das richtig sehe ich das die initialisierung bevor main() aufgerufen wird. Ich hab sie bloss noch nicht gefunden.
Aechz...ganz schoen kompliziert fuer so ein kleinen Prozessor.
Wenn ich das richtig sehe stehen die alle auf 0x9a,0xf7,0x00.
Ich denke auch das dies noch stimmen muss sonst wuerde Step zu begin nicht funktionieren.
Noe, ich hab garnichts mit dem Stack gemacht. Mein Programm ist ja komplett in C. Da kann ich doch wohl davon ausgehen das der Compiler das macht. Ich hab das Programm allerdings im HEW mit der Debug-Option uebersetzt in der Hoffnung das dies fuer den Debugger notwendig ist.
ICh hab mal, wie von Andre vorgeschlagen, einen Assemblerbefehl zum einschalten in main() aufgenommen. Hat aber nicht geholfen. Jetzt ist mir auch klar wieso, er kommt erst garnicht bis main().
Nicht ganz. :)
So wie ich das sehe, kann ich in meinem Programm nichts falsch gemacht haben weil der Debugger bereits abgeklemmt wird bevor es ausgefuehrt wird. Es koennte also hoechstens irgendeine Einstellung im HEW sein. Vielleicht muss fuer den Debugger eine andere Initialisierung eingebunden werden und das muss man in einer dunklen Ecke bei den sieben Buttons hinter den Bergen einschalten. :-/
Ahhh... Der initialisiert dann die standard-I/O... Nimm das mal raus, die standard-IO richtOCet einen seriellen Port für printf ein. Und wenn Dein R8 nur einen hat, ist es klar, dass der Debugger die Kommunikation verliert.
Es muss da eine startup geben. Versuch mal dem "jsr.a _init" mit 'step into' zu folgen. In der startup wird der RAM gelöscht und statics initialisiert (Makros: N_BZERO und N_BCOPY). Beim M16C heist das startup-File: "ncrt0.a30".
Das sieht gut aus.
Danach muss der Stackpointer gesetzt werden!!! Woher soll der Compiler wissen, wohin Du gern Deinen Stack haben möchtest und wie groß Du ihn denn gern hättest? Woher soll der Compiler wissen, wie viele IRQs bei Dir gleichzeitig auftreten können und wie diese priorisiert sind?
Beim M16C sieht das z.B. so aus:
;--------------------------------------------------------------------- ; after reset,this program will start ;--------------------------------------------------------------------- ldc #istack_top, isp ;set istack pointer bset 1,0ah mov.b #00h,04h ;set processer mode mov.b #08h,05h ;set reserved area expansion bit bclr 1,0ah bset 0,0ah mov.b #20h,07h ;set clock control register mov.b #08h,06h ;to no clock division bclr 0,0ah ldc #0080h, flg ldc #stack_top, sp ;set stack pointer ldc #data_SE_top, sb ;set sb register
fclr U ;ADD THIS TO SELECT ISP fset I ;ADD THIS TO ENABLE INTERRUPTS & STOPPING PROGRAM
Wenn Du ein x30-File erzeugst, und nur das kann der KD30 laden, dann sind da alle Infos zum debuggen drin. Zum erzeugen eines s19-Files wird dann ein anderer Linker verwendet. Irgendwas stimmt in Deiner startup nicht.
Aber zum Glück hast Du ja den KD30 und kannst Dich da durchwühlen. Mit PIC/AVR hättest Du jetzt ein echtes Problem.
Ne! Die angesprochenen Macken des Brennprogramm bleiben. Und die Dokumentation ist das GRAUEN. Ich hab ja das Glueck sehr viel English zu reden mit einer Japanerin. :) Ich bin also mit so manchen Eigenheiten vertraut trotzdem muss ich gelegentlich seufzen wenn ich die Doku lese. Ich wuesste mal gerne was ein Englaender denkt der die liesst.
Gerade habe ich mir mal angeschaut wie man den Compiler veranlasst Funktionen im Interrupt aufzurufen. Das wirkt ein bisschen nachtraeglich beigestrickt.
Wenn sich diese Controller auch in Deutschland ernsthaft verbreiten dann wird es Zeit das mal jemand ein Buch schreibt. Hm..ich glaub ich muss mal jemanden anrufen und ihn auf diesen Missstand aufmerksam machen.
Ich hab in meinem ganzen Leben noch nie einen Stackpointer bei einem Compiler gesetzt. Woher soll ICH denn wissen wie er es gerne haette und wieviel Platz er braucht.
Das sieht hier auch so aus. Aber das hat natuerlich der Compiler gemacht. Ich hab da nicht dran rumgefummelt.
Nana. Mit AVR und Dragonball hatte ich diese Probleme nicht.
Was mich dabei stört fürs erste mal (Resetvektor=0xFFFF) genügt es wenn nur IRQ auf low (läuft dann auch mit internem Clk). Wieso muß ich dann wenn ich weiter in den Monitor will diesen ganzen Aufwand (HighVoltage,ext.Clk,versch. Pins) treiben...
Haben die Angst man kommt versehentlich in den Monitor? (geht beim T89C51CC01 wunderbar mit einem Pin...)
Für ersteres gibt es zum Glück die wesentlich bessere Variante von microcontroller.net. Der "Profi" wird eher den "Flasher" der Firma Segger benutzen. Der kommt dank synchroner Übertragung dann auch mit krummen Quarztakten klar. Sonst ist es auch nicht wirklich schwer dieses Protokoll selbst zu implementieren. Wenn man denn irgendwo Dokumentation dadrüber findet. Ich hab sie durch Zufall in einem Datenblatt eines Vorgängers entdeckt. (M16C62)
Ich habe mich da auch schon öfters gefragt, ob ich zu dumm bin, die Renesas-Datenblätter/Dokumentationen zu verstehen.
Sonst gibt's da noch IAR und Tasking als Compilerlieferant. Aber die kosten gleich sehr viel Geld. In der Firma setzen wir IAR ein. Version 3 der EWM16C scheint mehr zu taugen, auch wenn ein Tag zum portieren des Quelltextes von Version 1 draufging. :-/ Beim Renesas-Compiler habe ich mich desöfteren bei Fehlermeldungen gefragt, was das Teil denn von mir will. Und manche Fehlermeldungen sind einfach viel zu freundlich für mich formuliert :) Diese HEW scheint ursprünglich vom Hitachi zu stammen und hat meiner Meinung nach den M16C Support drangeflickt. Und geht nicht wirklich sparsam mit den Resourcen um. Auf meinem P-II 400 Laptop ist das editieren von Quelltext im Editor schon eine Qual!
Also das wiederum kann ich nicht sagen. Ich hab das hier alles auf meinem neuen schnuckeligen Miniaturlaptop gemacht und der hat einen TransMeta Crusoe mit 867MHz und eine relativ lahme 1.8" Platte. Das duerfte von der Geschwindigkeit her vergleichbar sein da der Crusoe langsamer ist als der Takt einem glauben laesst. Und da kann ich eigentlich nicht drueber meckern.
Das ist eine Konzession an die Produktionsprogrammierer. Halte ich aber aus genannten Gründen nichts davon: man muß z.B. in Lagerware neue Software einspielen und Rückläufer analysieren können.
Bei interner RC-Clock ist die Toleranz ( +/-20% ehedem ) zu groß als daß es mit Baudrate für UART an jedem PC passen könnte.
Berechtigte. Wenn Controller in verseuchter Umgebung arbeiten können sie saftig abstürzen. Monitor bedeuted ja auch: Watchdog abgeschaltet.
Das steht in den einzelnen List-Files, wie groß beim Compilieren die Bereiche geworden sind und sieht dann z.B. so aus:
------------------------------------- Section List
Attr Size Name CODE 0001633(00661H) program DATA 0000262(00106H) data_NE DATA 0000003(00003H) data_NO ROMDATA 0000262(00106H) data_NEI ROMDATA 0000003(00003H) data_NOI DATA 0000244(000F4H) bss_NE
-------------------------------------
Die Bereiche (Stack, Data near, Data far usw.) müssen z.B. auch beim IAR eingestellt werden. Beim Mitsubishi-Compiler und M16C gibt es dazu das File "sect30.inc". Es könnte ja auch z.B. sein, dass Du Deinen Stack gar nicht im internen, sondern im externen RAM haben willst usw.
Wie schon geschrieben wird beim Mitsubishi-Compiler und M16C im File "ncrt0.a30" der Stack und die variable IRQ-Table gesetzt. Dieses File wird nicht! vom Compiler erzeugt, aber wohl als Beispiel mitgeliefert. Es liegt auch nur in Assembler vor. Lösche mal das File und Du wirst sehen, der Comier erzeugt kein neues und der Linker wirft Dir ein ganzes Füllhorn voll Fehlermeldungen um die Ohren.
Der AVR hat nicht die Möglichkeit auf dem Chip zu debuggen, d.h. teuren Emulator kaufen. Und warum? Weil die bei Atmel offensichtlich nicht in der Lage sind, priorisierte IRQs und 2 Address match IRQs zu spendieren. Aber inzwischen sind sie ja schon mal soweit, dass sich der AVR selbst umprogrammieren kann. Selbst für den uralten 68HC11 gibt es eine ähnliche kleine Möglichkeit zum debuggen (pcbug11). Für AVRs habe ich sowas noch nicht gesehen, obwohl das gerade für beginners von Vorteil wäre.
Kann man den Dragonball irgendwo kaufen? Was kostet der? Ist da ein kostenloser Compiler mit dabei?
Ich weiss, ich hab das mittlerweile auch gesehen. Ich lass da aber erstmal die Finger raus.
Momentan liefert der Compiler und der Linker keine Fehlermeldungen, dafuer stuerzt HEW gerne mal ab seitedem ich 4 Source und 4 Header Files benutze. Es wird wirklich Zeit das ich mir den Emacs installiere.
Mir ist uebrigens gerade beim portieren von Software aufgefallen das der R8C _ungefaehr_ in derselben Liga spielt wie ein 68k bei gleichem Takt.
Kommt drauf an. Der Dragonball ist in den alten Palms und macht IMHO fuer die meisten Leute wenig Sinn da die das LCD Interface nicht brauchen. Es gibt aber Typen die haben das nicht. Ich vergess nur immer die Nummer (68k332?).
Das ist aber eigentlich eine andere Liga. Du brauchst auf jedenfall externes Ram/Rom. (4-6Lagen Multilayer) Es gibt den gcc. Du kannst ueber ein BDI Interface mit dem gbd auf dem Prozessor arbeiten. Und besonders suess ist das der Proz dann noch einen zweiten Prozessor fuer IO-Kram enthaelt.
Hab mal vor langer Zeit (Linux 0.9xx) den Emacs installiert und gesehen, dass man erst Lisp lernen muss. Da hab ich den Gedanken gleich wieder verworfen. Vielleicht ist das aber inzwischen besser geworden. Ich verwende hier Visual Slick Edit und bin zufrieden. Codewright ist wohl auch nicht schlecht. Im Prinzip geht aber auch Visual Studio.
Also eher schlecht zu bekommen.
Ganz schlecht.
Braucht man für das BDI spezielle Hardware? Hört sich an wie JTAG.
Rafael Deliano wrote in news: snipped-for-privacy@t-online.de:
Mhh die Familie ist 10J. alt. Der '149 nicht. Und wenn du "alte" Klamotten einsetzt, dann bistu ja auch selber Schuld ;-). Man nimmt ja jetzt auch den '169 oder '1611 (von letztem Jahr) schon allein weil der 'ne verbesserte Debugging Einheit hat.
Also die Menge der Docu erschlägt einen. Ich habe hier 200 Dateien,
100MB pdf's + zips nur von TI! Man darf nicht nur die 2 trockenen Datenblaetter lesen, sondern muss sich unbedingt die Beispiele und App.-Notes holen! (Metering Handbook ist zwar noch für die erste Generation, aber unbedingte Lesepflicht! :-).
Im praktischen Einsatz hat mich bisher noch keiner der (alten) Bugs berührt. Im Prinzip sind die Listen nur schlechtes Marketing, man könnte die "Quirks" da auch einfach mit in das Datenblatt schreiben. Die Bugs werden nicht behoben, weil sie einfach irrelevant sind. Manche 'behebt' der Assembler (Compiler), bei manchen muss man halt einen (meist) einfachen Würgaround tun. Der '149 wird mittlerweile in Revision Q(?) verkauft. Die muessen da ziemlich viel dran gemacht haben (schliesst neben Bugbehebung aber auch Prozesswechsel usw. mit ein).
Naja sicherlich hat auch der MSP430 so seine Probleme, die ich hier jetzt aber nicht anführen werde. :-).
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.