Hallo,
ich muss auf dem Attiny841 die REMAP Möglichkeit nutzen.
Anstatt PA4 - PA7 nutze ich HW SPI auf PA0 - PA3.
Das hat auch soweit geklappt.
1
#define SPI_REMAP
2
3
#define SPI_DDR DDRA
4
#define SPI_PORT PORTA
5
6
#ifdef SPI_REMAP
7
#define SPI_SCK PORTA3
8
#define SPI_MOSI PORTA1
9
#define SPI_SS PORTA2
10
#else
11
#define SPI_SCK PORTA4
12
#define SPI_MOSI PORTA6
13
#define SPI_SS PORTA7
14
#endif
15
16
inlinevoidspi_init(void)
17
{
18
#ifdef SPI_REMAP
19
REMAP|=(1<<SPIMAP);
20
#endif
21
22
SPI_DDR|=(1<<SPI_SS)|(1<<SPI_MOSI)|(1<<SPI_SCK);
23
SPI_PORT|=(1<<SPI_SS);
24
SPCR=(1<<SPE)|(1<<MSTR);
25
SPSR|=(1<<SPI2X);
26
}
27
28
// Assumed state before call: SCK- Low, MOSI- High
29
voidspi_write(uint8_tc){
30
SPDR=c;
31
while(!(SPSR&(1<<SPIF)));
32
}
Jedoch habe ich das Problem, dass ich nun RXD1 und TXD1 auf PA4 und PA5
nicht nutzen kann. In der main rufe ich vorab spi_init auf. Damit das
Remap vor der UART kommt. Am Uart kommt jedoch nichts an. Nun ist an den
Pins PA4 und PA5 auch noch der ATMEL-ICE angeschlossen zum
Programmieren. Hab ihn abgezogen, aber keine Reaktion.
Nun werde ich aus dem Datenblatt an einem Punkt nicht ganz schlau. In
der FeatureList werden 2 Full-Duplex USARTs angegeben
sowie ein SPI
Gehe ich der Annahme richtig, dass ich eigentlich USART1 (PA4/Pa5)
eigentlich nutzen könnte, wenn ich SPI auf die vorderen 4 Bits mappe?
Stefan S. schrieb:> Nun werde ich aus dem Datenblatt an einem Punkt nicht ganz schlau. In> der FeatureList werden 2 Full-Duplex USARTs angegeben> sowie ein SPI
Das verstehe ich nun nicht. Feature Liste hin oder her. Das Ding hat 1x
SPI und 2x USART. Aber es sollte klar sein, dass man mangels Pinanzahl
nicht alle Features des Bausteins GLEICHZEITIG nutzen kann.
Im Abschnitt IO Ports und dort unter "Alternative Port Functions"
findest du ALLE Funktionen die ein Portpin haben kann. Inkl. den
mappbaren.
Im USART und im SPI Abschnitt wird nochmal tabellarisch die REMAP
Funktion beschrieben und da steht genau welcher Pin welche Funktion hat.
Wenn es da Überschneidungen gibt, dann geht halt nicht beides.
Ich verstehe also das Problem jetzt nicht. Muss man sich jetzt an deiner
Stelle durch das Datenblatt lesen um dir zu bestätigen oder zu
widerlegen dass deine gewünschte Kombi tut?
> Gehe ich der Annahme richtig, dass ich eigentlich USART1 (PA4/Pa5)> eigentlich nutzen könnte, wenn ich SPI auf die vorderen 4 Bits mappe?
Schau halt nach!
Hallo Cyblord,
das habe ich gemacht.
Demnach kann ich USART1 nutzen, wenn ich die Alternative Portfunktion
(REMAP) nutze. Jedoch bekomme ich dann keinen USART-In/Output mehr. Die
Leds blinken nicht. Hatte den Atmel ICE angetöpselt, jedoch wieder zu
einem Test abgezogen. Kann der Atmel ICE da überhaupt "zwischenfunken",
oder bleibt der für die Restliche Schaltung unsichtbar?
Bei dem Atmel mkII war immer das Problem, dass er den Reset betätigt
hat, sobald er nicht mehr an USB angeschlossen war.
So irgendwie geht das ganze dann doch nicht ;(
Ich habe jetzt mal die Files in ein zip gepackt. SPI ist noch nicht
einmal initialisiert. Habe jetzt einfach nurmal testweise beide UARTs im
Einsatz. UART0 geht ohne Probleme. Bei UART1 kommt garnichts raus oder
rein.
Die Attinys, die ich hier rumliegen hab, haben lediglich die AVR
Grundschaltung.
- VCC / GND mit 100n Kerko entkoppelt
- 10k PullUp an Reset
- Pins direkt rausgeführt
Habe jetzt mehrere getestet, es kommt nichts. Ich weiß, dass ich die
Schnittstelle schon einmal im Betrieb gehabt habe, jedoch existiert da
kein Code mehr von.
RX/TX vertauscht habe ich ebenfalls bereits überprüft. Früher kam über
die UART1 Schnittstelle ein Datenwirwar, wenn ich am flashen war (zu
vermuten bei ISP).
Vorher habe ich das mit dem mkII gemacht. Der ist derzeit aber verlegt,
und mache das mit dem Atmel-ICE über ISP. DebugWire brachte aber auch
keine Ergebnisse.
Ich habe auch bereits testweise das Adapterkabel vom Atmel ICE
herausgezogen.
Edit:
Das ist der alte Thread bei den ersten Tests mit dem alten Code
Beitrag "ATtiny841 : UART0"
Da ging es aber um UART0, welcher "Probleme" gemacht hat.
Was haben denn jetzt eigentlich die UART und SPI Probleme mit dem
Programmer zu tun?
Irgendwie gehst du doch völlig falsch an die Sache ran. Wenn du eine
UART in Betrieb nehmen willst, dann schaue doch ob es funktioniert in
dem zu sie z:B. mit einem USB-TTL Adapter mit dem PC verbindest und per
Terminalprogramm sehen kannst, was passiert. Oder du schaust mit einem
LA drauf.
Den UART in Betrieb zu nehmen ist doch wirklich SIMPELST. Du stellst mit
TXEN und RXEN das Ding an. Stellst mit UBRR die Baudrate ein (mittels
setbaud.h noch einfacher) und kannst dann sofort mit dem Schreiben auf
UDR loslegen. Wenn du dann noch davor jedes mal auf UDRE prüfst, ob das
vorherige Byte raus ist, wird's noch besser. (Registernamen bitte selber
nachschlagen).
Und wenn das für UART0 oder UART1 unremappt klappt (verifiziert durch
obige Methoden), dann kannst du REMAP mal versuchen.
Und dafür hält man das Programm MINIMAL. Config des UART und in einer
Schleife wird ein Byte rausgeschrieben. Bevor das bei dir nicht
zuverlässig klappt kannst du alles andere vergessen. Ich weiß auch nicht
warum man dann hier dauern vom mkii und vom Atmel ICE und von debugWire
lesen muss. Was hat das alles mit deinem Problem zu tun?
Geht mal etwas gezielt an die Problemlösung und mische nicht alles
durcheinander.
@Cyblord, ich ging davon aus, dass der Programmer, solange eingesteckt
ist, die Signale "drückt". Ist aber nicht der Fall. An die UART
Schnittstellen habe ich schon die USB_TTL Adapter drangemacht. Hast du
dir den Anhang angeschaut, da war eigentlich alles gemacht, was du
geschrieben hast.
@Karl, ein explizites Makefile hab ich nicht. Ist mit AS7 erstellt.
F_CPU ist in Symbols der Toolchain auf F_CPU=8000000 gesetzt. Eine UART
funktioniert ja.
Ideen:
- Vielleicht sicherheitshalber das PRR – Power Reduction Register
beschreiben. Sollte aber defaultmäßig keine Probleme machen. Man muss
explizit Module deaktivieren.
- Evtl. ein Problem mit den Fuses, da die Pins (PA4 & PA5) auch zum
Programmieren genutzt werden? Vielleicht musst du SPIEN rausnehmen, dann
kannst du aber nicht mehr per ISP programmieren...
Ich meine da hätte ich mal was gelesen, konnte es aber gerade im
Datenblatt nicht verifizieren.
Bernd schrieb:> Ideen:> - Vielleicht sicherheitshalber das PRR – Power Reduction Register> beschreiben. Sollte aber defaultmäßig keine Probleme machen. Man muss> explizit Module deaktivieren.
Humbug. Wie du schreibst, PRR ist defaultmäßig 0. Da ist nichts
eingeschaltet bzw. keine Module abgeschaltet.
> - Evtl. ein Problem mit den Fuses, da die Pins (PA4 & PA5) auch zum> Programmieren genutzt werden? Vielleicht musst du SPIEN rausnehmen, dann> kannst du aber nicht mehr per ISP programmieren...
Humbug hoch 3. SPIEN muss man natürlich nicht abschalten.
> Ich meine da hätte ich mal was gelesen, konnte es aber gerade im> Datenblatt nicht verifizieren.
Bitte erst nachschlagen, und dann erst Unsinn empfehlen.
ISP Programmer und UART tun sich normalerweise nichts. Den UART kann man
mit Serienwiderständen etwas entkoppeln, zur Sicherheit. Am ehesten geht
das ISP Programmieren nicht mehr, wenn die UART Gegenstelle ihren TXD
Pin auf einen Pegel zieht.
Praktisch jeder ISP Programmer von Original bis billigst, schaltet sich
nach dem Programmiervorgang hochohmig. Zum Test reicht ein Rausziehen
des Programmiersteckers bei Problemen.
Habe den Code noch nicht anschauen können.
Aber läuft dein Controller überhaupt? Blink-LED an weiterem Port könnte
darüber was aussagen. Und dann kannst du auch gleich den Takt
verifizieren.
Spannungsversorgung nachgemessen?
Welchen (Ruhe-)Pegel weißt dein TXD Pin am Tiny auf?
Wie geschrieben waren es nur Ideen denen der Threaderöffner nachgehen
könnte.
Aber das man hier einen drüber gebügelt bekommt ist ja mittlerweile
"normal".
Mit ISP habe ich auch noch keine Probleme im Zusammenhang mit dem UART
gehabt, aber mit JTAG sind schon viele darauf hereingefallen. Habe da im
Datenblatt zu gesucht, aber bin mir da nicht ganz sicher gewesen, weil
ich das nur so kenne, dass sich MISO mit TXD einen Pin teilt und MOSI
mit RXD.
Da kam mir auf PA4 SCK und RXD komisch vor.
Man könnte es ja ausprobieren, ob es daran liegt. Es bleibt ja immer
noch Debugwire. Und das bei so kleinen Käfern nicht alles gleichzeitig
geht, ist nicht selten.
Pin ISP UART1
PA6 MOSI
PA5 MISO TXD1
PA4 SCK RXD1
Cyblord -. schrieb:> ISP Programmer und UART tun sich normalerweise nichts. Den UART kann man> mit Serienwiderständen etwas entkoppeln, zur Sicherheit. Am ehesten geht> das ISP Programmieren nicht mehr, wenn die UART Gegenstelle ihren TXD> Pin auf einen Pegel zieht.> Praktisch jeder ISP Programmer von Original bis billigst, schaltet sich> nach dem Programmiervorgang hochohmig. Zum Test reicht ein Rausziehen> des Programmiersteckers bei Problemen.
Das einzige Problem, was mir bekannt ist, mit den orginal mkII ist, dass
sobald ich den USB Stecker herausziehe(das 6pol. Kabel aber noch
verbunden ist), der ATtiny nicht aus dem Reset kommt. Das lässt sich
beim mkII dadurch beheben, dass man nicht nur USB trennt. Beim Atmel-ICE
hatte ich das Problem nicht.
> Habe den Code noch nicht anschauen können.>> Aber läuft dein Controller überhaupt? Blink-LED an weiterem Port könnte> darüber was aussagen. Und dann kannst du auch gleich den Takt> verifizieren.> Spannungsversorgung nachgemessen?> Welchen (Ruhe-)Pegel weißt dein TXD Pin am Tiny auf?
EXTENDED = 0xFF (valid)
HIGH = 0xD4 (valid)
LOW = 0xC2 (valid)
Der Attiny841 läuft mit der internen 8MHz. Blink-Led war schon dran, hat
auch funktioniert. Die andere UART Schnittstelle läuft ohne Probleme.
Hallo Bernd, JTAG am Attiny gibt es nicht. Ich habe es mit ISP als auch
DW getestet. In Verbindung mit dem mkII lief es auch schonmal, siehe
Link oben von mir, auch wenn da der Code minimal anders war.
Habe bereits ein paar der Teile ausrprobiert, um einen Bauteil/Lötfehler
auszuschließen. PA4 und PA5 sind sicher rausgeführt. Habe an beiden eine
Led angebracht und diese zum blinken gebracht, ohne die UART Funktion.
Thread beobachten
Seitenaufteilung abschalten