Atmega8-načítání chybných hodnot z USART (GPS modul)

Zdravim, používam GPS modul a atmega8 spojené sériovkou na určenie polohy, no dnes mi nejakým zvláštnym spôsobom atmelko prestal rozumieť… z GPSky mi chodia data v poriadku(odsledované z hyperterminalu) s parametrami prenosu 9600baud, 1 stop bit, žiadna parita. Atmel dnes však rozoznáva samé nezmysly… čím môže byť spôsobená chybná komunikácia, keď na pin 2 samotného atmelu chodia data v poriadku, no atmel to vidí trochu inak?.. Atmelov USART mám nakonfigurovaný takto:

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

#define FOSC 8000000// Clock Speed
#define BAUD 9600
#define MYUBRR FOSC/16/BAUD-1

ISR(USART_RXC_vect)
{
prijateserial = UDR;
}

void usartinit()
{
/* Set baud rate /
unsigned int ubrr = MYUBRR;
UBRRH = (unsigned char)(ubrr>>8);
UBRRL = (unsigned char)ubrr;
/
Enable receiver and transmitter /
UCSRB = (1<<RXCIE)|(1<<TXCIE)|(1<<RXEN)|(1<<TXEN);
/
Set frame format: asynchronous, no parity, 8data, 1stop bit */
UCSRC = (1<<URSEL)|(3<<UCSZ0);
}

void init()
{

//nastavenie portov
DDRC = 0xFF; // port C vsetky vystupy
PORTC = 0x00; //vsetky vystupy na nulu - niesu pouzite

DDRD = 0x42; // PD7 PD6 PD5 PD4 PD3 PD2 PD1 PD0
// I O I I I I O I
// 0 1 0 0 0 0 1 0
PORTD = 0x00; // vystupy 0 vstupy vyp pullup

DDRB = 0x10; // SPI Port inicializ�cia
// NC , NC, SCK MISO, MOSI, SS , NC, NC
// PB7, PB6, PB5, PB4, PB3, PB2 , PB1, PB0
// I I I 0 I I I I
// 0 0 0 1 0 0 0 0
SPCR = (1<<SPIE)|(1<<SPE)|(1<<DORD)|(0<<MSTR)|(0<<CPOL)|(0<<CPHA);

PORTB = 0xFF; // v�etky vystupy 1, vstupy maj�
// pullup

usartinit();

PORTD |= 0b01000000; //tymto vypnem reset GPS modulu

sei();

}

int main()
{
init();
while(1)
{
_delay_ms(1000);
}
}

:arrow_right: administrator: přejmenováno z "Atmega8 USART problém"

Na PD0 (RXD) máš mít PullUp, místo toho tám máš totem k zemi.
Pokud do GPSky neodesíláš žádné příkazy, tak raději TXEN a TXCIE zruš.
Takže jsi signál kontroloval před nábojovou pumpou.
Zkontroluj to (osciloskopem) raději i za ní…

V programe som spravil nasledovné zmeny:

pred /set baudrate/ som dal vypnutie Sériovej línky
UCSRB = 0x00;

pri inicializácii portov som všetkym vstupom portu D zapol pullup
PORTD = 0b10111101

odstránil som TXEN a TXCIE
UCSRB = (1<<RXCIE)|(1<<RXEN);

tu seriovku som pred nastavenim vypinal, lebo som si uvedomil, že na programovanie týchto atmelov používam programovanie cez seriovku(pomocou bootloaderu v atmele)a tá má iné prenosové parametre.

Teraz … aspoň sa mi zdá, že sa už niektoré (ale je ich velmi málo) znaky prímajú správne… väčšina je nezmyslov…

Na komunikáciu medzi GPS modulom a atmegou ktore su od seba vzdialené pár milimetrov potrebujem nábojovú pumpu? ja to mám z tej GPS na atmel pripojené napriamo… vsetko to funguje na 3.3V… a dost dlho to tak aj fungovalo uz…(len teraz uz z nezistenych pricin nie)… max232 používam len na skúmanie pomocou PC sériovky.

Takže 3,3V logika GPSky?
Já měl GPSku s 12V logikou, ale o to nejde.
Pokud GPSka dává 3,3V signál a procesor deklaruje na vstupu identifikaci log.1 od 3V
(resp. 0,6VCC), jaká je pak šance, že se spolu tyto dvě zařízení nedokáží domluvit?

Odpovím si sám. Malá, ale je. Stačí, když:

1.) Stoupne napájení na procesoru (cca nad 5,5V)
2.) Klesne napájecí napětí na GPSce pod 3,1V
3.) Kombinací předchozích 2
4.) Objeví-li se svod na cestě mezi GPSkou a procesorem
5.) Dál mne nic nenapadá, ale určitě by se ještě neco našlo… :smiley:

