Jak skonfigurować wentylację i oświetlenie domu przez USB z PC?

Wed Feb 11, 2009 6:29 pm   

Użytkownik "T.M.F." napisał:

to że pisząc w asemblerze dokładnie wiesz co piszesz i jaki sprzęt
oprogramowujesz, a w językach wysokopoziomowych to nigdy nie wiesz jak
program zostanie skomplilowany, nawet w takim C pisząc pętlę nie wiesz jaki
naprawdę kod asemblera oba zawiera,



wiesz, widziałęm program graficzny 3D na PCta napisany w asemblerze
zajmujące megabajty kodu, więc mozna:O)
na starym pierniku (jakiś stary pentium) obliczał i wyswietlał grafikę 3D w
czasie rzeczywistym!!! co na dzisiejszych kompach PC jest wyzwaniem, wiec
można

..

Thu Feb 12, 2009 11:43 pm   

A po co ci to wiedziec? Zakladajac, ze kompilator nie ma bledow. Wlasnie
po to sie stosuje jezyki wysokiego poziomu, zeby nie martwic sie o
nieistotne pierdoly. Tam gdzie kod assemblerowy jest z jakiegos powodu
istotny wrzuca sie mala wstawke i juz. Poza tym wytlumacz prosze w jaki
sposob kompilator mi przeslania sprzet, ktory oprogramowywuje? Tak moze
byc jesli korzystam z jakiejs biblioteki i jej API, ale kompilator nie
ma nic do tego. Tak samo moge stosowac warstwe abstrakcji od sprzetu w
assemblerze.


Podaj nazwe. I nie twierdze, ze nie mozna, to po prostu jest bez sensu.


Jasne, biorac pod uwage, ze wspolczesne procesory graficzne bija na
glowe CPU, a drivery i biblioteki graficzne sa rozwijane od lat przez
zespol specjalistow, ktorzy niczym innym sie nie zajmuja to istotnie
masz szanse napisac cos szybciej w assemblerze... masz niezle ego

Fri Feb 13, 2009 10:16 am   

gargamel wrote:


'Komp' zwieszac sie nie powinien.

Przykladowo :

jerry etc # uptime
10:21:46 up 185 days, 15:19, 4 users, load average: 0.00, 0.00, 0.00

Jesli chcesz wiekszej pewnosci to pogooglaj za czyms co sie nazywa 'watchdog
timer' i 'hardware watchdog' . mozna tez takowy latwo zrobic samemu.

Druga sprawa to zastosowanie. Przykladowo jesli chodzi o sterowanie piecem
to owszem, uzycie PC (duzo czesci, duzy system operacyjny = duzo elementow
ktore moga potencjalnie zadzialac zle i dlugi proces testowania
niezawodnosci) wydaje sie zlym pomyslem, chociaz przy uzyciu prostego WDT
to jeszcze nie jest duzy problem.
Sterowanie rakieta czy samolotem albo komputer samochodowy - tu
juz 'wielkosc' systemu ma duze znaczenie , bo jesli zdarzy sie zwis czy
restart to system musi byc gotowy w ulamkach sekund.
Z drugiej strony czy lepiej uzyc systemu testowanego przez miliony ludzi
codziennie , dosc znanego i na otwartym kodzie, tak ze w razie znalezienia
bledu bez problemu znajdziemy programiste ktory napisze latke?
Czy moze malej domorobki, z kodem znanym tylko autorowi, testowanym tylko
przez siebie i wymagajacym specjalisty do zrozumienia kodu i wprowadzenia w
nim zmian?

Do sterowania oswietleniem i wentylacja mysle komputer domowy wystarczy,
jesli sie zwiesi to bedzie przez chwile ciemno i tyle. Dodatkowo latwo
wprowadzic skomplikowany ('prototypowy') kod typu analiza ruchu z kamer,
przewidywanie obecnosci osob i zalaczanie wentylacji zanim sie one pojawia
na podstawie analizy statstyk itd. itp. co tam autor ma w planach, bo zdaje
sie chce sie po prostu pobawic a nie budowac urzadzenie do podtrzymywania
zycia

