Wiedereinstieg AVR-Programmierung mit Studio7

[WoW (Gast)]

Hallo,
ich war 10 Jahre vom Fenster der uC-Programmierung weg. Jetzt habe ich 
ein Mini-Projekt wieder vor. Zu den Vorkenntnissen: Von 8-32-Bit 
Mikrocontrollerentwicklung/Programmierung alles gemacht. Wie so ein Ding 
funktioniert ist restlos alles klar. Jetzt habe ich gedacht, ich 
verwende für mein Miniprojekt meine alten Atmel-Sachen, die ich noch 
habe (JTAG-Ice MKII und STK500) und habe gesehen, daß damit nicht mehr 
alle Prozessoren eingesetzt werden können. Da ich wenige Pins brauche, 
bin ich beim ATtiny45 gelandet. Microchip Studio 7 Installiert und 
erwartet, daß ich mit Bibliotheken usw. schwer unterstützt werde. Bin 
dann auch auf ASF4 und Atmel START gestoßen, um zu merken, daß mein 
ATtiny45 gleich mal gar nicht unterstützt wird. Da mich die beiden 
Themen interessieren, habe ich mich mal kurz damit befaßt, aber das ist 
nichts für 5 Minuten. So richtig weiß ich jetzt nicht, wie ich am 
elegantesten mein C-Programm schreibe. Ich möchte nicht unbedingt alle 
möglichen Header-files für den ATtiny45 selber schreiben. Man könnte ja 
auch ein Projekt mit ASF4 für einen unterstützten uC aufsetzen und die 
Headerfiles händisch anpassen. Was würdet Ihr empfehlen und lohnt es 
sich mit START und ASF4 sich zu befassen?

Gruß   WoW

[Oliver S. (oliverso)]

Für einen Attiny45 lohnt das nicht.

Entweder die paar Hardwaremodule da drin selber programmieren, oder auf 
einen Arm umsteigen, für den sich der ganze HAL/… Kram dann lohnt.

Oliver

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Oliver S. schrieb:
> Für einen Attiny45 lohnt das nicht.

ACK. Schreib einfach los in C oder ASM, wie damals auch und vergiss ASF 
für die kleinen AVRs. Für XMega und SAM ists sicher sinnvoll.

[Jobst M. (jobstens-de)]

Für ASM kann ich den GAVRASM empfehlen.

http://www.avr-asm-tutorial.net/gavrasm/index_de.html

Gruß
Jobst

[Pepe T. (pepe_t)]

Nimm einen attiny85. Dazu arduino ide. Den kann man direkt an USB 
anschliessen und in C programmieren. Vernünftiger, billiger und 
einfacher wäre aber ein arduino mini clone für 2 eur.

[Uwe B. (uwebre)]

WoW schrieb:

> So richtig weiß ich jetzt nicht, wie ich am
> elegantesten mein C-Programm schreibe

Der gute alte GNU-C  (AVR-GCC, WinAVR) ist nicht "elegant" genug um 
einen ATTINY45 zu programmieren?

Uwe

[Stefan F. (Gast)]

Pepe T. schrieb:
> Vernünftiger, billiger und
> einfacher wäre aber ein arduino mini clone für 2 eur.

Für den Arduino Mini braucht man zusätzlich einen Programmieradapter 
(ISP oder USB-UART). Offenbar hast du das vorliegen.

Die Arduino Nano Klone, haben einen USB-UART ohne Mehrkosten on-board. 
Dafür nehmen sie mehr Strom auf, was bei langzeit Betrieb an Batterien 
hinderlich ist.

Mach dir keine Sorgen um das ASF, das benutzt nach meinem Kenntnisstand 
sowieso niemand. Ich glaube das Framework existiert nur, damit Atmel 
sagen kann "wir haben auch eins". Wenn du unbedingt ein Framework 
benutzen willst, dann nimm Arduino. Das ist weit verbreitet - auch auf 
ATtiny45.

Nenne mich "Opa" aber ich empfehle immer noch das alte Atmel Studio 4. 
Das ist viel kleiner und schneller, als das Microchip Studio 7. Wenn du 
willst, kannst du es mit einer aktuellen Toolchain benutzen, zum 
Beispiel die von Zak: https://blog.zakkemble.net/avr-gcc-builds/

[Christoph db1uq K. (christoph_kessler)]

Noch'n Opa
Ich benutze auch noch das letzte reine AVR-Studio, bevor das SAMs-Gedöns 
dazukam. Läuft in der Virtual Box unter XP.