ááaha, čim napájíš atmega? máš u napájení kondíky? bylo zařízení přeprogramováváno, než přestalo fungovat? sériová komunikace je někdy duchařina - nemám to teď v hlavě a ani před sebou, ale na 8MHz by se již nějaké chyby pro 9k6 mohly vyskytovat. Můžeš snížit rychlost na 2k4? Zkus dát na sériovou linku mezi mcu a gps nějaký odpor cca 1k.

Práve som to pomeral, napájanie GPS aj atmegy kolíše max medzi 3.30 a 3.31V…stalo sa to pri vývoji Power Supply dosky… dovtedy som to napájal z kontaktného poľa… napájanie potrebujem totiž z auto batérie. DPS som vyrobil, zariadenia k nej pripojil, akutát mi presne táto komunikácia začala blbnúť, keď som zapínanie GPS začal riešiť cez N mosfet oproti zemi. Vyariešil som to teda tak, že N Fetom spínam relé, ktoré prerušuje Vcc GPSky. GPSka potom ešte bez problémov fungovala… medzitým som sa venoval ISP programovaniu atmegy v ovládaní mostefov (na DPS zdroja)… raz som vyskúšal do toho zdroja použiť atmegu z GPS modulu (to znamena že som ju preprogramoval na zdrojovú, ale keďže v zdroji sa jej vďaka bootloadetu nechcelo fungovať, naprogramoval som ju naspäť hexákom z GPS modulu). V GPSke som skúšal aj úplne nový čip s bootloaderom, takže vadným atmelom by to byť nemalo… modul odosiela zistené data caz SPI… keďže čip na druhej strane SPI funguje na 5V, musel som na jeho SPI výstupoch spraviť odporový delič, aby atmega GPS dostavala cca 3.3V logicke impulzy.
Radekpaos, baudrate komunikácie by som musel vždy po spustení prenastaviť v GPSke… a keďže popravde ani neviem akým príkazom to spraviť, bol by som rád, keby fungovalo tých 9600… Na napájaní atmegy mám keramický 100nF kondík… pri každom vstupe / výstupe stabilizatorov v zdroji su kondiky 10nF… navyše som proti kolísaniu na napájanie modulu dal myslím že cca 200uF kondíky… vyskúšam tan 1Kohm… mám ho hodiť normálne do série na komunikačnú línku? (ešte taká blbá otázka, čo to spôsobí)?:slight_smile: (z teorie o RC členoch si pamätám, že by rezistor mal prepúšťať nízke frekvencie… nebude to blokovať tých 9600?)

Ešte menšia perlička z času vývoja DPS… pri testovaní spínania GPS som mal cca pol hodinky najdlhšie spustený v pover supply program, ktorý každých 5s zapol GPS a o 5 sekúnd ju zas vypol. (potom som si uvedomil že to možno GPSke nerobí dobre a odpojil som ju).

fakt je tam ATMega8? Ta má napájení 5V… Máš dobře navrženou DPS z pohledu rušení a pravidel? Ten rezistor může ošetřit některé špičky, které by se tam rušivě mohly objevit (tedy bývá mi to občas doporučováno, já to nedělám:-) ). Koukal jsem ale, že těch změn je tam hodně, od stavu kdy to chodilo do současného. Šel bych cestou:

  1. ATMega8? Zrušit, dát tam Ačkovou nebo Lkovou verzi, která snese nižší napájení
  2. Zkontrolovat DPS
  3. Rezistor na komunikační linku

no a pak by se vidělo. Možná ještě zkus vyměnit i ten kondík. Vůči jaké zemi na ATM8 máš zapojenou zem?

Sorry, za moju trochu zavádzajúcu info. Atmegou8 som samozrejme myslel svoju pouzívanú atmegu8L. Pri snahe identifikovať problém som vyskúšal už aj znova použiť napájanie z kontaktného poľa a zdroja ako predtým… bezvýsledne… idem vyskúšať ten 1K rezistor.

zkus když tak ještě na vstup ATM přivést signál z něčeho jiného, třeba si to jen fakt nerozumí s tou GPSkou (mohlo poklesnou mírně napěti nebo být vyšší a může to dělat takovýto bordel).

Nový zdroj som vyradil uplne z činnosti, zapojil som to k tomu kontaktnemu polu postarom… nepomohlo… GPS a MCU spojena 1Krezistorom… nepomohlo… vyskušam k tomu MCU pripojiť max232 a cez seriovku mu cosi posielat, co bude vidiet takto. (atmegu počas komunikácie s PC pripojím na 5V)

jj, dej pak vědět. Běží atmega na stejném kmitočtu? mimochodem, není v Lku bit na 1/8?

tak tu mam par noviniek.

