Werte Community,
Ich habe ein kleines Problem und ersuche eure Hilfe.
Ich bin relativ neu in der avr Welt und versuche mit einem ATTiny1616 zu
starten. Zunächst möchte ich einfach über den USART etwas senden.
Hierzu habe ich mit Atmel Start den USART eingerichtet.
Anschließend sieht meine main relativ simpel aus:
1
#include<atmel_start.h>
2
#include<usart_basic.h>
3
#include<util/delay.h>
4
5
intmain(void)
6
{
7
/* Initializes MCU, drivers and middleware */
8
atmel_start_init();
9
10
/* Replace with your application code */
11
while(1){
12
USART_0_write(55);
13
_delay_ms(1000);
14
}
15
}
Leider empfange Ich weder über RS232 oder Oszi irgendetwas auf dem TX
Port.
Der USART ist wie folgt initalisiert, baud ist 9600:
Tobias D. schrieb:> Kann mir jemand dazu kurz weiterhelfen?
Vermutlich nicht, da keiner weiß, was in den Funktionen wirklich
abläuft, da der Registerzugriff einem ja verborgen bleibt.
Ingo L. schrieb:> Tobias D. schrieb:>> Kann mir jemand dazu kurz weiterhelfen?> Vermutlich nicht, da keiner weiß, was in den Funktionen wirklich> abläuft, da der Registerzugriff einem ja verborgen bleibt.
Hallo Ingo,
deswegen habe ich ja vorher auf Atmel Start hingewiesen.
Die libary die daraus generiert wird ist ja ein " Standard" Teil.
aber um mir weiterhelfen zu können, welche infomrationen brauchst du?
Anbei das projekt gezippt.
Theo F. schrieb:> deswegen habe ich ja vorher auf Atmel Start hingewiesen.> Die libary die daraus generiert wird ist ja ein " Standard" Teil.
Das schon, allerdings nutzen das nur wenige Entwickler. Die meisten
bevorzugen bei 8bit Controllern direkte Registerzugriffe - ist mein
Endruck.
Mit den neuen tinyAVR®1 und dem Atmel Start kennen sich wohl die
wenigsten aus.
Ich hatte bisher keine Notwendigkeit auf die neuen AVR-Familien
umzusteigen, die sind ja bezüglich der Konfiguration um ein deutliches
komplizierter.
Theo F. schrieb:> Anbei das projekt gezippt.
Das USART_0_initialization finde ich darin aber nicht.
Solche Wizzards erzeugen ne ziemliche Menge Holz, da ist schwer
durchzusehen. Daß dann auch noch der Code in viele Unterverzeichnisse
verteilt ist, macht die Sache noch schwerer.
Peter D. schrieb:> Das USART_0_initialization finde ich darin aber nicht.
Sollte eigentlich zu finden sein. Mein Problem ist, dass ich den Attiny
auch für diverse QTouch Projekte nutzen will und spätestens da halte ich
atmel start für sinnvoll.
Kann wirklich keiner weiterhelfen?
Hallo,
wenn ich versuche dein Projekt zu kompilieren erhalte ich folgende
Fehlermeldungen:
1
Severity Code Description Project File Line
2
Error address 0x80380e of USART0.elf section `.data' is not within region `data' USART0 1
3
Error address 0x80380e of USART0.elf section `.data' is not within region `data' USART0 1
4
Error address 0x803814 of USART0.elf section `.bss' is not within region `data' USART0 1
5
Error address 0x803814 of USART0.elf section `.bss' is not within region `data' USART0 1
6
Error ld returned 1 exit status USART0 collect2.exe 0
7
Error recipe for target 'USART0.elf' failed USART0 C:\Users\Devil\Documents\USART0\USART0\Debug\Makefile 247
Atmel Start ist eigentlich nur zur Controller Konfiguration gedacht.
Hast darin ein usart Example gefunden? Ich würde mich erstmal an die App
Notes halten. Auf der Dokuseite vom ATtiny1616 wirst du dann unter
anderem eine "TB3216 - Getting Started with USART" finden.
Peter D. schrieb:> Ich hatte bisher keine Notwendigkeit auf die neuen AVR-Familien> umzusteigen, die sind ja bezüglich der Konfiguration um ein deutliches> komplizierter.
Eigentlich nicht komplizierter, zumindest nicht viel.
Im Wesentlichen halt nur etwas anders. Andere Register (weil effektiv
die XMega-Peripherie) und andere Namenskonventionen für die Symbole. Das
einzige, was die Sache substantiell tatsächlich etwas komplizierter
macht, ist das Portmapping. Das gab's aber teilweise auch schon bei den
"Classic-Tinys", z.B. beim 441/841.
> Zunächst möchte ich einfach über den USART etwas senden.
Dann würde ich jetzt (zähneknirschend) doch einen Schritt zurückgehen
und an PA2 eine LED blinken lassen.
(ich kenne den ATtiny1616 nicht, aber vom ATmega4809 bzw. AVR128DA
schließend (also Xmega-Architektur) sieht das Programm okay aus)
Theo F. schrieb:> So ich habe mich an die Getting started anleitung gehalten, dennoch kein> signal..
D.h. welche Spannung liegt an PA0?
Der Code sieht soweit o.k. aus.
Hast Du keine LED auf der Platine, die man zum Debuggen nehmen kann?
Hier mal ne einfache UART in SW:
1
voidsputchar(uint8_tc)
2
{
3
c=~c;
4
STX_PORT&=~(1<<STX_BIT);// start bit
5
for(uint8_ti=10;i;i--){// 10 bits
6
_delay_us(1e6/BAUD);// bit duration
7
if(c&1)
8
STX_PORT&=~(1<<STX_BIT);// data bit 0
9
else
10
STX_PORT|=1<<STX_BIT;// data bit 1 or stop bit
11
c>>=1;
12
}
13
}
STX_PORT, STX_BIT sind entsprechend zu definieren und den Pin als
Ausgang setzen.
> Ja an PA2 liegt GND
Also klappt schon die Initialisierung nicht. Es sei denn, es liegt ein
Verdrahtungsfehler vor (der sich mit der blinkenden LED feststellen
ließe). Wie sieht es ohne Umlenkung, also mit PB2 als TxD, aus?
Theo F. schrieb:> S. Landolt schrieb:>> PA0? Es geht doch um PA2.>> Tut mir leid, ich habe das überlesen und denke meinem Vorredner geht es> da ebenso. Ja an PA2 liegt GND
Lt. Datenblatt aber PA1.
Danke für das USART0.zip
In AtmelStudio7 kompiliert das Projekt mit avr-gcc9.3.0 und iotn1616.h
von
https://raw.githubusercontent.com/stateos/IntrOS-ATtiny817-Xplained-Mini/master/avr/iotn1616.h
Testen kann ich leider nicht, weil ich den tiny1616 nicht besitze.
USART0.lss und USART0.elf im Anhang.
Mein erster Eindruck:
Für mich ist das ein kompliziertes C-Programm in pseudo c++-style.
also, das Ganze ist doch eher einfach. Eine Library bringt eigentlich
nichts, Flupp - in die Tonne
- Rxpin als Input (DDRx)
- TxPin als Output (DDRx)
- PortControlRegister setzen (Baud, Parity, 2x, ..)
- Baudrate setzen. (BRRH & BRRL)
- auf UART Schreiben (UDRx)
Und dann mit dem Oszilloskop schauen. Dann ist vielleicht die Baudrate
noch falsch.
Hallo,
ich habs mal von meinem ATmega4808 rübergebrochen auf den ATtiny1616.
Usart.0 erstmal auf Standard Pins PB2/PB3 und zusätzlich blinkt an PC0
eine Led oder dergleichen. Wenn Theo nicht an den Fuse gefummelt hat,
taktet der interne 20MHz RC mit Default Prescaler 6, was besagte 3,33MHz
ergibt. Das muss funktionieren wenn alles normal angeklemmt ist. Wenn
das und die anderen Codes nicht funktionieren, dann liegt der Fehler
außerhalb unseres Sichtbereiches. Spätestens dann solltest du den
Blinktakt vermessen. Ub sollten min. 3,3V sein, Abblockkondensatoren
sind hoffentlich dran.
Hallo,
ich vermute er war nur am falschen Pin. Es gibt 4 Gehäusevarianten und
laut Tabelle 5.1 alles an verschiedenen Pins. Reine Spekulation.
Irgendeine kleine Rückmeldung wäre schon schön.
c-hater schrieb:> Eigentlich nicht komplizierter, zumindest nicht viel.
Nö eigentlich eher gleich bis einfacher. UART quasi gleich, bei I2C z.B.
wird einem besser unter die Arme gegriffen. Aber es gibt auch eine
Verschlechterung: Grundsätzlich ist in Peripherie-Interruptroutinen das
entsprechende Interruptflag manuell zurück zu setzen!