Da der USB-Prog nicht mehr gepflegt wird, hab ich den billigen MyAVR von 
Conrad Nr. 191406
https://asset.conrad.com/media10/add/160267/c1/-/gl/000191406ML01/bedienungsanleitung-191406-myavr-board082-usb-programmer-1-st.pdf
Auf Seiten 9-10 ist die Benutzung mit dem AVR-Studio beschrieben (als 
STK500), danach noch kurz mit AVR-Dude. Es funktioniert auch über die 
Virtual Box.

[Eberhard H. (sepic)]

WoW schrieb:
> Microchip Studio 7 Installiert ...

Atmel Studio 7 (nicht Microchip Studio) hat die alten AVRs drin.

Läuft bei mir mit einem JTAGICE3 seit Jahren sehr zuverlässig und 
komfortabel unter WIN10.

Hier geht es zum Download-Archiv für Atmel-Studio (u. a.):
https://www.microchip.com/en-us/tools-resources/archives/avr-sam-mcus

[Christoph db1uq K. (christoph_kessler)]

Genau, da gibt es weiter unten auch noch meine Version:
AVR® Studio v4.19.730

ab 5.1 heisst es "All 8-bit and 32-bit microcontrollers are supported"
Wer ARM programmieren will soll doch dafür eine eigene Toolchain 
benutzen, nur für AVR war die 4.19 die letzte Version.
Klar anschließend gab es auch neuere AVR, dann muss man die 
include-Datei suchen und eventuell anpassen.

[Eberhard H. (sepic)]

AVR Studio 4 ist aber schon ein sehr heftiger Rückschritt.

Bei Atmel Studio 7 muss man die 32-Bit-CPUs ja nicht installieren, wenn 
man sie nicht benötigt.

Und von Atmel Studio 5 und 6 sollte man tunlichst die Finger lassen.

[Falk B. (falk)]

Eberhard H. schrieb:
> AVR Studio 4 ist aber schon ein sehr heftiger Rückschritt.

Ein stabiler, bewährter, effizienter Klassiker! Nix Bloatware! Für einen 
Kleinen ATtiny whatever reicht das allemal! Hab ich bis heute im 
Einsatz, privat wie beruflich.

[Gerhard O. (gerhard_)]

Falk B. schrieb:
> Eberhard H. schrieb:
>> AVR Studio 4 ist aber schon ein sehr heftiger Rückschritt.
>
> Ein stabiler, bewährter, effizienter Klassiker! Nix Bloatware! Für einen
> Kleinen ATtiny whatever reicht das allemal! Hab ich bis heute im
> Einsatz, privat wie beruflich.

Dazu hätte ich eine Frage: Funktioniert bei Dir unter einem X64 BS noch 
der AVR-ISP MK2? Ich konnte den bei mir nie zum Laufen kriegen. Nur mit 
AS7 funktioniert der noch.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Eberhard H. schrieb:
> Atmel Studio 7 (nicht Microchip Studio) hat die alten AVRs drin.

Auch Microchip Studio 7 hat die alten AVR drin. MC Studio 7 ist 
lediglich ein Wiederaufguss von Atmel Studio 7, bei dem ein Praktikant 
'Atmel' durch 'Microchip' ersetzt hat. Ansonsten immer noch die gleiche 
Software und auch nur 32-bittig.
Ist viel langsamer als AVR Studio 4, aber es funktioniert. Selbst der 
Import von AS4 Projekten klappt beinahe komplett.

[Falk B. (falk)]

Gerhard O. schrieb:
> Dazu hätte ich eine Frage: Funktioniert bei Dir unter einem X64 BS noch
> der AVR-ISP MK2?

Hab ich nicht getestet, mein MK2 ist vor dem Umstieg von Win XP auf 
Win10-64 gestorben, hab nur noch AtmelICE unter Microchipstudio am 
Laufen.

> Ich konnte den bei mir nie zum Laufen kriegen. Nur mit
> AS7 funktioniert der noch.

Ja, das Problem habe ich in der Firma auch. Ist ein Treiberproblem. Man 
kann damit leben.

[Gerhard O. (gerhard_)]

