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.
Für ASM kann ich den GAVRASM empfehlen. http://www.avr-asm-tutorial.net/gavrasm/index_de.html Gruß Jobst
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.
Beitrag #6946017 wurde von einem Moderator gelöscht.
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/
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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
> ... mein MK2 ist vor dem Umstieg von Win XP auf > Win10-64 gestorben,... Hast Du ihn noch? Verkaufst Du ihn?
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
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.
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.
Bitte 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.