Sanfter Umstieg von 8bit auf 32bit Atmel

https://www.microchip.com/wwwproducts/en/PIC32MX270F256B

Wenn Du 5V brauchst:

https://www.microchip.com/wwwproducts/en/dsPIC33EV256GM102

Außerdem heißt es nicht mehr Atmel, sondern Microchip.

MPLABX, XC32 bzw. XC16, und ein PICKIT3 oder 4, und dann gehts los.

fchk

Frank K. schrieb:
> https://www.microchip.com/wwwproducts/en/PIC32MX270F256B
>
> Wenn Du 5V brauchst:
>
> https://www.microchip.com/wwwproducts/en/dsPIC33EV256GM102
>
> Außerdem heißt es nicht mehr Atmel, sondern Microchip.
>
> MPLABX, XC32 bzw. XC16, und ein PICKIT3 oder 4, und dann gehts los.
>
> fchk

Sorry wer von AVR auf PIC umsteigt dem kann man nicht mehr helfen. So 
was zu empfehlen ist echt frech und wenig hilfreich.

Cyblord -. schrieb:
> Frank K. schrieb:
>> https://www.microchip.com/wwwproducts/en/PIC32MX270F256B
>>
>> Wenn Du 5V brauchst:
>>
>> https://www.microchip.com/wwwproducts/en/dsPIC33EV256GM102
>>
>> Außerdem heißt es nicht mehr Atmel, sondern Microchip.
>>
>> MPLABX, XC32 bzw. XC16, und ein PICKIT3 oder 4, und dann gehts los.
>>
>> fchk
>
> Sorry wer von AVR auf PIC umsteigt dem kann man nicht mehr helfen. So
> was zu empfehlen ist echt frech und wenig hilfreich.

Aha. Ein ewig gestriger also, der immer noch meint, dass PIC immer nur 8 
Bit ist und nur ein W-Register hat. Wach auf. Die Welt hat sich 
geändert, Atmel gibts nicht mehr, Microchip lebt.

fchk

Cyblord -. schrieb:
> Sorry wer von AVR auf PIC umsteigt dem kann man nicht mehr helfen

dsPIC ist PIC24 und eine durchaus vernünftige Architektur. PIC32 ist 
eigentlich MIPS und damit über jeden Zweifel erhaben.

Wenn man vom Umstieg auf PIC (egal welche Architektur) abraten würde, 
dann aus einem ganz anderen Grund: die Toolchain, die Microchip liefert, 
ist binary-only und streckenweise in der nichtkommerziellen Variante 
eingeschränkt (z.B. bei der Optimierung). Bei anderen Architekturen (bei 
32-Bit würde man wohl ARM an erster Stelle nennen wollen) ist das alles 
Open Source und man ist nicht mehr auf die Gnade eines (auch noch 
US-amerikanischen) Herstellers angewiesen, wenn man eine aktuelle, nicht 
eingeschränkte Version installieren will.

Fire Heart schrieb:
> da muss ich mal
> meine Lötphilosophie überdenken

z.B. für die STM32 ARM Cortex-M Prozessoren gibt es diverse 
super-billige Minimal-Boards, fast schon billiger als AVR-Prozessoren. 
Die kann man praktisch als Ersatz für Through-Hole-Prozessoren sehen.

Fire Heart schrieb:
> Wie flasht man die 32er überhaupt?

Über entsprechende JTAG/SWD-Adapter.

Fire Heart schrieb:
> tu ich mir das
> überhaupt noch an, oder steig ich in dem Fall auf Raspberry PI um?

Das hängt natürlich stark von den Anforderungen ab.

Fire Heart schrieb:
> Nun möchte ich halt nicht ganz von vorne (mit
> einer neuen Religion?) anfangen, sondern mich eben nur 'sanft'
> erweitern.

Die Frage ist, wie sinnvoll das ist; mit ARM anfangen und ggf. den 
Hersteller zu wechseln ist auch nicht so unglaublich schwer. Das haben 
schon viele hinbekommen...

Für ARM gibt es jede Menge Tools und Ressourcen, vieles davon frei, und 
für STM32 auch vieles für den Hobby-Bereich.

Axel S. schrieb:
> Wenn man vom Umstieg auf PIC (egal welche Architektur) abraten würde,
> dann aus einem ganz anderen Grund:

Ich habe doch gar keinen Grund genannt. Die grottige und Closed-Source 
Toolchain ist natürlich ein sehr valider Grund kein PIC nehmen. Es gibt 
auch einfach keinen Grund der dafür spricht.

