[elektro] PIC Soros port induláskor szemetel

[elight]

Köszi a segítséget.
Az adatirány és portbeállítás már próbáltam többféle
módon és az időzítésekkel is eljátszadoztam.
Mivel ez INT -es hardveres 3 szintű bufferes
módszerrel ad, (ez pont egy újítása amitől félek)
teszegettem be a küldött bájtok közé mindenhol
100uSec-es  ( +1 stop bit) időzítéseket is.
Az elején meg mikrokontrolleres léptékben
  jó nagyot várok. 200mSec az indulásig,
és a Uart_init után is van 10mSec.
Egyébként szünetek meg vannak bőven a sorok között.  Másodpercenként max 
3 rekord megy kis és
rekordonként is várok 5-10 msec-et.
A baudrétet felvittem 19k és 57k-ra.
Ezeken a sebességeken  is ugyanaz
az indulási  bizonytalansági a helyzet.
Más régebbi típussal ez a módszer
szerintem  lazán, rég működhetne stabilan.

A probléma lényegi része pont az,
hogy ha ellépve indul akkor már
sajnos soha nem jön rendbe.
Csak a következő resettel!
Vagyis úgy sem, mert random módon
hol jól indul és úgy is marad mindvégig
vagy tolja a szemetet folyamatosan.
Ha csak nagy ritkán kimaradozna
és rögtön helyre jönne
az már nem annyira érdekelne,
mert akkor  a hibajavító kód hamar
helyrehozhatná.

Ezekből a tesztekből  származik
az esetlegesen indulási rossz baudrate gyanúm.
De ezt még  bizonyítani kellene.

Ezért is helyből osztanám a Pipi véleményét!
Hagyjam  is a francba,  és az UART-nál is
írjam meg a saját módszeremmel
ezt a könyvtári függvényt.
Üdv István




2019-05-09 19:44 keltezéssel, Nemeth Tibor írta:
> Hali!
>
> Nem tudom jogos elvárás-e, hogy reset alatt ne történjen semmi a 
> lábakon. A soros átvitel természetéből adódik, hogy ha szünetmentesen
> küldesz adatokat és elcsúszás történt, akkor addig nem kerül 
> szinkronba az adó és a vevő, amíg legalább egy byte-nyi, esetedben 
> 10*1e3/9600=1.0417ms időtartamnyi szünet elő nem fordul.
> A legelső adatátvitel megkezdése előtt iktass be 2ms semmittevést. 
> Lehet, hogy ekkor is lesz egyetlen byte (framing erroros) vétel, de 
> utána a teljes üzenetnek helyesen meg kell érkeznie.
>
> A konkrét típus ismeretének hiányában nem tudom, de lehet, hogy 
> fölösleges az adatirányt beállítani, hiszen átadod a lábat a 
> perifériának. Esetleg hagyd ki ezt a lépést egy próbára.
>
> Üdv.
>                    Németh Tibor
>
>
> 2019.05.09. 16:56 keltezéssel, elight írta:
>> Sziasztok.
>>
>> Most először próbálom a 18F45K42
>> UART1-ét életre bírni..
>> Ez a PPS kialakítású lábkiosztás kicsit megtréfált,
>> de már úgy néz ki azt egészen uralom.
>>
>> TX jelem C7 láb és jelenleg csak adni szükséges..
>>
>> Tettem felhúzó ellenállás kívülről a C7-re
>> Inicializálom a C portot,
>> LAT_C7 = 1 ( Hi szint a sorosnak)
>> Beállítom a C7 adairányt Outputra
>> A jelem kifele Hi szintű.
>> PPS beállításával átadom a C7 vezérlését a TX reg-nek.
>>
>> Inicializálom a soros portot a
>> UART1_Remappable_Init(9600);
>>      // 9600 Baud, alap átvitel vezérlés
>>
>> Kiadok egy stringet, mondjuk  "Hello world!"
>> Uart1_Remappable_Write( 'x' ); parancsok használatával.
>> + (CR)  + (LF).
>>
>> Az a tapasztalatom ahogy   a Terminal
>> programot olvasgatom:
>> A RESET gombot nyomogatva
>> az esetek felében jól jeleni meg a string
>> a másik felében valamiféle pár karakter hosszú
>>   szemét kerül a felirat helyett képernyőre.
>>
>> Nézegetem, de tanácstalan vagyok.
>> Esetleg találkoztatok már hasonló jelenséggel?
>>
>> Szkóppal is nézegettem és még
>> nem találtam zavaró  tüskét a jeleben.
>> Este majd előásom az analizátort is..
>> Egyébként olyan mintha a baudrate
>> némelyik induláskor elugrana,
>> vagy a többszintű bufferből némi
>> egyéb bit  valahogy kicsoroghatna.
>>
>> 18F45K22 -vel tucat hasonló átvitelt elkövettem,
>> ott még nem találkoztam hasonló hibával.
>>
>> Üdv István.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>>
>> ---
>> Az e-mailen az AVG vírusellenőrzést végzett.
>> http://www.avg.com
>>
>>
>
> -----------------------------------------
>          elektro[-flame|-etc]
>