Hallo Leute, Ich habe mit den AT90CAN AVRs viel Erfahrung über die letzten fast 10 Jahre gesammelt - speziell auch in Bezug auf die CAN Hardware. Nun ist ein neues Projekt anstehend, welches ebenfalls wieder prädestiniert für den Einsatz eines solchen Controllers wäre. Ich habe jetzt aber gewisse Bedenken, da es diese Typen mittlerweile schon seit einer Ewigkeit gibt, und eine gewisse Angst dass diese eher mal bald abgekündigt werden. Mir ist klar, dass es hierzu keine eindeutige Aussage gibt - aber was würde euer Gefühl zum Lifecycle dieser Controller sagen? Viele werden wahrscheinlich auch sagen dass 8 Bitter sowiso nicht mehr Zeitgemäß sind, und ich auf einen ARM umsteigen soll - das ist aber leistungsmäßig absolut nicht notwendig, und prinzipiell macht es ja Sinn wenn man was verwendet wo man schon Erfahrung hat. Danke und Viele Grüße Max
Das, was Microchip in eigenen Fabs fertigt, verkaufen sie, solange es noch Bedarf dafür gibt. Du kannst noch problemlos PIC16C73 kaufen, die mitte der 80'er Jahre rausgekommen sind. AVR-Zeugs ist zugekauft und wird fremdgefertigt. Atmel wird AVRs solange fertigenlassen, wie sie damit Geld machen und wie die alten Fabs noch in Betrieb sind. Wenn es da irgendwo ein Feuer gibt, wird die Fab eher nicht mehr wieder aufgebaut und das ganze Zeugs abgekündigt. Und so einen alten Prozess irgendwo anders hin umziehen ... keine Ahnung, ob sich das rechnen würde. In welchen Zeiträumen planst Du denn? Automotive-typische 15 Jahre? Dann würde ich vielleicht doch was aktuelles nehmen. fchk
Hast du mal einen Kostenvergleich gemacht, was so ein kleiner STM32 im Vergleich zum AT90CAN kostet? Willst du mittelfristig aus der Entwicklung raus oder in Rente gehen wenn du an neuen Techniken nicht mehr interessiert bist?
Ich bin von den 90CAN32 und ATMEGA16M1 weg weil die kein CAN-FD können. Also egal wie lange die noch angeboten werden, technologisch sind die für mich bereits tot, leider. Und weil es gar keine Automotive STM32 gibt und auch keine die CAN-FD konnten (die paar wenigen die es jetzt gibt sind immer noch nicht Automotive), war STM32 als Alternative bei mir ganz schnell raus. Aktuell benutze ich ATSAMC21 und ATSAME51. Neben viel mehr Speicher, extrem viel mehr Peripherie und einer deutlich größeren Auswahl an Varianten die Code-Kompatibel aber mit unterschiedlicher Pin-Anzahl sind, ist der niedrigere Preis auch nett. So kostet ein einzelner ATMEGA16M1-AU bei Mouser gerade 3,49€ während ein einzelner ATSAMC21E18A-AUT im exakt gleichen Gehäuse 2,64€ kostet. Ein AT90CAN32-16AU ist bei Mouser gerade nicht lieferbar, soll aber 4,09€ kosten, ein ATSAMC21J18A-AUT mit ebenfalls 64 pins aber 0,5mm Pitch kostet 2,92€. Und während ich gedacht habe, dass ich die Performance sowieso nicht benötige, vor allem nicht von dem E51, auf z.B. DMA für den SPI möchte ich nicht mehr verzichten. Und eines meiner letzten Projekte war vor Weihnachten ein Display an einen CAN-FD mit 1MBit/8MBit zu klemmen und dazu muss man den CAN-Controller schon mit 80MHz takten.
Max schrieb: > Nun ist ein neues Projekt anstehend, welches ebenfalls wieder > prädestiniert für den Einsatz eines solchen Controllers wäre. Du wolltest wohl sagen, dass du das Projekt mit dem Controller gestemmt bekommst und es aus technischer Sicht keinen Bedarf an einem anderen Controller gibt? Die Stückzahl ist vermutlich gering, weil sonst würde sich der Controller schon aus wirtschaftlicher Sicht verbieten. Dann wäre es auch nicht so tragisch wenn man im schlimmsten Fall all-time bevorraten müsste, oder?
Ich hatte auch mal zwischen AT90CAN und ATmegaxxM1 zu entscheiden. Die M1 waren aber nicht stabil verfügbar, daher wurde es der 90CAN. ARM kam nicht in Frage, da das ein Grab an Pegelwandlern erfordert hätte. ADCs, DACs, TPIC usw. sind alles 5V. Der AT90CAN hat mich auch nicht enttäuscht, keinerlei Lieferprobleme für unsere kleinen Stückzahlen. Ich denke mal, er wird oft in Industriesteuerungen eingesetzt und daher lange verfügbar sein.
Peter D. schrieb: > ARM kam nicht in Frage, da das ein Grab an Pegelwandlern erfordert > hätte. ADCs, DACs, TPIC usw. sind alles 5V. Die Anekdote ist aber schon ein paar Jahre alt, oder? Und mal davon ab das es den ATSAMC21 schon über 3 Jahre gibt, der läuft auch mit 5V. Zum Beispiel könnte das so aussehen: https://github.com/RudolphRiedel/SAMC21_one Aber inzwischen findet man eh mehr 3,3V als 5V. Und mit den AVR bedeutet das entweder Pegelwandler oder nicht mehr als 12MHz.
Rudolph R. schrieb: > Die Anekdote ist aber schon ein paar Jahre alt, oder? Das mag sein, aber wenn die Stückzahl< einige tausend ist und das mögliche eol des Controllers handhabbar ist, kostet die Umstellung auf neuen Controller UND neue Peripherie einfach mehr. Wobei das eol bisher rein theoretischer Natur ist.
Karl schrieb: > Wobei das eol bisher rein theoretischer Natur ist. Kommt darauf an, für mich ist das EOL längst überschritten für alle Controller die nur Classic-CAN können. Und wenn ich damit auch früh dran war, inzwischen ist CAN-FD längst in Serien-Fahrzeugen auf der Straße angekommen. Da geht es auch gar nicht mal immer um höher, schneller, weiter, sondern im einfachsten Fall schlicht um Kompatibilität.
Rudolph R. schrieb: > für mich ist das EOL längst überschritten für alle Controller die nur > Classic-CAN können. Rolleyes Für den nächsten ist alles mit can fd bereits eol weil kein 1000042 gBit Ethernet dabei ist. Daher erlaube mir zu präzisieren: Wobei die Abkündigung bisher rein theoretischer Natur ist.
Ja, den ATSAMC21 gab es damals noch lange nicht. Den könnte man als Alternative nehmen, aber das Datenblatt erschlägt einen regelrecht. Das wird einiges an Programmierarbeit kosten, die ganzen Initialisierungen zu machen und die CAN-Lib anzupassen. Die HW-Division und die Interruptlevel würden natürlich einiges beschleunigen. Wenn ich das richtig sehe, kann man ihn auch mit dem Atmel-Studio in C programmieren und debuggen und braucht keinen verdongelten Compiler.
:
Bearbeitet durch User
Karl schrieb: > Rolleyes > Für den nächsten ist alles mit can fd bereits eol weil kein 1000042 > gBit Ethernet dabei ist. Ich schaue bereits auf CAN XL und Automotive Ethernet. Man kann natürlich auch einfach warten bis einen die Realität überrollt hat. Und Gigabit Automotive Ethernet, auch 1000BaseT1 genannt, fährt da draußen inzwischen auch in Serie herum. Nur wird Ethernet noch länger nicht CAN ersetzen, nur nach oben ergänzen. Peter D. schrieb: > Ja, den ATSAMC21 gab es damals noch lange nicht. Tja, damals habe ich auch noch die AT90CAN und die ATMEGA16M1 verwendet. > Den könnte man als Alternative nehmen, aber das Datenblatt erschlägt > einen regelrecht. Oh ja, die Dinger sind voll gestopft mit Peripherie. > Das wird einiges an Programmierarbeit kosten, die > ganzen Initialisierungen zu machen und die CAN-Lib anzupassen. Kostet es. Auf der anderen Seite hätte ich aber auch ganz real diverse Projekte die letzten zwei Jahre gar nicht machen können, wenn ich die Zeit nicht investiert hätte. > Die HW-Division und die Interruptlevel würden natürlich einiges > beschleunigen. Der Cortex M0+ in dem ATSAMC21 hat keinen Hardware Dividierer. Und die DIVAS Unit habe ich mir noch nicht genauer angesehen, weil es eben eine eigene Einheit ist die man extra füttern muss. Im Kontext mit dem CAN benutze ich gar keinen Interrupt mehr, sondern einen der Empfangs-FIFOs für bis zu 64 Botschaften. > Wenn ich das richtig sehe, kann man ihn auch mit dem Atmel-Studio in C > programmieren und debuggen und braucht keinen verdongelten Compiler. Das ist richtig, hier mal ein einfaches Beispiel-Projekt von mir: https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_SAMC21_EVE2-50G Also einfach im Bezug auf den Controller, der meiste C21 spezifische Code ist in der main.c, dazu noch ein bisschen was für SPI und DMA in der EVE_target.h und EVE_target.c. Das ist jetzt auch kein ASF Geschwurbel.
Rudolph R. schrieb: > Und Gigabit Automotive Ethernet, auch 1000BaseT1 genannt, fährt da > draußen inzwischen auch in Serie herum. Das ist alles gut und schön und vielleicht auch richtig, geht aber völlig am Thema vorbei. Der TO kann ein Problem offensichtlich mit einem angegrauten AT90CAN lösen, sorgt sich aber um die Verfügbarkeit. Egal. Immer schön weiter missionieren. Irgendwann muss das Internet doch zur Vernunft kommen.
Rudolph R. schrieb: > hier mal ein einfaches Beispiel-Projekt von mir: Ich sehe da aber nirgends was mit CAN und auch kein CAN FD.
Peter D. schrieb: > Ich sehe da aber nirgends was mit CAN und auch kein CAN FD. Das ist richtig, dazu habe ich kein Beispiel Online, das war jetzt nur generell dazu wie das mit dem ATSAMC21 im Atmel-Studio aussieht.
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.