Linux seriovy port

Pondělí Březen 30 20:37:20 CEST 2020

Zamykani je dobrovolne, aplikace musi soubor testovat a sama odmitnout otevrit port.
Jeste zkuste sudo lsof /dev/ttyS1, jestli si ho neotevrel nekdo dalsi.
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 19:08
Subject: Re: Linux seriovy port

Jeste jeden dotaz - zkousel jsem vyvorit odpovidajici soubor ve 
/var/lock po spusteni aplikace s cislem procesu (mezery, cislo, nl - 
celkem 11 znaku jak jsem nasel) a nezabranilo to pouziti portu kdyz jsem 
znovu spustil aplikaci v jine konzoli. To takto nefunguje?
Jina aplikace uz tam ma odpovidajici soubor pro modem.
Zda se, ze ale ucinkuje API fce flock(...)

Dne 30.03.2020 v 18:14 Jaroslav Buchta napsal(a):
> 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

_______________________________________________
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/b3b9c197/attachment.html>