Fire Heart schrieb:
> da ich bislang mit through hole
> gearbeitet hab. TQPF Adapterplatinen sind auch schweineteuer

Also das hängt sicher von der Definition von schweineteuer ab, aber aus 
China kriegst du die als Centartikel.

Fire Heart schrieb:
> Ich
> hab jahrelang mit AtmelStudio meine ATmega programmiert und war
> eigentlich zufrieden. Nun möchte ich halt nicht ganz von vorne (mit
> einer neuen Religion?) anfangen

Wenn du das jetzt nicht an der IDE sondern den Atmel Firmwarepaketen 
festgemacht hättest - OK. Da kann sich natürlich tatsächlich eine 
gewisse Gewöhnung und Erfahrung einstellen. Soweit ich weiß gibt es da 
von (ex-)Atmel aber nur das ASF für die größeren Mikrocontroller, für 
die kleinen 8 bitter nicht.
Aus meiner Sicht bist du also völlig frei, was die Wahl deiner neuen 
Controller angeht; die Umstellung auf eine neue IDE dauert höchstens ein 
paar Tage.

Wieso nimmst du nicht einfach Entwicklungsboards von beliebten 32bit 
uCs, zum Beispiel STM32, die mit Stiftleisten ausgestattet sind? Die 
kannst du dann zum Prototypen auf deine Lochrasterplatinen stecken und 
dann im Bedarfsfall eigene SMD-Platinen fertigen (lassen).

Fire Heart schrieb:
> Da tut sich gleich eine ganz andere Bekenntnisfrage auf: tu ich mir das
> überhaupt noch an, oder steig ich in dem Fall auf Raspberry PI um?

Das sind aus meiner Sicht komplett andere Anwendungsbereiche, die Menge 
an Overhead, die du auf einem Raspberry hast, um "simple" 
Mikrocontroller-Aufgaben wie SPI, ADC, PWM usw. zu erledigen, ist schon 
recht groß. Wenn du da wirklich "durchsteigen" (und nicht nur anwenden) 
willst, brauchst du schon erweiterte Linux-Kenntnisse.

Felix U. schrieb:
> Fire Heart schrieb:
>> da ich bislang mit through hole
>> gearbeitet hab. TQPF Adapterplatinen sind auch schweineteuer
>
> Also das hängt sicher von der Definition von schweineteuer ab, aber aus
> China kriegst du die als Centartikel.

Wenn ich bei eBay nach "TQFP breakout" suche (und nicht TQPF), dann 
findet man genug günstige Angebote sogar aus D. Keine Ahnung wo manche 
Leute ihre Sachen zusammensuchen. So was kauft man nicht beim Distri.

Fire Heart schrieb:
> erweitern.
> Allerdings sehe ich schon starke Veränderungen auf mich zukommen. Die
> 32bit Prozessoren sind alle mit 0.5mm Pinabstand ... da muss ich mal
> meine Lötphilosophie überdenken, da ich bislang mit through hole
> gearbeitet hab. TQPF Adapterplatinen sind auch schweineteuer, direkt
> geht aber auch kaum, weil meine selbstgeätzten Platinen kaum unter 0.5mm

Es gibt etliche Typen der (ex-) Atmel 32 bit controller auch im SOIC 
package mit 1.27 mm pitch. z.B. SAMD11.

Fire Heart schrieb:
> Ich glaube nicht, dass es sich hier um eine Religionsfrage handelt. Ich
> hab jahrelang mit AtmelStudio meine ATmega programmiert und war
> eigentlich zufrieden. Nun möchte ich halt nicht ganz von vorne (mit
> einer neuen Religion?) anfangen, sondern mich eben nur 'sanft'
> erweitern.

Ja, da nimmst Du dann das MPLABX, installierst den XC8 dazu, dazu ein 
PICKIT4, und kannst dann auch Deine AVRs weiter programmieren.

> Allerdings sehe ich schon starke Veränderungen auf mich zukommen. Die
> 32bit Prozessoren sind alle mit 0.5mm Pinabstand ... da muss ich mal
> meine Lötphilosophie überdenken, da ich bislang mit through hole
> gearbeitet hab. TQPF Adapterplatinen sind auch schweineteuer, direkt
> geht aber auch kaum, weil meine selbstgeätzten Platinen kaum unter 0.5mm
> gut werden und ich keine Lötmaske hab.