Falk B. schrieb:
> Gerhard O. schrieb:
>> Dazu hätte ich eine Frage: Funktioniert bei Dir unter einem X64 BS noch
>> der AVR-ISP MK2?
>
> Hab ich nicht getestet, mein MK2 ist vor dem Umstieg von Win XP auf
> Win10-64 gestorben, hab nur noch AtmelICE unter Microchipstudio am
> Laufen.
>
>> Ich konnte den bei mir nie zum Laufen kriegen. Nur mit
>> AS7 funktioniert der noch.
>
> Ja, das Problem habe ich in der Firma auch. Ist ein Treiberproblem. Man
> kann damit leben.

Danke. Ist gut, das bestätigt zu hören.

[Stefan F. (Gast)]

Gerhard O. schrieb:
> Funktioniert bei Dir unter einem X64 BS noch
> der AVR-ISP MK2? Ich konnte den bei mir nie zum Laufen kriegen.

Unter Linux geht es auf jeden Fall. Wenn die IDE ihn nicht mehr 
unterstützt, dann nimm avrdude und ggf. irgendeine GUI dazu.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Gerhard O. schrieb:
> Funktioniert bei Dir unter einem X64 BS noch
> der AVR-ISP MK2? Ich konnte den bei mir nie zum Laufen kriegen. Nur mit
> AS7 funktioniert der noch.

Hier funktioniert er mit einem 'Microchip Tools' Treiber vom 15. Oktober 
2020 unter Win10/x64. Den wird er wohl bekommen haben, als ich um die 
Zeit MC Studio 7 installiert habe.
Allerdings ist MC Studio 7 selber, wie erwähnt, nur 32 bittig. Das kann 
verwirren, weil einige nötige Visual Studio Dateien evtl. nicht 
installiert werden und Studio 7 deswegen fehlerhaft arbeitet oder 
eigenartige Fehlermeldungen zeigt. So wars zumindest bei mir. Manuelles 
Nachinstallieren hilft dann. Allerdings habe ich auch eine etwas 
ungewöhnliche CPU.

[Stefan F. (Gast)]

Ich erinnere mich daran, dass ich die Firmware meines Atmel AVRISP Mk-II 
für das neue Atmel Studio upgraden musste und für das alte AVR Studio 
wieder downgraden musste.

Der in der IDE integrierte Menüpunkt zum Upgraden kann auch downgraden.

Für den alten Jungo Treiber, den AVR Studio benutzt, muss man seit 
Windows 8 die Überprüfung der Treibersignatur deaktivieren. Siehe 
http://stefanfrings.de/avr_tools/libusb.html

[Gerhard O. (gerhard_)]

Stefan ⛄ F. schrieb:
> Gerhard O. schrieb:
>> Funktioniert bei Dir unter einem X64 BS noch
>> der AVR-ISP MK2? Ich konnte den bei mir nie zum Laufen kriegen.
>
> Unter Linux geht es auf jeden Fall. Wenn die IDE ihn nicht mehr
> unterstützt, dann nimm avrdude und ggf. irgendeine GUI dazu.

Linux nehme ich fast nie her. Ist aber kein großes Problem. Ich 
arbeitete zwar früher recht gerne mit AS4, aber AS7 funktioniert ja auf 
einen modernen X64 Rechner auch ganz gut und damit lässt sich der MK2 
oder das ICE betreiben. AS4 war halt noch richtig schlanke und schnelle 
SW. AVRdude ist sowieso eine feine Sache und leicht von der 
Kommandozeile aus konfigurierbar.

[c-hater (Gast)]

Falk B. schrieb:

> Ein stabiler, bewährter, effizienter Klassiker! Nix Bloatware! Für einen
> Kleinen ATtiny whatever reicht das allemal!

Ganz genau. Und deshalb ist es auch absolut kein Problem, den einfach 
parallel zu Studio7 installiert zu haben.

[Uwe K. (ukhl)]

> ... mein MK2 ist vor dem Umstieg von Win XP auf
> Win10-64 gestorben,...

Hast Du ihn noch? Verkaufst Du ihn?

[Falk B. (falk)]

Uwe K. schrieb:
>> ... mein MK2 ist vor dem Umstieg von Win XP auf
>> Win10-64 gestorben,...
>
> Hast Du ihn noch? Verkaufst Du ihn?

Ist längst verschrottet.

[WoW (Gast)]