--
--

Fri Feb 13, 2009 10:29 am   

T.M.F. wrote:


Sluszne uwagi. Ja dodam ze :

1)Na mikrokontrolery rowniez sa kompilatory C i duzo ludzi pisze w C ,
uzywajac tych 'niebezpiecznych' kompilatorow (co do 'wyniku' to racja ze
sie nie wie co kompilator wygeneruje, ale jesli juz sie trafi na wadliwy,
to latwo zmienic platforme)

2)Wlasnie o to chodzi przy uzywaniu 'peceta' i jezyka wyzszego poziomu,
jesli ktos nie ma doswiadczen ze sprzetem - cos mu nie dziala, zepsulo
sie 'cos w srodku' to wywala cale pudlo , idzie do sklepu, kupuje nowe,
niekoniecznie takie samo albo uwaznie patrzac na konstrukcje, byle mialo
podobne porty i mozliwosci. W skrajnych przypadkach moze zmienic nawet
architekture procesora

3)Jesli mamy kod w C ktory jest 'idealny' i nie planujemy w nim poprawek to
mozna zatrudnic elektronika/firme ktora skompiluje go na VHDL i wykona nam
z niej chipa/kontroler. ew. przeportuje na mikrokontroler :)

--

Fri Feb 13, 2009 11:49 am   

On 2009-02-13 10:16:45 +0100, Piotr Curious Gluszenia Slawinski
<curious@moj.ip.tpnet.pl> said:


Wystarczy??? toż to aż za dużo...
Nie wiem czy był już poruszany problem energochłonności... ? i
optymalnego wykorzystania zasobów?

komputer o mocy 100-150W, pracujący 24/7 (bo taka rola sterownika) da
nam miesięcznie rachunek około 40-50PLN. Może się okazać że to więcej
niż sterowane nim oświetlenie. Oczywiście jeśli kogoś stać na kosztowne
zabawy, to potraktuje ten fakt ciepłym strumieniem.

Tymaczasem sterownik zrobiony samodzielnie na jakimklolwiek 8 bitowym
procesorze zupełnie wystarczy, i będzie miał średnie zużycie mocy może
z 10W, albo i mniej jeśli zaprojektuje się go z odpowiednią dbałością w
tym keirunku.
Mówię tu o sterowaniu urządzeniami elektrycznymi (jak w temacie), nie o
śledzeniu zmian obrazu z 25 kamer.

Następna rzecz - przypuszczam że parcie w kierunku wykorzystania PC
wynika z tego że on już w domu jest, tylko mu trzeba dokoptować kawałek
hardware i software.
A pomyśleć też trzeba że przy pracy ciągłej szybciej padnie chiński
zasilacz, o wymianie wentylatorów 2 razy w sezonie nie wspomnę (bo też
chińskie;)


Pobawić się zawsze można, jednak nie można do takich eksperymentów
dorabiać ideologii że jest to rozwiązanie słuszne technologicznie.

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

Fri Feb 13, 2009 1:10 pm   

DJ pisze:

Tylko skąd u niego upór żeby ten hardware nie miał w sobie procka. Ani
to nie podraża ani specjalnie nie komplikuje układu. Dochodzi troszkę
softu na procek w C czy nawet w Basicu. Prościej obsłużyć porty w
mikrokontrolerze niż siłowo dobierać sie do LPT czy rzeźbić coś na FT245
czy PCF8574 jako porcie zewnętrznym.
Sterowanie w mikrokontrolerze, zarządzanie/monitoring w PC, komunikacja
USB przez FT232 bądź AVR-CDC.

--
Pozdrawiam
MD

Fri Feb 13, 2009 1:43 pm   

On 2009-02-13 13:10:26 +0100, Mario <lolo@poczta.onet.pl> said:



