Hallo, Es soll ein Gateway entwickelt werden, und zwar mit dem Tricore von Infineon. Ziel ist, ihn in ein CAN Netzwerk einzubinden und über eine Ethernet-Schnittstelle eine Verbindung an einen PC zu realisieren. Damit ist auch schon der einzige Typ vorgegeben: TC1130 (CAN und Ethernet). Die Kommunikation ist also wahlweise CAN und Ethernet. Funktioniert wie ein Gateway. Da µVision den Controller nicht unterstützt muss TASKING genommen werden. ca. 6 Monate ist dafür Zeit. Ich kenne leider niemand mit Erfahrung mit diesem Teil. Ich selbst habe nur Erfahrung mit PIC und AVR (8-Bit). Habe auch schon über mcp25xx CAN Schnittstellen realisiert. Kann es sein dass es mit dem Tricore ungleich schwieriger ist, selbst nur ein funktionierendes CAN zu erzeugen? ich hoffe es kann jemand helfen, ist ja alles noch sehr neu.
Hmm, ich wär' da ein bischen (ziemlich) skeptisch. Wenn man nicht auf bestehende Erfahrungen mit dem konkreten uP, seinem Compiler, Debugger, Emulator etc. zurückgreifen kann, wird's schwierig. Zumindest bräuchte man ein "Beispielprojekt" das funktioniert und das man voll nachvollziehen kann. Bei CAN braucht man immer auch eine oder meherer Gegenstellen, sowie evtl. zusätzliches "Mithör"-Möglichkeiten. Übliches Laborequipment, speziell Speicherscope >= 100 MSample ist zwingend. (offensichtlich sind wir Namenskollegen)
Also 6 Monate sind für ein solches Projekt schon wirklich arg knapp, besonders wenn man die Komplexität der Plattform im Hinterkopf behält (das ist wirklich eine ganz andere Dimension als ein AVR oder ein PIC) und daran denkt dass daran meist auch noch eine andere Toolchain hängt. Der Vorteil des TC1130 ist, dass es hier ein Linux gibt, ich glaube aber nur als Binärabbild, Quelltext habe ich dazu noch keinen finden können, wenn es dir also gelingt, für diese Linux einen CAN Treiber zu bauen, bist du fertig - herzlichen Glückwunsch. Eine andere Möglichkeit wäre, einen anderen TriCore zu nehmen und die Ethernetschnittstelle auf anderem Wege anzubinden, die TriCore-Derivate TC1766, TC1775, TC1796 werden auch von diversen OSEK-Implementierungen unterstützt (z.B. ProOSEK) - Nachteil: OSEK-Implementierungen sind nicht umsonst! Warum muss man übrigens Tasking nehmen, nur weil uVision dieses Derivat nicht unterstützt? Wenn du mit der GNU Toolchain vertraut bist (davon gehe ich mal aus, wenn du mit dem AVR vertraut bist), dann bleibe dabei und setze sie auch für dieses Projekt ein, das ist schon mal eine neue Sache weniger. Natürlich kann es auch sein, dass du mit der Tasking Toolchain 'per du' bist und die in- und auswendig kennst. Ciao, Fabian
KlausT. wrote: > Da µVision den Controller nicht unterstützt muss TASKING genommen > werden. Nur weil ein bestimmtes Derivat nicht in einer Auswahlbox auftaucht, muß es noch lange nicht heißen, daß man es nicht programmieren kann. In der Regel reicht es, sich das passende include-File downzuladen oder ein ähnliches anzupassen, und schon gehts los. Den Compiler interessiert ja nur der Befehlssatz in den er die C-Ausdrücke übersetzt und der sollte ja gleich sein. Ich nehme z.B. nen Keil von 1995 und programmiere damit 8051-er, die erst 2005 rauskamen. Peter
> Eine andere Möglichkeit wäre, einen anderen TriCore zu nehmen und die > Ethernetschnittstelle auf anderem Wege anzubinden, die TriCore-Derivate > TC1766, TC1775, TC1796 werden auch von diversen OSEK-Implementierungen > unterstützt welche Erleichterung bringt das von dem TC1130 auf zB TC1766 zu gehen? Theoretisch wäre die ETH-Anbindung durch einen externen Baustein machbar. Aber ob es das vereinfacht weis ich nicht..oder übersehe ich was?
> welche Erleichterung bringt das von dem TC1130 auf zB TC1766 zu gehen? > Theoretisch wäre die ETH-Anbindung durch einen externen Baustein > machbar. Aber ob es das vereinfacht weis ich nicht..oder übersehe ich > was? Die Entwicklung selbst wird dadurch vielleicht nicht unbedingt beeinflusst (und wenn dann eher negativ als positiv, weil man solche externen Bausteine ja immer recht schlecht debuggen kann), aber wenn man einen TC1130 nimmt, sollte man beachten, dass man auf jeden Fall externes RAM und Flash benötigt. Der TC1796 hingegegen hat z.B.2 MB internes Flash und wenn man nicht gerade mit Speicher um sich wirft, dürfte auch hier der interne Speicher reichen, das Hardware-Zeug wird dadurch einfacher.
kein Flash Memory im Chip. Wussta garnicht dass es sowas gibt, aber stimmt. Das Problem würde dann verschwinden wenn ich mit einem dieser Starterkits arbeite(?) Nei denen ist der Speicher drauf.
Ja, so siehts aus. Und Du hast noch eine Baustelle weniger mit einem funktionierenden EvalKit. In den allermeisten Fällen liegt auch noch Source-Code bei, der die Funktionsfähigkeit der einzelnen Schnittstellen demonstriert. Stephan.
also ein EvalKit wollte ich sowieso nehmen. Damit wäre das schonmal ok. Wie verschieden sind eigentlich die Programme von einem 16Bit zum Tricore? Ich denke existierende Programme für einen C166 z.B. eine CAN Implementierung dürfte zu finden sein, bin mir natürlich jetzt nicht sicher. Aber evtl könnte man sich das als Grundlage nehmen. Kann sich das jemand vorstellen?
Es sind bei Infineon einige simple Beispiele zu finden, das ist ja schon mal was. Aber nochmal dazu: Wie ähnlich sind die 16Bit MCUs zu den Tricore MCUs, was das Programmieren in Tasking angeht? Hat da jemand Erfahrung? Wär echt gut das zu wissen..
Also diese beiden Prozessoren sind schon ziemlich verschieden, es kann aber sein, dass du dir gar nicht so viel Gedanken drüber machen musst, wenn dir der Tasking Compiler das evtl. abnimmt. Das fängt schon mal damit an, dass der TriCore eine Harvard-Architektur ist und z.B. explizit zwischen Adress- und Datenregistern unterscheidet (der C166 dürfte da keine Unterscheidung treffen - oder?), außerdem verwaltet der TriCore seine Aufrufkontexte in verketteten Listen, die teilweise automatisch und teilweise explizit auf und abgebaut werden. Aber ok, wenn du einen Compiler verwendest und keinen eigenen Startup-Code haben willst, sollte dich das eigentlich nicht stören und der Tasking sollte durchaus einen passenden Startup-Code mitliefern. Das nächste ist die Interrupt-Behandlung - da kenne ich den C166 nicht genau genug, bzw. weiß nicht wie die Derivate die Interrupt-Behandlung implementieren. Ich kann mich aber erinnern, dass man für die einzelnen Quellen, die Level in jewiels einem Register setzen kann (zumindest war das beim C167CR so), wenn dann die Vektortabelle noch nach den Levels aufgebaut ist und innerhalb der Levels selbst dispatchen musst, wenn zwei Quellen Unterbrechungen auf demselben Level erzeugen, ist das schon ziemlich ähnlich. Beim TriCore kannst du halt noch die Anzahl der Levels in ein paar Stufen konfigurieren und so die Hardware-Interrupt-Latenz etwas beeinflussen. Aber auch das sollte dich nicht interessieren, wenn der Tasking irgendein 'Interrupt-Hanlder" Schlüsselwort unterstützt, auch das sollte der Tasking bieten. Bleibt also nur noch das CAN-Modul selbst, wenn du riesen Glück hast, ist das immer noch dasselbe, wie beim C166 verwendete CAN-Module, weiß ich nicht, müsste man nachsehen, ansonsten kommst du um ein eingehendere Beschäftigung mit diesem Teil des Controllers nicht drumherum. Du bist hier aber auf einfädiges Programm und Unterbrechungsbehandlung beschränkt, eine OS-Implementierung bietet der Compiler im Normalfall nicht. Ciao, Fabian
Ja, CAN ist schon ne prima Sache für Steuerungen, bloß ein PC hat kein CAN. Mit CAN-Karten hatten wir immer nur Ärger, da haben wir nen eigenen CAN-Ethernet Converter gebaut. Ist ne ganz simple Sache, nur 2 Chips: AT89C51CC01 + LAN91C96 auf ner 2-Ebenen Platine. Funktioniert prima. Ethernet und CAN sind ja Byte-orientiert, da nützt ein 16-Bitter also überhaupt nichts. Peter
Warum ist der 16 Bitter nicht geeignet? byteorientiert = infos werden byteweise ausgetauscht, oder? hat das was mit den Kontrollbits zu tun?
Man kann zwar einen 16bitter nehmen, muß man aber gar nicht. (das ist Peters Aussage...) Man kann die Aufgabe mit einen schnellen 8-bit-Controller erledigen. ==> Der Tricore dürfte sich die meiste Zeit langweilen.
Der ursprüngliche Post von KlausT klang aber durchaus so, dass der TriCore wegen einer anderen Randbedingung genommen wird, nicht wegen dem CAN, also sollte der Controller hier eigentlich gar nicht zur Debatte stehen.
PCan Explorer, USB Dongle, und ab. Ich habe damit gute erfahrungen gemacht. www.systec-electronic.com/html/index.pl/product_pcan_explorer3 Dennis
Zum Thema PC und CAN, kann ich noch diese Seite beitragen: http://www.mhs-elektronik.de/cgi-bin/mhs.pl Ciao, Fabian
Ich muss hier dem WM-Rahul recht geben. Wenn die einzige Aufgabe das Gateway ist, dann reicht ein 8-Bit µC mit externem Ethernet-Controller dicke aus. Das wird sich von der Platzfläche nichts nehmen und günstiger im Einkauf sein.
Ich wollte das nur als Beispiel nennen, daß sowas durchaus lösbar ist und auch mit wesentlich einfacherer Hardware. Das 16Bitter es nicht können, steht nirgends. Sie können bloß ihre Vorteile nicht ausspielen. Bei den PC-Karten hatte wir massive Probleme mit den mitgelieferten DLLs, die waren der absolute Schrott. Peter
@Carsten: Danke! Es werden aber insgesamt 3 Bausteine gebraucht: CAN-Controller, Ethernet-Controller und Controller-Controller. Der Controller-Controller koordiniert (nicht kontrolliert, siehe Wikipedia "Falscher Freund") den Datenverkehr zwischen den beiden anderen. Das könnte vielleicht sogar mit einem Mega8 machbar sein, wenn die beiden anderen über die SPI angesprochen werden...(ENC... + MCP2515) Je nach mitglieferter Periferie sollte der Tricore das problemlos schaffen (Spatzen&Kanonen?).
ja die Methode mit AVR + mcp + mcp kenne ich und habe sie auch schon aufgebaut. Aber aktuell muss es ein TriCore sein. Darauf wird dann später aufgebaut. Mein Ziel ist erstmal das CAN darauf zum laufen zu bringen. Danach noch Ethernet. Sieht nach Arbeit aus. Ich müsste unbedingt auf Beispielen aufbauen, sonst wird das wohl nix.
Ich habe dann auch mal das DAvE entdeckt. Kennt jemand das Tool? Ist direkt vom Hersteller Infineon und es erleichtert einem das Grundgerüst zu schaffen. Kennt sich jemand näher aus..taugt das was?
Hab mit DAvE und einem XC167 mal etwas rumgespielt.Der produziert selbst für kleinste Sachen schon grössere Mengen Code und ganze Romane an Kommentaren.Und wenn man einmal damit Code erzeugt&das eigentlich Programm hinzugefügt hat,muss man dann den Spaghetti-Code von Hand anpassen falls man irgendwas an der Initialisierung ändern möchte.Überhaupt ist das generierte arg unübersichtlich. Da gefallen mir z.B die Startup-Files die beim KEIL beiliegen wesentlich besser.Da ist alles gut kommentiert und deutlich übersichtlicher als bei dem Zeugs aus einem Codegenerator.Ausserdem gliedert man da ein einziges Startupfile an das eigene Projekt,nicht das Projekt an viele kleine Includefiles. Was allerdings für den Einsieg sehr praktisch ist,sind die Assistenten die z.B für den UART aus Taktfrequenz und Baudrate die richtigen Initialisierungswerte für die entsprechenden Register berechnen.Zumal man sofort sieht,welche Auswirkungen die Änderung eines Teilerregisters auf die Baudrate hätte. In einem eigenen Projekt schreibt man dann aber besser wieder den Code selber.
Ich finde den DAvE Klasse. Der Code ist überhaupt nicht unübersichtlich, wenn man sich etwas stärker damit befasst. Jedes Module erhält seine eigene Datei. Was den Code so aufbläht ist, dass jedes Register initialisiert wird, auch wenn es schon richtig aus dem Reset kommt. Die erzeugten Kommentare sind sehr ausführlich und sind notwendig um DAvE klarzumachen welcher Code von ihm erzeugt wurde bzw. vom User kommt.
Hallo nochmal.. da ich bis jetzt nichts mit dem TASKING zu tun hatte, nur eine kurze Frage vorab: ich sehe immermal das Stichwort "Start-up file". Was genau soll das sein? Ist das für das Tasking gedacht?
Hallo, ich habe mal eine Frage zum Starterkit von Infineon: Warum hat dieses SK-TC1130 eigentlich nur zwei CAN Nodes ? Der Chip 1130 hat aber 4 CAN Nodes.... Wurden da einfach zwei nicht genutzt?
Also der TC1796 z.B. hat auch vier CAN-Module, herausgeführt und mit einem Treiber bestückt sind auf dem TriBoard aber auch nur zwei. Man bestückt halt einfach nicht alle möglichen Anschlüsse eines solchen uController auf einem Evaboard, die Masse der Nutzer würde sowieso kaum welche davon verwenden. Bei den Infineon Starterkits sind aber alle Ausgänge der Chips zugreifbar, so dass du selbst noch einen Treiber etc. für die anderen beiden CAN-Controller an das Board anflanschen kannst. Ciao, Fabian
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.