Die PICs, die ich Dir genannt habe, gibts auch noch im DIL. Microchip 
ist einer der wenigen Hersteller, die überhaupt noch DIL-Controller 
herstellt. Daher hatte ich Dir genau diese Typen genannt.

> Unterstützt Atmel Studio die 32bitter überhaupr noch?
> Wie flasht man die 32er überhaupt? Ich hatte mein geliebtes MyAVR
> (mySmartUSB) im Einsatz...geht das überhaupt noch?

Atmel Studio wird so wie ich das sehe sterben, wenn der AVR und 
ARM-Support im MPLABX komplett ist. Microchip ist dabei, das alles zu 
vereinheitlichen, um langfristig Kosten für die Softwarepflege zu 
sparen. Gehe davon aus, dass MPLABX die Zukunft sein wird, plus PICKIT4. 
Das kannst Du dann für alles aus dem Microchip-Universum verwenden, PIC, 
AVR und ARM.

Es gab auch mal AVR32, aber das ist schon vor der Microchip-Übernahme 
gestorben, weil Atmel nicht genug Geld hatte, um AVR32 und ARM parallel 
zu pflegen, und da AVR32 nicht so viel besser wie ARM war, wurde es 
fallen gelassen. Der letzte AVR32 ist der EDBG-Chip im Atmel Ice. Der 
wird aber auch nur noch so lange am Leben erhalten, wie Microchip das 
Atmel Studio für die Bestandskunden noch braucht.

> Da tut sich gleich eine ganz andere Bekenntnisfrage auf: tu ich mir das
> überhaupt noch an, oder steig ich in dem Fall auf Raspberry PI um?

Der Pi ist nur eines: billig. Für Embedded-Geschichten bietet z.B. ein 
Beaglebone bessere Voraussetzungen. Aber Linux-SOCs und Mikrocontroller 
haben jeweils andere Stärken und Schwächen.

Einen PIC behandelst Du von der Hardware eher wie einen AVR: 100n 
zwischen VCC und GND, weitere 100n zwischen AVDD und AGND, dann 10uF 
keramisch zwischen VCAP und GND, 10k zwischen MCLR und VCC, und dann 
läuft das Teil. Und Du hast bei den PICs keine Fuses, mit denen Du Dich 
aussperren kannst, und Du kannst alle Chips nicht nur programmieren, 
sondern auch im Einzelschritt debuggen, Dir Speicher und Register 
anschauen etc. - auch bei den 8-Bittern.

fchk

Fire Heart schrieb:
> Die 32bit Prozessoren sind alle mit 0.5mm Pinabstand ... da muss ich mal
> meine Lötphilosophie überdenken, da ich bislang mit through hole
> gearbeitet hab.

Normalerweise (habe jedenfalls noch nie etwas anderes gesehen, ymmv) 
sind die QFP-32 immer mit 0,8mm Pinabstand.

Fire Heart schrieb:
> TQPF Adapterplatinen sind auch schweineteuer, direkt geht aber auch
> kaum, weil meine selbstgeätzten Platinen kaum unter 0.5mm gut werden und
> ich keine Lötmaske hab.

Ohne Lötstopp ist schon sehr schwierig. Schonmal drüber nachgedacht 
Platinen zu bestellen? Kostet heute doch wirklich kein Vermögen mehr 
(z.B. bei Aisler oder vom Chinamann).

Adapter sind auch alles andere als "schweineteuer". Gerade mal schnell 
geschaut: 10 St. QFP32-Adapter kosten 1,50€ inkl. Versand beim Ali.

Fire Heart schrieb:
> Wie flasht man die 32er überhaupt? Ich hatte mein geliebtes MyAVR
> (mySmartUSB) im Einsatz...geht das überhaupt noch?

Das kannst du getrost in der Schublade liegen lassen. Die Cortexe haben 
zumeist integrierte Bootloader und falls nicht nimmst du SWD, zum 
Beispiel in Verbindung mit einem J-Link Edu Mini.

Den Artikel 
https://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger kann 
man sich auch mal durchlesen; vieles davon gilt auch für andere 
Cortex-M.

Oder man bleibt im Land, greift hier zu

https://www.reichelt.de/mips32-m4k-mikrocontroller-32-bit-2-3-3-6v-128-kb-spdip-28-32mx150f128b-isp-p121326.html?&nbc=1

und drückt den mit drei Kondensatoren und einem Widerstand in sein 
Steckbrett.