Może kwestia żeby było - polutować i działa. Na procka w hardware
trzeba nieco wiedzy o architekturze, programator, zbudować najprostszy
starter kit. Trochę z nim potrenować. Może to niektórych przeraża,.
zwłaszcza jeśli programowali wcześniej tylko pod "duże sytstemy", bez
bezpośredniego kontaktu software ze sprzętem.


No i już. PC po to żeby nie dorabiać rozrośniętego GUI w 8-bitowcu.
Nastawy z PC, potem go gasimy, a sterownik czuwa nad sprzętami.

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

Fri Feb 13, 2009 6:09 pm   

Użytkownik "T.M.F." napisał:

no właśnie w tym stwierdzeniu jest całą prawda o językach wysokopoziomowych,
nie wiedzieć jest łatwo, wygodnie, łatwiej nauczyć się języka C raz na całę
życie niż architektury i asemblera kolejnych uP-uf, ale ceną tej łatwości
jest to że potem taki windows, czy linux sie zawiesza, programy sie
zawieszają nie wiedzieć dlaczego, a nawet telefony komurkowe się zawieszają
(i reset nie pomaga) dawniej gdy sprzęt był programowany w asemblerach coś
takiego się w głowie nie mieściło żeby telefon mógł się zawiesić, a mam w
domu taką starą dwóekranową gierkę (donkey kong) i w życiu sie nie
zawiesiła, cuda jakeiś czy co?:O)




kompilatopr może nie mieć błędów, chodzi o brak kontroli) a własnie
niewiedza jest przyczyną błędów, dodatkowo oprogreamowując sprzęt urzywasz
sterowników producenta i też używasz funkcji wysokopoziomowych, czyli też
nie masz pojęcia jak dana instrukcja jest wykonywana, znowu nie masz
kontroli i dupa blada




nazwy nie pamiętam, zresztą jak programu na oczy nie widziałeś to i nazwa
nic ci nie powie, a sens ma to ogromny, bo program który pisany
wysokopoziomowo nie ma szans na działąnie w czasie rzeczywistym na nowym
super sprzęcie, napisany w asemblerze tylko śmiga na starych piernikach,
wiec sens jest, jest nim wydajnosć i niezawodność,
p.s. do tego programu 3D to pamiętam jak sam pisałem w C takie funkcje i
wiem że jedna klatka takiego obrazu zajmowała nowemu PC 10 minut a bryła 3D
skąłdała się z kilkuset takich klatek, więc taka obróbka trwała setki
godzin, dlatego byłem ogromnie zdziwiony gdy program napisany w asemblerze
działąjacy na starym peirniku robi to samo w czasie rzeczywistym i jeszcze w
czasie rzeczywistym obraca taką bryłę i ją kroi w dowolnej płaszczyźnie,
więc różnica w wydajnosci między językami niskopoziomowymi a
wysokopoziomowymi jest OGROMNA i im język jest wyższego poziomu to jego
wydajność drastycznie spada!



jakie ego? to oczywisty fakt że pisząc w asemblerze na tym samym sprzęcie
program będzie o niebo szybszy od pisanego wysokopoziomowo, ale ja tego nie
będę pisał bo mi za to nie płącą:O)

Sat Feb 14, 2009 12:47 pm   

On Monday 09 February 2009 01:55, onet wrote:

Witam,

Troszkę późno na odpowiedź, ale co tam :-)

Sam używam komputera do sterowania różnymi rzeczami. Wykorzystałem do tego
port równoległy (LPT), złożyłem prosty układ na optoizolatorach sterującymi
przekaźnikami i napisałem sobie program sterujący pod DOS (komputerek który
służy za "centrum sterowania" jest z zeszłej epoki).

Działa bardzo sprawnie, do tej pory nigdy nie miałem żadnych problemów
technicznych. Uwaga: podczas uruchamiania komputera, na porcie LPT mogą
pojawiać się śmieci. Trzeba to uwzględnić.

