Hi Leutz, also ich bin immer noch dabei einen CAN-BUS zu realisieren, wie ich ihn hier schon angefangen habe: Beitrag "CAN-BUS mit dsPIC30F6014" Jetzt habe ich allerdings ein neues Problem: Die Sache mit den 2Boards geht grad nimmer, weil des eine Schrott ist, also dachte ich mir, kein Problem, man kann das ja mit dem 6014 machen, der hat ja zwei CAN-Module drauf... also drauf los programmiert, mittlerweile gehts schon recht fix, nachdem man sich damit jetzt gut auskennt...*g* Dann uP programmiert und ausprobiert...gebe beidesmal die gleichen Daten aufs Register und von da auf die TX-Pins. Das Problem ist nun folgendes: Ich bekomm beim CAN1-Modul das Ergebniss so wie ich es erwarte, aber beim CAN2-Modul kommt was völlig anderes raus, obwohl die beiden Teile identisch sind. Benutze weiterhin das dsPICDEM 1.1 http://ww1.microchip.com/downloads/en/DeviceDoc/70099D.pdf und da ist auf Seite 76 zu sehen wie die beiden PIN's RF0/RF1 und RG0/RG1 auf dem Board angeschlossen sind... Die Beschaltung von RG0/RG1 dürfte doch völlig egal sein, wenn ich an die Schnittstelle nichts hinhänge, oder? Oder übersehe ich da etwas und kann somit keine richtigen Werte am Modul CAN2 ausgeben? Im Anhang hab ich mal das Projekt gepostet, falls jemand den Chip hat und das ausprobieren kann...
Servus, wo hast denn jetzt die Ausgabe gemessen zum Vergleich? Bei CAN1 vor oder nach dem CAN-Transceiver? Ansonsten kann ich mit der Aussage: >Die Beschaltung von RG0/RG1 dürfte doch völlig egal sein, wenn ich an >die Schnittstelle nichts hinhänge, oder? ehrlich gesagt nichts anfangen. Du willst doch mit CAN1 und CAN2 auf den Bus, oder? Gruss, Edson
Tom wrote: > Hi Leutz, > > also ich bin immer noch dabei einen CAN-BUS zu realisieren, wie ich ihn > hier schon angefangen habe: > > Beitrag "CAN-BUS mit dsPIC30F6014" > Warum hast du ihn da nicht weitergemacht? > Jetzt habe ich allerdings ein neues Problem: > > Die Sache mit den 2Boards geht grad nimmer, weil des eine Schrott ist, > also dachte ich mir, kein Problem, man kann das ja mit dem 6014 machen, > der hat ja zwei CAN-Module drauf... Ja, das hat er > > also drauf los programmiert, mittlerweile gehts schon recht fix, nachdem > man sich damit jetzt gut auskennt...*g* Lass mich raten: Du machst jetzt sei zwei Wochen CAN? Respekt, wenn du dich da schon auskennst. > > Dann uP programmiert und ausprobiert...gebe beidesmal die gleichen Daten > aufs Register und von da auf die TX-Pins. Das Problem ist nun folgendes: > > Ich bekomm beim CAN1-Modul das Ergebniss so wie ich es erwarte, aber > beim CAN2-Modul kommt was völlig anderes raus, obwohl die beiden Teile > identisch sind. Nein, die beiden Module sind nicht identisch. Der große Unterschied sind die Speicherbereiche und da können durchaus noch Bugs im Chip, der Beschreibung oder in deiner Software sein. > > Benutze weiterhin das dsPICDEM 1.1 > > http://ww1.microchip.com/downloads/en/DeviceDoc/70099D.pdf > > und da ist auf Seite 76 zu sehen wie die beiden PIN's RF0/RF1 und > RG0/RG1 auf dem Board angeschlossen sind... > > Die Beschaltung von RG0/RG1 dürfte doch völlig egal sein, wenn ich an > die Schnittstelle nichts hinhänge, oder? Definitiv NEIN. Du solltest dir genau ansehen was auf einem Pin verdrahtet ist, bevor du ihn als Ausgang benutzt. Der entscheidende Pin (RG1) geht zB auf den RS485 Transceiver. Zu deinem Glück auf einen Eingang, sollte also gehen. > > Oder übersehe ich da etwas und kann somit keine richtigen Werte am Modul > CAN2 ausgeben? > > Im Anhang hab ich mal das Projekt gepostet, falls jemand den Chip hat > und das ausprobieren kann... Ich werd mal ein Stück Hardware suchen, auf der ich das testen kann.
Ich habe ne Platine gefunden auf der ich testen könnte, allerdings funktioniert sie im Moment nicht. Sobald ich den Fehler gefunden habe, teste ich mit. Was mir eben aufgefallen ist. Ist da wirklich ein 6014 drauf? es gibt eigentlich nur noch 6014A.
sers, danke für die obigen antworten... ja, da ist ein 6014 drauf ich hab aber auch den 6014a rumliegen, also kein problem, wenn du es mit dem testest.. danke schon mal... ich versuch mich mal weiter...*fg* das mit dem auskennen ist so ne sache...ich denk das ich die grundzüge jetzt verstanden habe auf was es ankommt...aber um alles genau zu verstehen und zu können brauch ich wohl noch etwas länger...sonst würd das ding schon laufen...lol
von mir aus können wir auch gern wieder auf den alten thread wechseln, da du eh der einzige bist der hier zurückschreibt, bzw. bereit ist mit bei meinem problem zu helfen
@edson sorry die message hab ich total überlesen...*schäm* ich hab das signal vor dem can-tranceiver abgenommen, also direkt am ausgang des dspicf30f. und dort am rf0/rf1 bzw. rg0/rg1 danke @edson
Meine Hardware funktioniert leider noch immer nicht. keine Ahnung was da nicht geht. Ich bau ma was vergleichbares auf und teste deine routine. kann aber paar Tage dauern.
jo danke, hauptsache ich komm da irgendwann noch drauf...so langsam bin ich schon dabei die ersten grauen haare zu bekommen
hast du mir da mal nen auszug aus der initialisierung? vielleicht komm ich ja so irgendwie drauf?
@Tom kein Problem, hab mich halt gewundert. So wie es ausschaut gehts jetzt in diesem Thread weiter? Werde mich gerne der Sache annehmen, heute geht allerdings nichts mehr. (Arbeit drängt rein, hat Mittags noch ruhiger ausgesehen...) Gruss, Edson
Also ich schreib jetzt auch mal hier weiter. Tom sagt ja dazu nix. Is etwas blöd, da die Diskussion zerrissen ist und kein Mensch mehr den zusammenhang versteht. Aber gut. Das nächste mal weisst dus. Ich hab mir mal deine Routine für CAN1 (auf nem Controller) angeschaut. Ich hab kein Oszi. Welche Baudrate wolltest du denn verwenden? und bei welcher Fcy Frequenz? Also. Zwei Dinge, dann geht deine Routine: Problem 1: Deine Prescalereinstellung erscheint mir sehr sehr hoch. Schreib mal in deiner can_init_CAN1(): C1CFG1 = 0x0003; C1CFG2 = 0x01ED; Dann hast du schon mal funktionierende 250kBaud bei 120MHz bzw 30 MIPS. Dann empfängst du aber noch ne Abenteuerliche ID. Ausserdem ist der DLC bei mir auf dem selbstgebauten CAN Monitor 12. Kann ja wohl nicht sein. Problem 2: Die ID Einstellung ist Abenteuerlich bei dem Controller, das geb ich zu. Wenn du versprichst im Datenblatt nachzuschauen warum es so ist, darfst du die ID folgendermaßen setzen. unsigned int CAN1_SendeID = 0x123; C1TX0SID =((CAN1_SendeID<<2)&0x00fc)|((CAN1_SendeID<<5)&0xF800); Das setzt die ID auf 0x123. Und dann funktioniert der erste CAN auch schon. Den zweiten hab ich nicht getestet, das müsstest du selbst hinbekommen. Sag Bescheid obs bei dir läuft.
guten morgen, dann schreiben wir jetzt alles hier in diesem thread weiter, ist mir auch lieber und beim nächsten mal weiß ich bescheid fg also ich hab nen 7,37MHz Quarz auf dem board stecken... und deine änderungen bezüglich des codes bin ich grad am implementieren... das mit der SID, kann ich mir denken wenn ich den code anschau, aber ich schaus nachher nochmal in der reference nach...
wieso ist der DLC 12? ich setz den bei mir noch gleich der data_length und die ist mit ach defined????
okay und das mit der SID ist klar...hätt ich auch schon früher drauf kommen können: hab am anfang versucht die bits einzeln zu setzen mit C1TX0SIDbits.SID<0> usw... hat der compiler aber nicht gemacht... C1TX0SID hat er genommen....dachte der dröselt das selber auf...aber nee er schreibt meinen wert also die 3bf ins C1TX0SID Register und setzt damit aben auch SRR und TXIDE....nachdem ich den EID allerdings ausgeklammert hab und für SRR eigentlich ne 0 will....trouble... aber danke jetzt noch builden und dann programmen....
Angehängte Dateien:
-
TEK00005.jpg
50 KB
und hier das bild mit can1 und can2, beides mal die gleichen einstellungen, nur SID keine EID und die SID auch richtig ins Register geschrieben.... Jetzt frag ich mich allerdings, wieso wenn ich doch beidesmal das gleiche bei CAN1 und CAN2 mach, wieso ich dann bei CAN2 nicht das selbe bild wie bein CAN1 erhalte...sondern dieses bitmuster, was auch nur alle ca. 5s kommt.... wisst ihr da was?
C1TX0SIDbits.SID<0> geht nicht. Wenn dann C1TX0SIDbits.SID = irgentwas; Beim 2. CAN hast du die Änderungen auch gemacht? Hast du mittlerweile eine Möglichkeit einen Bus aufzubauen?
zur init con tx.SID das hab ich jetzt in den griff bekommen, und ich hab auch verstandne was ich falsch gemacht habe. ich hab jetzt ein 2tes board gefunden, zwar nur das 28PIN Starter Board aber damit müsste es gehen... mit dem CAN1 und CAN2 wollte ich eigentlich auch ein netzwerk simulieren, aber solang der CAN2 da immer was macht, was ich nicht verstehe, wirds wohl besser sein es so zu probieren. Ich hoffe mein MCP2551 kommt nachher mit der Post, dann hab ich für das andere Board auch einen CAN-Treiber, sonst hab ich ja unterschiedliche Pegel.... klappt das mit dem CAN2 bei dir?
das mit dem C1TX0SIDbits.SID = irgendwas geht auch nicht.... da motzt er, dass es kein SID in diesem Register gibt, das ich setzen kann...kann aber auch an der Version 6.6 von MPLAB liegen
Tom wrote: > ich hab jetzt ein 2tes board gefunden, zwar nur das 28PIN Starter Board > aber damit müsste es gehen... hattest du das nicht schon mal und dann gesagt es wär kaputt? > > mit dem CAN1 und CAN2 wollte ich eigentlich auch ein netzwerk > simulieren, aber solang der CAN2 da immer was macht, was ich nicht > verstehe, wirds wohl besser sein es so zu probieren. > > Ich hoffe mein MCP2551 kommt nachher mit der Post, dann hab ich für das > andere Board auch einen CAN-Treiber, sonst hab ich ja unterschiedliche > Pegel.... Das sind ganz andere Signale. Komm nicht auf die Idee die zusammenzuschliessen. > > klappt das mit dem CAN2 bei dir? Konnt ich nicht testen, ich habs mit einem 30F4011 getestet, der hat nur einen CAN.
Tom wrote: > das mit dem C1TX0SIDbits.SID = irgendwas geht auch nicht.... > > da motzt er, dass es kein SID in diesem Register gibt, das ich setzen > kann...kann aber auch an der Version 6.6 von MPLAB liegen Du solltest dein MPLAB unbedingt updaten, die Version ist schon lange veraltet. Wenn du updatest, werden auch neue Headerfiles auf deine Platte kopiert, dann sollte das gehen.
das 2te dsPICDEM 1.1 ist im eimer...das 28PIN ist die Notlösung, weil ja kein Treiber drauf ist... keine Sorge, ich werd die unterschiedlichen Pegel nicht zusammenschliesen...*fg*....wobei??? No sorry just a joke... ich schreib gerade dir routine für das 28Pin board und dann lade ich das ganze mal und vergleich die beiden ausgaben miteinander, denn auf dem 28pin ist nur ein 4012 drauf....
Da musste nicht umschreiben. einfach den zweiten CAN auskommentieren und paar Portinitialisierungen löschen. dann sollte es schon gehen. Was heisst "nur ein 4012" ? Der langt doch völlig. Allerdings musst du beim 4012 aufpassen. Da kannst du nicht gleichzeitig programmieren und CAN anschauen. bzw CAN debuggen geht normal gar nicht. Hast du den Schaltplan (oder Link) von dem Board? Würd mich mal interessieren.
vom 28er? häng ich dir in den anhang das mit dem programmieren und laufen lassen hab ich nachdem ich den schaltplan gesehen habe realisiert... das mit dem programm hat auch geklappt...einziges dilemma: ich bekomm dort am signalausgang RF3 das gleiche Signal wie bei 6014 am CAN2, das was anders aussieht als das an CAN1 und ich nicht wusste wieso.... wenn ich die jumper j8 und j9 entferne, bekomm ich gar kein signal mehr.. ich würds einfach nur verstehen wollen...das kann doch nicht so schwer sein....
Tom wrote: > vom 28er? häng ich dir in den anhang Danke Die haben einfach widerstände reingebaut, dass der programmer stärker treiben kann als die uart. Das Problem beim 30F4012 ist, dass Programmieren, CAN und UART auf denselben Pins ist. Das ist mehr als unglücklich. Wenn du also sinnvoll messen sollst, musst du Uart und Programmer abklemmen. > > das mit dem programmieren und laufen lassen hab ich nachdem ich den > schaltplan gesehen habe realisiert... > > das mit dem programm hat auch geklappt...einziges dilemma: > > ich bekomm dort am signalausgang RF3 das gleiche Signal wie bei 6014 am > CAN2, das was anders aussieht als das an CAN1 und ich nicht wusste > wieso.... Kann nicht sein. Du hast das gleiche Programm genommen mit den Änderungen die ich dir gesagt hatte ? Dann müsst gehen. Passt der Quarz und die PLL? Ich habs doch getestet. Wenn du den mit 120MHz laufen lässt, sollte das Programm auch was auf dem CAN ausgeben. > > wenn ich die jumper j8 und j9 entferne, bekomm ich gar kein signal > mehr.. Sicher? Kann eigentlich nicht sein. > > ich würds einfach nur verstehen wollen...das kann doch nicht so schwer > sein....
Angehängte Dateien:
-
1.JPG
42 KB
ich hab eine idee wegen der unterschiedlichen signale beim benützen von CAN1 und CAN2 auf dem dsPICDEM 1.1 (Schaltplan im Anhang) kann es sein, dass ich wegen der unterschiedlichen IC's die nach den Ausgängen folgen, beide haben ja unterschiedliche Funktionen und Eingangsbeschaltungen, diese beiden unterschiedlichen Signale bekomme?
Das hatte ich ganz am Anfang in dem anderen Tread schon vermutet. Aber der C2TX Pin sollte auf einen Eingang treffen. Deshalb hatte ich beschlossen, dass es nichts ausmacht. aber kontrollier das lieber noch mal.
> Das Problem beim 30F4012 ist, dass Programmieren, CAN und UART auf > denselben Pins ist. Das ist mehr als unglücklich. > Wenn du also sinnvoll messen sollst, musst du Uart und Programmer > abklemmen. Wenn ich da beide Jumper (J8 und J9) für die UART Schnittstelle entferne, bekomm ich gar kein Signal mehr zu messen..... ?????? ( Ohne Scheiß und mir sind auch nicht die Klemmen oder so verrutscht) > Kann nicht sein. Du hast das gleiche Programm genommen mit den > Änderungen die ich dir gesagt hatte ? Dann müsst gehen. Passt der Quarz > und die PLL? Ich habs doch getestet. Wenn du den mit 120MHz laufen > lässt, sollte das Programm auch was auf dem CAN ausgeben. ich hab das programm mit deinen änderungen übernommen.....wie gesagt, er gibt auch was aus...aber eben nur das was beim 6014 der CAN2 macht, das was CAN1 ausgegeben hat, bekomm ich nicht her... --> überlegung mit ausgangsbeschaltung
Angehängte Dateien:
-
TEK00009.jpg
47 KB
und hier das bild vom 4012 beidesmal das gleiche programm....
So heute ist der MCP2551 gekommen und ich kann auf das kleine Demoboard den Treiber für die CAN drauf machen...sodass ich am RX / TX PIN bei beiden Boards die selbe beschaltung habe. Das ganze hat aber an der Tatsache nichts geändert, dass ich immer noch 2 Unterschiedliche Signale bei gleichem Programm habe....egal ob zwei unterschiedliche dsPIC's oder ob ich beide Module auf einem benütze.... mittlerweile hab ich deswegen ne antwort von microchip erhalten: die sagen dass es ganz klar ist, dass ich nur ein Signal am CAN-Port bekomme, da nur CAN1 dort angeschlossen ist... :-( da frag ich mich wer da die mails beantwortet...ist ja nicht so das ich geschrieben habe, dass ich an den PINS direkt abgreife....LOL * Wie lang muss ich eigentlich im Configzuration mode bleiben? * Wenn ich die auszugebenden Daten im PRogramm ändere, kann ich komischerweise am Signal selber keine Änderung erkennen, wieso? Danke schon mal Thomas
Warum du zwei unterschiedliche Signale da rausbekommst weiss ich nicht. Ich kann dir nur sagen, dass deine Routine für CAN1 definitiv richtig sendet. wenn sie es bei dir nicht tut, dann liegt es vermutlich an deiner Taktgeschwindigkeit oder sowas. Ich habe keine Ahnung was das Can Modul macht, wenn man es mit falscher Taktrate füttert.
also CAN1 sieht richtig aus, zumindest kann man erkennen, wo das Signal anfängt und aufhört. Aber das mit CAN2 ist mir ein Rätsel was ich mir nicht erklären kann und auch sonst keiner was weiß, nicht mal die von microchip. ich such mal weiter...danke wenn ich ne lösung habe, post ich das hier mal
hab gerade ne antwort von microchip bekommen...ist aber nicht wirklich befriedigend..: You need to setup the module in configuration mode first and depending on the bus rate you specify in registers CmCFGn, the module will sync. with the bus. Now when you put the module in "normal" mode, it is ready to TX and Rx data. So configuration mode first, change the appropriate register values and than put the module in one of the operating modes.
so, jetzt habe ich nochmal neue news von microchip... mit dem verwendeten Quarz von 7,3728MHz auf dem DemoBoard, kann keine vernünftige Bitrate erzeugt werden. z.B. 500kBit geht nicht, da dann der Fehler beim CAN > 1,25% ist. Und deswegen springt mir der Controller in einen Errorzustand und sendet mir lauter Errorframes...das mit dem Signal Nummer 2 vom CAN soll laut Microchip daran liegen, dass die beschaltung der signale nach dem chip anders ist...soweit waren wir auch schon, nur dass sich das durch eine eigene beschaltung widerlegen lässt... grummel
Tom wrote: > mit dem verwendeten Quarz von 7,3728MHz auf dem DemoBoard, kann keine > vernünftige Bitrate erzeugt werden. z.B. 500kBit geht nicht, da dann der > Fehler beim CAN > 1,25% ist. Und deswegen springt mir der Controller in > einen Errorzustand und sendet mir lauter Errorframes... > grummel Das hatte ich ja schon vermutet. Dann sorg doch mal auf deinem zweiten Aufbau dafür, dass der Takt 120MHz ist. Was hastn du da fürn Quarz dran? Ich habe funktionierende CAN Controller mit 6 MHz, 12 MHz und 120 MHz. Hast du einen Quarz mit dem du eine dieser Frequenzen in Kombination mit PLL erreichen kannst?
natürlich auch einen 7.3728MHz Quarz....:-( ich schau mal was passiert, wenn ich einen 12MHz Quarz nimm und ohne PLL arbeite.... deine 120MHZ hast du wie realisiert? Nen 120er Quarz oder mit PLL?
Hallo Tom, muss mich leider ausklinken. Ich wollte mir ein dsPIC-Board basteln und Deinen code testen aber jetzt lässt meine Arbeit das nicht mehr zu :( Werde aber auf jeden Fall wieder reinschauen was Du und der Willivonbienemaja so macht. Viel Erfolg noch! Mit der bitte um Entschuldigung, Edson
Tom wrote: > natürlich auch einen 7.3728MHz Quarz....:-( > > ich schau mal was passiert, wenn ich einen 12MHz Quarz nimm und ohne PLL > arbeite.... Stell den Prescaler auf 0, dann solltest du 100kBaud haben. (so ausm Bauch raus. Kannst es zur Sicherheit nachrechnen) > > deine 120MHz hast du wie realisiert? Nen 120er Quarz oder mit PLL? 7,5 MHz Quarz (schwer zu bekommen) + PLL x 16 Wenn man sich genau an die Vorgaben - bezüglich des Taktes - aus dem Datenblatt hält, dann ist es sehr schwer genau auf 120 MHz zu kommen. Wenn mir da jemand ne schönere Variante nennen kann immer her damit.
Angehängte Dateien:
-
TEK00001.jpg
45 KB
@edson kein thema @willi ich hab folgende settings vorgenommen: prescaler 0 phaseseg1 auf 8TQ phaseseg2 auf 5TQ und sjw auf 1TQ bei einem verbauten 12MHz Quarz und ohne PLL erhalte ich 100kbit übertragungsrate. von der uart schnittstelle hab ich nachdem ich programmiert hab den tX pin enabled (jumper9) bild 1 und dann den mcp2551 enabled, bild 2 gesendet hab ich immer noch die 10101010 folge welche einstellungen hast du bei deinen 12MHz? Die Signale, die ich da empfange schauen bis auf bild1 eigentlich nicht gut aus....
Wie kommst du denn drauf, dass die Signale nicht gut aussehen? Bild 3 und 4 sehen doch hübsch aus? Und bei Bild 2 steht 50 kS/s ? Ist es sinnvoll bei 100kBaud mit 50kS/s abzutasten?
Wie kommst du denn drauf, dass die Signale nicht gut aussehen? Bild 3 und 4 sehen doch hübsch aus? -> bei Bild 3 steckte der MCP nicht richtig drin -> bei Bild 4 hab ich halt immer noch nicht das, was der Frame darstellensollte.... Und bei Bild 2 steht 50 kS/s ? Ist es sinnvoll bei 100kBaud mit 50kS/s abzutasten? -> Sicherlich nicht, aber nur so konnte ich das ganze Frame anzeigen lassen...bei den anderen Bildern fehlt ja hinten immer ein kleines Stück (Bild 1 z.B.) aber mir ist noch was anders eingefallen...ich sollte nach dem MCP2551 meinen 120Ohm Terminierungswiderstand einbringen...da ändert sich das Signal auch wieder...zumindest hats beim dsPICDEM 1.1 einen unterschied gemacht....
hab mich jetzt hier mal angemeldet und werd dann ab jetzt dann unter dem Namen tom-tom weiterposten...
> -> bei Bild 4 hab ich halt immer noch nicht das, was der Frame > darstellensollte.... Lass doch mal dein Scope weg. Das CAN Frame ist kompliziert. Wenn du willst, kannst du mir dein Programm schicken und mir sagen welchen Quarz und welche Baudrate du nutzt, dann kann ich das bei mir testen und dir sagen, ob das richtige auf den CAN gesendet wird. > aber mir ist noch was anders eingefallen...ich sollte nach dem MCP2551 > meinen 120Ohm Terminierungswiderstand einbringen...da ändert sich das > Signal auch wieder...zumindest hats beim dsPICDEM 1.1 einen unterschied > gemacht.... CAN ist ein Bus, der an beiden Enden mit 120 ohm abgeschlossen werden muss. Aber du misst doch nicht direkt auf dem bus oder? Also sollte das nicht allzu kritisch sein. Machs aber trotzdem richtig.
Nein, ich mess noch gar nicht auf dem bus, aber wenn der Widerstand über den Jumper rausgenommen wird, dann ändert sich das Signal. Ich post dir nachher mal das Programm. Willst du die Version mit der Microchip Bibliothek oder die selber geschriebene, wo ich jedes Register einzeln setze? Ich benutze einen 7,3728 MHz Quarz mit PLLx16 was einer Osz. Frequenz für den CAN von 29.4912 MHz entspricht. Hier werd ich wohl noch einen 7,5er suchen oder auf 30MHz ohne PLL gehen... auf dem dsPICDEM 1.1 mit dem 6014 / 6010a Auf dem dsPICDEM 28 hab ich einen 4012 und beim Quarz hatte ich die 7,3728 drauf mit PLLx16 und hab das jetzt auf nen 12MHz Quarz getauscht (PLLx4), dass ich die 100kBit hinbekomme das im anhang ist die file für den 6010a auf dem dsPICDEM 1.1 mit der Microchip lib
und das hier das projekt mit den einzelnen registern und dem 4012er
Ich muss dich mal etwas bremsen. Du hast nicht erzählt das du ne Version mit der microchip Lib hast. So, du hast folgendes: - Funktionierende Routinen für CAN1 - zwei Boards Warum baust du nicht jetzt ein CAN Bus mit den zwei Teilnehmern auf ??? Irgentwie versuchst du immer noch den CAN Frame mit dem Scope aufzuzeichnen und zu dekodieren. Is nicht böse gemeint, aber du solltest Schritt für Schritt vorgehen und erst mal das zweite CAN Modul ausser acht lassen.
okay, das zweite Progi mit der lib, hab ich mittlerweile nebenzu gemacht. Wusste vorher nicht das es sowas gibt, und zum Verständnsi war es sicher nicht schlecht am Anfang die Register selber mal zu setzen und zu wissen was da dann in der Lib geschieht. Du hast recht, dass ich mit dem scope evtl. etwas stur bin grins...ich werds mal ausschalten... und dann werde ich mal mit den beiden platinen und der funktionierenden CAN-Routine versuchen das dinges zum laufen zu bekommen... thx
hallo erstmal, es gibt neues von der front...das mit dem dsPICDEM 28 und dem falschen Signal hat sich auch geklärt. Zum einen hat die Frequenz nicht gestimmt, es kamen nur Errorframes, da der dsPIC über den 30MIPS lag. zum anderen muss beim MCP2551 der RS-Pin auf Masse gelegt werden, sonst hab ich ein floatendes Signal. Damit hab ich jetzt bei beiden boards das gleiche aussgangssignal und kann mich an die kommunikation machen. grüße Thomas
> zum anderen muss beim MCP2551 der RS-Pin > auf Masse gelegt werden, sonst hab ich ein floatendes Signal. Das muss bei allen CAN Transceivern gemacht werden, sonst legt er sich schlafen.
So, jetzt hab ich die beiden boards miteinander verbunden, und zwar jeweils CANH auf CANH und CANL auf CANL. die Routine vom zweiten board hab ich so geändert, dass der sende und empfangsteil vertauscht ist, sprich erst empfangen, dann senden. damit ich einfach ein echo realisieren kann.....jetzt sendet das board1 allerdings ständig und board 2 sendet gar net...wie teilt der can von board 2 dem von board 1 mit, dass die nachricht da ist und er aufhören kann zu senden? Oder muss er das gar net? Und ich versteh da mal wieder was falsch?
ich glaub ich habs...interrupt und flags...damit müsste es doch klappen...???
Ja mit den Interrupt Flags gehts. Hübscher ist es allerdings wenn du die Interrupts nutzt. Sollte aber auch so gehen.
Wie verhält sich das mit dem TXREQ Bit? Wenn ich das setze, dann sende ich die nachricht. ist der buffer leer, dann wird das bit automatisch gecleared? weil request ist doch die anfrage/anforderung, dann muss ich doch eigentlich aus einer empfangenen nachricht rausfinden können, ob ich eine message senden soll? oder? kann mir jemand verraten wie das geht?
Schau dir mal im 30F Family Reference das Kapitel 23.7.4 an. Das heisst: Message Transmission nachfolgend zwei Auszüge daraus: Tom wrote: > Wie verhält sich das mit dem TXREQ Bit? > "To initiate transmitting the message, the TXREQ bit (CiTXnCON<3>) must be set" > Wenn ich das setze, dann sende ich die nachricht. ist der buffer leer, > dann wird das bit automatisch gecleared? > "Setting TXREQ bit does not actually start a message transmission" > weil request ist doch die anfrage/anforderung, dann muss ich doch > eigentlich aus einer empfangenen nachricht rausfinden können, ob ich > eine message senden soll? oder? > > kann mir jemand verraten wie das geht? Was ich jetzt nicht verstehe: Was machst du? du hattest doch schon mal funktionierenden Code mit dem du senden konntest. Beim senden musst du nicht unbedingt die Interrupts benutzen, da ist es sogar teilweise sinnvoll diese zu umgehen.
nachdem ich beide boards zusammengeschlossen habe und einfach mal testen wollte ob was ankommt und so, hab ich mich dazuentschlossen das dann auch mit interrupt zu machen, so wie vorher gesagt. das mit dem TXREQ kommt daher, da ich eben den interrupt auslösen will, wenn eine message anliegt, und dann erst senden will. Dazu hab ich in der ISR das TXREQbit gesetzt und dachte der sendet. tat er nicht... ----> beim einbinden der ISR und beim testlauf hab ich dann gemerkt, dass ein Interrupt auslöst und zwar nicht der RX0IF der auslösen sollte wenn eine message im buffer ist, sondern der ERRIF und da stellte sich dann raus das das TXWAR gesetzt ist, was mir sagt transmitter errorstatus, warning bit. das ist das dilemma, das ich gerade habe und wo ich nicht weiterkomme...
Tom wrote: > nachdem ich beide boards zusammengeschlossen habe und einfach mal testen > wollte ob was ankommt und so, hab ich mich dazuentschlossen das dann > auch mit interrupt zu machen, so wie vorher gesagt. Ging die CAN Kommunikation oder nicht? > beim einbinden der ISR und beim testlauf hab ich dann gemerkt, dass ein > Interrupt auslöst und zwar nicht der RX0IF der auslösen sollte wenn eine > message im buffer ist, sondern der ERRIF und da stellte sich dann raus > das das TXWAR gesetzt ist, was mir sagt transmitter errorstatus, warning > bit. Ich könnt wetten du hast verschiedene Baudraten bzw Taktfrequenzen. Andere Möglichkeit wäre noch Anschlussfehler. Ich brauch etwas mehr Infos. zB anschlussplan, bild des aufbaus. verwendete software...
Hi, also die Kommunikation hat nicht funktioniert, zumindest ist nichts in das rx_data geschrieben worden. ich mach mich mal daran die pläne zu digitalisieren und hier zu posten.. ebenso die programmteile... die timings und die frequenzen sind auf beiden controllern gleich gewesen...
Tom wrote: > Hi, > > also die Kommunikation hat nicht funktioniert, zumindest ist nichts in > das rx_data geschrieben worden. Dann stimmt was bei deinem empfangen nicht. Das Senden habe ich definitiv bei mir gesehen. Oder hast du die Änderungen die ich dir gesagt habe nicht gemacht?
doch, hab ich gemacht, ich kann die nachricht auch sehen, nur empfangen tut er nicht...und wenn ich mir das ganze dann am scope anschau..verzeih mir, und das frame aufdrösel, dann seh ich das die daten+errorframne gesendet werden..
Angehängte Dateien:
-
Aufbau.JPG
61 KB
So, hier hab ich mal den Aufbau grob aufgestellt. Beide dsPICS laufen mit einem 7,37MHZ Quarz und einer PLL von momentan 8. Die Timings müssten so für die PLL stimmen, dass ich eine 250k Übertragungsrate hinbekomme. Das Programm poste ich dir später von zuhause, wenn ich an nen USB-Port hinkomme...
Tom wrote: > doch, hab ich gemacht, ich kann die nachricht auch sehen, nur empfangen > tut er nicht...und wenn ich mir das ganze dann am scope anschau..verzeih > mir, und das frame aufdrösel, dann seh ich das die daten+errorframne > gesendet werden.. wird bei dem controller der empfangen soll das error flag gesetzt im INTF Register?
Tom wrote: > So, hier hab ich mal den Aufbau grob aufgestellt. > > Beide dsPICS laufen mit einem 7,37MHZ Quarz und einer PLL von momentan > 8. > Die Timings müssten so für die PLL stimmen, dass ich eine 250k > Übertragungsrate hinbekomme. > > Das Programm poste ich dir später von zuhause, wenn ich an nen USB-Port > hinkomme... das mit dem krummen Quarz is so ne Sache. Am besten du gibtst mir einfach mal ein Programm das ne Nachricht sendet und ein Programm das ständig Nachrichten empfängt und diese wieder zurücksendet. Also ein Echo. Dann kann ich schnell mal testen ob das funktioniert was du da machst. (Ich hoffe ich bin im Bestitz eines 7,37 MHz Quarzes, muss ich mal schauen)
hi, bevor ich das ganze projekt jetzt dann poste, hab ich noch eine frage, hab den fehler nämlich glaub ich gefunden....lol wie ist das mit dem message request bit? REQ? ich glaub daran hängt nämlich das ganze problem....mein Modul sendet die nachricht immer weiter, obwohl ich mir am anfang sicher war, dass das nur einmal gesendet wird. aber dadurch das ich immer sende, kann mein zweiter knoten kein echo senden, da der bus immer belegt ist... was hat das request bit damit zu tun?
und nochmal....hat wohl das erste mal nicht geklappt.. ich hoffe du findest den bug...
Das is ja jetzt alles aus irgentwelchen Quelltexten aus der Microchip Bibliothek zusammengebastelt ??? Warum nimmst du denn nicht deinen eigenen Code der schon funktioniert hat ???
weil ich um das ganze etwas übersichtlicher haben wollte und auch für andere, die sich nicht so mit den registern auseinandergesetzt haben und die lib benutzen zugänglich machen wollte. Ich hab vor das ganze wenns geht hier irgendwo als democode reinzustellen, damit nachfolgende, die evtl. die selben probleme bekommen eine funktionierende version haben, die auf standards basiert. hast du es bei dir schon mal laufen lassen? grüße tom
Ich habe es gerade mal getestet. Also mit 7,3728 MHz und PLL8 kommen keine 250 kBaud raus. - Du hast schätzungsweise 20 Dateien mehr eingebunden als bei der Version mit deinem eigenen Code. Warum soll es dadurch übersichtlicher werden? - Wenn sich jemand nicht mit den Registern auseinandersetzt hat er wohl eh nicht ernsthaft vor einen Controller zu programmieren. - Democode mit den Bibliotheksfunktionen kannst du dir sparen. Es gibt schon genug Code Examples von Microchip dazu. - Der Umweg über die Lib ist Standard, aber der direkte Zugriff auf die Register nicht ??? Aber ok. Du kannst es natürlich so machen wenn es dir lieber ist. Was bei deinem Code jetzt wieder nicht stimmt kann ich dir noch nicht sagen.
grummel, momentan hab ich folgenden Stand: dsPICDEM 1.1 sendet eine Nachricht z.B.: Kreation dsPICDEM 28 empfängt 8 Zeichen, & sendet diese an dsPICDEM 1.1 dsPICDEM 1.1 empfängt DAten und gibt sie aus: _ #°.... sende ich nach empfangener Nachricht am dsPICDEM 28 folgendes: KrEATION, empfange ich am dsPICDEM 1.1 KrEATION, also alles wunderbar... nur wo liegt das Problem beim senden von 1.1 zu 28? An der Umwandlung von rx -> tx liegts nicht, das hab ich schon separat getestet. beim dsPICDEM 1.1 sollte das ganze auch richtig senden, zumindest geht das im Loopback-mode...also liegts irgendwo am MCP2551 RX oder am 4012er RXn ?? Hast du oder jemand anders eine Idee?
danke an alle....es geht!!! ich werd bei gelegenheit, also heute abend noch den code hier posten, falls nochmal jemand mit so einem gschmarnn zu tung hat
ich hab díe verschiedenen Programmteile in der Codesammlung abgelegt, falls jemand mal sowas brauchen sollte.. mf*grinsen* tom
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.