Datenblätter gibts hier:
https://www.microchip.com/wwwproducts/en/PIC32MX150F128B

PICKIT3-Clones gibts für 20€ bei Amazon (das sind alles 1:1 Nachbauten), 
der PICKIT4, der dann auch AVR und ARM kann, kostet 50€ beim 
Distributor.

fchk

Ich bin von den AVR auf zunächst ATSAMC21 umgestiegen.
Okay, ich brauchte iso CAN-FD und eigentlich nicht mehr Power.

Die laufen mit 5V, lassen sich mit dem Atmel-Studio programmieren und 
mit dem Atmel ICE hatte ich schon einen passenden Debug-Adapter.

Das TQFP-32 hat 0,8 mm Abstände und somit war der kleinste aus der Reihe 
dann auch noch im gleichen Gehäuse wie der ATMega16M1-AU den ich vorher 
benutzt habe.

Nur, glaube nicht, dass das so einfach ist.
Der Core kann einem ja weitgehend egal sein, dafür gibt es ja den 
Compiler.

Aber die Peripherie ist eine völlig andere Welt, da muss man sich 
erstmal durchbeissen.

Und wenn man da sowieso durch muss was neues zu Lernen, es kann sehr gut 
sein, dass das erheblich leichter wird mit einer Controller-Familie die 
weiter verbreitet ist.
Also wenn man nicht an Features gebunden ist die es woanders nicht so 
leicht gibt.
Sowas wie STM32 ist vielleicht für den Einstieg besser, auch wenn es 
mich gerade geschüttelt hat als ich das Referenz-Manual vom STM32F4xx 
aufgemacht und die GPIO Register gecheckt habe.

Bei den ATSAM mit Cortex hat Atmel wenigstens die Chance von dem 
deutlich aufgebohrtem Aufdressraum genutzt und da reichlich Register 
eingebaut.
Eine PORT Gruppe für 32 Pins hat bei dem ATSAMC21 mal eben 95 Register.
Ein STM32F4xx hat dagegen gerade mal 36 Register für einen Port.
Und sowas wie GPIOx_BSRR finde ich deutlich weniger intuitiv benutzbar 
als die OUTSET und OUTCLR Register vom ATSAM.

Wie auch immer, auch wenn ich STM32 nicht für die bessere Familie halte, 
alleine der Umstand das man dafür leichter Support bekommt, könnte sehr 
hilfreich sein, wenn man eh vieles neu lernen muss.

Fire Heart schrieb:
> Ich muss jetzt nur eure Kommentare zusammen mit ein paar
> Datenblätter in die Waagschale werfen... Und es kommt wohl nicht
> notwendigerweise Atmel dabei heraus.

Lass am Ende STM32 dabei rauskommen, kauf dir für 6 Euro einen ST-Link 
v2 Clone oder für 10 Euro einen ST-Link v3 Mini oder für 20 Euro einen 
ST-Link V2 Original und programmiere und debugge damit. Kein 
ISP/DebugWire/HV Crap ohne Debugging Möglichkeiten wie bei AVR.

Fire Heart schrieb:
> Und eines hab ich auch draus gelernt: ein 'sanfter Umstieg' scheint in
> der Form nicht möglich zu sein, somit stehen mir dann sowieso alle
> Optionen offen.

Naja, die Frage ist halt was "sanfter Umstieg" für dich bedeutet. Willst 
du das dein Code statt auf einem AVR auf irgendeinem anderen Controller 
werkelt, ohne irgendetwas dafür zu tun? Dann könntest du auch gleich ins 
Arduino-Universum abtauchen. Willst du unbedingt bei Atmel Studio 
bleiben aber bist bereit deine Hardware-Treiber neu zu schreiben, dann 
nimmst du halt ein SAMD21-Breakout Board und pflanzt es wie ein DIP auf 
eine Lochrasterplatine oder meinetwegen eine selbstgeätzte Leiterplatte.

Beides halte ich nicht für sonderlich ziehlführend. Die Diskussion über 
Arduino kann man sich denke ich sparen und was deine Vorliebe für Atmel 
Studio angeht, bin ich ganz bei Frank. Früher oder später wird Microchip 
das sterben lassen und dann musst du so oder so umsatteln. Deinen 
geliebten AVR-Programmer kannst du wie gesagt sowieso abschreiben.