ZALETY: Pod LPT bardzo łatwo pisać oprogramowanie, prosta i niezawodna
konstrukcja.
WADY: Można wysterować do ośmiu urządzeń (tyle mamy linii w porcie LPT), by
wysterować więcej trzeba dorobić odpowiednią logikę, albo wołożyć dodatkowy
port LPT (ja używam dodatkowej karty ISA z dwoma portami, dzięki czemu mogę
sterować 24-oma urządzeniami).

Schemat znajduje się na
http://mateusz.viste.free.fr/electronic/schemes/switch6v.htm

A mój program sterujący (DOS) umieściłem na
http://mateusz.viste.free.fr/dos/en/download.php?plik=lptdrv

Pozdrawiam,
Mateusz Viste

Sat Feb 14, 2009 12:49 pm   

Zawiesza sie bo jest napisany w jezyku wysokiego poziomu? Masz jakas
literature na poparcie tej tezy? Porownaj taki ZX Spectrum, ktory mial
16 kB ROM, w dodatku z bledami, ze wspolczesnym komputerm, ktorego OS ma
setki MB.


Jaka niewiedza? Co mnie obchodzi jak dziala jakas funkcja. Mam funkcje
biblioteczna, ktora realizuje np. x+y i nie ma dla mnie znaczenia jak
ona to robi, byle to robila.


Pisales procedury do takiego programu 3D i nie pamietasz jego nazwy? Wez
nie sciemniaj.


Wez sie nie osmieszaj. Masz np. funcje realizujaca np. pomniejszenie
fragmentu obrazu z antyaliasingiem. Realizowana jest ona sprzetowo przez
GPU, jaka bedzie roznica czasu wykonania jesli wywolam ja programujac
bezposrednio GPU, albo wywolujac przez funkcje GDI? Podpowiem, zadna.
A w tym pierwszym wypadku trace od razu kompatybilnosc, w dodatku moj
program ma szanse miec o wiele wiecej bledow niz program korzystajacy z
przetestowanej przez tysiace programistow funkcji bibliotecznej.

Sat Feb 14, 2009 2:18 pm   

Mateusz Viste pisze:

Gdy pracuje pod dosem to pc traci trochę ze swojej funkcjonalności.
Trudno zrealizować sterowanie i monitoring przez internet. Interfejs
użytkownika trochę skromny bo najczęściej przypomina linię poleceń. Mało
komu chciałoby się pisac programu graficzne pod DOS.

To jest jedna z podstawowych wad. Ja kiedyś problem rozwiązałem stosując
PCF8574 (startuje zawsze z wyjściami ustawionymi na 1) a LPT służył
tylko jako interfejs i2c. W ten sposób można podłączyć więcej portów
oraz termometry/termostaty cyfrowe.

Sterowanie portami w AVRach też jest proste zwłaszcza gdy pisze się w C.
Podejrzewam, że także w Bascomie.



--
Pozdrawiam
MD

Sat Feb 14, 2009 4:21 pm   

On Saturday 14 February 2009 14:18, Mario wrote:

Zależy do czego ma być. Jeżeli ma służyć jako dedykowana centralka
sterownicza, to DOS jest właśnie w sam raz. Wystarczy choćby stary 386SX z
640K RAM'u.
Jeżeli jednocześnie na komputerze ma siedzieć jakiś użytkownik i grać w
pasjansa, przeglądać stronki itp, to DOS rzeczywiście nie nadaje się.


Wręcz przeciwnie, bardzo łatwo. Pod warunkiem, że do karty sieciowej
istnieje packet driver (ja z reguły używam 3Com 3C509, a na nich nie ma
najmniejszego problemu). Do packet driver'a podłączamy jakikolwiek
podsystem TCP (np. WatTCP, NTCPDRV, Watt32...), i tyle.
Co więcej, taki program można napisać choćby w QuickBASIC'u, więc dosłownie
każdy może się podjąć - nie trzeba być programistą na etacie. :)


