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.
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.
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.
