Hi, momentan suche ich mit meinem Betreuer nach einem Thema für meine Bachelorarbeit im Bereich Elektro- und Informationstechnik. Ursprünglich sollte ich die Sensorauswertung eines Elektromotors in einem Projekt machen. Dieses Projekt hat sich verzögert und deshalb suchen wir etwas neues... Mein Betreuer macht viel mit Elektrofahrzeugen und deren Sensorauswertung, Fahrspurerkennung, etc. und meinte jetzt, dass man vielleicht etwas mit dem Tricore machen könnte. Ist der Tricore dazu überhaupt gut geeignet? Hab mich jetzt ca. 2 Wochen mit dem Thema beschäftigt und bisher sieht es recht kompliziert aus, zumal ich fast keine Erfahrung mit Mikrocontrollern habe. Die Bachelorarbeit soll in 3 Monaten bei zusammenhängender Bearbeitung fertiggestellt werden können. Maximum sind 5 Monate. Dauert das Einarbeiten in den Controller zu lange und ist es zu kompliziert, etwas brauchbares zustande zu kriegen? Ist es womöglich ein Schuss ins eigene Bein, das Thema anzunehmen? Der Experte für Tricores ist nur 1 mal pro Woche hier und hat dann auch noch wenig Zeit für mich. Muss also viel selbst rausfinden... Wie könnte denn ein passendes Thema sein?
Mach etwas wovon Du bereits eine gewisse Ahnung hast. Etwas "Neues" zu machen wovon man keine Ahnung hat, macht zwar Spass ist aber evtl. hinderlich wenn man gute Ergebnisse erzielen möchte. Wenn Du rechnest dass Du nochmal 2-3 Wochen für die Einarbeitung brauchst (uC u.ä.), dann noch einen Monat um die Thesis zu schreiben, drucken und binden, dann bleiben Dir 5-6 Wochen für das Thema !!! Verzögerungen, die es mit Sicherheit noch geben wird, nicht mit eingerechnet. Grüße
Tricore sind schlecht verfügbar (und Infineon etwas komisch) und es gibt nur wenige Derivate, ausserdem zu teuer. Der kann nichts, was andere Controller nicht auch könnten. (Siemens hatte den mal als revolutionär vorgestellt ....von wegen) ..würde den nicht nehmen Vielleicht reicht sogar n 8biter
T. Mai schrieb: > Hab mich jetzt ca. 2 Wochen mit dem Thema beschäftigt und bisher sieht > es recht kompliziert aus, zumal ich fast keine Erfahrung mit > Mikrocontrollern habe. Für mich sieht er auch recht höllisch kompliziert aus. Ich würde erstmal mit ner 1-Kern-CPU anfangen, z.B. ARM-Cortex M3. Auch weil dazu bestimmt wesentlich mehr Wissen und Hilfe im Web zu finden ist. Um die Leistungsfähigkeit eines 3-Kern auszureizen, braucht man bestimmt > 1 Jahr. Peter
Der TC1796 zB wird in Motorsteuerungsgeräten von Premiumfahrzeugherstellern verwendet. Der ist Wahnsinnig komplex. Alleine das benötigte OS für diesen Chip ist so kompliziert, das man alleine darüber eine Bachelorarbeit schreiben kann. Ich würde dir einen single core Chip empfehlen zb ARM7 oder 9. Alleine um auf dem TC was sinvolles zum Laufen zu bekommen benötigt jeder Normalsterbliche mindestens 3 Wochen.
T. Mai schrieb: > Hi, [...] > Sensorauswertung, Fahrspurerkennung, etc. [...] > fast keine Erfahrung mit Mikrocontrollern habe. > > Die Bachelorarbeit soll in 3 Monaten bei zusammenhängender Bearbeitung > fertiggestellt werden können. Maximum sind 5 Monate. Bei den Randbedingungen wird das nichts, sorry. Warum muss es denn auf µC-Basis sein? Es ist mit einiger Sicherheit sinnvoller, wenn Du einen Prototypen (z.B. zur Fahrspurerkennung) auf PC-Basis machst. Das ist auch schon ganz nett anspruchsvoll, selbst wenn es nicht in Echtzeit, sondern auf der Basis aufgezeichneter Daten funktioniert. Wenn das System dann toll funktioniert (und sei es in Matlab), kannst Du Dich als Masterstudent dann als wissenschaftliche Hilfskraft anstellen lassen und das Ergebnis auf den µC portieren, sei es nun der TC1796 oder ein anderes Riesengeschoss. Das macht Spass und finanziert die Kneipenbesuche während des Masterstudiums. Gruß, Max (der das zu Diplomzeiten etwa so praktiziert hat)
Mit dem GNU-Debugger den TriCore zu debuggen, ist eine wahre Freude. Zumal der alte TC1796 nur 2 Hardware-Unterbrechungspunkte hatte. Bei uns in der Firma arbeiten wir mit Lauterbach-Debuggern. Die sind einigermassen leistungsfähig. Sie kosten aber schon einmal ca. 3000 Euro. Es gibt aus Dresden so ein um 700 Euro günstigeres Ding. Mit welchem Compiler soll gearbeitet werden? Das GNU-Teil war lausig (langsam und fehlerhaft bei der Installation) - die kommerziellen kosten richtig. Plane schon mal so 2 Tage im günstig Fall ein, um ein Tooling zu installieren und die erste Lampe blinken zu lassen. Mein Rat: Wenn die Zeit begrenzt ist, dann nimm ein Ding, das weit verbreitet ist. Ich persönlich finde die AVR32 UC3- MCU interessant, weil das Tooling kostenlos und ordentliche Debugger noch bezahlbar sind. Aber das Ding ist noch recht neu und die Erfahrung nicht so zahlreich, wie bei STM32 oder ARM. Mit dem TC1796 wirst Du als Anfänger keine Freude haben. Die Zeit wird Dir durch die Finger rinnen. Daran wird der Hardware-Konfigurator DaVE aus nichts ändern. Nimm ein anderes Thema ...
>Ich würde erstmal mit ner 1-Kern-CPU anfangen...
Tricore ist eine 1-Kern-CPU. Die bezeichnen lediglich einige weitere
Komponenten im Chip (die andere Hersteller aber auch haben) als weitere
Kerne, und sagen (sagten) deswegen sei es grundlegend neu.
Vor Jahren erzählten die, später würde die f bei vielen hundert MHz
liegen, und es könnte eine Konkurenz zu schnellen MIPS oder PowerPCs
werden.
... ist auch nicht der Fall.
Die Flash-Geschwindigk. bei TC wird sogar eher noch unterdurchschn.
sein.
(Contex-Switch-Umschaltung ist allerd. recht schnell, aber das alleine
rechtfertigt kein TC)
MCUA schrieb: > Tricore ist eine 1-Kern-CPU. Die bezeichnen lediglich einige weitere > Komponenten im Chip (die andere Hersteller aber auch haben) als weitere > Kerne, und sagen (sagten) deswegen sei es grundlegend neu. Damit hast Du ja die ganze Luft aus dem super-duper Ding rausgelassen. Wirklich ne ziemlich dreiste Lüge mit den 3 Kernen. Und ich hatte mich schon gewundert, wie man für 3 unterschiedliche Kerne mit 3 Programmcountern eine Applikation erstellen können soll. Dann sehe ich keinen Grund mehr, nicht etwas viel bekannteres zu nehmen (z.B. Cortex M3), wo man deutlich mehr Hilfe bekommen kann. Peter
Peter Dannegger schrieb: > MCUA schrieb: >> Tricore ist eine 1-Kern-CPU. Die bezeichnen lediglich einige weitere >> Komponenten im Chip (die andere Hersteller aber auch haben) als weitere >> Kerne, und sagen (sagten) deswegen sei es grundlegend neu. > > Damit hast Du ja die ganze Luft aus dem super-duper Ding rausgelassen. > Wirklich ne ziemlich dreiste Lüge mit den 3 Kernen. Ganz so ist es ja nicht. Selbst wenn man die Signal-Prozessor Befehle nicht als eigenen Kern zählt (wie bei den dsPICs) gibt es immer noch einige High-End Tricores (der 1796 gehört auch dazu) mit einer eigenständigen PCP-Unit. Im Zusammenhang mit dem GPTA-Timer-Array lassen sich da hübsche komplexe Timing-Funktionen nahezu unabhängig vom Hauptprozessor programmieren. Das ganze geht natürlich auch mit dem Haupt-Prozessor, allerdings ist da die Interruptbelastung erheblich. Gruß Anja
Ich würde mir ja ein Thema suchen, was ich auch später noch ausschlachten könnte. Sodaß sich der Aufwand lohnt! Denk drüber nach.
>>> Tricore ist eine 1-Kern-CPU. Die bezeichnen lediglich einige weitere >>> Komponenten im Chip (die andere Hersteller aber auch haben) als weitere >>> Kerne, und sagen (sagten) deswegen sei es grundlegend neu. >> >> Damit hast Du ja die ganze Luft aus dem super-duper Ding rausgelassen. >> Wirklich ne ziemlich dreiste Lüge mit den 3 Kernen. >Ganz so ist es ja nicht. Selbst wenn man die Signal-Prozessor Befehle >nicht als eigenen Kern zählt (wie bei den dsPICs) gibt es immer noch >einige High-End Tricores (der 1796 gehört auch dazu) mit einer >eigenständigen PCP-Unit. Ja, Tricores hat schon einiges an Perif-Features. Aber das deswegen als 3-Kerne zu bezeichnen ist 'nicht sinnvoll'. Oder soll man alles was irgentwie mit Takt versorgt wird und irgentwie parametrierbar ist als Kern bezeichnen? Dann wäre jeder Controller mit Periferie zumindest schonmal ein 5-Kern. Ich sehe es so, dass das Ding letztlich auch nur mit Wasser kocht, weil nämlich alle Perif-Teile letztlich auch nur Werte von/zu Speicher schicken, wie bei anderen Controllern auch. Und dafür gibt halt verschiedene Mechanismen, wie DMA, uDMU, ExtDMA, DTC usw., das verschiedene Controllern anderer Hersteller mehr oder weniger gut machen. Insgesamt gesehen sollte Siemens mit dem Tricore ein riessiger! Wurf gelingen, was aber gescheitert ist. Und für geschätzte 99,9% der Anwendungen ist er ausserdem viel zu teuer.
MCUA schrieb: > Und für geschätzte 99,9% der > Anwendungen ist er ausserdem viel zu teuer. In großen Stückzahlen sicherlich nicht, sonst wäre er nicht in vielen KFZ-Steuergeräten drin. Gruß Anja
Naja. Die schwören ihre Kunden schon ein. Das einzige was in dem Laden wirklich funzt! Ich kenne viele Siemens/Infineon Controller (die aus Silizium): Generell sind sie zu kompliziert in ihrer Struktur. Das fing schon damals mit dem aufgebohrten 8051 an. Davon gabs eine Unmenge von Masken-Versionen. Wohl weil sie es selber nicht mehr blickten, wie kompliziert sie dachten. Generell sollte ein Datenblatt nicht mehr als 100 Seiten benötigen!! Bei Massenstückzahlen geht nichts mehr über Distris und die Preise werden grundsätzlich ausgehandelt und sind dann erheblich tiefer!
Abdul K. schrieb: > Naja. Die schwören ihre Kunden schon ein. Das einzige was in dem Laden > wirklich funzt! Hä, wie meinen? Dass Infineon seine Kunden mit irgendwelchen mehr oder weniger sauberen Methoden bei der Stange hält? Da würde mich ein Beleg interessieren. > Generell sollte ein Datenblatt nicht mehr als 100 Seiten benötigen!! Das reicht ja nicht mal bei einem habwegs modernen 16-Bitter. Die großen 32-Bit-Teile kommen locker auf > 1000 Seiten, wenn man die (unverzichtbaren) Family User´s Guides, Application Notes, Errata und was auch immer sonst noch nötig ist dazurechnet. In Anbetracht der Komplexität ist das aber auch voll gerechtfertigt. Wenn ich Deine Forderung weiterdenke, müsste die Welt beim Achtbitter eigentlich aufhören. Ich bin froh, dass sie das nicht getan hat. > Bei Massenstückzahlen geht nichts mehr über Distris und die Preise > werden grundsätzlich ausgehandelt und sind dann erheblich tiefer! Richtig. Bist Du eigentlich Schweizer? Den Begriff "Tiefe Preise" kenne ich nur als Helvetismus.
Infineon hat nie behauptet das ein TriCore 3 Kerne hat. Die Aussage ist folgende: The Infineon TriCoreTM architecture combines the best of three worlds: RISC, DSP and μ-Controller together in a single core to offers maximum system performance for embedded real-time applications.
>... combines the best of three worlds: >RISC, DSP and μ-Controller together in a single das haben viele andere auch integriert, ausserdem kann man da nicht von 3 Welten sprechen.
Max G. schrieb: > Abdul K. schrieb: >> Naja. Die schwören ihre Kunden schon ein. Das einzige was in dem Laden >> wirklich funzt! > > Hä, wie meinen? Dass Infineon seine Kunden mit irgendwelchen mehr oder > weniger sauberen Methoden bei der Stange hält? Da würde mich ein Beleg > interessieren. Nun ja. Siemens galt schon seit Jahrzehnten als Bank mit angeschlossener elektrotechnischer Werkstatt. Das Konzept ist einfach: Einladungen zu Vorführungen, regelmäßige Vertreterbesuche etc. Aus Sicht eines BWLers ist das auch ein gutes Konzept! Man verdient mehr mit Geld was in die Werbung fließt als mit dem was die Entwickler bekommen! Kleines Beispiel?: Schau dir deinen Arbeitsplatz und den einer Sekretärin an. Im Allgemeinen ist der der Sekretärin schöner eingerichtet. Das Thema hatten wir ja oft. > >> Generell sollte ein Datenblatt nicht mehr als 100 Seiten benötigen!! > > Das reicht ja nicht mal bei einem habwegs modernen 16-Bitter. Die großen > 32-Bit-Teile kommen locker auf > 1000 Seiten, wenn man die > (unverzichtbaren) Family User´s Guides, Application Notes, Errata und > was auch immer sonst noch nötig ist dazurechnet. > In Anbetracht der Komplexität ist das aber auch voll gerechtfertigt. > Wenn ich Deine Forderung weiterdenke, müsste die Welt beim Achtbitter > eigentlich aufhören. Ich bin froh, dass sie das nicht getan hat. > Es ist einfach so, daß die Einarbeitung und Verwirrung durch eine riesige Doku schlicht das Produkt teurer macht. Bei kleineren Stückzahlen wesentlich teurer. Und bei sehr kleinen Stückzahlen (Studenten und Hobbyisten) oftmals dazu führt, das ein Projekt scheitert ! Ein Datenblatt hört bei mir beim Timing auf. Befehlsbeschreibung etc. kommt separat in ein TRM. Das darf mir wegen 200-300 Seiten haben. Alles drüber halte ich für Unfug und zeigt nur, das das Konzept kokolores ist. Ich sehe das übrigens bei der Pinanzahl genauso! Was will man mit 300 Pins an einem FPGA, wenn davon 200 überflüssig sind und höchstens als Kühlleitung oder Testpunkt mißbrauchbar sind? ALLE müssen im Layoutprogramm definiert werden. ALLE verschmutzen den Bildschirm beim Arbeiten. Verblasene Arbeits- und Lebenszeit. >> Bei Massenstückzahlen geht nichts mehr über Distris und die Preise >> werden grundsätzlich ausgehandelt und sind dann erheblich tiefer! > > Richtig. > Bist Du eigentlich Schweizer? Den Begriff "Tiefe Preise" kenne ich nur > als Helvetismus. Den Ausdruck gibts in DE auch.
danke für die zahlreichen antworten :) auch wenn die letzten posts etwas vom thema abschweifen. wenn mir hier alle raten was anderes zu machen, dann mach ich das auch. scheint schon super kompliziert zu sein.
Abdul K. schrieb: > Nun ja. Siemens galt schon seit Jahrzehnten als Bank mit angeschlossener > elektrotechnischer Werkstatt. > Das Konzept ist einfach: Einladungen zu Vorführungen, regelmäßige > Vertreterbesuche etc. > Aus Sicht eines BWLers ist das auch ein gutes Konzept! Man verdient mehr > mit Geld was in die Werbung fließt als mit dem was die Entwickler > bekommen! Infineon bietet für gute Kunden exzellenten Support. Und die Produkte sind auch nicht schlecht. Da ist nicht nur Marketing dabei. Abdul K. schrieb: > Es ist einfach so, daß die Einarbeitung und Verwirrung durch eine > riesige Doku schlicht das Produkt teurer macht. Bei kleineren > Stückzahlen wesentlich teurer. Und bei sehr kleinen Stückzahlen > (Studenten und Hobbyisten) oftmals dazu führt, das ein Projekt > scheitert ! Wenn jemand Ingenieur werden will, muss er damit umgehen können und die nötigen Informationen entsprechend filtern. Dagegen ist es sehr ärgerlich, wenn die Doku unvollständig ist. Abdul K. schrieb: > Ich sehe das übrigens bei der Pinanzahl genauso! Was will man mit 300 > Pins an einem FPGA, wenn davon 200 überflüssig sind und höchstens als > Kühlleitung oder Testpunkt mißbrauchbar sind? ALLE müssen im > Layoutprogramm definiert werden. ALLE verschmutzen den Bildschirm beim > Arbeiten. Verblasene Arbeits- und Lebenszeit. Nur weil du keinen Bedarf hast, heißt das noch lange nicht, dass es überflüssig ist. Ich habe schon sehr viele FPGA-Designs gesehen, bei denen viele hundert Pins gebraucht wurden. Selbst die ganz großen mit >800 Pins bekommt man voll, wenn man ein entsprechend komplexes Design hat. Für Hobbybastler mag das, was du da sagst, vielleicht zutreffen. Aber hier geht es doch um einen angehenden Ingenieur. Und da ja die Firma, in der er seine Thesis schreibt, offensichtlich mit Infineon zusammenarbeitet (sonst würden sie ja nicht den Tricore vorschlagen), ist es erst einmal Blödsinn, einen Atmel vorzuschlagen.
Stefan L. schrieb: > Infineon bietet für gute Kunden exzellenten Support. Und die Produkte > sind auch nicht schlecht. Da ist nicht nur Marketing dabei. Volle Zustimmung. Ich habe bei anderen HL-Herstellern da schon ganz andere Nummern erlebt. Den Rest Deines Beitrags kann ich ebenfalls nur 1:1 unterschreiben. Max
Stefan L. schrieb: > Abdul K. schrieb: >> Nun ja. Siemens galt schon seit Jahrzehnten als Bank mit angeschlossener >> elektrotechnischer Werkstatt. >> Das Konzept ist einfach: Einladungen zu Vorführungen, regelmäßige >> Vertreterbesuche etc. >> Aus Sicht eines BWLers ist das auch ein gutes Konzept! Man verdient mehr >> mit Geld was in die Werbung fließt als mit dem was die Entwickler >> bekommen! > > Infineon bietet für gute Kunden exzellenten Support. Und die Produkte > sind auch nicht schlecht. Da ist nicht nur Marketing dabei. > Das stritt ich nicht ab. Wo aber kein Support benötigt wird, macht es mehr Spaß. > Abdul K. schrieb: >> Es ist einfach so, daß die Einarbeitung und Verwirrung durch eine >> riesige Doku schlicht das Produkt teurer macht. Bei kleineren >> Stückzahlen wesentlich teurer. Und bei sehr kleinen Stückzahlen >> (Studenten und Hobbyisten) oftmals dazu führt, das ein Projekt >> scheitert ! > > Wenn jemand Ingenieur werden will, muss er damit umgehen können und die > nötigen Informationen entsprechend filtern. Dagegen ist es sehr > ärgerlich, wenn die Doku unvollständig ist. Und, wie ist das wohl? Nimmt die Qualität eher zu oder ab mit Länge des Dokuments? > > Abdul K. schrieb: >> Ich sehe das übrigens bei der Pinanzahl genauso! Was will man mit 300 >> Pins an einem FPGA, wenn davon 200 überflüssig sind und höchstens als >> Kühlleitung oder Testpunkt mißbrauchbar sind? ALLE müssen im >> Layoutprogramm definiert werden. ALLE verschmutzen den Bildschirm beim >> Arbeiten. Verblasene Arbeits- und Lebenszeit. > > Nur weil du keinen Bedarf hast, heißt das noch lange nicht, dass es > überflüssig ist. Sei jedem freigestellt was er bevorzugt. Bei mir spricht vielleicht einfach nur viel Erfahrung und eine bestimmte Einstellung zu den Dingen überhaupt. > > Ich habe schon sehr viele FPGA-Designs gesehen, bei denen viele hundert > Pins gebraucht wurden. Selbst die ganz großen mit >800 Pins bekommt man > voll, wenn man ein entsprechend komplexes Design hat. > Serielle Busse unbeliebt? Was du beschreibst, sehe ich als Exoten an. Wir hatten mal ein PCB, das war unglaublich dick, groß wie ein Kuchenbrett in den Sechzigern (wo man sie noch zum Bäcker trug zum Backen), alle Leitungen impedanzkontrolliert und gleichlang, usw. für einen Detektor. Ein Kunstwerk für einen irrsinnigen Preis. Der Kunde zahlte für sein Strahlendetektor-PCB gerne den 5-stelligen Preis (ohne Bauelemente). Das ist aber nicht der Normalfall. > Für Hobbybastler mag das, was du da sagst, vielleicht zutreffen. Aber > hier geht es doch um einen angehenden Ingenieur. Und da ja die Firma, in > der er seine Thesis schreibt, offensichtlich mit Infineon > zusammenarbeitet (sonst würden sie ja nicht den Tricore vorschlagen), > ist es erst einmal Blödsinn, einen Atmel vorzuschlagen. Ich schrieb ja schon, er solle das nehmen was ihn später auch weiterbringt! Wenn er dort arbeiten will, dann ist das ein guter Einstieg. So eine dicke 2000 Seiten Schwarte ist genauso wie die dicke Bibel ein zuverlässiger Eintritt, wenn man an der richtigen Pforte läutet.
Abdul K. schrieb: > Das stritt ich nicht ab. Wo aber kein Support benötigt wird, macht es > mehr Spaß. Support ist im professionellen Umfeld immer notwendig. Abdul K. schrieb: > Und, wie ist das wohl? Nimmt die Qualität eher zu oder ab mit Länge des > Dokuments? Die Qualität des Dokumentes ist unabhängig von der Länge. Bei komplexen Bausteinen ist aber eine gewisse Informationsmenge notwendig, um ihn richtig handhaben zu können. 100 Seiten geht vielleicht bei einem 30 Jahre alten Prozessor ganz gut, bei modernen Typen fehlt dann sicher alles wichtige. Richtig nervig wird es dann, wenn man sich die Informationen mühselig aus App-Notes und Beispielcode heraussaugen darf. Abdul K. schrieb: > Serielle Busse unbeliebt? Wo gibt es noch einmal DDR-RAM mit seriellem Bus? Und selbst wenn man nur seriell verwendet: Ein paar AD-Wandler, zwei Ethernetschnittstellen, SD-Karte, SPI-Flash: Da sind ganz schnell 100 Pins weg und man hat noch nicht einmal etwas komplexes gebaut.
WICHTIGE FRAGE: Hab heute mit meinem Betreuer geredet. Was er sich jetzt als Bachelorarbeit vorstellt: Ein Konzept/eine Architektur, wie man per TC1797 den CAN-Bus ansteuern und auswerten kann, ohne dass ich da selbst was Größeres programmieren muss. Als Programm reicht etwas, das z.B. Daten per CAN an den Tricore schickt und Daten vom Tricore empfängt. FlexRay wird auch noch in Betracht gezogen, falls die CAN-Sache alleine zu einfach sein sollte. Meinungen dazu?? Persönlich finde ich das recht abstrakt und kann mir wenig vorstellen. Kann den Aufwand schlecht einschätzen. Bin mir über die Herangehensweise im Unklaren. Der Tricore-Experte ist immer nur 1 mal pro Woche da. Findet ihr das ein gutes Thema? Wieso oder wieso nicht? Was würdet ihr ändern? Oder ist das schon im Vornherein zum Scheitern verurteilt?
Minty Mint schrieb: > WICHTIGE FRAGE: > Hab heute mit meinem Betreuer geredet. Was er sich jetzt als > Bachelorarbeit vorstellt: > Ein Konzept/eine Architektur, wie man per TC1797 den CAN-Bus ansteuern > und auswerten kann, ohne dass ich da selbst was Größeres programmieren > muss. Als Programm reicht etwas, das z.B. Daten per CAN an den Tricore > schickt und Daten vom Tricore empfängt. FlexRay wird auch noch in > Betracht gezogen, falls die CAN-Sache alleine zu einfach sein sollte. Radio Eriwan: es kommt darauf an. Der TC1797 hat einen CAN-Transceiver eingebaut, Du musst also nur diesen ansteuern und einen CAN-Treiber dazulöten, wenn das Board das noch nicht hat. Entweder gibt es schon eine Referenzimplementation von Infineon (was ich annehme), oder es gibt keine. Im ersten Fall nimmst Du nur etwas Bestehendes in Betrieb, im letzteren Fall erfindest Du das Rad zum x-ten Mal neu. Was sind Deine Vorstellungen von Deinem Job anschließend? Willst Du lieber [1] etwas fertig Konzipiertes implementieren (z.B. Treiber schreiben oder Matlab-Algorithmen in µC-Code gießen), oder willst Du lieber [2] selbst Konzepte erstellen und z.B. Algorithmen entwickeln? Beides hat seine Berechtigung. Wenn Du [1] ankreuzt, ist die Aufgabe was für Dich. Wenn Du [2] ankreuzt, dann nicht. Gruß, Max
>Als Programm reicht etwas, das z.B. Daten per CAN an den Tricore >schickt und Daten vom Tricore empfängt. FlexRay wird auch noch in >Betracht gezogen, falls die CAN-Sache alleine zu einfach sein sollte. Ohne den Tricore zu kennen, gibt es meistens schon fertige Treiber für die Teile, die sollten dass alles können. Da verstehe jetzt nicht wirklich, was dabei deine Lorbeeren werden sollen?
jonas biensack schrieb: >>Als Programm reicht etwas, das z.B. Daten per CAN an den Tricore >>schickt und Daten vom Tricore empfängt. FlexRay wird auch noch in >>Betracht gezogen, falls die CAN-Sache alleine zu einfach sein sollte. > > Ohne den Tricore zu kennen, gibt es meistens schon fertige Treiber für > die Teile, die sollten dass alles können. Da verstehe jetzt nicht > wirklich, was dabei deine Lorbeeren werden sollen? Das weiss ich auch nicht so richtig. Aber was kann man denn generell großartig Neues erfinden in einer Arbeit, die man in 3 Monaten fertigstellt? Von diesen 3 Monaten braucht man auch noch 1 Monat nur zum Schreiben... Prinzipiell, auf die meisten Bachelorarbeiten bezogen, müsste es schon Sachen geben, die sowas können und wohl ausgereifter sind. Ich finde es daher auch schwer, ein Bachleorarbeitsthema zu definieren.
@Max G.: Ich bevorzuge [1] etwas fertig Konzipiertes implementieren (z.B. Treiber schreiben oder Matlab-Algorithmen in µC-Code gießen) Wenn ich einfach den Treiber von Infineon nehm, ist das ja keine Leistung. (Mal schauen, obs den gibt und wie ich den am besten finde) Was ist da dann meine Aufgabe? Meinen Job nachher stell ich mir eher ohne µController vor.
>Das weiss ich auch nicht so richtig. Aber was kann man denn generell >großartig Neues erfinden in einer Arbeit, die man in 3 Monaten >fertigstellt? Muss ja nichts großartiges sein, aber man sollte doch schon deine eigene geistige Leisung erkennen können. Aber ich kann mir schon vorstellen, dass es schwwierig ist, ein Thema aus dem Boden zu stampfen. Ein konkretes Ziel ist natürlich minimale Vorraussetzung für eine Planung... Gruß Jonas
Stefan L. schrieb: > Abdul K. schrieb: > ... > Pins weg und man hat noch nicht einmal etwas komplexes gebaut. Deine ganze Argumentation hat nur ein Ziel: Mir unbedingt zeigen (oder besser gesagt: den anderen mitlesenden), daß ich unrecht hätte. Ich habe dir nur mein interessantes Konzept des Minimalismus vorgestellt. Du könntest daraus lernen. Willst es aber nicht. Schade. Nie stritt ich ab, das einige Anwendungen wahre Monster brauchen. Aber ist das dein Himmelreich? Du kannst allen zeigen: Ja, ICH habe es geschafft 800 Pins unter Kontrolle zu bringen?! Das ist doch arm!
Minty Mint schrieb: > Meinen Job nachher stell ich mir eher ohne µController vor. Interessante Aussage. Das wird man wohl eher selten hören. Da hätte ich was für dich: Bauelemente-Übersichten aus der Sicht der Anwender und nicht der Marketingabteilung eines Herstellers. Z.B. wie sich die diversen CMOS-Standardbauelemente unterscheiden. Welche Probleme das ergibt. Oder SPICE-Modelle entwickeln. Ein riesiges Gebiet, kaum beackert. Und hier bei µC.net gut besucht, wenns fertig wird!
Abdul K. schrieb: > Deine ganze Argumentation hat nur ein Ziel: Mir unbedingt zeigen (oder > besser gesagt: den anderen mitlesenden), daß ich unrecht hätte. Ich habe > dir nur mein interessantes Konzept des Minimalismus vorgestellt. Du > könntest daraus lernen. Willst es aber nicht. Schade. Mit deinem "Konzept kann man eben viele Aufgaben nicht zufriedenstellend lösen. Ich wollte dem Threadersteller nur eine andere Sichtweise zeigen, denn das ganze was du hier brintgst klingt doch sehr nach Tunnelblick. Wenn die Firma einen Infineon-Prozessor einsetzt, ist es auf jeden Fall sehr zweifelhaft, einen Atmel zu empfehlen. Vor allem weil Atmel in der Industrie immer noch keinen besonders guten Ruf hat. Abdul K. schrieb: > Aber > ist das dein Himmelreich? Du kannst allen zeigen: Ja, ICH habe es > geschafft 800 Pins unter Kontrolle zu bringen?! Die Anzahl der Pins sagt recht wenig über die Komplexität aus. Das habe ich ja oben auch schon angedeutet. Aber generell diese Bausteine zu verteufeln, nur weil sie viele Pins haben, ist einfach falsch. Zurück zum Thema: Minty Mint schrieb: > Ein Konzept/eine Architektur, wie man per TC1797 den CAN-Bus ansteuern > und auswerten kann, ohne dass ich da selbst was Größeres programmieren > muss. Als Programm reicht etwas, das z.B. Daten per CAN an den Tricore > schickt und Daten vom Tricore empfängt. FlexRay wird auch noch in > Betracht gezogen, falls die CAN-Sache alleine zu einfach sein sollte. Für mich klingt das auch noch nach zu wenig Eigenleistung. Vielleicht solltest du wenigstens direkt auf Flexray gehen, falls in deiner Firma damit noch nicht so viel gearbeitet wurde, kann man ja eine Anwendung suchen, die bisher auf CAN aufbaut und diese auf Flexray umbauen. Das wäre für eine Bachelorarbeit auf jeden Fall mehr als ausreichend, es sollte aber auch in der Zeit machbar sein (zumindest auf den Status "Machbarkeitsstudie" kommt man).
>Wenn die Firma einen Infineon-Prozessor einsetzt, ist es auf jeden Fall >sehr zweifelhaft, ... Vieleicht hat auch die Firma einen Tunnelblick, weil sie Infineon einsetzt.
Den Tunnelblick sehe ich auch gerade. Paßt auch zu der Betrachtung über meine konzeptionelle Denke! Was fällt denn auf einer Platine am häufigsten aus?? Ja, Lötverbindungen.
Abdul K. schrieb: > Den Tunnelblick sehe ich auch gerade. Paßt auch zu der Betrachtung über > meine konzeptionelle Denke! Was fällt denn auf einer Platine am > häufigsten aus?? Ja, Lötverbindungen. Wenn man die Funktion nicht erfüllt, brauch auch gar nichts ausfallen. ;-) Ich finde auch, dass man überfrachtete Funktionen nicht unbedingt einbaut, aber das schließt meist der Preisdruck ja von vornerein schon aus. Aber wenn es die Anwendung erfordert, kann man nicht sagen "geht nicht" nur weil man keine 300+ Pin Bauteile verwenden mag.
Gut, dann einigen wir uns darauf das ich einfache übersichtliche Konzepte bearbeite und schwierige dir überlasse.
Ich kenne leider den Ablauf einer Abgabe einer solchen Arbeit nicht, aber musst du dich zu der Arbeit äußern oder evtl. sogar vor einem Prüfungskomitee bestehen? Dann solltest du das Thema so einfach wie möglich halten, um da nicht auf die Nase zu fallen... Ich drück dich schon mal sporadisch die Daumen. gruß Jonas
@Abdul K: Deine Vorschläge klingen ganz interessant. Gibts auch ne SPICE-Sektion im Forum oder ist die in Planung, weil du schreibst "wenn's fertig wird" ? Kenn mich in Orcad P-Spice etwas aus. Das mit den Bauelement-Übersichten aus Anwendersicht klingt auch nicht schlecht. Allerdings wüsst ich da nicht, was ich konkret machen soll. Sowas in der Art gibts doch sicher auch schon. @Stefan L.: Das mit FlexRay: keine Ahnung. Ich mache die Arbeit übrigens an der FH, nicht in nem Unternehmen. @jonas biensack: Ja, ich muss auch nen Vortrag zu dem Thema halten. Der wird allerdings nicht wirklich großen Einfluss auf die Note haben. Die Note gibt der Betreuer und der schaut sich neben der Arbeit eben auch den Vortrag an. Wichtig ist jedenfalls, dass die ganze Sache machbar ist und auch in der Zeit. 2 Monate zum arbeiten (entspricht 40 Arbeitstagen) und einen Monat zum schreiben (20 Arbeitstage). Kann auch maximal 1-2 Monate länger dauern zum Arbeiten. Momentan verlier ich mich in den Manuals zum Tricore, die teils 2500 Seiten haben.... Woher weiss ich, ob es einen Can-Treiber von Infineon gibt und wo ich diesen finde? Die bisherige Vorgabe ist ja echt uneingegrenzt und schwammig: > Ein Konzept/eine Architektur, wie man per TC1797 den CAN-Bus ansteuern > und auswerten kann, ohne dass ich da selbst was Größeres programmieren > muss. Als Programm reicht etwas, das z.B. Daten per CAN an den Tricore > schickt und Daten vom Tricore empfängt. FlexRay wird auch noch in > Betracht gezogen, falls die CAN-Sache alleine zu einfach sein sollte. Wäre jetzt gut, sagen zu können, - was alles machbar ist - ob der Tricore nicht doch zu komplex ist - wie man das Thema sinnvoll eingrenzt - wie lange man dafür braucht
Gerade habe ich ein Déjà-vu :-) Warnte ich nicht vor allzugroßen Datenblättern! Naja, SPICE-Forum gibt es hier nicht und anderswo eigentlich auch nicht als allgemeine Veranstaltung. 'Foren' dazu findet man eigentlich nur bei den jeweiligen SPICE-Herstellern. Für LTspice gibt es eine Yahoo-Gruppe. Wenn man die Liste der Projektvorschläge brauch, hat man sie nicht im Kopf. Ich sollte wirklich mal eine schriftlich führen. Daher fällt mir gerade sonst kein weiteres Thema ein. Ich meinte: SPICE-Modelle für Bauelemente, die wir hier viel verwenden und bei denen der Hersteller zu blöde oder zu faul ist, ein ordentliches Modell zu erstellen. Oftmals sind die Teile auch vor Jahrzehnten designet worden und damals wurde SPICE kaum benutzt. Vielleicht können einige der Mitleser einige interessante Bauelemente vorschlagen? Los Leute, hier wird kostenlos für uns gearbeitet. Das muß man nutzen! Die hier fallen mir gerade ein: 1. DIAC (vor allem Haltestrom, Freiwerdung) 2. Glühlampe (Die bisherigen Modelle sind thermisch unzureichend. Wir hatten das schonmal angefangen. Benutze die Suche...) 3. Überstromsicherungen (Wieder das thermische Problem kombiniert mit Pulsleistung) 4. I/O-Schutzschaltungen von ICs (Gibt viele Patente, aber die Hersteller verschweigen durchweg die konkrete Realisierung) 5. Extrem rauscharmer Spannungsregler aus Standardbauelementen herstellerunabhängig! Interessant für Audioisten und Meßtechnik. Für alle gilt, es sollen REALE kaufbare Bauelemente modelliert werden. Abstruse mathematische Modelle nützen in der Praxis fast nichts. Such dir auf jeden Fall was aus, wo du bereits Kenntnisse hast!
Minty Mint schrieb: > @Stefan L.: Das mit FlexRay: keine Ahnung. > > Ich mache die Arbeit übrigens an der FH, nicht in nem Unternehmen. Gut, wenn du die Freiheit hast, etwas anderes zu wählen, ist die Situation natürlich ein bisschen anders. Minty Mint schrieb: > Momentan verlier ich mich in den Manuals zum Tricore, die teils 2500 > Seiten haben.... Im Studium hat man doch intensiv gelernt, Informationen zu filtern? Wenn man natürlich noch nie Berührung mit solchen Datenblättern hatte, wird es allerdings schwer, wenn man sich erst mit Beginn der Thesis mit dem Baustein beschäftigt. Aber normalerweise kann man diese Einarbeitungsphase noch bevor man die Arbeit anmeldet einschieben. Minty Mint schrieb: > Wäre jetzt gut, sagen zu können, > - was alles machbar ist > - ob der Tricore nicht doch zu komplex ist > - wie man das Thema sinnvoll eingrenzt > - wie lange man dafür braucht Machbar ist vieles, das hängt von den persönlichen Fähigkeiten ab. Der Tricore ist sicherlich nicht der einfachste Baustein, wenn du wenig Erfahrung mit Embedded Systems hast, brauchst du aber bei jedem System dieser Leistungsfähigkeit sehr lange. Das Thema grenzt man am besten so ein, dass man an mehreren Stellen "abbrechen" kann, wenn die Zeit knapp wird. Übrigens: Das Dokumentieren an das Ende der Zeit zu schieben ist meiner Meinung nach eine sehr schlechte Idee. Idealerweise macht man das immer schön nebenbei mit. Mir persönlich geht es so, dass ich selten mehr als 3 Stunden am Stück konzentriert schreiben kann. Dann häufen sich die Fehler und die Effizienz sinkt enorm. Wenn ich immer mal eine Stunde zwischendrin schreibe, tue ich mir sehr viel leichter. Ich denke das wird auch anderen so gehen. Abdul K. schrieb: > Such dir auf jeden Fall was aus, wo du bereits Kenntnisse hast! Das sehe ich genauso. Suche dir ein Thema, in dem du bereits Erfahrung hast (durch Praxissemester, Studienarbeiten oder ähnliches). Da ist die Wahrscheinlichkeit, eine böse Überraschung zu erleben, deutlich geringer.
Minty Mint schrieb: > Mein Betreuer macht viel mit Elektrofahrzeugen und deren > Sensorauswertung, Fahrspurerkennung, etc. und meinte jetzt, dass man > vielleicht etwas mit dem Tricore machen könnte. > Ist der Tricore dazu überhaupt gut geeignet? > Hab mich jetzt ca. 2 Wochen mit dem Thema beschäftigt und bisher sieht > es recht kompliziert aus, zumal ich fast keine Erfahrung mit > Mikrocontrollern habe. Mal ganz allgemein zu solchen Arbeiten: Das Themengebiet sollte etwas sein, indem man sich schon auskennt, Erfahrungen gesammelt hat und auch einschätzen kann, wie komplex/realistisch ein Gestecktes Ziel ist. Ein Thema, bei dem ein Großteil der Arbeit darin besteht, dich in was Neues einzuarbeiten, wird dich immer schlecht dastehen lassen weil eben dieser Großteil der wirklichen Arbeit abgeht. Von daher finde ich das von deinem Betreuer unfair, "einfach mal so" ein Thema aus dem Ärmel zu schütteln weil er keine Idee hat. Ich hab mir damals das Thema zu meiner Diplomarbeit selber gewählt. Allerdings hatte ich da 1 Jahr Zeit und es wurde erwartet, daß man neue wissenschaftliche Resultate auf den Tisch legt nebst Veröffentlichung in internationaler Fachzeitschrift. Aber mit ein paar Monaten und dem ganzen Geschreibsel, Grafiken machen, Textsatz, Datensammeln, Korrekturlesen und den Teufeln im Detail ist in so ner kurzen Zeit nicht wirklich viel drinne wenn du noch in ein komplett neues Thema wie "noch nie was mit µC gemach" must. Zum TriCore: Die Dinger -- insbesondere die interne Peripherie -- sind hoch komplex. Die Datenblätter sind kacke, zumindest im Vergleich zu Datenblättern von Atmel AVR die bei Adam und Eva anfangen und zB Busprotokolle erklären oder Zusammenhänge zwischen einzelnen Units aufzeigen. Wenn man nicht das komplette Datenblatt eines TC gelesen hat, wird man mit 100% Sicherheit was übersehen und irgendwas klappt nicht und du hast keinen Plan was nicht geht. Den TC-Expertem siehtst du nur 1x pro Woche, und bis dahin läuft dir die Zeit weg und du reibst dir die Nerven auf. Prinzipiell ist TriCore keine schlechte Wahl, gerade weil's kein Allerwelts-µC ist und in Automotive eingesetzt wird. Die Anzahl TriCores unter Motorhauben dürfte mindestens achtstellig sein. Aber mit deinem Background -- sorry -- ist das nicht realistisch und von deinem Betreuer unfair. Lies dir einfach nochmal den Tred von Anfang an durch, es ist die einhellige Beurteilung der Gememgelage. Übrigens wurden viele Features auf Kundenwunsch in den TriCore integriert bzw. zusammen mit Infineon designt, von daher sind Aussagen wie. Abdul K. schrieb: > Naja. Die schwören ihre Kunden schon ein. an den Haaren herbei gezogen. Und zum GNU-Compiler für TriCore: Wenn ich die "Compilerfehler" für avr-gcc hier im Forum auf einen tricore-gcc extrapoliere, bei der ungleich größeren Komplexität dieses µC und seinen wesentlich mieseren Datenblättern im Vergleich zu AVR; da überlass ich jedem selbst das Urteil über "Compilerfehler"...
Ich habe wohl einfach zu viele Siemens-Controller gesehen. Dann die ganzen Maskenversionen. Nee danke, ich bin ja blöde.
So, wir sind jetzt am überlegen, einen ARM-Controller statt dem TC 1797 zu verwenden. Die vorherige Aufgabenstellung bleibt aber im Groben gleich: "Ein Konzept/eine Architektur, wie man per µC den CAN-Bus ansteuern und auswerten kann, ohne dass ich da selbst was Größeres programmieren muss. Als Programm reicht etwas, das z.B. Daten per CAN an den µC schickt und Daten vom µC empfängt. FlexRay wird auch noch in Betracht gezogen, falls die CAN-Sache alleine zu einfach sein sollte. " Finde das allerdings keine sehr konkrete Themenstellung. Was könnte man da genau machen? Für mich wirkt das zu abstrakt. Ich kann schlecht einschätzen, ob das machbar ist.
Das ist eindeutig zu unkonkret formuliert. Irgendwelche Konzepte, die einen uC und CAN beinhalten findest du zu tausenden im Netz und in irgendwelchen Arbeiten. Da fehlt einfach der konkrete Anwendungszweck.
Habe mich mittlerweile dazu breitschlagen lassen, etwas mit dem TC1797 zu machen. Hauptsächlich aus Mangel an Alternativen von Seiten der Hochschule. Zum Anderen, weil Professor, Betreuer und Tricore-Experte meinten, das geht schon. Und weil es den Code-Generator DAvE gibt. Und ehrlich gesagt, klingt das zunächst nicht weiter schwer. Hört sich zunächst einfach nach Inbetriebnahme an. Müsste ja machbar sein. Nach nun etwas über 1 Monat Beschäftigung und Einarbeitung mit CAN und dem Tricore versuche ich aktuell das MultiCan-Modul in Betrieb zu nehmen mit Code, den Dave erstellt hat. Ziel ist erstmal Nachrichten von Can-Bus-Teilnehmern empfangen zu können. Das ist momentan einfach Ausprobieren. Ich experimentiere mit den Auswahlmöglichkeiten in Dave. Hoffe das klappt demnächst. Optimales Ziel ist es, Sensordaten einlesen zu können, via ADC, diese zwischenzuspeichern (hier ist noch die Frage: wie und wo?) und diese Daten via Canbus zu versenden. Problematisch ist es mit dem Code den man eventuell ergänzen muss. Ich weiß nämlich nicht, was fehlt, damit es läuft. Es fällt einem zudem schwer zu erkennen, wo denn nun der Fehler liegt, bei den ganzen Registern und Komponenten, wenn etwas nicht geht. Es ist also leider noch im Ungewissen, ob das so klappt. In folgendem Post hat jemand den ADC konfiguriert und die Dave-Datei mit angefügt. WEiß jemand, was bei dem noch genau gefehlt hat, damit es ging? Was genau muss da ergänzt werden? Beitrag "TriCore & Dave" Wer kennt sich hier denn noch mit den TC1797 aus? Habt ihr Beispiele für CAN unter Dave oder ähnliches? Oder generell Erfahrung mit dem MultiCan-Modul? Was mir noch in den Sinn kam als Alternative, falls ich mit dem Tricore scheitere, wobei ich nicht weiß, ob das Sinn macht: Verschiedene CAN-Transceiver testen, z.B. unter maximaler Geschwindigkeit und Parameter variieren. Weiß jemand, ob das eine gute Idee ist? Wer kennt sich mit den Dingern aus? Die sind ja recht günstig. Damit würde sich das Thema vom Tricore etwas entfernen, wenn es mit dem nicht so gut klappt. Und ich kann das Thema CAN-Bus verwenden, zu welchem ich mich jetzt informiert habe und welches ich ganz interessant finde. Vielen Dank schonmal für die Antworten :)
hm, keine Antwort bisher. Kann jemand das bereits im letzten Post gefragt beantworten: "Verschiedene CAN-Transceiver testen, z.B. unter maximaler Geschwindigkeit und Parameter variieren. Weiß jemand, ob das eine gute Idee ist? Wer kennt sich mit den Dingern aus?"
Klar kann man die CAN-Transreceiver und Controller testen. Aber das ist auch nicht viel mehr als das Datenblatt lesen. Die Specs zeigen schon ziemlich schnell die Grenzen aus. Wer sich damit auskennt, solltest du mittlerweile via google gefunden haben, der sich sehr speziell mit den Dingern beschäftigt hat. Wenn du was mit Motoren machen willst würd ich mal ganz stark in Richtung Flurförderfahreuge gucken. Da ist all das drin was du suchst. Nur ich glaube ganz ehrlich das du mit deinem jetzigen Wissen nicht sehr weit kommst. Da die Komplexität in dem Bereich schon recht hoch ist und man schon etwas Entwicklungserfahrung braucht bis man sicher mit dem Zeugs rumspielen kann und da ist es dann egal welchen Controller du nimmst.
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.