www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Tricore - Projekt. ist das zu schaffen?


Autor: KlausT. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KlausT. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: KlausT. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: KlausT. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: KlausT. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: KlausT. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum ist der 16 Bitter nicht geeignet?
byteorientiert = infos werden byteweise ausgetauscht, oder?
hat das was mit den Kontrollbits zu tun?

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PCan Explorer,

USB Dongle, und ab. Ich habe damit gute erfahrungen gemacht.


www.systec-electronic.com/html/index.pl/product_pcan_explorer3

Dennis

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema PC und CAN, kann ich noch diese Seite beitragen: 
http://www.mhs-elektronik.de/cgi-bin/mhs.pl

Ciao, Fabian

Autor: Carsten St. (carsten)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?).

Autor: KlausT, (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: KlausT. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carsten St. (carsten)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: KlausT. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Armin O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.