www.elektronik.si

[rizzo]

Pozdravljeni. Imam problem pri pošiljanju podatkov po serial portih. Načeloma komunikacija deluje problem nastane v tem ko mi naprava pošlje nek ukaz v mikrokotroler ta zadevo premelje in jo pošlje nazaj v sistem. No tu nastane problem ker v tem času ko mikrokontroler pošlje podatke se oglasi tudi sistem in prav tako pošlje v mikrokontroler podatke.

Gre za enožično komunikacijo ki jo z posebnim vezjem ločim na rx tx. Tako da rx in tx v tem primeru ne moreta istočasno delovati.

Moralo bi delovati tako da ko želim poslati podatke mora mikrokontroler najprej preveriti na rx-u če kaj dobiva če je vse tiho pošlje podatek v sistem.

Baje se da to rešiti z nekimi interupti samo nevem kako. Uporabljam Bascom AVR in pa ATMEGA 32 DIL

[besoft]

Če maš komunikacijo sprejema v interuptu, potem pri pojavu podatka na vhodu postaviš eno zastavico, ki ti v glavni zanki prekine pošiljanje oziroma ti v glavni zanki spremlja dogajanje.
Kako pa ima naprava rešeno? tudi posluša kaj se dogaja na liniji ?

Lahko kaj malo veš napiše ?

[rizzo]

Gre za komunikacijski protokol v vozilu tako imenovan LIN BUS.

Komunikacija po kateri se moduli pogovarjajo in poslušajo po eni žici.

Gre za niz podatkov v hex obliki v katerem je naziv govornika ki pove kateri napravi opravi neko operacijo. Sepravi ko želi neka naprava nekaj povedati preveri linijo če je ta prosta pošlje paket podatkov.

No pri meni je problem ker jaz ne poslusam linije samo posljem v tem casu se pa oglasi neka naprava in se mi nekaj ukazov ne izvede.

Sr pravi rabil bi pred posiljanjem ukaza preverjanje linije ce je ta prosta.

[frenki]

V naslovu teme malce zavajaš. V tem primeru gre sicer res za serijski prenos podatkov, je pa na LIN vodilu kar natančno definiran protokol prenosa in struktura podatkovnih paketov. Brez upoštevanja specifikacije ne bo šlo. Prilagam specifikacijo vodila, kjer je sam protokol natančno opisan.

[rizzo]

Že samo me zanima kako bi spisal program da ko se nekaj na RX vhodu v mikrokontroler nekaj dogaja da takrat ne pošilja po TX.

Skratka pred pošijanjem bi moral preveiti na RX če so kakšni podatki po LIN-busu če jih ni pošlje...

[besoft]

Na forumu je kar nekaj primerov kako izvest komunikacijo z interuptom..ko to imaš, preverjaš če je v sprejemnem buferju kaj ..ali je prazen. V kolikor je prazen lahko delaš kar koli, v primeru, da se v buferju kaj pojavi pa pač prekineš ostali del programa in poslušaš..

Čeprav priporočam, da preštudiraš link do specifikacij protokola.

[rudiP]

tu imaš nekaj osnov serijske komunikacije.

http://www.elektronik.si/phpBB2/viewtopic.php?t=13792

[stursc]

Nerazumljiva dogajanja so me pognala po pomoč.
Za spremljanje programa imam SW-UART. Na testni plošči je vse delovalo.
Ko sem vse prenesel na delovno ploščo, tukaj sem moral zaradi razporeda zamenjati pin
za SW_UART (prej je bil na pinb.6 , sedaj na pina1).
Vse lepo deluje dokler imam konektor programatorja na pinih delovne plošče, ko snamem
konektor programatorja, SW-UART neha delovati, ostali del programa deluje b.p.
Pametne ideje več nimam, zato prosim za kak komentar, ki bi me približal rešitvi


Hvala

LP, stursc

[protoncek]

Jaz bi najprej dal kakšen pull-up ali pull-down upor. Itak ga je dobro imeti, da ne vleče preveč motenj.

[stursc]

