On 2013-12-13 20:46, Sylwester Łazar wrote:
>> Przychodzi kod d'12' i wyświetla mi się 1.bmp
> Wyświetla full screen na ekranie.
> Nic więcej nie trzeba.

No więc propozycja napisana na kolenie w 10 minut:

plik start.sh
----------------
#!/bin/bash

DEVICE=/dev/ttyUSB0

stty -F $DEVICE raw speed 9600 >/dev/null

while [ 1 ]; do
ASCII=`dd if=$DEVICE count=1 2>/dev/null | od -t d1 | awk '{print $2}'`
COMMAND=`grep $ASCII: config | cut -d' ' -f2-`
echo $COMMAND
$COMMAND &
done
---------------

plik config
---------------
97: echo "hello"
98: echo "world"
99: display image.jpg
---------------

Wyjaśnienie:
a) plik start.sh działa w nieskończonej pętli czytają pojedyncze bajty z
$DEVICE.
b) bajt jest zamieniany na reprezentacje decimal (polecenia od i awk)
c) w pliku "config" wyszukiwany jest ciąg znaków <liczba>: polecenie
d) wykonywane jest polecenie

i to wszystko. plik start.sh należy zmienić na wykonywalny: chmod +x
start.sh

Plik config zawiera więc pary liczba:polecenie

Jako przykład masz tam polecenie display. Pochodzi z pakietu imagemagick
i wyświetla po prostu obraz fullscreen (wymaga parametrów zeby ładnie
wyświetlić, ale ja leniwy jestem, w kazdym razie działa i pokazuje plik
image.jpg na pełnym ekranie, sam sobie dopieść).

Przed odpaleniem tego skrytpu w systemie muszą być awk, imagemagick. W
debian-like wystarczy apt-get install awk imagemagick. W slacku nie
wiem, nie mam.

Oczywiście po odpaleniu chciłbyc zapewne aby nastepne polecenie zamknelo
obraz. Można to zrobić np. za pomocą killall. Napisz czy dziala a potem
zobaczymy co dalej.

do góry

Bardzo Dziękuję!
Sprawdzę jutro (niektóre dzieciaki już jednak śpią) i napiszę jak działa.
Ja to taki szybki nie jestem :-)
Pozdrawiam,
S.

do góry

On 2013-12-13 22:18, Bo t manager wrote:
>> A konkretnie tak:
>> socat -x TCP4-LISTEN:2000,nodelay,fork
>> /dev/ttyS1,raw,echo=0,crnl,b57600,cs8
>> Od tej pory RS232 jest na porcie tcp 2000 i mozna połaczyć się z nim
>> byleczym, poczynając od telnetu.
> A to nie lepiej
> cat /dev/cośtam > cośtam.txt i i dalej w bashu/pythonie obrobić?

Plik jest mniej elastyczny niż socket. W szczególności socket jest
blokujący i to dwukierunkowo.

do góry

On 13.12.2013 17:07, Sylwester Łazar wrote:

> Po przyjściu RS-em kodu ma wywoływać odpowiednie reakcje.
> Jeżeli np. 12 to ma wyświetlić kolejny rysunek.
> Jeśli 13 to ma odtworzyć kolejny dźwięk.
> S.
>

Toż to w skrypcie bash-a można zrobić.
Jakiś mini Python to już byłby super komfort... ale może ktoś lubi kosić
trawnik klimatyzowanym kombajnem ;)

--
Mirek.

do góry

On 13.12.2013 20:34, Jarosław Sokołowski wrote:

>
> No to broń Boże nie Debian!
>
Eee tam. Każdy przyzwyczajony do swojego.

--
Mirek.

do góry

On 13.12.2013 22:18, Bo t manager wrote:

> A to nie lepiej
> cat /dev/cośtam > cośtam.txt i i dalej w bashu/pythonie obrobić?
>
Ja to robiłem jeszcze inaczej: read moja_zmienna </dev/cośtam
z tym, że komenda musi być zakończona znakiem końca linii... a jeszcze
jak "po ludzku" wygląda - np: next_image <enter> to już w ogóle inna
rozmowa.

--
Mirek.

do góry

Pan Sebastian Biały napisał:

[...kawał dobrej roboty...]

> Jako przykład masz tam polecenie display. Pochodzi z pakietu imagemagick
> i wyświetla po prostu obraz fullscreen (wymaga parametrów zeby ładnie
> wyświetlić, ale ja leniwy jestem, w kazdym razie działa i pokazuje plik
> image.jpg na pełnym ekranie, sam sobie dopieść).