Hallo,
ich wollte mich jetzt nochmal zum aktuellen Status melden. Zunächst 
einmal vielen Dank für die eingebrachten Vorschläge, die ich mir zum 
Teil angeschaut habe, aber mich dann doch zu einem eigenen Vorgehen 
entschieden habe. Was war mein Weg:
Zunächstt einmal habe ich einfach ein ATtiny45-Projekt mit der 
Studio-IDE angelegt und ein Build gemacht. Da hat man in den 
"Dependencies" mal die eingezogenen Headerfiles anschauen können. Beim 
ATt45 sind in der entsprechenden IO....h-Datei nur rudimentäre defines 
vorhanden. Rein theoretisch genügt das fast zum Programmieren, denn 
damit kann man auf alle SFR´s zugreifen.
Dann habe ich zum Vergleich mit Atmel-START ein Projekt eines neueren 
AVR´s angelegt. Da habe ich dann gesehen, daß man dort deutlich 
elegantere Ansätze hat (bereits definierte Structs für 
Peripherieeinheiten usw.). Nicht so schön, daß man ältere Chips halt 
wohl hängen läßt.
Dann bin ich noch auf die AVR-LIBC gestoßen. Das war dann doch ein 
gewisser Minimalansatz eines nicht Steinzeitprogrammierens. AVR-LIBC 
unterstützt auch ältere Controller und deckt doch einiges ab. Was mir in 
diesem Falle nicht so gefallen hat, war der Eindruch, der die LIBC auf 
mich gemacht hat: Unausgereift, oder schlecht gepflegt. Beispiel: Um den 
Sleep-Modus zu setzen, wird das Makro set_sleep_mode(mode) benutzt. Es 
ist aber nicht beschrieben, ob mode nur der Wert für die 2-Bits sind, 
oder der Wert für das komplette 8-Bit-Register. Da mußte ich dann im 
Quellcode nachschauen, um festzustellen, daß es letzteres war. Aber wie 
gesagt - der Gesamteindruck macht leider einen vernachlässigten 
Eindruck. Ich hätte nach 10Jahren Abstinenz ein runderes 
Entwicklungsvorgehen erwartet.

Gruß   WoW

[Oliver S. (oliverso)]

WoW schrieb:
> Dann bin ich noch auf die AVR-LIBC gestoßen.

Die avrlibc ist Bestandteil der avr-gcc-toolchain, auch der des Studios 
(egal, ob mit oder ohne Atmel-Start-Gedöns benutzt).

WoW schrieb:
> Beispiel: Um den
> Sleep-Modus zu setzen, wird das Makro set_sleep_mode(mode) benutzt. Es
> ist aber nicht beschrieben, ob mode nur der Wert für die 2-Bits sind,
> oder der Wert für das komplette 8-Bit-Register.

Was dir beim Blick in den Quellcode aufgefallen sein müsste, hat die lib 
dafür vordefinierte Macros. Die Doku ist da allerdings tatsächlich etwas 
zurückhaltend mit den Infos dazu.

Oliver

[Johannes S. (Gast)]

nur so als Info reingeworfen, ich bekomme den Newsletter von Codeproject 
und im letzten war dieser Artikel drin:

https://www.codeproject.com/Articles/5321801/Debugging-an-Arduino-project-with-GDB-on-Classic-A

habe es nur überflogen weil ich die AVR nur noch seltenst einsetze, fand 
es aber trotzdem interessant.

[Stefan F. (Gast)]

WoW schrieb:
> Dann habe ich zum Vergleich mit Atmel-START ein Projekt eines neueren
> AVR´s angelegt. Da habe ich dann gesehen, daß man dort deutlich
> elegantere Ansätze hat (bereits definierte Structs für
> Peripherieeinheiten usw.). Nicht so schön, daß man ältere Chips halt
> wohl hängen läßt.

Könnte daran liegen, dass die Register der älteren AVR anders angeordnet 
waren, so dass Structs wenig hilfreich waren.

Zum Beispiel: Bei einem Xmega mit 6 seriellen Ports haben alle 6 die 
selben Register schön zusammenhängend. Bei einem ATmega328PB sieht das 
schon anders aus.

[MitLeserin (Gast)]

Stefan ⛄ F. schrieb:

> Könnte daran liegen, dass die Register der älteren AVR anders angeordnet
> waren, so dass Structs wenig hilfreich waren.

Nicht wirklich. Es war halt üblich Konstanten als #defines zu 
deklarieren.

In C sind Konstanten auch als enums definierbar und benachbarte Register 
sind in structs{reg..,reg..} mit bekannter struct-address indirekt 
adressierbar.

Die Erweiterung von #defines zu enum und struct{} ist eigentlich 
trivial.

Den Schritt zu c++ hat microchip noch nicht gewagt ..

Die üblichen #defines sind in den neuen iotnxx.h und iomxx.h aber immer 
noch enthalten.