Mag jetzt ne naive Frage sein... Aber warum sieht man kaum Mega16M1 sondern stattdessen relativ viele CAN Controller von Microchip? Nur wegen des Preises? Das kann doch nicht sein, oder? Oder kommt mir das nur so vor?
Joachim ... schrieb: > Mag jetzt ne naive Frage sein... Aber warum sieht man kaum Mega16M1 > sondern stattdessen relativ viele CAN Controller von Microchip? Nur > wegen des Preises? Das kann doch nicht sein, oder? Oder kommt mir das > nur so vor? at90canXXX gibts auch noch... und ja der preis ist ein hauptgrund..bei großen stückzahlen nimmt man sehr spezifische controller und nicht ne eierlegendewollmilchsau..
Um es mal so auszudrücken, Atmel würde keine Automotive-Controller produzieren wenn sie keine Abnehmer hätten, zu denen afaik u.a. BMW zählt.
Ach ja ich vergaß: die Atomitivdinger mit can. Ja, stimmt die kannte ich. Bloß denk ich auch, dass hersteller und entwickler sich schon nach dem Preis richten müssen. Andersrum gefragt: wieso sollte man viele AVRs einsetzen, wenn es doch günstigere von Microchip gibt. Dann ist alles plötzlich ne dumme frage.
Philipp Bigott schrieb: > Andersrum gefragt: wieso sollte man viele AVRs > einsetzen, wenn es doch günstigere von Microchip gibt. Dann ist alles > plötzlich ne dumme frage. Ich finde die Frage, warum Atmel sowas produziert, wenn es sich nicht lohnt, nicht gerade dumm. Zu Anwendungsbeispielen siehe deren Internetauftritt. Nebenbei muss auf einem Chip nicht der Hersteller stehen, OEMs lassen die auch mal umlabeln.
Ich stelle Stück für Stück um. Atmel ist einfach zu teuer geworden. Ander Controller werden immer billiger, die von Atmel teurer... Je nach benötigter Leistung vs Preis kommt am Ende immer PIC oder STM32 raus. Eigentlich liebe ich die AVRs und kenne sie inzwischen sehr gut, aber wenn es um >1000Stk geht, spielt der Preis eben eine wichtige Rolle. Ich gebe zu, dass mir eine Neuentwicklung am schnellsten mit nem AVR von der Hand geht (Erfahrung, unzählige Designs, Softwarebibliotheken). Macht sich trotzdem bezahlt, umzusteigen, wenn Stückzahlen absehbar. Aus diesem Grund werde ich den ATXMega nicht mal ansatzweise anfassen.
Mal ne ganz andere Frage: Das CAN-Bus-Protokoll ist ja relativ einfach aufgebaut. Es sollte sich doch auch ohne Spezialhardware, also rein durch die Software in den Griff kriegen lassen. Oder?
Markus W. schrieb: > Mal ne ganz andere Frage: > > Das CAN-Bus-Protokoll ist ja relativ einfach aufgebaut. Es sollte sich > doch auch ohne Spezialhardware, also rein durch die Software in den > Griff kriegen lassen. Oder? Spätestens bei High-Speed CAN (bis 1 MBit/s) macht das keinen Spaß mehr...
At(x)mega+CAN ist an sich nicht schwer, es gibt ja genügend externe Chips. Sowas ist mir ehrlich gesagt auch lieber, anstatt SO viele interne halbfertige Module zu haben (siehe: z.B. ADC beim AtXmega). Mir ists lieber ich häng was extern dran wo ich dann auch GENAU DAS habe was ich brauche. Denn oftmals ist auch eine galvanische Trennung sinnvoll und sowas ist auf nem einzelnen Mikrochip kaum möglich zu machen. Oder wie soll das bei TQFP aussehen, wenn CAN z.B. bis 1000V galvanisch getrennt sein soll?
meckerziege schrieb: > Denn oftmals ist auch eine galvanische Trennung > sinnvoll und sowas ist auf nem einzelnen Mikrochip kaum möglich zu > machen. Oder wie soll das bei TQFP aussehen, wenn CAN z.B. bis 1000V > galvanisch getrennt sein soll? dann benutzt man aber einen galvanisch getrennten transceiver ala iso1050 ..
Michael Graf schrieb: > Spätestens bei High-Speed CAN (bis 1 MBit/s) macht das keinen Spaß > mehr... Völlig richtig. Allerdings ist CAN aus meiner Sicht ein Protokoll, das man normalerweise dann einsetzt, wenn es auf möglichst robuste Echtzeitübertragung ankommt. Durch "High-Speed" verspielt man sich diesen Vorteil, weil dann Übertragungsfehler zur Normalität werden. Trotzdem - wenn man unbedingt will - ist auch 1 MBit/s softwaremäßig in den Griff zu kriegen.
Markus W. schrieb: > Völlig richtig. Allerdings ist CAN aus meiner Sicht ein Protokoll, das > man normalerweise dann einsetzt, wenn es auf möglichst robuste > Echtzeitübertragung ankommt. Bei harten, sicherheitsrelevanten Echtzeitanforderungen ("x-by-wire") hätte ich jetzt gerade nicht CAN genommen, sondern einen deterministischen Bus wie Flexray. > Durch "High-Speed" verspielt man sich > diesen Vorteil, weil dann Übertragungsfehler zur Normalität werden. Wenn ich mich recht entsinne, sind in aktuellen Fahrzeugen die meisten CANs High-Speed, und ich erinnere mich nicht an unverhältnismäßig hohe Fehlerraten. Aber meine Automotive-Zeit ist jetzt auch schon ein paar Jahre her... > Trotzdem - wenn man unbedingt will - ist auch 1 MBit/s softwaremäßig in > den Griff zu kriegen. Fragt sich nur, ob der arme Controller da sonst noch zu etwas kommt...
Ich muss auch sagen, dass meine Begeisterung für CAN, nach den ersten Experimenten im Labor damit deutlich abgenommen hat. Robust und Echtzeitfähig war da nichts. Das ist eher was für Leute, die eine Abneigung gegenüber Übertragern und Ethernet haben.
Christian Berger schrieb: > Ich muss auch sagen, dass meine Begeisterung für CAN, nach den ersten > Experimenten im Labor damit deutlich abgenommen hat. Robust und > Echtzeitfähig war da nichts. > Das ist eher was für Leute, die eine > Abneigung gegenüber Übertragern und Ethernet haben. Erzähl das mal der Autoindustrie. Ich bin sicher, die stellen morgen auf Ethernet um. Gerade die Echtzeit-Sachen. SCNR, Michael
Christian Berger schrieb: > Ich muss auch sagen, dass meine Begeisterung für CAN, nach den ersten > Experimenten im Labor damit deutlich abgenommen hat. Robust und > Echtzeitfähig war da nichts. Das ist eher was für Leute, die eine > Abneigung gegenüber Übertragern und Ethernet haben. Was soll beim CAN nicht Robust?
Christian Berger schrieb: > Das ist eher was für Leute, die eine > Abneigung gegenüber Übertragern und Ethernet haben. Willst du damit sagen das Ethernet Echtzeit fähig ist ? Ethernet ist in der Beziehung mit CAN vollkommen identisch. Beide Systeme verwenden ein Collision Mitigation / Collision Avoidence in Verbindung mit CRC Checksummen. Willst du Echtzeit haben musst du ein System mit TDM Systematik verwenden. Wie zb Flexray. Und zur ursprünglichen Frage. Die AVR Teile sind einfach für das was sie können zu teuer im Vergleich zu anderen µC.
Ralph schrieb: > Ethernet ist in der Beziehung mit CAN vollkommen identisch. > Beide Systeme verwenden ein Collision Mitigation / Collision Avoidence Wo gibt es in heutigem geswitchtem duplex Ethernet noch Kollisionen? Entspricht das Verhalten von Switches stets Echtzeit-Anforderungen? Echte Hubs kriegt man ja kaum noch. CAN Nodes, die Fehler erkennen, teilen dies aktiv mit. Ethernet Nodes verwerfen kommentarlos.
Es gibt Ansätze, über Ethernet und speziell TCP/IP zumindest Softrealtime herzustellen, dazu wird versucht trotz TCP/IP wieder verbindungsorientiert zu arbeiten und dann durch entsprechendes Routing genug Daten für Echtzeit von einem Sender zu einem Empfänger rüberzubrigen. Gibts glaub ich ein paar RFCs dazu, hab allerdings weder Nummern noch Namen im Kopf.. Ethernet würde ich jederzeit gerne einsetzen, nur bei Stückzahlen in Verbindung mit Mikrocontrollern sind Ethernetbausteine einfach noch zu teuer, wenn man da so an die 10-20€-Grenze für ein Teil herankommt lohnt sich problemlos Einbau von CAN/RS485 oder anderen Bussen..
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.