ImageMagic i 'display' możliwości ma wiele, więc jest się z czym pieścić.
Niestety twórcy tych klocków zapomnieli o opcji, o którą aż się prosi
do tego typu zastosowań -- wyświetlania nie w oknie, a w root window.
Czyli niejako w tle, jak tapeta, bez żadnych ramek. To jest standardowa
możliwość programów pisanych pod X11, można jej użyć lub nie. Wygaszacze
ekranu zwykle pisze się w ten sposób -- są to normalne programy potrafiące
pokazywać te swoje obrazki w okienku, a dopiero wywołane z opcją "--root"
(lub podobną) zaczynają się prezentować jak typowy wygaszacz. Proponowany
wcześniej xv akurat ma taką opcję.

> Oczywiście po odpaleniu chciłbyc zapewne aby nastepne polecenie zamknelo
> obraz. Można to zrobić np. za pomocą killall.

To jest druga ważna kwestia. Ubijanie procesu po to, by go za chwilę na
nowo uruchomić, nie jest najlepszym pomysłem (akademik Grigorij Syzyfow
problem ten omawia w swojej głosnej pracy). Ani to porządne rozwiązanie,
ani przeważnie nie wygląda ładnie na ekranie w czasie pracy. Chciałoby
się, żeby program siedział w pamięci i pokazywał różne obrazki. To jest
na tyle częsta potrzeba, że na przykład 'display' ma opcję "-update",
która co podaną liczbę sekund czyta obrazek na nowo. Dobre do śledzenia
jakichś zmieniających się procesów zapisywanych przez inny program jako
grafika, czy choćby do podglądania kamery. Autor programu telak do tego
przewidział parametr "refresh" dla każdego obrazka z osobna. Tu znowu
widać, że czasem twórcom wyobraźni nie staje, albo zapominają o tym, co
w Uniksie łatwo osiągnąć. Aż się prosi, by programy miały umiejętność
reagowania na sygnały z zewnątrz. Chiałoby się szturchnąć taki proces
sygnałem SIGUSR1 żeby wykonał coś. To "coś", to w najbardziej ogólnym
i pożądanym przypadku, to ponowne przeczytanie konfigów lub parametrów
i zweryfikowanie zawartych w nich poleceń. Wtedy można działać nie na
pałę, co określony czas, ale dokładnie wtedy, kiedy potrzebujemy.

Do telaka wrażliwość na sygnał została dodana, i to błyskawicznie,
jak już wspomniałem. Odbyło się to tak szybko, ze nie ma o tym nawet
wzmianki w manie, ani w changelog w źródłach, jest tylko w changelog
na stronie -- między innymi dlatego o tym teraz piszę. Do ImageMagic
też można to oczywiście dopisać, ale do tej pory nikt tego nie zrobił.

Jarek

--
Czekamy na sygnał. Z centrali!
Czekamy, czekamy. Czekamy, czekamy.
Wszyscy na jednej fali!
Centrala nas ocali.

do góry

On 2013-12-14 14:15, Jarosław Sokołowski wrote:
> ImageMagic i 'display' możliwości ma wiele, więc jest się z czym pieścić.
> Niestety twórcy tych klocków zapomnieli o opcji, o którą aż się prosi
> do tego typu zastosowań -- wyświetlania nie w oknie, a w root window.

Mój pokazuje bez ramek na Ubuntu. Gdyby wyłaczyć menagera okien (a i tak
by sie oprzydało w dyskutowanym zastosowaniu) to zadziała prawidłowo.

>> Oczywiście po odpaleniu chciłbyc zapewne aby nastepne polecenie zamknelo
>> obraz. Można to zrobić np. za pomocą killall.
> To jest druga ważna kwestia. Ubijanie procesu po to, by go za chwilę na
> nowo uruchomić

Można więc zrobic lepiej: poszukać procesu, zapamiętać pida, odpalić
nowy, zamknąć stary. Jesli oprogramowanie pracuje na czymś lepszym niz
kalkulator Bolek, nie zauważysz różnicy.

> , nie jest najlepszym pomysłem (akademik Grigorij Syzyfow
> problem ten omawia w swojej głosnej pracy).

Rozwiązanie sprawdzi się bez względu na akademickie wywody. W tym
przypadku okres wyświetlania obrazu będzie na tyle dlugi że zamortyzuje
overheat odpalania procesu.

> Chciałoby
> się, żeby program siedział w pamięci i pokazywał różne obrazki.

Nie rózni się to niczym od prawidlowego zamykania i odpalania procesów,
jesli nie masz na mysli 50 obrazków na sekunde.