Znów zależy, do czego potrzebujemy... Do centralki, TUI w zupełności
wystarczy. Osobiście wolę działać w linii poleceń, aniżeli przeprawiać się
przez multum klikanych menu.


Ciągnąc sprawę zarządzania przez sieć, można sobie z łatwością wyobrazić
schemat, w którym centralka (DOS) kontroluje zestaw przekaźników, a samo
zarządzanie jest załatwiane na zdalnym kliencie (graficznym) pod
jakimkolwiek OSem posiadającym stack TCP.

Pozdrawiam,
Mateusz Viste

Sat Feb 14, 2009 5:10 pm   

Użytkownik "T.M.F." napisał:

oj zaraz byś chciał literaturę kjtóra by zaciebie pomyślała, naprawdę nie
rozumiesz aktu że im język jest wyższego poziomu tym programista ma mniejszą
kontrolę nad kodem?:O)
np: taka zwykłą pętla for w C, wiesz ile z tego kompilator robi instrukcji
asemblera?:O) jak sprawdzisz to przynajmniej dędziesz wiedział ile tam jest
śmiecia



no włąśnie, co ciebie obchhodzi, tak samo co ciebie obchodzi ze
oprogramowanie jest niestabilne i z masą śmieci skoro jest poprawnie
napisane:O(



nic do tego programu nie pisałem, pisałem włąsny program w C o
funkcjonalności podobnej do tamtego programu w asemblerze, dlatego wiem jaka
byłą między nimi róznica w wydajnosci



jeśli coś można zrobić sprzętowo to lepiej to będzie działąć sprzętowo, ale
czy ty myślisz ze grafika 3D to tylko gry PC? nie każda grafika ma zwiazek z
przetwarzaniem obrazu, często są to czasochłonne filtracje, sploty, operacje
na wielkich macierzach i tym poodbne, pod które nikt sprzętu masowo nie
produkuje

Sat Feb 14, 2009 5:26 pm   

Mateusz Viste pisze:

Nie wiem po co uczyć się historii. Lepiej nauczyć się jak udostępniać
sterowanie/pomiar przez Apache/PHP, Tomcat czy Ajax. A to już wymaga
współczesnego systemu operacyjnego.


No więc to samo będziesz miał pisząc polecenia z hyperterminala czy
Br@ay++ terminala do AVRa z przekaźnikami (po rs232 + konwerter lub
korzystając z CDC-AVR).


Też jestem zwolennikiem rozdziału zadań na zarządzanie/monitoring - w
graficznym PC i sterownik - urządzenie wykonawcze realizujące proste
polecenia z centrali. Tylko, że jeśli hobbysta/początkujący będzie robił
sterownik na współczesnym mikrokontrolerze to nauczy się programować
wpółczesny mikrokontroler. Jeśli zajmie się starym nieużywanym pc to
nauczy się programować stare nieużywane pecety.


--
Pozdrawiam
MD

Sat Feb 14, 2009 6:35 pm   

On Saturday 14 February 2009 17:26, Mario wrote:

Nie o to chodzi, by uczyć się historii... Ale jeżeli człowiek sam jest
historią, to łatwiej mu zaprogramować stary PC aniżeli przesiadać się na
siakieś mikrocuda i/lub uczyć Ajax'a tudzież PHP. Mówię oczywiście
spoglądając na sprawę z mojej własnej perspektywy. :-P

Dawno temu nauczyłem się programować w DOS, i nie będąc zawodowym
programistą/eletronikiem nie mam wcale ochoty próbować/uczyć się czegoś
nowego w tym zakresie. To, czega nauczyłem się kilkanaście lat temu w
zupełności mi wystarcza.

Jeżeli ktoś dopiero uczy się i szuka rozwiązań, rzeczywiście równie dobrze
mógłby próbować tych obecnych nowości (AVR, Tomcat, itd, itp...).

Pozdrawiam,
Mateusz Viste