Atmega32 Uart met interupt lukt niet

[Anoniem: 414228]

Beste tweakers

ik ben bezig met een Atmega32 programeren en ik wil wat experimenten uitvoeren.
hiervoor wil ik eerst een uart verbinding maken met mijn laptop.

zonder interupt is het mij al gelukt zowel RX als TX maar met interupt lukt het mij gewoon niet.
iemand sugesties ?

C:

#include <avr/io.h>
#include <avr/interrupt.h>

#define F_CPU 8000000
#define BAUD   38400   // F_CPU is 8000000 Hz
#define UBRR_VALUE ( ((F_CPU) + 8UL*(BAUD)) / (16UL*(BAUD)) - 1UL )


void uart_init(unsigned int ubrr) 
{
  UBRRL = ubrr;
  UBRRH = (ubrr >> 8);
  UCSRC = _BV(URSEL)|_BV(UCSZ1)|_BV(UCSZ0); // 8 N 1
  UCSRB = _BV(RXEN)|_BV(TXEN)|_BV(RXCIE);
}

ISR(USART_RXC_vect)
{
  char data;

  data = UDR; // ontvang byte
  UDR = data; // verstuurde byte 
}

int main(void)
{
  uart_init(UBRR_VALUE);
  sei();

  while(1) {}
}

voor suggesties :
- ik heb intern osc. 8 mhz (DUBBLE CHECK)
- connectie is goed, dus het is software

[ Voor 10% gewijzigd door Anoniem: 414228 op 08-07-2011 03:19 ]

[houthakker]

als polled wel lukt, zou ik zeggen dat het niet ligt aan je UART instellingen.

gebruik je winavr/avr-gcc of avrstudio?

weet je zeker dat USART_RXC_vect goed is? daar krijg je geen compiler fout op?
misschien kun je in de will pollen of er wel data ontvangen word (alsnog polled)

[Infant]

Wachten kan nooit kwaad.

C:

    data = UDR; // ontvang byte
    while !(UCSRA & (1<<UDRE));
    UDR = data; // verstuurde byte 

Alleen UBRRL inladen met 12 in jouw geval?

[Anoniem: 414228]

houthakker schreef op donderdag 07 juli 2011 @ 23:14:
als polled wel lukt, zou ik zeggen dat het niet ligt aan je UART instellingen.

gebruik je winavr/avr-gcc of avrstudio?

weet je zeker dat USART_RXC_vect goed is? daar krijg je geen compiler fout op?
misschien kun je in de will pollen of er wel data ontvangen word (alsnog polled)

pollen is ook een optie voor mij maar ik heb veel liever interupts, dat maakt mijn code veel overzichterlijker

ik heb nog niet echt een een goede manier bedacht hoe ik de USART_RXC_vect kan testen.
ik heb tot nu toe een led blink in mijn MAIN laten draaien en dan iets versturen naar mijn atmega.

vervolgens stop de led blink ermee.
dus er is een teken van leven. maar ik krijg geen reactie terug.
het lijkt er een beetje op dat hij de UDR niet leeg schrijft

[Anoniem: 414228]

Infant schreef op vrijdag 08 juli 2011 @ 02:03:
Alleen UBRRL inladen met 12 in jouw geval?

klopt maar ik laat het liever uitrekenen als het kan.
baud 38.4k
ubbr 12
err 0.2%
8 mhz

Infant schreef op vrijdag 08 juli 2011 @ 02:03:
Wachten kan nooit kwaad.

C:

    data = UDR; // ontvang byte
    while !(UCSRA & (1<<UDRE));
    UDR = data; // verstuurde byte 

kan je deze interupt soort wel wachten op dat de UDRE vrij is ?

ik ga het morgen ochtend proberen

[Stoney3K]

Kijk ook even of je Global Interrupt Mask goed staat: Als de USART_RXC interrupt gemaskeerd staat kun je natuurlijk wachten tot je een ons weegt.

[houthakker]

Anoniem: 414228 schreef op vrijdag 08 juli 2011 @ 03:04:
[...]


pollen is ook een optie voor mij maar ik heb veel liever interupts, dat maakt mijn code veel overzichterlijker

ik heb nog niet echt een een goede manier bedacht hoe ik de USART_RXC_vect kan testen.
ik heb tot nu toe een led blink in mijn MAIN laten draaien en dan iets versturen naar mijn atmega.

vervolgens stop de led blink ermee.
dus er is een teken van leven. maar ik krijg geen reactie terug.
het lijkt er een beetje op dat hij de UDR niet leeg schrijft

klinkt alsof de boel crashed om dat de processor niet naar de goede interrupt handler jumpt

[Anoniem: 414228]

houthakker schreef op donderdag 07 juli 2011 @ 23:14:
gebruik je winavr/avr-gcc of avrstudio?

WINAVR/AVR-GCC gebruik ik

[Anoniem: 414228]

enig idee hoe ik dat kan testen ?

houthakker schreef op vrijdag 08 juli 2011 @ 09:32:
[...]


klinkt alsof de boel crashed om dat de processor niet naar de goede interrupt handler jumpt

[Sphere-]

Anoniem: 414228 schreef op vrijdag 08 juli 2011 @ 12:00:
enig idee hoe ik dat kan testen ?

[...]

De eerste n bytes van de SRAM staan de interrupt vectors.
Deze kan je terug vinden in de datasheet.

Je kan met JTAG een breakpoint zetten (indien je JTAG gebruikt).
Anders kan je eventueel in assembly de interrupt vectors die je niet gebruikt naar een eigen functie zetten.

Indien hij inderdaad naar de verkeerde interrupt vector jumpt is USART_RXC_vect wellicht niet de juiste.
De vectornamen voor eenzelfde soort interrupt kunnen verschillen tussen verschillende devices, alhoewel als de headers goed zijn opgezet hij op device type filtert en je niet zomaar de verkeerde zou kunnen gebruiken.

[ Voor 20% gewijzigd door Sphere- op 08-07-2011 12:57 ]