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)

http://www.hitex.co.uk/tricoretoolbox/main.html

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