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