Ich würde mich sowieso frei von irgendwelchen IDEs oder Herstellertools 
machen. Für den Anfang sind die sicher ganz nett aber wenn es nicht ohne 
geht, dann ist das für mich ein absolutes no-go, weshalb ich sowohl 
Infineon, als auch Cypress meide, obwohl beide sicher keine schlechten 
Controller bauen. Es gibt aber einfach genügend Controller auf dem 
Markt, die man sich ohne diese härteste Form des Vendor-Lockins gönnen 
kann, z.B. von NXP, Nordic, Silabs, STM, TI und nicht zuletzt auch 
Atmel.

Nordic und Silabs haben meiner Meinung nach die schickeste Peripherie 
(gefolgt von NXP), wobei beide eher beschränkt sind, was die Auswahl der 
Controller angeht (beide eher mit Fokus auf low-power und BLE). Die 
größte Auswahl bekommst du vermutlich bei Atmel, NXP und STM, da die 
jeweils alles vom ultrastromsparenden CM0+ bis zum dicken CM7 anbieten. 
Die letzteren beiden sind meine persönlichen Favoriten aber am Ende 
musst du einfach für dich selbst ausmachen was dir am besten taugt. Als 
ich mit ARM-Controllern angefangen habe, habe ich mir auch gleichzeitig 
Dev-Boards von Freescale und STM bestellt. Die Freescale-Controller fand 
ich zwar etwas intuitiver aber bin schlussendlich auf STM32 "hängen 
geblieben", weil die eben so weit verbreitet und dementsprechend auch 
sehr gut verfügbar waren und sind.

W.S. schrieb:
> Und was Schaltungstechnik betrifft, da schätze ich, daß du das als
> einer, der sich seine LP bislang selber geätzt hat, bereits besser weißt
> als die reinen Programmierer hier, die 3 linke Hände und Angst vor der
> Hardware haben - und die deshalb irgend welche Eval-Boards lobpreisen.
> Meine Erfahrung ist, daß man gerade mit Eval-Boards in 99% aller Fälle
> genau DAS nicht machen kann, was man eigentlich machen will. Irgendwas
> an den Dingern stört immer.

Im Gegensatz zu dir könnse aber Software ;)

Ja, sobald man mal etwas auf einem Grafikdisplay hinmalen will. 
Heutzutage benoetigt man meist ein paar Pins mehr wie ein TQFP 44 
hergibt. Die groesseren haben die Beinchen dann auch naeher beieinander. 
Und ja, das macht keinen Sinn mehr selbst zu aetzen. Zumal eine 
Leiterplatte nicht mehr die Welt kostet. Ich rechne mit 100Euro fuer 
1dm^2 in 4 Lagen. 2 Lagen mach ich nicht mehr.
Zum Loeten von TQFP100, TQFP144 oder so, gibt's einige Youtoob videos.

Wolfgang schrieb:
> Nur weil die BWLer beschlossen haben, eine Firma zu übernehmen,
> verschwindet die Originalbezeichnung nicht.

Aber nur weil die Originalbezeichnung noch existiert heißt das nicht, 
das nicht zumindest Teile der alten Firma verschwinden bzw. mit dem 
Mutterkonzern verschmelzen. In dem Fall würde ich mal darauf wetten, 
dass es in sehr naher Zukunft kein Atmel Studio mehr geben wird. Wenn 
ich für die Zukunft auf Atmel setzen will und auf jeden Fall plane mit 
der Hersteller-IDE zu fahren, dann muss ich eben auch jetzt schon MPLAB 
evaluieren.

Ich feier ja den Tag an dem hier bei ner Frage nach Architekturwechsel 
nicht gleich ein Glaubenskrieg ausbricht. :(

Klaus schrieb:
> Es gibt doch kleine Boards mit einem SAM ind 32 Bit drauf. Programming
> erfolgt mit SWD. Dazu musst du dir aber einen neuen Programmer
> anschaffen.
Nö, ein neuer Programmer/Debugger ist nicht nötig.
Man kann seinen ATMELICE einfach weiterverwenden, muß das Target nur an 
der SAM-Buchse statt an der mit AVR bezwichneten anschließen.

Da liegen die gleichen Signale drauf, sind aber so angeordnet, daß sich 
die von ARM für den Programmierstecker vorgesehene Belegung ergibt, die 
Atmel für seine SAMs sinnigeeweise übernommen hat.

Ich verwende sowohl AVR 8-Bit, STM32 als auch SAM Mikrocontroller.
Wobei IMHO die SAMs die etwas intelligenteren Peripherieeinheiten haben.

AVR 32 mag ich nicht so, die sind big Endian...