Atmega bežiaca na 5V nemala problem korektne primat znaky cez usart a posielat ich na SPI… mám ešte aj GSM modul, v ktorom komunikuje rovnakym sposobom a s rovnakym atmelkom mobil. Skúsil som teda pripojiťmobilný Tx do RX v GPS atmege… vysledok… telefon stale a neustale kričal atmege príkaz ATE1… neviem či niečo nestíhalo, alebo ako, občas sa zobrazil divny znak, no v globáli to prímalo správne. pripojil som teda atmegu s5 na 3.3V. Pripjím GPSku… a samozrejme ze sa dostavil rovnaký výsledok ako predtym… GPSka posiela každú sekundu info o pozicii a inych veciach v sekundovych intervaloch… medzi prijmanim datmoze byt max 0.5 sekundy pauza. … pri tomto chaotickom prijme som si pripojil medzi atmela a gpsku este aj ten svoj max na seriovku do pc… a v pc mi samozrejme na rovnakej baudrate aj s rovnakym nastavenim prijmalo vsetko uuuplne spravne… uz naozaj prestavam rozumiet… co moze robit “zrazu” problem prijmat atmelu cez usart na 3.3V logike? keby som atmel nakopol na 5V, mal by byt schopny prijmat spravne 3.3V seriovku? P.S: nepochopil som co si myslel s tym 1/8… atmelko mi ide na 8MHZ(aspon tak su nastavene fuses)

Už mne napadá pouze jedna možnost.
Jako oscilátor používáš vnitřní RC ?
Pokud ano, je možné, že jeho frekvence během času “ujela”.
O další kousek frekvence “ujede” při snížení napájení na 3,3V.
A když k tomu přičteš ještě chybu samotného příjmu,
vyjde ti docela pěkné hausnumero.

Ano, používam vnútrný RC oscilátor. Ako by som mohol čo najjednoduchšie identifikovať či je to spôsobené tým oscilátorom? Skúšal som to aj s druhým atmelom, s ktorým to robilo presne rovnakú chybu… SPI chybovost nevykazuje… no tá je taktovaná od master čipu(ak sa nemýlim). Môžem bez ohrozenia niektoreho čipu vyskúšať spojiť atmel fungujúci na 5V a tou GPS pripojenou na 3.3V?

Tak som to vyskúšal. Atmega na 5V, GPS na 3.3V a čuduj sa svete, sériovka fungovala v pohode… ako by sa to dalo vyriešiť ta, aby mi oscilátor v pohode fungoval aj pri 3.3V? Našiel som v datasheete nejakú kalibráciu osc. no moc to,mu nerozumiem…

Skúsil som pri inicializácii čipu použiť volbu osccal = 0x7F aj volbu 0xFF no bezvysledne… ako zistím skutočnú frekvenciu oscilátora pri napájaní 3.3? ono by mi totiž stačilo predefinovať tú definíciu cpuclock na začiatku zdrojáku:) alebo nie?

no a je frekvence při 3.3V opravdu 8MHz? Mne ještě napadlo, že prostě nestíhá. Nebo jsou logické hodnoty / napěťové úrovně pro ně hraniční a někdy to vyjde, někdy ne. Zkus jinou atmegu.

vsak ale ako zisti pri pouziti interneho oscilarota, ci ma frekvenciu naozaj 8 MHz ? jedine ze by za pouzitia timeru toggloval vystup a sledoval na osciloskope, kolko to procesoru skutocne tvra.

// podla datasheetu je frekvencia vnutorneho RC oscilatora 8MHz pre 5V napajanie a 25 stupnov. pri inom napajacom napäti bude frekvencia rc oscilatora zrejme ina, tak bude treba pouzit bud externy krystal alebo 5V napajanie…

// :smiley: tak som si precital wikipediu a osviezil som si zabudnute vedomosti zo strednej, podla ktorych casova konstanta RC oscilarota od napätia nijako nezavysi :frowning: tak som nakoniec nic podstatne do diskusie nepriniesol :frowning:

Páni, ďakujem Vám, spoločnými silami sme to odhalili:) Keď som zistil , že pri 5V napájaní to atmel zvláda a pri 3,3V to nezvláda, ako napísal radekpaos, atmel proste “nestíhal”… poklesla mu frekvencia interného oscilátora. Program som si upravil, aby vhupol do nekonečnej slučky, v ktorej bude akurát stále dávať na port C striedavo hodnoty 1 a 0… zmeral som to osciloskopom, a zistil som, že pri zapojení na 3.3V frekvencia mierne poklesne. Napadlo ma teda skúsiť mierne “poštelovať” nastavenie výpočtu baudrate. Ako som na začiatku vlákna hodil kód, mám na začitku programu preddefinovanú konštantu pre frekvenciu procesora… mal som tam 8000000… hneď pri prvom pokuse zmien som zaznamenal úspech… hodnota konštanty 7900000 rozbehla sériovku správne aj na 3.3V :slight_smile: Ešte raz diky:)