Hallo zusammen, haben gerade dieses kleine Programm geschrieben und möchte damit den KD30 Debugger ausprobieren. Klicke ich dann auf "Go", fängt meine LED wohl an zu blicken, aber die Sanduhr bleibt ziemlich lange stehen. Wenn ich dann nach 15sec auf "Stop" klicke, hängt sich KD30 mit der Fehlermeldung "Can't accept data" auf. Hat jemand irgendwelche Vorschläge? Danke! #include <sfr62.h> void main (void) { long int i; pd5 = 0xFF; //Port 5 alles Ausgänge p5 = 0x00; // alle LED aus while(1) { for (i=0; i<100000;i++) //Warten p5_0=0; //LED D1 aus for (i=0; i<100000;i++) //Warten p5_0=1; //LED D1 ein } }
Ist eine kommunikation mit dem Prozessor moeglich? Sind also die Interrupts eingeschaltet und wird die RS232 die der KD30 benutzt nicht zufaellig beim start fuer printf initialisiert? .-) Olaf
Hi Olaf, wie kann man etwas für einen printf initialsisieren!??????? und was hat mein programm mit interrups zu tun!?????es ist doch lediglich eine while schleife die eine led blinken lassen soll!? Simon
Um den Debugger nutzen zu können müssen die Interupts aktiviert werden. Vor die While Schleife den Befehl asm" fset i" setzen
..aha, sorry, aber was bewirkt denn dieser befehl. stehe hier ein wenig im dunklen!!! gibts irgendwo eine brauchbare doku um das ein wenig in den griff zu bekommen??? wie werden überhaupt spezielle inerrups priorisiert und freigegeben, also in welcher datei stehen defines oder zuordnungen (interrupt , priorität und freigabe). globale interrupt freigabe!???? arbeiten hier in einem studienprojekt, und verleiren so langsam jede hoffnung mit dem tm-Studio dem kd30 debugger und nc30 compiler. das ganze wirkt sehr sehr unübersichtlich!!! gruß, simon
Der Debugger muss ja offensichtlich mit dir Reden. Dazu ist eine RS232 und ein IRQ notwendig. Wie man dir bereits hier gesagt hat schaltet fset i den IRQ ein. Dann darfst du natuerlich den seriellen Port ueber den der Debugger mit deinem Prozessor spricht nicht selber verwenden. Ich bin da auch beim R8C/15 auf die Nase gefallen weil dort bei der Initialisierung die RS232 defaultmaessig auf Standardwerte gesetzt wird. ICh vermute mal damit printf dort etwas ausgeben kann. Da dein fetter M16C aber mehr RS232 hat kann es sein das du dieses Problem nicht hast, trotzdem sei es mal erwaehnt. Ansonsten ist es natuerlich die Aufgabe von Studenten im Studium zu lernen wie man vernuenftig arbeitet und dazu gehoert auch das lesen von Datenblaettern! Allerdings sind die Datenblaetter von Renesas etwas schwer verdaulich weil der Schreiber wohl besser japanisch als englisch konnte. Es ist aber nicht so schlimm das man sie nicht verstehen kann. Ein Haufen UEBELSTER Murks ist allerdings ihr HEW. Das Teil stuerzt manchmal ab, oder es vergisst auch schonmal mittendrin einen Teil deines Source mit zu uebersetzen und die FEhlermeldungen des Compilers sind wegen des ungluecklichen English auch eher fuer Leute geeignet die gut in C sind. Aber der KD30 ist gut. Vielleicht nicht so gut wie der gdb, aber damit kann gerade der ahnungslos lernende Student Fehler finden die ihn sonst wochenlang beschaeftigen wuerden. Olaf
Hi Olaf, gott sei dank gibt es tatsächlich menschen auf dieser welt die es schonmal geschafft haben ein programm in diesen verflixten controller zu flashen.... was den uart betrifft, so ist dort natürlich ein zweiter aufgebracht den ich zur not verwenden könnte, auch wenn das erstmal nicht von nöten sein wird, aber danke für den hinweis. das erste testprogramm habe ich bereits gestern zum laufen gebracht, allerdings habe ich noch ein 2tes board mit einem m30624fgP, dort benutzen wir die software m16cflash starter. problem: der controller lässt sich nicht löschen, und damit nur selten programmieren, also das ist dann wohl glücksache. ziel war es den monitor zu flashen. auf dem anderen board ist ein m30624fgA, dort hatten wir anfangs wirklich unlösbare kommunikationsprobleme... da hört der spass dann auf... verzweifung ist kein ausdruck ... gab einen post hier vor ein paar wochen, aber wenig resonanz, haben sogar ähnliche posts mit ebenso wenig gehalt gefunden.... nunja, wie das hier alles auch ausgehen wird, momentan wird das problem mit der priorisierung der interrupts auf uns zu kommen. ach ja, das für den com port ein interrupt benötigt wird macht wohl schon sinn, nur waren wir der meinung das das der monitor wohl schon regeln wird, tja wohl falsch gedacht.... trotzem verstehe ich kaum wie dieser controller jemals irgentwo fuss fassen konnte, wenn eine firma sich solche mühe gibt die programmierung dermassen kompliziert zu gestalten das man die lust am programmieren schon vorm programmieren verliehrt, aber das ist wohl eine frage des anspruchs... bis dahin gruß simon
Da du ja einen M16C verwendest wuerde ich dir dringend empfehlen nicht das Flashprogrogramm von Renesas zu verwenden das ist ziemlicher Murks. Es gibt noch ein anderes Program das genauso heisst (m16cflasher) und das ist viel besser. Soweit ich weiss brennt der KD30 sein Monitorprogramm aber selber rein. JEdenfalls macht er dies bei meinem R8C. Solange man den DEbugger benutzt braucht man da also nichts anderes. Wenn du den HEW benutzt solltest du darauf achten auch zwischen Release und Debug Modus umzuschalten. Ausserdem sind die ganzen Einstellungen in den include Files etwas verwirrend, besonders da sie nicht benutzt werden da der HEW dies mit Commandozeilenparametern am Compiler ueberschreibt. Ausserdem darfst du natuerlich nicht in deinem Programm bewusst Dinge machen welche den Debugger abklemmen. Dies ist ja letztlich auch nur ein Programm das irgendwo laeuft. Was die Verbreitung angeht, die Teile kommen nunmal aus Japan und sind dort ziemlich verbreitet. Und zwar sowohl in der Industrie wie auch unter Bastlern. Bei uns sind sie wohl noch im kommen. Ausserdem muss man natuerlich sagen das gerade der M16C fuer Bastler etwas uninteressant ist wegen seines Gehaeuse. Das ist natuerlich schade weil er von seinen eingebauten Moeglichkeiten so einiges in den Schatten stellt. Auch die R8C mit denen ich gerade rumspiele sind viel schoener als ein AVR, aber auch hier ist das Gehaeuse nicht ganz so bastelfreundlich wie ein Mega8. Und wer als Einsteiger das Kapitel ueber die Timer oder Interrupts im Datenblatt gelesen hat wird wohl etwas verwirrt sein. Aber wenn man viel Leistung will muss man eben auch viel lernen. .-) Vielleicht noch ein Tip zum schluss der dich mit dem M16C (IMHO 20kbRAM) nicht ganz so stark trifft wie mich mit dem R8C (1kb). Man ist verfuehrt auf diesen Controllern genauso locker C-Code aus dem Handgelenk zu schuetteln wie man dies auf einem PC tun wuerde. Man sollte da gelegentlich mal einen Blick auf den Ramverbrauch werfen. Zum Beispiel benoetigt ein printf (oder auch sprintf) beim R8C sofort 120Byte Ram. Beim M16C koennte es sogar noch mehr sein da der IMHO auch float unterstuetzt. Und ein extremes Aergenis ist es wenn man keine echte RS232 hat. Ich entwickel auf einem Sony PCG-U1 weil ich finde das man bei einem kleinen Microcontroller auch einen kleinen Laptop braucht. :-) Einen USB nach RS232 Adapter kann man aber vergessen. Die Verbindung wird dann aeuserst merkwuerdig unzuverlaessig. Manchmal geht es stundenlang, dann wieder wird nichtmal mehr der Controller vom Flashprogramm erkannt. Ich verstehe garnicht warum das so ist da ja auf beiden Seiten nur eine echte RS232 verwendet wird und im Gegensatz zum AVR NICHT durch klimpern mit Steuerleitungen ein eigenes Protokoll nachgebildet wird. Trotzdem laeuft es bei mir erst zuverlaessig seitdem ich einen CF-RS232 Adapter verwende. Olaf p.s: Ich hab zum Thema auch einiges im usenet geschrieben. Das ist schoener als so propritäre Weboberflaechen.
Was mir gerade noch eingefallen ist. Ich habe hier ein japanisches Elektronikheft (Transitor Gajitsu). Dort war der R8C letzten Monat ein grosses Thema und es war auch ein Demoboard und eine CD mit der Software im Heft. Dort wird der Controller direkt aus dem HEW ueber die RS232 gebrannt. Die Menuepunkte die ich da sehe konnte ich aber in der aktuellen englischen HEW Version nicht wiederfinden. Ich vermute daher mal das die japanische Version schon neuer ist und der englischen demnaechst ein Update ins Haus steht. Leider ist die japanische Version fuer nicht Japaner etwas aehem...kompliziert.. Olaf
Hi Olaf, sorry, aber usenet!? wäre sehr nett wenn du uns den Link zur verfügung stellen könntest, dann hätten wir die möglichkeit da mal nachzulesen. ich wusste nicht das der kd30 das flashen des monitors übernimmt, und wir werden das jetzt gleich mal probieren, vielleicht haben wir ja glück... warum wir schon einen etwas größeren typen einsetzten hat nicht den grund das wir größenwansinnig sind, sondern es ist eine von mehreren ramenbedingungen. wir müssen nur ein signal zeitgenau erzeugen und wieder auffangen, wir wollen beides interrupt und timergenau steuern. im bezug auf den controller und auf die unübersichtlichkeit: wenn es nach mir ginge, dann würde ich den fujitsu mb30985s verwenden - aber nicht wegen seiner hardwarevorzüge, die sind was timer/reload und capture einheiten sowie ad wandlung u.v.m. natürlich auch besser als beim avr oder gar beim pic zudem es 16 bitter sind - sondern wegen der mitgelieferten software und programmierumgebung sowie der doku. die ist meiner meinung nach bei dem controller wirklich gut und übersichtlich...es gibt z.b. eine vorgefertigte vector datei, mit interrupt vektoren deren funktionen nur noch ausgeprägt und priorisiert werden müssen.... was das thema für den m16c bedeutet, so wühle ich mich gerade durch die verdammten datenblätter.... und doku des compilers. Mit dem zweiten Controller haben wir noch folgendes Problem. Wenn ich im Debugger KD30 auf "Start" klicke, rennt der controller wohl los (Led blinkt, z.b.). Die Sanduhr bleibt sehr lange stehen und klickt man wenn es wieder geht auf stopp, hängt sich KD30 auf. Durchläuft man das Programm mit dem Stepper, hängt sich KD30 an folgender Stelle auf: ldintb #VECTOR_ADR Uns wurde übrigens folgende Modifikation "empfohlen", in der Startdatei Ncrt0.a30. Wir vermuten dass es da Zusammenhänge gibt wegen "Vector_Adr". um auch auf das problem mit den include/start dateien anszusprechen... ; Modifikation für Monitor 30624FGP_1_x1 VECTOR_ADR .equ 0fbd00h; <- Debugger 0fbd00h ;VECTOR_ADR .equ 0ffd00h ; <- Flash eine sache noch zu unserem vorgehen, das mit dem einlesen ist sicher richitg, aber leider ist dieser controller nur eine kleine sorge von vielen aufgaben die dazu gehören, und wir müssen unsere zeit schon gut einteilen um auch irgendwann mal zu einem ergebnis zu kommen, es kommen u.a. noch analoge filterung und auswertung der empfangenen signale, triggerung und auch abschirmung usw usw dazu.... aber wir kommen gut vorran und sind guter dinge, momentan hängen wir nur an der stelle mit dem 2 ten board mit dem m30624fgp fest. haben auch schon überlegt ob es an eingestellten speicherbereich liegen könnte, sind gerade dabei das zu checken.....haben halt immer noch kommunikationsprobleme gruß, simon Ps.: Versuchen gerade den controllern mit dem M16C-Flasher zu programmieren, die Kommunikation klappt auch ohne Probleme, aber es gibt Problem mit dem erasen, programmieren und blank check. Es erscheinen folgende Fehlermeldungen: -ID Check-failed -Received timeout! 70: Last Command, 0 of 2 chars received
Ihr benutzt wirklich keinen USB-RS232 Adapter? Die Beschreibung eures Problems sieht genauso aus wie ich das damit erlebt habe. Ansonsten bist du hoffentlichbereit laut SCHEISSE zu schreien? :-) Du weisst doch dank dieses Board das der Debugger IRQs verwendet. Ausserdem ist das auch nur logisch da er ja irgendwie gestartet werden muss wenn ein Programm von dir laeuft. Des weiteren benutzt er ja eine RS232 wie du auch schon weisst. Da liegt der Schluss natuerlich nahe das er nur auf Anfragen vom PC antwortet wenn die RS232 einen Interrupt erzeugt welcher dann im Debugger landet oder? ODER? Und wo landet der IRQ deiner Meinung nach wenn du die funktionierden Interrupt-Vektor Tabelle auf eine eigene umschaltet? NA? WO? Schau dir doch mal mit dem KD30 vor dem Absturz mal die alte Vektortabelle an und uebernimm die von ihm benoetigten Vektoren in die Neue Olaf
Hallo Olaf, ....das problem mit dem usb-232 adapter hatten wir vor wochen schon mal vermutet. wir haben hier 2 laptops, eins mit usb dongel, einen mit rs232 hardware schnittstelle, wollte das erst noch erwähnen aber da das auch bei unserem letzten kommunikationsproblem nicht der fall war, habe ich das zu allem überfluss nicht mehr erwähnt, meiner meinung nach haben wir das aber auch schon an beiden schnittstellen ausprobiert, aber das kann man ja nochmal kleinigst überprüfen, uns haut hier heute so schnell nichts mehr aus den socken... haben hier gerade hinweise auf die vectortabelle gefunden, sect30.inc, hoffendlich ist die gleich auch aufzufinden. der vector eintrag den wir eben gepostet haben ist aus der datei Ncrt0.a30 wie schon erwähnt.... arrrrr .....wenn ich dich recht verstanden habe, dann gibts mehrere vectortabellen, und wenn ich jetzt recht schluss folgere dann landet er ergo in der vectortabelle des debuggers!??? wir lesen und lesen und blättern und blättern..... sagmal nur nebenbei, wieviele beschreibungen und datenblätter gibt es da eigendlich so!? ich glaube in dem einem ist ein komma anders, und im nächsten, da ist eine seite mehr, aber sonst ist alles gleich. aber naja - so gehen sie wenigstens sicher der neuen deutschen rechtschreibung auf jeden fall gerecht zu werden :-) so spass bei seite, wenn wir die richtige vectortabelle gefunden haben, und aus den datenblättern endlich eine art interrupt struktur bild zu erstellen auf dem wir sehen könne welcher interrupt wo mit welcher prioriät aufgerufen werden kann, und wir dann noch herusfinden welche möglichkeiten es gibt das ganze in c im tm studio zu behandeln, ohne das sich der uart interrupt dessen grund jetzt ganz klar ist zu behindern, dann haben wirs doch schon geschafft, also wäre doch ein witz wenn das nicht zu schaffen wäre, oder??? gruß, simon
Hallo Olaf, wegen unserem Kommunikationsproblem: am USB-Dongle scheint es nicht zu liegen, haben das Board jetzt noch einmal an die RS232 Hardware-Schnittstelle und bekommen immer noch die Fehlermeldung: -Received timeout! 70: Last Command, 0 of 2 chars received Übrigens schon mal vielen vielen Dank für die Hilfen.... Ach ja, wenn du aus Bielefeld oder Umgebung kommst würden wir dich heute noch auf ein Bierchen einladen... :)
Zunaechst mal, wir wollen nicht vergessen das ich mit dem R8C arbeite. Ich hab zwar noch ein OAKS16 rumliegen (M16C) damit aber noch nicht viel gemacht. Es kann also sein das bei euch manches etwas anders ist auch wenn die CPU selber ja gleich sein soll. So wie ich das sehe ist eine Vectortabelle eine Vectortabelle und wenn du das Gefuehl hast ein Dutzend davon zu brauchen dann kannst du dir das so einrichten. Eine sollte es aber wenigstens geben und sie wird, wie du schon gemerkt hast, defaultmaessig in den include Dateien eingerichtet. Solange du also noch garnicht genau weisst was du da machst LASS DA DIE FINGER VON! In einer der beiden Dateien werden diese Sachen eingestellt, in der anderen in den Code uebernommen. Und da steht auch die Defaulttabelle drin in der du z.B auch deine eigenen Interruptroutinen eintragen musst wenn du z.B selber einen Interrupt benutzt. Das ist nicht ganz so elegant wie bei WinAVR, funktioniert aber. Wichtig ist aber, wie schon erwaehnt, das HEW einige Einstellungen beim Aufruf des Compilers ueberschreibt. Das hat mich auch einen halben Tag gekostet weil ich mich gewundert habe wieso mein Programm immer abgestuerzt ist obwohl ich doch extra die Stackgroesse in der Datei angepasst hatte. ARGH! Es gibt uebrigens ein Handbuch zum Compiler wo gezeigt wird wie das mit den Interrupts funktioniert. Ansonsten sei erwaehnt das der Compiler nicht ganz so kritisch nach Fehlern schaut wie dies ein gcc tut. Er laesst z.B ein "if (a=0) unwichtig();" gaenzlich ohne kommentar durchgehen. Olaf
Bielefeld? Was soll das sein? Das gibt es doch garnicht. Ausserdem gehoere ich nicht sie IHNEN. :-) Mit der RS232 kann ich mir sonst nicht erklaeren. Mal verschiedene Baudraten probiert? Die Dinger unterstuetzen zwar verschiedene Baudraten und erkennen die auch automatisch, aber nicht alle! So hat mein R8C am Anfang nur mit 9600Baud funktioniert. Jetzt geht er auch mit 38xxx. Ich vermute mal das liegt daran das ich als erstes in meinem Programm vom internen Takt (128kHz/8) auf den externen Takt (20MHz/1) umschalte. Das legt den Verdacht nahe das die groesse des externen Takts festlegt welche Baudrate der Prozessor maximal abkann. Olaf
Hi Olaf, erstmal wirlich vielen dank für die ruhe die du ausstrahlst wenn du schreibst. also wir haben mittlerweilen immer mehr nachvolzogen was da so passiert, wer macht da was mit wem und wann... trotzdem ists zu spät davon die finger zu lassen!!! 1) denn es wird laufen, die hoffnung werden wir nicht aufgeben 2) und ich denke wir sind in der nächsten stunde soweit einen zweiten interrupt zu unserem bestehenden hinzuzufügen, und wir werden jetzt sicher nicht die segel streichen.... ach in dem handbuch kramen wir gerad rum, das ist ja noch einigermassen verständlich, im bezug auf die anderen 27,3 pdf files die hier noch dümpeln.... simon
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.