> Do ImageMagic
> też można to oczywiście dopisać, ale do tej pory nikt tego nie zrobił.

Myslę że w tym wypadku do niczego to nie jest potrzebne. Szyj
oprogramowanie na miarę.

do góry

Pan Sebastian Biały napisał:

>> ImageMagic i 'display' możliwości ma wiele, więc jest się z czym pieścić.
>> Niestety twórcy tych klocków zapomnieli o opcji, o którą aż się prosi
>> do tego typu zastosowań -- wyświetlania nie w oknie, a w root window.
>
> Mój pokazuje bez ramek na Ubuntu. Gdyby wyłaczyć menagera okien (a i tak
> by sie oprzydało w dyskutowanym zastosowaniu) to zadziała prawidłowo.

Nie miałem racji -- nie zapomnieli, tylko zrobili to inaczej niż inni.
Uruchomienie programu przez "display -window root plik.png" działa
nadzwyczaj dobrze -- obraz jest wyświetlony jako tapeta (w root window),
a sam 'display' kończy działanie. Więc niczego później nie trzeba ubijać.

>>> Oczywiście po odpaleniu chciłbyc zapewne aby nastepne polecenie zamknelo
>>> obraz. Można to zrobić np. za pomocą killall.
>> To jest druga ważna kwestia. Ubijanie procesu po to, by go za chwilę na
>> nowo uruchomić
>
> Można więc zrobic lepiej: poszukać procesu, zapamiętać pida, odpalić
> nowy, zamknąć stary.

I to ma być lepiej?!

> Jesli oprogramowanie pracuje na czymś lepszym niz kalkulator Bolek,
> nie zauważysz różnicy.

Argument z Bolkiem, to już w ogóle do niczego. Chcę *tylko* wyświetlać
obrazki, co nawet dla Bolka nie jest ambitnym zadaniem, a mam se kupić
maszynę z czterema rdzeniami i akceleratorem graficznym?

>> , nie jest najlepszym pomysłem (akademik Grigorij Syzyfow problem
>> ten omawia w swojej głosnej pracy).
>
> Rozwiązanie sprawdzi się bez względu na akademickie wywody. W tym
> przypadku okres wyświetlania obrazu będzie na tyle dlugi że zamortyzuje
> overheat odpalania procesu.

Akurat akademickie wywody się tu przydają. Nie można na przykład pominąć
tego, co w swoim słynnym podręczniku do fizjologii napisał prof. Widzeń.
Telewizory, co teraz na lotniskach wyświetlają odloty i przyloty, na ogół
projektowane są przez ludzi, który żadnej tego typu książki nie czytali.
Coś się zmienia w rządku cyfr, a ekran nawet nie błyśnie. Trzeba wciąż
śledzić co się tam zmieniło. Ale równie często jest inaczej -- zależy
nam na możliwie płynnej zmianie. Kolejne obrazy są niemal takie same,
zmienia się kilka szczegółów i nic nie może nawet mignąć. Rozwiązanie
z odpalaniem na nowo procesu na ogół się nie sprawdza (choć akurat przy
'display' i root window będzie ok).

>> Chciałoby się, żeby program siedział w pamięci i pokazywał różne obrazki.
>
> Nie rózni się to niczym od prawidlowego zamykania i odpalania procesów,
> jesli nie masz na mysli 50 obrazków na sekunde.

A jesli mam? Albo jeśli program, to wielka kobyła? Na przykład chciałbym
uruchomić firefoksa w root window. I szturchać go sygnałem, żeby robił
'reload' strony. Niestety nie da się, ktoś zapomniał albo olał problem,
bo sam uważał, że to bez sensu (albo ja nie potrafię znaleźć rozwiązania).

>> Do ImageMagic też można to oczywiście dopisać, ale do tej pory nikt
>> tego nie zrobił.
>
> Myslę że w tym wypadku do niczego to nie jest potrzebne.

Autorzy programu myśleli co innego. Jakby nie było potrzebne, to by tego
nie zrobili. ImageMagick używam rzadko, więc tego nie pamiętałem. Ale
trafiłem na to w dokumentacji pakietu jako sposób na robienia tapety.

> Szyj oprogramowanie na miarę.

Ta zasada sprawdza się u krawców mężczyźnianych. W uniksie lepszą zasadą
jest "szyj oprogramowanie na wyrost". Nie chodzi o przerost formy nad
treścią, tylko o udostępnianie nic nie kosztujących opcji. Nawet jak
ktoś sobie myśli, że "w tym wypadku do niczego to nie jest potrzebne".

--
Jarek

do góry

