[AVR/C++] Uart probleem

[Damic]

Heb hier een gps module aan een avr (at90can64 xtal 8.000MHz) hangen en krijg de data binnen via uart0, deze steek ik via interrupt direct richting UDR1 (dit als echo) maar dan krijg ik niet wat ik van de gps module ontvang te zien op Realterm.

Als ik de Txd van de gps module direct uitlees krijg ik het volgende:

quote: ansi

$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,00*79
$GPGLL,,,,,,V,N*64
$GPRMC,,V,,,,,,,,,,N*53
$GPVTG,,,,,,,,,N*30
$GPGGA,,,,,,0,00,99.99,,,,,,*48

zoals je kunt zien heb ik geen fix maar krijg ik wel data binnen en het volgende ontvang ik op de uart1

quote: ansi

€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€
€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€
€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€
€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€
€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€
€€€€€€€€€€€€€€€€€€€€€€€€€€€€

Als melding bij RealTerm krijg ik Framing Error.

De uart lib dat ik gebruik is van hier tezamen met de NMEA lib: https://code.google.com/p...gps-library/uart/uart.cpp

mon code:

C:

#define F_CPU 8000000UL 
#include <avr/io.h>
#include <util/delay.h>
#include <compat/twi.h>
#include "uart.cpp"
#include "nmea.cpp"

NMEA nmea;
UART usart0,usart1;

ISR(USART0_RX_vect)
{
    nmea.fusedata(UDR0);
    PORTC |= _BV(PC1);//put led on when receiving data
    usart1.Send(UDR0);
//UDR1=UDR0;
}

int main(void)
{
    CLKPR=0x80;
    DDRC=0b00000010;
    PORTC=0x00;
    usart0.Init(0,9600,true);
    usart1.Init(1,9600,true);
   while(1)
    {
if((1<<UDRE0) || (1<<RXC0) ){PORTC &= ~_BV(PC1); }//put led off when data is received
    }
}

Iemand een idee in welke richting ik moet zoeken?

Dank bij voorbaat Damic

[ Voor 3% gewijzigd door Damic op 28-12-2014 10:05 ]

[Radiant]

Bij veel AVRs zit er achter de UDR-registers een FIFO waardoor je hem maar één keer kan uitlezen. Stop UDR0 eens eerst in een lokale variabele?

[Damic]

Dat was het origineel en hetzelfde resultaat.

Zelfs als je gewoon "hello world" in send() zet dan komt het niet aan zoals het moet, dus ik weet het niet echt meer

[ Voor 58% gewijzigd door Damic op 28-12-2014 10:08 ]

[brambo123]

Denk dat Radiant dit bedoelt:

C:

ISR(USART0_RX_vect)
{
    volatile char c = UDR0;
    nmea.fusedata(c);
    PORTC |= _BV(PC1);//put led on when receiving data
    usart1.Send(c);
}

[Damic]

En ik bedoel het ook anders origineel is het

C:

ISR(USART0_RX_vect){
        volatile char c = UDR0; //Read the value out of the UART buffer
        nmea.fusedata(c);
}

maar zelfs als ik het volgende doen, dan komt het niet aan

C:

ISR(USART0_RX_vect){
        volatile char c = UDR0; //Read the value out of the UART buffer
        nmea.fusedata(c);
usart1.send("hello world");
}

[Radiant]

Er klopt overigens wel meer niet..
- Je zet interrupts aan voor UART1 maar declareert er geen functies voor; in een gunstig geval plaatst je compiler "RETI"-instructies in de interrupt vector tabel waardoor het goed gaat, maar vaak niet en dan reset je programma of krijg je ongedefinieerd gedrag.
- De if in je mainlus doet niks want UDRE0 en RXC0 zijn gewoon constantes die je moet checken in een ander register. Bit RXC0 ga je ook nooit zien in je mainlus want de interruptfunctie is veel sneller

