Hallo, Leider kommen die neueren AVRs ATMEGAS nun nur noch mit UPDI Interface , da Atmel nun Microchip ist frage ich mich, ob ich einen mir ohnehin zur Verfügung stehenden ICD3 https://www.microchip.com/en-us/development-tool/DV164035 auch zum debuggen/programmieren des Atmega4808 verwenden kann?
Products Supported: MPLAB® ICD 4: PIC, SAM MCU, dsPIC DSC* MPLAB PICkit™ 4: PIC, AVR, SAM MCU, dsPIC DSC https://www.microchip.com/en-us/development-tools-tools-and-software/programmers-and-debuggers
Jan Jans schrieb: > Hallo, > > Leider kommen die neueren AVRs ATMEGAS nun nur noch mit UPDI Interface > , da Atmel nun Microchip ist frage ich mich, ob > ich einen mir ohnehin zur Verfügung stehenden ICD3 > https://www.microchip.com/en-us/development-tool/DV164035 > > auch zum debuggen/programmieren des Atmega4808 verwenden kann? Nein, funktioniert nicht. fchk
Hallo, such einmal nach 'UPDI' im Forum, du findest paar Beiträge die sich mit günstiger UPDI Programmierung befassen. Fürs Debuggen wirst du wohl um einen Atmel ICE nicht drumherum kommen.
Angehängte Dateien:
-
20210902_173607.jpg
240 KB
Die Microchip ATmega4809 Curiosity Boards (DM320115) gehen auch hervorragend dafür wenn man nicht gleich soviel Geld für den ICE ausgeben will. Die UPDI Anschlüsse sind herausgeführt und man kann damit auch andere AVR's mit UPDI programmieren und debuggen - aus Atmels Studio7 heraus.
Hallo, ich habe hier auch eine Lösung zum Programmieren via Arduino Nano gefunden: https://www.youtube.com/watch?v=yWb7qHI0YN4 ginge debugging via UPDI nicht auch über Eclipse und dem AVR Plugin? Oder kann gerade dieses kein UPDI?
Hallo, die ElTangas und pyupdi Varianten können den µC nur programmieren. Wobei pyupdi günstig ist, weil an Hardware nur ein Widerstand bzw. Diode und ein USB-Serial-TTL Wandler benötigt wird. ElTangas Adapter ist aufwändiger dafür kann man dann avrdude verwenden. Debuggen funktioniert damit nicht.
Angehängte Dateien:
-
UPDI_Prog.png
120 KB -
20210910_184147.jpg
230 KB
Hier ist noch eine Variante für einen. MicroUPDI Programmer/Debugger - gebildet aus einem Pro Micro (ATmega32U4) mit Zusatzplatine. Zusatzplatine: https://www.tindie.com/products/mcudude/microupdi-programmer/ Hardware: https://github.com/MCUdude/microUPDI Firmware: https://github.com/MCUdude/microUPDIcore Programmieren klappt bei allen, debugging leider nicht bei allen möglich. Zum Bsp. der ATmega4809 geht nicht zu debuggen.
:
Bearbeitet durch User
Hallo, ich bin blöd!!! Ich habe jetzt mal das ElTanga Projekt auf den Arduino Nano gejagt. Das hat auch alles super geklappt! Kann den Atmega4808 auch direkt mit dem Arduino Nano mit AVRdude programmieren. (Nach Austausch der avrdude.config gemäß Eltangas) Nun wollte ich ein bisschen näher ran, also habe ich mir einen Atmel-ICE geliehen und die MPLABX IDE installiert. Leider kann ich mit dem AVR-gcc nicht für den avrxmega3 kompilieren. Wie in diesem Artikel beschrieben, habe ich mir das Atmega Series device support pack geladen. Beitrag "ATmega4808 mit GCC Toolchain" http://packs.download.atmel.com/ Ich nutze eine Ubuntu Linux auf dem System, auf dem das MPLAB läuft. wo finde ich ich diesen verdammten include path? Deswegen mein: Ich bin blöd!!!
Hallo, kann man in MPLAB nicht wie in Atmel/Microchip Studio die Device Packs nachinstallieren? In Atmel/Microchip Studio wäre das unter Tools > Device Pack Manager. Ansonsten ziehe ich die Pfade aus meiner Batch Datei raus wie ich es für die avr-gcc Toolchain für Windows ergänze. Du müßtest dann schauen ob du die Pfade unter Linux findest und hoffen das sie existieren. Ich habe das unter Linux noch nicht probiert.
MPLABX ist nur die IDE. Du brauchst mindestens Version 5.35, am besten die neueste. Dazu brauchst Du dann den XC8 Compiler, der für alle 8 Bit PICs und AVRs ist. Der arbeitet mit dem MPLABX zusammen. Dann sollte das Compilieren klappen. Eventuell muss Du dem MPLABX sagen, wo der XC8 ist. Tools -> Options -> Embedded -> Build Tools, dann Add, und dann das XC8 Bin Verzeichnis wählen. Den Rest erkennt er dann automatisch. An der Stelle könntest Du dann auch einen Fremdcompiler einbinden, aber dafür solltest Du mit dem XC8 erstmal erfolgreich kompilieren und debuggen können. fchk
Hallo, ich habe für alle Fälle die Pfade rausgesucht. Für meine Windows Toolchain ergänze ich aus dem Atmel Device Pack folgende Dateien.
1 | QUELLE: Atmel.ATmega_DFP.1.7.374.atpack\gcc\dev\atmega4808\avrxmega3\ |
2 | ZIEL: avr-gcc Ordner\avr\lib\avrxmega3\ |
3 | Dateien: crt*.o lib*.a |
4 | |
5 | REM ------ FAMILIE: atmega ------ HEADER: iom ------------------------ |
6 | QUELLE: Atmel.ATmega_DFP.1.7.374.atpack\include\avr\ |
7 | ZIEL: avr-gcc Ordner\avr\include\avr\ |
8 | Datei: iom4808.h |
9 | |
10 | REM ------ io.h ergänzen --------------------------------------------- |
11 | #elif defined (__AVR_ATmega4808__) |
12 | # include <avr/iom4808.h> |
Das device spec File nur wenn es fehlt.
1 | REM ------ device-specs ---------------------------------------------- |
2 | QUELLE: Atmel.ATmega_DFP.1.7.374.atpack\gcc\dev\atmega4808\device-specs\ |
3 | ZIEL: avr-gcc Ordner\lib\gcc\avr\x.x.x\device-specs\ |
4 | Datei: specs* |
Zusätzlich habe ich noch die avr-gcc 9.4.0 Version für Linux64 ergänzt so wie ich es bei meiner Toolchain für Windows mache. Meine Batch hat an den Pfaden nicht gemeckert, sollte deswegen passen. Aber ungetestet. Kannste gern ausprobieren. Liegt für kurze Zeit in meiner Dropbox. https://www.dropbox.com/s/c9tierqv4uszneg/avr-gcc-9.4.0_Linux64.zip?dl=0 Damit hättest du eine Toolchain die C++17 komplett unterstützt und folgende Controller zusätzlich unterstützt. Wenn du Lust kannst du das (oder jemand anderes) ausprobieren ob das unter Linux so wie gedacht auch funktioniert. atmega328pb atmega808, 809, 1608, 1609, 3208, 3209, 4808, 4809 attiny202, 204, 212, 214, attiny402, 404, 406, 412, 414, 416, 417 attiny804, 806, 807, 814, 816, 817 attiny1604, 1606, 1607, 1614, 1616, 1617 attiny3216, 3217 attiny1624, 1626, 1627 attiny3224, 3226, 3227 avr128db28, avr128db32, avr128db48, avr128db64 avr64db28, avr64db32, avr64db48, avr64db64 avr32db28, avr32db32, avr32db48
:
Bearbeitet durch User
Hallo, ich habe nun den XC8 installiert und nutze den in der Freeware-Version. spricht etwas dagegen einfach den XC8 zu verwenden? Oder anders: spricht etwas ausdrücklich dafür den avr-gcc zu verwenden? VG
Hallo, verwenden kannst du was du möchtest. Nur ich wüßte nicht warum ich mich in die Fänge von einer Microchip Toolchain begeben sollte. gcc ist komplett offen ohne jede Einschränkung. Allein wenn ich beim XC8 das hier lese "Need to optimize your code-size reduction or get better speed from your project’s software? PRO licenses are available to unlock the full potential of the MPLAB XC C Compiler’s advanced-level optimizations." sage ich nein Danke. Desweiteren gibts lieb gewonnene Features vom gcc wie case range für switch case die nicht im C/C++ Standard stehen. Dann gibts noch als Bonus sowas wie strlcpy_P, was meines Wissens nach avr-gcc speziell ist. Okay, man macht sich damit auch irgendwie abhängig was man woanders nicht verwenden kann, aber dafür mach ich mich gern abhängig, weil das ohne Zwang und ein sinnvolles Feature ist. Kurzum. GCC ist der ganz große Compiler der auch von den ganz dicken Fischen unterstützt wird. Den kennt jeder. Den wird es auch immer geben. Es ist noch nicht lange her da wurde die Unterstützung für avr im gcc gerettet. Dafür war ein größerer Umbau nötig. Da ich sowieso nur 8Bit Atmel/Microchip µC programmiere, sehe ich für mich keinen Zwang so lange es möglich ist auf irgendeine andere Toolchain umzusteigen. Außerdem gewöhnt man sich an etwas, lernst es zu nutzen usw. Vielleicht wird einmal der Tag kommen wo man von Atmel/Microchip Studio auf MPLABX wechseln muss, aber Einbindung einer avr-gcc Toolchain sollte bestehen bleiben. Ist alles meine persönliche Meinung.
Jan Jans schrieb: > ich habe nun den XC8 installiert und nutze den in der Freeware-Version. > spricht etwas dagegen einfach den XC8 zu verwenden? > Oder anders: spricht etwas ausdrücklich dafür den avr-gcc zu verwenden? Die Microchip XC-Compiler (Ausnahme XC8 für PIC) basieren auf älteren gcc-Versionen, die oft kleineren Code erzeugen als die neueren Versionen. Bedenke, dass gcc für AVR quasi ein Abfallprodukt ist, weil gcc eben für 32 Bit Systeme entworfen und optimiert wurde und wird - kleinere Architekturen fallen da ab und an einfach hinten runter. Wenn Du nicht die allerneuesten Compilerfeatures brauchst, bleib beim XC8. Die über 1000 PIC10/12/16/18-Varianten kannst Du dann auch nutzen - einfach so. Und die haben auch ihre Vorteile, insbesondere was die Peripherie angeht. Und wenn nicht, dann weißt Du ja jetzt, wo Du Fremdcompiler einbinden kannst. fchk
Frank K. schrieb: > Bedenke, dass gcc für AVR quasi ein Abfallprodukt ist ... An der Stelle darf laut gehustet werden.
Hallo, ich wollte nun ein paar Gehversuche machen. U.a. ein LCD SSD1306 ansteuern. Habe mir dazu ein Beispiel herausgesucht. https://github.com/Sylaina/oled-display Nun versuche ich es für den ATMEGA4808 zum kompilieren zu bringen :( Es stimmt leider etwas nicht in der i2c.c was unterscheidet denn die "TWI-Register" des ATMEGA4808 von denen der anderen angegebenen Controller, z.B. dem ATmega328? VG
Jan Jans schrieb: > was unterscheidet denn die "TWI-Register" des ATMEGA4808 von denen der > anderen > angegebenen Controller, z.B. dem ATmega328? Ein Blick ins Datenblatt dürfte schnell Erleuchtung bringen. Also ich schau jetzt nicht für dich rein ....
Angehängte Dateien:
-
ATmega4808_TWI_I2C.png
93 KB
Jan Jans schrieb: > was unterscheidet denn die "TWI-Register" des ATMEGA4808 von denen der > anderen > angegebenen Controller, z.B. dem ATmega328?
Jan Jans schrieb: > Es stimmt leider etwas nicht in der i2c.c Was nicht stimmt ist offensichtlich ein sooo grosses Geheimnis dass du es uns nicht verraten willst. Nun, die Hellseher und Geheimdienst-Beschäftigten unter uns sind rar gesät.
Hallo, die Sylaina Lib funktioniert für die aufgeführten Controller die in der i2c.c stehen. Die Lib greift direkt auf die Register zu. Das müßtest du alles abändern. Eine Vorlage kannste dir bei MCUdude auf Github anschauen. https://github.com/MCUdude/MegaCoreX/tree/master/megaavr/libraries/Wire/src Die andere Möglichkeit ist, wenn du direkt programmierst, dich mit der I2C Funktionsweise vertraut zu machen und eine eigene Lib zu schreiben. Das ist die vielleicht ernüchternde Antwort.
Jan Jans schrieb: > Nun versuche ich es für den ATMEGA4808 zum kompilieren zu bringen :( Da hast Du schlechte Karten, weil das Beispiel für den ATmega328 ist. Allgemein würde ich sagen, daß Du für die neuen Typen nur sehr wenige Beispiele finden wirst. Als Anfänger bist Du mit einem klassischen Board (ATmega8..ATmega2560) deutlich besser bedient. Bei den neuen megaAVR0 wurde die Hardware komplett umgekrempelt, da stimmt gar nichts mehr überein. Daher werden bisherige AVR-Programmierer diese nur selten ausprobieren. Oft bleibt man bei den Typen, die man schon gut kennt.
Veit D. schrieb: > Das ist die vielleicht ernüchternde Antwort. Die ernüchternde Erkenntnis daraus ist vielleicht noch: Hat man sich einmal eine Soft-I2C-Implementierung selbst geschrieben hat man a) gut daraus gelernt wie I2C funktioniert und zu bedienen ist. b) eine einfache Möglichkeit seine eigene Kreation mit geringsten Änderungen auf andere Controller-Architekturen anzupassen.
Hallo, ich hätte noch einen Tipp. Wenn du es ganz einfach haben möchtest, dann lädst du einen Bootloader auf deinen ATmega4808. Nimmst die Arduino IDE, fügst das MCUdude MegaCoreX Package hinzu, vorher dessen Doku auf Github lesen! wählst den ATmega4808 usw. aus und nimmst für dein Display die u8g2 Lib. Auch hier Doku lesen. Kannste in der IDE heraus hinzufügen. Wenn du dich reinknien möchtest nimmste den Umweg. @ Schlau Berger: Korrekt. Es ist wie immer, es gibt verschiedene Lösungsansätze. Möchte man nur mal schnell was ausprobieren oder möchte man das hinter den Kulissen verstehen. Letzteres hilft einem für eigene Anpassungen.
:
Bearbeitet durch User
Veit D. schrieb: > ich hätte noch einen Tipp. Wenn du es ganz einfach haben möchtest, dann > lädst du einen Bootloader auf deinen ATmega4808. Nimmst die Arduino IDE, > fügst das MCUdude MegaCoreX Package hinzu, vorher dessen Doku auf Github > lesen! wählst den ATmega4808 usw. aus und nimmst für dein Display die > u8g2 Lib. Auch hier Doku lesen. Kannste in der IDE heraus hinzufügen. > Wenn du dich reinknien möchtest nimmste den Umweg. Das habe ich zuerst gemacht, jetzt wollte ich aber etwas besser verstehen, wie das eigentlich funktioniert. da komme ich dann wohl nicht um das hier drumherum: http://ww1.microchip.com/downloads/en/AppNotes/Getting-Started-with-megaAVR-0-series-00002563B.pdf
Hallo, naja, ich denke zuerst einmal muss die Funktionsweise von I2C verstanden sein. Wenigstens im Groben bis Mittleren. Dafür findet sich Lesestoff von TI und NXP u.v.a. im Netz. Danach brauchste das Manual/Datasheet vom ATmega4808. Die AppNote "AN_1981 - AVR155: Accessing an I2C LCD Display using the AVR 2-Wire Serial Interface" wird auch nützlich sein. Das ist eine allgemeine Beschreibung. Findest du alles auf der Microschip Seite zum Controller unter Documentation. Wenn du noch nie direkt programmiert hast, empfehle ich dir zum warm werden erstmal eine Led blinken zulassen. Damit du einfacher reinkommst wie man die Register und dessen Bits liest und schreibt. Dafür hilft dir dein Link. Vielleicht auch hilfreich sich beim ATmega4809 umzuschauen und die AppNote TB3229 durchzuarbeiten. Danach kannste dich auf die I2C Hardweareinheit stürzen. Du kannst dich auch bei Peter Fleury Seite umschauen. Das Prinzip ist immer gleich. Nur die Register sind bei deinem Controller eben anders und müssen angepasst werden. Leider gibt es kein Getting Started für I2C/TWI direkt für diese Controller Serie. Übrigens, du kannst alle Dokumente, auch das Netz, durchwühlen von der megaavr0 Serie, AVRxDA Serie und AVRxDB Serie. Die sind alle verwandt und die Register zu 99,x% ähnlich.
Angehängte Dateien:
-
Gauge_2.gif
2,4 MB
Wenn du es mal schnell testen willst, ich hatte da mal was in Assembler geschrieben. Das ist eine Simulation eines Rundinstruments. Dieses ändert seine Nadel in Abhängigkeit des ADC Wertes an Port PA5. Belegung: ADC -> PA5 (über Poti) ext.Reset Taster -> PA4 (nicht zwingend erforderlich) I2C SCL -> PA3 I2C SDA -> PA2 Und hier noch den TWI Code - allerdings in Assembler Beitrag "[ASM] TWI im polling für AVR 0-Series und AVR 1-Series"
Hallo, ich möchte mich hier erst einmal bei allen Antwortenden bedanken. "Danke!" Die Abkürzung zu nehmen macht dann doch erst Sinn, wenn man weiß, was man eigentlich gerade umfährt ;) Mal sehen, wann ich auch mal die Zeit habe, mich länger am Stück damit zu beschäftigen. VG
Thread beobachten
Seitenaufteilung abschalten
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.