Linux seriovy port

[Ladislav Vaiz]

Jeste me napada, ze se mi v linuxu nezdala kotrola parity. Myslim, ze se pres ioctl da nastavit znak, co se posle v pripade chyby parity. Zkuste zapatrat, tohle v hlave nemam.
Co na sbernici nasadit nejaky sniffer?
L.

--
Stručně naklofáno na mobilu

-----Original Message-----
From: Jaroslav Buchta <jaroslav.buchta na hascomp.cz>
To: hw-list na list.hw.cz
Sent: po, 30 bře 2020 18:14
Subject: Re: Linux seriovy port

Dekuji za informaci,
Zajimave je, ze mi prijde, jako by se ztratily nejake znaky - treba 
tohle, odpoved na zapis 4 registru, az po adresu to sedi ale pocet je uz 
posunuty. Ale zase je divne, ze celkovy pocet znaku asi prijde, protoze 
jinak by to vypadlo na timeout. Na strane slave (STM32) problem 
nepredpokladam, pres jiny port to stejnym zpusobem komunikuje s PC a 
bezi to dny bez problemu.

ERROR CRC received 0xAF8F != CRC calculated 0xAC8C
msg [8]: 01 10 9C 44 04 00 AF 8F

Je pouzity  tento projekt https://github.com/stephane/libmodbus , uz 
jsem to pridal ve zdrojacich abych to mohl ladit ale nejak uplne 
korektne mi ta RTU komunikace udelana neprijde - treba neresi 
meziznakovy timeout atd. Nepouzil to nekdo z vas, ze by mel nejake 
zkusenosti?

Dne 30.03.2020 v 15:53 Ladislav Vaiz napsal(a):
> Dne 30.03.2020 v 15:16 Jaroslav Buchta napsal(a):
>> Takze v principu muzou 2 aplikace otevrit jeden port zaroven?
>
> Ano, zamykání v linuxu je dobrovolné. Vždyť stačí fork() a hned jsou 
> všechny soubory otevřené vícekrát. Sériák se zamyká souborem 
> /var/lock/LCK..ttyS1 .
>
>> Ono to tim ale asi nebude, ta druha aplikace pouziva komunikaci jen v 
>> pripade, ze dela reset modemu a to je velmi sporadicky - ta funguje 
>> stylem open-w-r-close. Podle logu casy nekoreluji s chybami.
>
> Pak to tím zřejmě nebude.
>
>> Jeste uplne nechapu API funkci select, ta skonci pri prichodu jednoho 
>> a vice znaku nebo zadanem timeoutu? 
>
> Přesně tak plus dále
>
>> Kdy vznikne chyba EINTR?
>
> Proces dostal signal. Jaký vám řekne program strace (strace program 
> nebo za běhu strace -p PID)
>
>> A rset je nejake bitove pole se seznamem periferii na ktere se ceka?
>
> Ano
>
> https://linux.die.net/man/3/fd_set
> https://linux.die.net/man/2/select
>
> L.
>
>> Pouzita je takto:
>>     while ((s_rc = select(ctx->s+1, rset, NULL, NULL, tv)) == -1) {
>>         if (errno == EINTR) {
>>             if (ctx->debug) {
>>                 fprintf(stderr, "A non blocked signal was caught\n");
>>             }
>>             /* Necessary after an error */
>>             FD_ZERO(rset);
>>             FD_SET(ctx->s, rset);
>>         } else {
>>             return -1;
>>         }
>>     }
>>
>>     if (s_rc == 0) {
>>         /* Timeout */
>>         errno = ETIMEDOUT;
>>         return -1;
>>     }
>> #endif
>>
>>     return s_rc;
>>
>>
>>
>> Dne 30.03.2020 v 14:29 Ladislav Vaiz napsal(a):
>>> Hádal bych, že problém bude čtení z portu - data dostane vždy právě 
>>> jedna aplikace a to bude ten problém. Lepší by bylo udělat nějakou 
>>> proxy, která bude znát Modbus.
>>>
>>> L.
>>>
>>> Dne 30.03.2020 v 14:20 Jaroslav Buchta napsal(a):
>>>> Takova zasadni otazka - lze otevrit port napr. /dev/ttyS1 zaroven z 
>>>> vice aplikaci? Predpokladam, ze ne ale chova se to divne jako by 
>>>> ano (je to embeded system na ARM) Zase ale vzhledem k tomu, ze se 
>>>> rychlost a dalsi parametry nastavuji az po otevreni, tak mi neni 
>>>> jasne, kdy vlastne k fyzickemu otevreni HW portu dojde?
>>>>
>>>> Je to modbus-rtu komunikace jako master, pouzivaji ji 2 aplikace, 
>>>> jedna velmi sporadicky a druha by mela mit port otevreny stale (tu 
>>>> momentalne ladim, ta druha je trosku black box). Zda se mi divne, 
>>>> ze by to fungovalo, kazdopadne ta hlavni aplikace s castou 
>>>> komunikaci nekdy hlasi chybu - bud CRC nebo neshoda cisla funkce, 
>>>> prijata data v bufferu nedavaji smysl, jedine, co me jeste napada, 
>>>> ze by si do komunikace nejak vzajemne kecaly... 
>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list


_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20200330/796692a1/attachment.html>