Hallo zusammen, das Datenblatt des atmega4809 hat mich etwas aufhorchen lassen, sind dort doch einige interessante features drin. Allerdings ergeben sich für mich die folgenden Fragen: 1) Programmierung über UPDI UPDI wird ja von avrdude unterstützt. Reicht es, einen USB/Seriell-Wandler zu verwenden und TX an den UPDI-Pin anzuschließen? 2) CPU-Core der 0-Serie Wird der vom gcc unterstützt? Etwa als atxmega? Danke für jeden Hinweis!
:
Raoul D. schrieb: > UPDI wird ja von avrdude unterstützt. Reicht es, einen > USB/Seriell-Wandler zu verwenden und TX an den UPDI-Pin anzuschließen? Vermutlich nicht. Oftmals lässt sich der TX Pin nicht auf "Empfang" umstellen. UPDI ist AFAIK bidirektional. Damit es einigermaßen sicher funktioniert sollte man einen der Programmer/Debugger verwenden der UPDI nativ unterstüzt.
Jim M. schrieb: > Raoul D. schrieb: >> UPDI wird ja von avrdude unterstützt. Reicht es, einen >> USB/Seriell-Wandler zu verwenden und TX an den UPDI-Pin anzuschließen? > > Vermutlich nicht. Oftmals lässt sich der TX Pin nicht auf "Empfang" > umstellen. UPDI ist AFAIK bidirektional. Ja stimmt. Es gibt etwa: https://github.com/mraardvark/pyupdi Dort ist es dargestellt. > Damit es einigermaßen sicher funktioniert sollte man einen der > Programmer/Debugger verwenden der UPDI nativ unterstüzt. Würde das auch mit avrdude so wie oben bei pyupdi funktionieren?
Der Atmega4809 ist ja genial! Wie oft hab ich mir das schon gewünscht, ein kleiner CPLD in einem AVR Mikrocontroller. Gibt es ein empfehlenswertes Entwickler Board?
Thomas W. schrieb: > Der Atmega4809 ist ja genial! Finde ich auch ;-) > Wie oft hab ich mir das schon gewünscht, ein kleiner CPLD in einem AVR > Mikrocontroller. > > Gibt es ein empfehlenswertes Entwickler Board? Die curiosity-boards von microchip.
Wilhelm M. schrieb: > Die curiosity-boards von microchip. Oh danke. Die sind ja sehr günstig. Hab gleich zwei Boards geordert. Warum ist das Explain 4 mal so teuer als das Nano? Es hat doch quasi den selben Funktionsumfang? Bis auf die Selektion der Spannung 5V / 3,3V. Lustig finde ich, dass der Programmer/Debugger auf dem Board ein 32 bitter ist. Der 32 bitter ist nur dazu da den 8 bitter zu bedienen … Sogar eine virtuelle COM Schnittstelle. Alles da … Die 20Mhz macht der 4809 auch selbst??? Warum hat man das nicht schon bei den alten Atmega so gemacht? Bin schon echt gespannt auf das Board. :-)
Thomas W. schrieb: > Wilhelm M. schrieb: >> Die curiosity-boards von microchip. > > Oh danke. > Die sind ja sehr günstig. > Hab gleich zwei Boards geordert. > > > Warum ist das Explain 4 mal so teuer als das Nano? welche hast Du denn jetzt? Es gibt das Nano und eins mit WiFi drauf. > Die 20Mhz macht der 4809 auch selbst??? Ja, hat einen internen Taktgenerator von 20MHz. Ich finde die megaAVR-0 Serie mit 3208/4808/4809 auch ganz klasse.
Raoul D. schrieb: > 1) Programmierung über UPDI Es gibt auch solche Lösungen: https://www.elektormagazine.com/labs/arduino-for-updi-programming-for-atmega4809-and-tiny816817-with-jtag2updi
Wilhelm M. schrieb: > welche hast Du denn jetzt? > > Es gibt das Nano und eins mit WiFi drauf. Ohne Wifi Gestern habe ich ein ATmega4809 Curiosity Nano Evaluation kit und ein ATmega4809-XPRO bestellt. Es soll angeblich schon Ende nächster Woche da sein … … schauen wir mal.
Hallo, hast du bei Microchip direkt bestellt? Kommt zu den angezeigten Preisen noch Steuer und Versand hinzu?
Ja direkt bei Microchip. Ich habe Promo Codes eingegeben, die ich im Netz gefunden habe. Es kam zwar eine Fehlermeldung, aber es hat keine Versandkosten berechnet.
Hallo, habe nun auch bestellt. Nach gültigen Code muss man aber lange suchen. Mit Free Shipping ging gar nichts, alles veraltet. Aber ein 25% Rabattcode funktionierte genau für das Nano Board. NANOHOLIDAY (soll bis 20.2.19 gültig sein)
Der 4809 ist soooo genial! Ich bin begeistert! Dabei war ich echt skeptisch, als Atmel übernommen worden ist. Übrigens gibt es jetzt auch einen Arduino im UNO Format mit einem Atmega4809. Der hat sogar das Wifi Shield schon integriert! Hab ich mir jetzt auch mal bestellt zum genauer anschauen.
:
Bearbeitet durch User
Hallo, war auch erst am überlegen ob Arduino UNO WiFi Rev2 oder das Nanoboard hier. Da ich Wifi nicht benötige und beim Uno viele Pins ungenutzt bleiben bzw. sowieso durch die onboard Erweiterungen aufgebraucht werden, war für mich das Nanoboard die bessere und billigere Wahl. Was haste denn schon alles angestellt mit dem Teil, weil so begeistert bist?
Veit D. schrieb: > Was haste denn schon alles angestellt mit dem Teil, weil so begeistert > bist? Begeistern kann man sich bereits über die vielen potentiellen Möglichkeiten! Gerade im Vergleich zu den alten Megas. Beachtenswert und fast genauso vielseitig sind auch die neuen Tinys (1614/1616)!
Dieser ach-so-bewunderte mega 0 ist einfach ein leicht verbesserter xmega. Und wenn ihr das damals schon gepeilt hättet, hätte Atmel damals auch mehr von diesem Wunderchip absetzen können und wäre wohl auch nicht so leicht übernommen worden.... Ich setze seit Jahren nur xmegas ein. Vor allem die E Serie hat wahre Zauberfeatures. Zum Beispiel eine 120nA RTC, die den µC aufwecken kann.
Oder der xmega A mit EMI, der so 16 MB externes RAM einbinden kann, auf das man dann einfach via ld, st, etc. drauf zugreifen kann, als wäre es fest eingebaut. Gerade für Logginganwendungen mit grafischer Darstellung ein must have.
Aber das kann man jetzt ja alles vergessen, weil Microchip die xmega Preise so hochgeschraubt hat, dass jetzt jedes neue Projekt NICHT mit diesen gemacht werden soll, weil es einfach andere (PICs) gibt, die das gleiche zum halben Preis liefern. Dankeschön.
Genervt schrieb: > Dieser ach-so-bewunderte mega 0 ist einfach ein leicht > verbesserter > xmega. Nein. Mehr als das. Besonders punktet der neue Mega gegenüber den alten Xmegas mit erweitertem Versorgungsspannungsbereich bis 5V und modernerem UPDI Interface mit nur einem Pin. Getoppt nur von den verwandten, gut vom Bastler lötbaren 1614er Series 1-Tinys mit noch viel weniger Platzbedarf. Sogar mit doppelter Anzahl ADCs. Segensreich bei beiden auch die deutlich erweiterte Auswahl interner Referenzspannungen. Und, und, und... > Ich setze seit Jahren nur xmegas ein. Vor allem die E Serie hat wahre > Zauberfeatures. Zum Beispiel eine 120nA RTC, die den µC aufwecken kann. Absolut. Zu ihrer Zeit und bis heute hervorragend. Mittlerweile eben nur mit reichlich (je nach Anwendung übermächtiger) Mega/Tiny Konkurrenz. Für manche Instruktion benötigen die sogar weniger Takte. Brauchst nicht "genervt" darüber sein. Ist doch gut wenn die AVRs so erfrischend weiterentwickelt werden und die neuen leistungsfähigen so günstig zu erwerben sind. XMegas setz ich heute nur noch ein wenn ich sehr viele (serielle) Schnittstellen, Speicher und Pins brauche.
:
Bearbeitet durch User
Hallo, mein erstes ATmega4809 Curiosity Nano Board ist tot. Gestern noch damit hantiert. Rechner runtergefahren, heute wieder hochgefahren, wird nicht mehr erkannt. Auch die grüne Power LED nahe Stecker ist aus. Neues Board angesteckt - geht. Sehr seltsam.
Beitrag #5728720 wurde von einem Moderator gelöscht.
Beitrag #5728736 wurde von einem Moderator gelöscht.
Veit D. schrieb: > mein erstes ATmega4809 Curiosity Nano Board ist tot. Oje, wahrscheinlich einfach nur Pech. meine beiden Boards und auch das 4809 Arduino Board arbeiten tadellos. Hat es den ARM erwischt oder den Atmega?
Hallo, Kurzantwort: es war die onboard Sicherung, gleich nach der USB Buchse. neues Thema So langsam werde ich warm mit dem 4809. Die grundlegenden Timer Konfigurationen sind verstanden. USART klappt auch soweit. Dabei fiel mir jedoch auf das man die Namen der Register wie im Manual angegeben nicht mehr wie gewohnt (328P, Mega2560, ATtiny841) verwenden kann. Ein Register namens CTRLA gibts bspw. mehrfach bei verschiedenen Hardwareeinheiten. Timer, ADC, USART. Hier sind die Registeradressen (Offset) im Manual allerdings bei vielen gleich mit 0x00. Außer beim USART-CTRLA steht 0x05. Schaut man jedoch in die iom4809.h stehen völlig andere Adressen dahinter. Etwas weiter davor stehen Moduladressen für die Hardwareeinheiten. Beides (+Offset) wird scheinbar addiert um letztlich an das richtige Register zugelangen. Nur wo finde ich im Manual die Beschreibung wie sich all die Adressen zusammensetzen? Von den Moduladressen habe ich noch nichts gelesen. Mir gehts nur ums Verständnis wie sich was zusammensetzt. Verwenden tue ich weiterhin die Namen wie in der iom4809.h definiert. Noch eine Frage. Hat schon jemand probiert die USB Verbindung vom Curiosity Nano Evalboard als serielle zubenutzen? Damit man an die USART Pins keinen externen Wandler ranbammeln muss. Quasi wie beim Arduino. Oder ist die Verbindung rein zum flashen und debuggen gedacht?
Veit D. schrieb: > Schaut man jedoch in die iom4809.h stehen völlig andere Adressen > dahinter. Etwas weiter davor stehen Moduladressen für die > Hardwareeinheiten. Beides (+Offset) wird scheinbar addiert um letztlich > an das richtige Register zugelangen. Nur wo finde ich im Manual die > Beschreibung wie sich all die Adressen zusammensetzen? Bei mir Kap. 6.1 im Manual zur megaavr0-Serie
Ohne einen Großkunden dahinter hätte Micrchip die niemals auf den Markt geworfen. Vor allem nicht, wenn man mal quer auf die ATSAMC20G16A schielt, um jetzt mal beim gleichen Gehäuse, nur etwas mehr Speicher und vom gleichen Hersteller zu bleiben. Wenn man von einem Mega328/324/1284 kommt sind die "megaAVE 0-series" erstmal reichlich fremd, was sich vor allem auch in den Includes und entsprechend wie man Programme schreibt spiegelt: ADC0_CTRLA = ADC_ENABLE_bm; Ich sage ja nicht, dass die 0-series irgendwie schlecht wäre, im Gegenteil, ich finde die auch interessant. Aber irgendwie kann ich keinerlei Vorteile gegenüber zum Beispiel den ATSAMC20 entdecken. Und wenn man sich eh schon neu einarbeiten muss, warum das nicht auch gleich mit einem dicken Upgrade verbinden? Also wenn man jetzt mal so Dinge in den Raum wirft wie das man beim AS7 bleiben und den Atmel ICE weiterhin verwenden möchte.
Hallo, es wird immer Alternativen geben. :-) Wenn man sich durch die Definitionen gewühlt hat wirds leichter. Man muss nur aufpassen zwischen den Getting Started.pdf's und den Code Bsp. Da wird gern _bm und _bp vermischt. Mich würde generell interessieren ob ihr die Atmel Start Konfiguration verwendet? Die hatte ich bisher noch nie benötigt. Aktuell verwende ich diese nur für die Mainclock Grundkonfiguration. Ansonsten weiß ich nicht so recht ob das weitere Vorteile bringt. Konfiguriert man weitere Hardwareinheiten bekommt man einen Rattenschwanz Libs hingeklatscht und muss sich erstmal dort durcharbeiten wo was nun konfiguriert ist und welche Namen die benötigten Methoden haben. Da kommt man doch besser man schreibt es gleich selbst? Damit hat man weniger Lib Kaos. Habe aktuell den TCA0 Splitmodus durch. Geile Sache, nur wofür verwendet man sowas in der Praxis? Zwei unabhängige Frequenzen die zueinander nicht syncron takten. Selbst die 3 Compares takten nicht syncron zueinander. Man hat also auf einen Timer 6 PWM Kanäle mit 2 Frequenzen und kann 6 verschiedene Duty-Cycle einstellen. Alle takten nicht syncron und haben kein Compare Buffer. Nur für die 3 Kanäle die auf den low Bytes liegen hat man paar Steuermöglichkeiten wie ISR/Flag. Wofür könnte man das in der Praxis gebrauchen?
Beitrag #5739643 wurde vom Autor gelöscht.
Angehängte Dateien:
-
TCA0_splitmode_a.png
19 KB -
TCA0_splitmode_b.png
19 KB -
TCA0_splitmode_c.png
18 KB
Hallo, muss mich korrigieren, sie takten doch alle syncron, auf fallende Flanke, hatte mich schon gewundert. Bei unterschiedlichen "lower"/"higher" Byte Frequenzen bleiben die jeweiligen 3 compares syncron.
Hallo, der zugehörige Code ist vielleicht auch nicht falsch. :-) Einstellungen sind vom letzten Bild. Wie schon gesagt, ich nutze Atmel Start zur 10MHz MainClock Konfiguration und dann der Inhalt der main.c Nur wofür kann man das verwenden? Die 3 Compares vom lower Timer mit wenigen Steuermöglichkeiten würde noch Sinn machen. Vielleicht für Motoren? Dagegen wüßte ich nicht wofür man die unflexiblen higher Timer und dessen Compares verwenden könnte. Ohne Steuermöglichkeiten laufen die eigentlich in fester Einstellung.
:
Bearbeitet durch User
Angehängte Dateien:
-
TCA0_splitmode_CCL.png
26 KB
Hallo, und noch mit der CCL rumgespielt. :-) Folgende Ergänzung zur obigen main.c. Damit schaltet PA6 wenn alle 3 lower compares High sind. Vielleicht hilft es jemanden für den Einstieg. Ich habe solche Beispiele gern.
1 | void CCL0_LUT0_init(void) |
2 | {
|
3 | CCL.LUT0CTRLB = CCL_INSEL0_IO_gc; // pin LUTn-IN0 input source, PA0 |
4 | CCL.LUT0CTRLB |= CCL_INSEL1_IO_gc; // pin LUTn-IN1 input source, PA1 |
5 | CCL.LUT0CTRLC = CCL_INSEL2_IO_gc; // pin LUTn-IN2 input source, PA2 |
6 | |
7 | CCL.TRUTH0 = 128; // Wahrheitstabelle > AND |
8 | |
9 | PORTMUX.CCLROUTEA = 1; // Portmux output PA3 > PA6, Manual 14.3.2 |
10 | CCL.LUT0CTRLA = CCL_OUTEN_bm; // enable Output LUT0 |
11 | CCL.LUT0CTRLA |= CCL_ENABLE_bm; // enable LUT0 |
12 | |
13 | CCL.CTRLA = CCL_ENABLE_bm; // enable CCL module |
14 | }
|
15 | |
16 | |
17 | void Port_Init(void) |
18 | {
|
19 | PORTA.DIR |= PIN0_bm; // set PA0 as output |
20 | PORTA.DIR |= PIN1_bm; |
21 | PORTA.DIR |= PIN2_bm; |
22 | PORTA.DIR |= PIN3_bm; |
23 | PORTA.DIR |= PIN4_bm; |
24 | PORTA.DIR |= PIN5_bm; // set PA5 as output |
25 | |
26 | PORTA.DIR |= PIN6_bm; // set PA6 as output for CCL |
27 | }
|
Raoul D. schrieb: > 2) CPU-Core der 0-Serie > > Wird der vom gcc unterstützt? Etwa als atxmega? Müsste ab v8 möglich sein mit -mmcu=avrxmega3. http://gcc.gnu.org/gcc-8/changes.html#avr Unterstützung für die Devices gibt's noch nicht, d.h. man brauch eigene Specs, Header, CRT und Device-Lib. Flash ist an anderer Stelle im RAM-Adressraum sichbar (0x4000 statt 0x8000), d.h. beim Linken muss man Symbol __RODATA_PM_OFFSET__ anpassen, etwa mittels Linker-Spec:
1 | *link_arch: |
2 | %{mmcu=*:-m%*} --defsym __RODATA_PM_OFFSET__=0x4000
|
Johann L. schrieb: > Raoul D. schrieb: >> 2) CPU-Core der 0-Serie >> >> Wird der vom gcc unterstützt? Etwa als atxmega? > > Müsste ab v8 möglich sein mit -mmcu=avrxmega3. Und für ältere Versionen als v8 mit -mmcu=avrxmega2, der Core den Atmel angedacht hatte (für die ähnlichen ATtiny814 etc.) Dann sollte man allerdings unbedingt ein eigenes Linker Skript verwenden, das .rodata ins Flash lokatiert:
1 | ... |
2 | __RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ? __RODATA_PM_OFFSET__ : 0x4000; |
3 | ... |
4 | .text : |
5 | {
|
6 | ... |
7 | } > text |
8 | .rodata ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ : |
9 | {
|
10 | *(.rodata) |
11 | *(.rodata*) |
12 | *(.gnu.linkonce.r*) |
13 | } AT> text |
14 | .data : |
15 | {
|
16 | /* No .rodata in .data! */ |
17 | ... |
Falls man die crt*.o selbst assembliert, ist darauf zu achten, dass die .vectors-Einträge für Devices <= 8KiB nur 2-Byte-Einträge sind, was für kleine Devices wie ATtiny814 etc. wichtig ist (avrxmega2 geht von Flash > 8KiB aus => JMP/CALL wird unterstützt => avr-libc schließt daraus, dass IRQ-Vektoren 4 Bytes lang sind). Die Device-Pakete, die man im Web findet, sind wahrscheinlich für avrxmega2 übersetzt. Falls man GCC v8 einsetzt, möchte mal aber auf jeden Fall avrxmega3 verwenden; keine Ahnung wie man das am besten löst... Der Eintrag im specs-File ist schnell geändert, allerdings ist die Architektur im elf-Header des Object-Files crt<device>.o eingetragen, und der Linker meckert, wenn man versucht, Objects unterschiedlicher Cores gegeneinander zu linken[*]. Es bleibt einem dann nichts anderes übrig, als die crt*.o selbst für avrxmega3 zu übersetzen (Verfügbarkeit von CALL/JMP wird in v8+avrxmega3 per -m[no-]short-calls erreicht). [*] Bisher hab ich noch nicht gesehen, dass jemand dieses Problem mit den crt.o hatte, liegt aber vielleicht daran, dass nur wenige diese neuen Devices mit v8 + avrxmega3 einsetzen.
:
Bearbeitet durch User
Ich habe gcc-9.0.1. und xmega3 und den crt*.o aus dem Atemel-Pack, die sind avrxmega3.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.