On 2013-12-14 16:19, Jarosław Sokołowski wrote:
>> Można więc zrobic lepiej: poszukać procesu, zapamiętać pida, odpalić
>> nowy, zamknąć stary.
> I to ma być lepiej?!

Zdefiniuj najpier kryterium "lepiej". IMHO w zastosowaniu o jakim tu
rozmawiamy lepiej oznacza prościej. Prościej się chyba nie da.

>> Jesli oprogramowanie pracuje na czymś lepszym niz kalkulator Bolek,
>> nie zauważysz różnicy.
> Argument z Bolkiem, to już w ogóle do niczego. Chcę *tylko* wyświetlać
> obrazki, co nawet dla Bolka nie jest ambitnym zadaniem, a mam se kupić
> maszynę z czterema rdzeniami i akceleratorem graficznym?

Dlatego nie widze sensu pisania oprogramowania do czynności która jest
osiągalna od ręki w dowolnym unixie. O to całe boje od początku. W
dodatku nie widze sensu robienia akademicko poprawnie, skoro problem nie
ma żadnych zagadnień związanych z wydajnościa, zajętością pamięci czy
czymkolwiek istotnym *akademicko*. Powiedzmy że problem ma być
rozwiązany biznesowo: napisać jak najmniej, uzyskać jak najwięcej,
nawet jesli to oznacza pogwałcenie wszelkich zasad w tym akademickich.
To i tak lepiej niż Lazarus.

>>> , nie jest najlepszym pomysłem (akademik Grigorij Syzyfow problem
>>> ten omawia w swojej głosnej pracy).
>> Rozwiązanie sprawdzi się bez względu na akademickie wywody. W tym
>> przypadku okres wyświetlania obrazu będzie na tyle dlugi że zamortyzuje
>> overheat odpalania procesu.
> Akurat akademickie wywody się tu przydają. Nie można na przykład pominąć
> tego, co w swoim słynnym podręczniku do fizjologii napisał prof. Widzeń.

Dreptasz w absuradlnym kierunku.

> Telewizory, co teraz na lotniskach wyświetlają odloty i przyloty, na ogół
> projektowane są przez ludzi, który żadnej tego typu książki nie czytali.
> Coś się zmienia w rządku cyfr, a ekran nawet nie błyśnie.

To *nie* ma żadnego związku z tematem bo nie mamy pojęcia jakie to
obrazki mamy pokazywać.

> Kolejne obrazy są niemal takie same,

Nie wiesz tego.

> z odpalaniem na nowo procesu na ogół się nie sprawdza (choć akurat przy
> 'display' i root window będzie ok).

Nic nie rozumiem, co ma odpalanie procesu z kiepskim designem gui?

>> Nie rózni się to niczym od prawidlowego zamykania i odpalania procesów,
>> jesli nie masz na mysli 50 obrazków na sekunde.

> A jesli mam?

To sa inne rozwiązania. Nijak nie pasujące do rozwiązania problemu w tej
dyskusji. Ogólnie nie istnieje prawidłowe rozwiązanie wszystkich
problemów ludzkości. Do odtwarzania filmów weźmiesz mplayera. Do
obrazkow display. Do muzyki mpeg123. Oprogramowanie na miarę, a nie
uniwersalne. Uniwersalne zazwyczaj nie pasuje nigdzie.

> Albo jeśli program, to wielka kobyła? Na przykład chciałbym
> uruchomić firefoksa w root window. I szturchać go sygnałem, żeby robił
> 'reload' strony. Niestety nie da się, ktoś zapomniał albo olał problem,
> bo sam uważał, że to bez sensu (albo ja nie potrafię znaleźć rozwiązania).

Ale co to ma wspólnego z czymkolwiek ?

>> Szyj oprogramowanie na miarę.
> Ta zasada sprawdza się u krawców mężczyźnianych. W uniksie lepszą zasadą
> jest "szyj oprogramowanie na wyrost". Nie chodzi o przerost formy nad
> treścią, tylko o udostępnianie nic nie kosztujących opcji. Nawet jak
> ktoś sobie myśli, że "w tym wypadku do niczego to nie jest potrzebne".

Nie pamiętam aby ktokolwiek dorabiał switcha gdziekolwiek na zaś.
Zazwyczaj wiele absuralnych switchy miało uzasadnienie w postaci
zarośniętego admina w serwerowni w singapurze który chciał zwiększyć
czas na pożeranie pizzy. Być może dlatego do tej pory nie ma jak
sensownie skonwertowąc bajta do liczby w bashu. Nikt tego na zapas nie
zrobił choć np. programiście wydaje się oczywiste.

do góry