Da se malo dopolnim
Vsi pini imajo zunaje pullup 10K upore. Poskušal sem zmanjšati pullup na 5K, razlike ni.
Potem sem odstrali pullup upor, razlike ni.
Vrnil sem se nazaj na testno ploščo in ugotovil enako stanje, namreč na testni plošči (minipin) ni bilo potrebe odstranjevati programatorja in teh težav nisem opazil. Sedaj sem tudi na testni odstarnil programator (COM kabel) in terminal na SW UART ne dela več. Če priklopim programator nazaj na COM port, SW-uart spet normalno izpisuje.
Nadaljnih idej mi je zmanjkalo (vsaj za danes). Premeril sem morebitne slabe povezave, predvsem GND, vse OK.

Vsakega pregloga, komentarja bom vesel, predvsem, ker sem tak sistem komunikacije že uporabil in še danes deluje, tukaj se je pa nekaj zapletlo.


LP, stursc

[protoncek]

Daj ledici na TX in RX, da vidiš, ali kaj utripajo v enem in drugem primeru.
Pa poskusi dati upor na maso (pull-down). Probat ni greh...
A ostalo pa dela? Da ni AVR v stanju reseta ? (daj upor z reseta na maso) na en pin sprogramiraj utripanje ledice, da vidiš, če AVR sploh teče. Jaz sem imel bogate težave na EasyAVR, ko se mi je na 3.3V po cca 15 sekundah AVR ustavil. Na koncu sem ugotovil, da progrmator nekako na polovico potegne reset gor, ravno dovolj, da se ustavi. Dodatni pull-down upor je pomagal...

[vilko]

Torej, če je komunikacija obojesmerna in ni nekoga, ki bi upravljal promet na liniji, je potrebno predvideti, da pride do čim manj kolizije - zaletavavanja telegramov na liniji, to se zgodi, ko več udeležencev linije želi oddati podatke.

Kot vidim iz sheme, (Lin2.1book stran 111) lahko iz ene žicel ločiš TX in RX signala

Sam uporabljam dvožično RX485 komunikacijo na sledeč način:

RX vežem izključno na hardware uart RX. Ta omogoča serial interrupt.
V serial interrupt rutini lovim bajte iz linije in sestavljam telegram, podatek v spremenljivko tipa string.
Ko ugotovim, da je telegrama konec, prenesem cel string v drugo polje, da s tem sprostim prvi string za sprejemanje novih podatkov. Postavim zastavico glavnemu programu, da obdela podatek.
Pri sprejemu vsakega bajta rx interrupt rutina postavi števec časa na nič.
Ta števec časa poriva naprej timer prekinitveni podprogram, tako vem, koliko časa je bila na liniji tišina, ni nihče nič oddajal.

Pri pošiljanju podatkov v linijo, najprej čakam neko slučajnostno vedno drugo število - čas. Na samo oddajanje bajtov grem šele, ko ugotovim, da je bila na liniji tišina toliko časa, kot je generator slučajnih števil predlagal za to oddajo.

Kolizija telegramov s tem ni izključena, a s pravilnim uglaševanjem je verjetnost kolizije tako majhna, da je zadeva uporabna.

[stursc]

Hvala za vse komentarje, vsak je dobrodošel.
Napako se odkril naključno, slaba masa na vmesniku, ki ga sicer uporabljam že 3 leta.
Se zgodi, da moraš kaj popraviti za sabo. Torej komunikacija deluje in sedaj lahko ugotavljam tudi druge napake.
Takoj sem ugotovil naslednjo napako (povezano z komunikacijo).
Ta je sigurno "softwerska", vendar še nisem našel rešitve, namreč gre za sistem in povezavo z GSM modulom TC35 in ATmega 32.
Kaj se dogaja? Modulu pošljem SMS z vsebino za opravljeno delo. SMS je vredu prebran, zahtevana naloga se izvede OK, potem gre program v podprogram brisanje SMS sporočila (Bascomaši vedo, da je to ukaz AT+CMGD=id_sms)
Problem je le brisanje tega sporočila po izvedeni zahtevi.
Da bi se prepričal o kompatibilnosti ukaza, sem dodal tipko za prehod v ta del podprograma, ki ob prehodu dejansko zbriše določeno sporočilo.
Ukaz (gosub brisi_sms) po izvedeni zahtevi SMS sporočila, ki jo solidno opravi, sicer gre v sam podprogram (vidno iz izpisa podatkov), vendar sporočila ne briše.

Nabiram si šele izkušnje z tem modulom, zato so vaše izkušnje dobrodošle.


Hvala za sodelovanje

LP, stursc

[arksi]

[stursc]