De manier waarop je de prescaler schrijft klopt ook niet (ik ga er vanuit dat je op de interne 8MHz van de controller wil draaien en geen externe klok) en dat is mijn volgende verdachte; de datasheet van je controller zegt:

Bit 7 – CLKPCE: Clock Prescaler Change Enable
The CLKPCE bit must be written to logic one to enable change of the CLKPS bits. The CLKPCE
bit is only updated when the other bits in CLKPR are simultaneously written to zero. CLKPCE is
cleared by hardware four cycles after it is written or when CLKPS bits are written. Rewriting the
CLKPCE bit within this time-out period does neither extend the time-out period, nor clear the
CLKPCE bit.

To avoid unintentional changes of clock frequency, a special write procedure must be followed
to change the CLKPS bits:
1. Write the Clock Prescaler Change Enable (CLKPCE) bit to one and all other bits in
CLKPR to zero.
2. Within four cycles, write the desired value to CLKPS while writing a zero to CLKPCE.
Interrupts must be disabled when changing prescaler setting to make sure the write procedure is
not interrupted.

Wat je dus moet doen is:

code:

CLKPR = 0x80;
CLKPR = 0x00;

Werkt dat niet meteen, laat dan eens een ledje knipperen op 1 sec en check of dat klopt op het oog, dan kan je fouten m.b.t. je kloksnelheid in ieder geval uitsluiten.

[Damic]

Interrupt uart1, staat nu af.
Dat ledje in de while() flikkerd
Ja die prescaler is voor de oled (u8glib) en dat klopt, was vergeten dat er bij te zetten, maar het werkte wel, draai trouwens op een kristal zodus extern.

[Radiant]

Ja, hij flikkert, maar niet om de reden dat je denkt dat hij flikkert

Als je een kristal gebruikt, heb je dat ook zodanig ingesteld in de fuses van de controller met je programmer? Als dat daar al goed staat kan je die hele CLKPR gewoon weglaten.

Maar dan nog steeds; vage tekens op UART is 9/10x verkeerde baudrates of klokproblemen, dus check eens of je klok echt goed is (dus LEDje togglen op 1 sec).

Als je een scope of logic analyser tot je beschikking hebt kan je ook je AVR eens een stroom van 0xAA laten versturen en daarmee checken of je baudrate klopt.

[Damic]

Wel asjemenouw ding draait niet op xtal

[Super_ik]

Radiant schreef op zondag 28 december 2014 @ 11:28:
Als je een scope of logic analyser tot je beschikking hebt kan je ook je AVR eens een stroom van 0xAA laten versturen en daarmee checken of je baudrate klopt.

de hooftletter U is daar handig voor, dat is 0x55.
Voor een mooie blokgolf om je baudrate na te meten kun je makkelijk dit doen:

C:

usart1.send("UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU");

[Damic]

grbml en ik denk dat ik met juist heb buitengesloten uit de avr

[Matis]

Je gebruikt de termen UART en USART door elkaar.
Weet je wel wat de verschillen zijn en wat je er mee impliceert?

Heb je ook de levels gecontroleerd? Is het TTL of RS 232. Met andere woorden; tussen 0V en Vcc of postieve en negatieve spanning voor een respectievelijke logische 0 of 1.

[Damic]

Levels zijn ttl, vermits ik een TTL/usb converter gebruik. En usart = uart maar dan met een syncro optie die op kan zetten.

[Radiant]

Damic schreef op zondag 28 december 2014 @ 12:28:
grbml en ik denk dat ik met juist heb buitengesloten uit de avr

Als dat gebeurd is nadat je de clockfuses hebt gewijzigd is er iets niet goed aan je kristalopstelling of je hebt de verkeerde fuses gekozen (external clock is iets anders dan external crystal of external full swing oscillator).

[Damic]

Ja de instellingen zijn nogal logisch, een 1 moet een 0 zijn en daarmee blijkbaar de ISP afgezet en jtag heb ik niet liggen.

Komt wel goed eerst jtag programmer nodig