Hallo Leute! Hat´s von euch schonmal jemand geschafft, dem M16C ein par I²C-Bits zu entlocken?? Bei Renesas gibt´s nur eine Application Note und auf die kann man ehrlich gesagt verzichten, wenn man das Datenblatt gelesen hat, da steht nämlich das selbe drin... Außerdem steckt das Teil voller Fehler! Greetz und Danke, Dirk.
Oh ja, hab auch ewig rumgemacht mit den I²C-Routinen, hab irgendwann mal ne implementierung in SW gefunden, die ohne Hardwareunterstützung auf jedem beliebigen Port läuft. Kannst dir ja mal anschauen. Die Anzahl der nop's stimmt zwar nicht ganz und man sieht ev, das ich es mir ein wenig zurechtgebogen hab, aber ich denk es liefert dir ne gute Grundlage zum weitermachen.... Bei den Beipielen von Renesas kann ich dir nur beipflichten, die sind fürn Ar..., weil voller Fehler Gruß Peter
Danke Peter! Werd´s mir gleich mal anschauen, aber ich denke, daß ich´s doch mit dem Hardwaremodul realisieren sollte :( Das Ganze ist für ´ne Industriesteuerung und in Bezug auf die Spezifikationen sind solche Features wie "Arbitration lost", "Nack detection", ... doch sehr sinnvoll. Aber trotzdem Danke. Schön zu wissen, daß man nicht alleine ist :) Gruß, Dirk.
PS: Hast du ´ne Ahnung, was mit m16c-forum.com geht??? Oder kennst du noch ´n anderes für Renesas-MCUs ? Ich glaube, die User hier sind mehr auf AVR getrimmt...
Hi, hatte auch schon mal vor längerem das gleiche Problem. Der m16c(60) unterstützt den i2c-Bus leider fast nur durch Software. Auf der homepage gibt es einen kompletten hardwareunterstützten Treiber für das komplette Protokoll. Aber wenn es schon klappt...
AAAAARGH!!!! Problem gelöst... Neuerdings muss man vor jedem Schreiben auf das Port Direction Register (PD_7) das PRC2-Bit setzen und im nächsten Atemzug dann das PD-Reg nach belieben setzen; Und das bei jedem Mal!!! KEIN WORT DAVON IM I²C-Manual oder den App-Notes... Congratulations to Renesas... Bin begeistert... Greetz, Dirk.
Äh, ich dachte dass PRC2 bit bezieht sich nur auf die PD von Port 9 ??? Hab ich da was verpasst? Gruß Peter
JUP! PD_7 UND PD_9... Und wie gesagt: Das Bit wird sofort zurückgesetzt nach der nächsten Instruction! Also: PRCR |= 0x04; PD_7 = 0x??; (HardwareManual M16C/6N5, Rev. 1.0, Seite 41 ;) Greetz, Dirk.
Könnte wohl daran liegen, dass ich nen M16C/62A verwende ;) btw, verwendest du eigentlich den internen Watchdog? Bin gerade dazu übergegangen einen externen Baustein zu verwenden da er nach meiner Erfahrung nicht in jeder Situation zuverlässig funktioniert. Gruß Peter
Nein, bis jetzt noch nicht... Kommt aber noch (früher oder später). Habe aber gerade das nächste Problem in Sachen I²C gefunden. Der sch&§*! TransmitBuffer (U2TB) übernimmt nicht den Wert, den ich ihm per mov gebe (das steht nämlich auch explizit im HW-Manual). Ich könnte im Mom. gerade die ganze Fa. Renesas an die Wand stellen!! Von der CPU an sich bin ich ja echt überzeugt, aber die Manuals sind absoluter Schrott!! Kennt hier niemand ein gutes (ist nicht böse gemeint) M16C-Forum?? www.m16c-forum.com war erst nur halb tot (posten, aber keine Antwort, sondern Anrufe von den Vertriebsleitern) und jetzt ist´s ganz geschlossen! Das kann doch wohl nicht sein, daß ich mit einer CPU, die mir Hardware-I²C verspricht, Software-Routinen vom Mitsubishi Application Engineer benutzen muss!! Bin echt sauer... Grüße, Dirk.
Ich weiß, is ne blöde Frage, aber Pull-Up Widerstände hast du am Bus dran? Wie Andreas schon sagte unterstützt der M16C nur I²C, implementiert es aber nicht vollständig in Hardware. Mußt noch ziemlich viel in Software machen. Ich hab es damals "aufgegeben" zumal ich dann eh den UART für was anderes gebraucht hab. Falls du es hinbekommst kannst ja mal deinen Code posten, würd mich dann doch interessieren. Bezüglich Foren, ich beschäftige mich bereits seit einiger Zeit mit dem M16C, hab aber bis jetzt noch kein Forum gefunden in dem auch wirklich mal ein paar Leute zu finden sind. Die meisten sind ziemlich tot(Foren). Hier verwenden zwar auch ein paar Leute den M16C, aber der Anteil ist im Vergleich zu den AVRs verschwindend gering. Gruß Peter
Hi Peter:) Jou, PullUps sind natürlich dran *G Ich kann schon ziemlich genau sagen, daß im U2TB-Reg nichts ankommt, da ich den Vorzug eines Emulators genießen darf... Sobald ich´s rausgefunden hab´, werde ich es posten! Gruß, Dirk.
Hmm..., Fehler im Emulator, falsche sfr*.h, schau mal nach ob die Hardwareadresse stimmt.
Ganz so verbissen muß man das aber nicht sehen. In den meisten Fällen braucht man nur einen I2C-Master und da ist es viel einfacher, universelle Bitschieberoutinen zu nehmen, als sich erstmal in ein kompliziertes Hardware-I2C reinzuarbeiten. Ich habe so z.B. meine 8051-Routinen blitzschnell auf den AVR umgerubelt, hier mal ein 8051 Beispiel: http://www.specs.de/users/danni/appl/soft/c51/eeprom/index.htm Als Single Master hat ein Hardware-I2C auch keinerlei Vorteile. Erst, wenn man wirklich einen Multimaster-I2C-Bus zwischen mehreren MCs aufbauen will dann braucht man das Hardware-I2C. Und das muß dann auch entsprechend leistungsfähig sein, d.h. Arbitration, Synchronisation, Bittiming vollautomatisch machen. Ich hatte mal angefangen Multimaster auf einen Tiny26 zu machen, aber das kann man schlichtweg vergessen. Ich hab dann auf den Mega8 gewechselt, die haben ein ordentliches Hardware Multimaster I2C. Übrigends kann man für die Atmels, die I2C Routinen von den original Philips 80C552 fast unverändert übernehmen. Peter
Hi Peter! Du hast natürlich Recht, aber das Problem ist, daß auf meiner MCU noch andere Sachen abzuarbeiten sind und da hätte ich schon gerne den Vorzug eines ACK/NACK-Interrupts... Und den gibt´s halt nur durch Hardwarelösung. Ich möchte nicht warten, bis zigtausend NOPs endlich das Timing hingebogen haben. Ich werde Renesas solange auf die Nerven gehen, bis sie mir ein Beispiel mit dem neuen I²C-Mod zukommen lassen und werd´s dann hier posten :) Betr. Fehler im Emulator: Das wär´ das erste Mal,) Das Ding mag ja seine kleineren Macken haben, aber darauf ist in der Regel Verlass *g Der Beweis dafür ist ja auch, daß nichts aus SDA getaktet wird... Gruß, Dirk.
@Dirk, "Ich möchte nicht warten, bis zigtausend NOPs endlich das Timing hingebogen haben." Das muß man immer im Verhältnis zum Gesamtprogramm sehen. Und da wird man ja nicht ständig nur I2C machen. D.h. wenn ab und zu mal ein paar NOPs gemacht werden, hat das kaum Einfluß auf die Gesamtleistung der CPU. Und "zigtausend NOPs" sinds definitiv nicht, um 5µs zu machen oder läuft Deim M16 mit 4GHz ? "Ich werde Renesas solange auf die Nerven gehen" Ich weiß jetzt nicht, wie gut das I2C beim M16 ist. Ich weiß nur, daß beim Tiny26 oder 87C571 das I2C erbärmlich ist. Erst beim 89C668 bzw. ATMega ist es brauchbar. Es kann daher durchaus sein, daß die Reneas-Leute es einfach nicht können. Obwohl die Philips-Leute auch für den 87C751 ein voll funktionierendes Multimaster-I2C als Beispielcode hinbekommen haben. Allerdings zu dem Preis, daß der Softwareoverhead so groß ist, daß effektiv nur 50kHz I2C-Takt dabei rauskommen. Peter
Hi Peter! Nein, zigtausend NOPs sind´s natürlich nicht, aber ich find´s trotzdem jämmerlich... Der M16 läuft auf 16Mhz -> 80 NOPs :( Wie gesagt: Es ist eine Industriesteuerung und damit ist nicht auszuschließen, daß in späteren Anwendungen auch mal ein Multimaster-System notwendig werden kann. Deswegen werde ich den Rest des Tages wohl noch damit verbringen, der Ursache auf den Grund zu gehen; Wohl auch im Interesse aller anderen M16-User. Greetz, Dirk.
@Dirk, Du weißt aber schon, daß I2C nicht für außerhalb eines Gerätes gedacht ist. In Industriesteuerungen ist da mindestens RS-485 Pflicht oder besser CAN, die lassen sich nämlich galvanisch trennen. Bzw. bei hohen Datenraten aber nicht so harter Echtzeit auch Ethernet. Peter
Danke für den Hinweis, Peter. Genau das ist der Grund, warum ich auch ein wenig kleinlich mit dem Timing bin. Die von dir gennanten Bussysteme laufen nämlich auch noch auf der MCU... Außerdem muss MultiMaster nicht unbedingt "extern" bedeuten. Da kann man auch an ´ne Sandwich-Platine, usw., denken, oder??
meld also ich benutze einen m32c/83 und würde auch gern den iic mode nutzen (allerdings nur um nen 256x8 seriell-eeprom zu programmieren). hat da jemand schon code mit dem ich sowas machen kann? wenn ich hier höre dass der code von renesas für den m16c nicht gerade top ist will ich lieber gar nicht anfangen das zeug auf den m32c zu portieren.
Hab´s temporär auch aufgegeben, die Hardware zu benutzen. Werd´ mich mal wieder dransetzen, wenn ich Zeit und Laune habe. Habe die Dateien, die Anfangs von Peter gepostet wurden, für den Tasking-Compiler umgeschrieben und etwas universeller gemacht. Funktioniert sehr gut und zuverlässig! Gruß, Dirk. PS: "#include 'main.h'" rausstreichen und #define CRYSTAL_FREQ xxx (in MHz) einfügen...
Jaaaaa!!! Ich habe es geschafft!!! Mann muss unbedingt digital delay benutzen. i2c format siet vor das SDA zustand nur wärend SCL - low verandert wird was ohne digital delay nicht geht. Ausserdem ging es bei mir nur mit ckph_u2smr3 funktion. Nun das grösste problem bei mir war (hat 2 wochen gebraucht), dass ckph 1-te bit des u2smr3 ist und nicht 4-te, wie in der Hardware Manual stand. Also DAS GEHT!!!
Hallo Waldemar, poste doch bitte mal Deine Ergebnisse(init(), read_byte(), write_byte() reicht). Es gibt immer wieder Probleme mit der Hardware I2C von M16C und M32C. Dann können alle Anderen ihren aktuellen Stand mit Deinen erfolgreichen Ergebnissen vergleichen. Nur so funktionieren Foren.
Entschuldigung Freunde, ich war ausser sich als ich ACK von gerät bekommen habe. Das Programm ist noch nicht vollständig aber, ich habe mit die einstellungen: mov.b #11111111B, pd3 mov.b #11111110B, p3 ;************************ mov.b #00000010B, pd7 mov.b #11111111B, p7 mov.b #00000010b, u2mr mov.b #00000001b, u2smr mov.b #10000010B, u2smr2 ;iicm2-ACK/NACK int mov.b #10100000B, u2smr3 ; ckph-aus, delay-an mov.b #01110000B, u2smr4 mov.b #10010000B, u2c0 mov.b #050h, u2brg mov.b #00010000B, u2c1 ;************************ mov.b #00000100B, bcnic ;stop/start on mov.b #00000101B, s2tic ;ACK/NAK int on mov.b #00000110B, s2ric ;************************ fset i mov.b #01110001B, u2smr4; -- Gestartet mov.b #00001001B, u2smr4 und dann in start/stop interrupt: iicstart_stop: btst bbs_u2smr jz stop01 ;-------------------START bset ckph_u2smr3 mov.b #00010101B, u2c1 ;transfer an mov.b #0, u2smr4 mov.w #0, u2rb bset 8,r0 ;sonst empfängt man kein ACK mov.w r0, u2tb ;sende Chip Addrese reit stop01: ;------------------STOP bclr ckph_u2smr3 mov.b #0, u2smr4 reit und dan habe ich ACK interrupt bekommen.(was bedeuted addrese war richtig versendet und ACK empfangen.) da musste man dann teoretish beim senden: bset 8,r0 ;sonst empfängt man kein ACK mov.w r0, u2tb ;sende Byte addr. und letzte byte: bset 8,r0 ;sonst empfängt man kein ACK mov.w r0, u2tb ;sende Byte mov.b #01110100B, u2smr4 ;STOP mov.b #00001100B, u2smr4 beim empfangen: erste byte: mov.w #01ffH, u2tb zweite: mov.w u2rb, r1 ;Daten lesen mov.w #01ffH, u2tb ;ACK senden und letzte: mov.w u2rb, r1 ;Daten lesen mov.w #00ffH, u2tb ;NACK senden mov.b #01110100B, u2smr4 ;STOP mov.b #00001100B, u2smr4 So bald ich vollfunktions fähiges Programm habe poste ich das auch.
Korrigiere: beim empfangen: erste byte: mov.w #00ffH, u2tb ;!!!! zweite: mov.w u2rb, r1 ;Daten lesen mov.w #00ffH, u2tb ;ACK senden ;!!!! und letzte: mov.w u2rb, r1 ;Daten lesen mov.w #01ffH, u2tb ;NACK senden ;!!!! mov.b #01110100B, u2smr4 ;STOP mov.b #00001100B, u2smr4 ACK ist ja 0 - nicht 1 Ich benutze m16c62 bei 16 Mhz und m24c32 EEPROM von ST.
Renesas hat euer verweifeltes Flehen erhoert. :-) Es gibt eine relativ frische Applikation rej05b1349_m16cap.pdf ueber die Benutzung von simplen I2C. Also nicht das ganze Multimaster gedoehns... Olaf
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.