DJ pisze:
> On 2009-02-13 10:16:45 +0100, Piotr Curious Gluszenia Slawinski
> <c...@m...ip.tpnet.pl> said:
>
>>
>> Do sterowania oswietleniem i wentylacja mysle komputer domowy wystarczy,
>
> 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.

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

do góry

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


>> 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.
>
> Tylko skąd u niego upór żeby ten hardware nie miał w sobie procka.

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.

> 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.

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

do góry

Użytkownik "T.M.F." napisał:
> A po co ci to wiedziec?

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)


> Zakladajac, ze kompilator nie ma bledow.


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


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


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!


> masz szanse napisac cos szybciej w assemblerze... masz niezle ego :)

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)

do góry

On Monday 09 February 2009 01:55, onet wrote:
> szukam jakiej

do góry

>> A po co ci to wiedziec?
>
> 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)

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.

>> Zakladajac, ze kompilator nie ma bledow.
>
> 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

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.

>> Podaj nazwe. I nie twierdze, ze nie mozna, to po prostu jest bez sensu.
>
>
> 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ść,

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

>> masz szanse napisac cos szybciej w assemblerze... masz niezle ego :)
>
> 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)

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.

do góry

Mateusz Viste pisze:
> On Monday 09 February 2009 01:55, onet wrote:
>> szukam jakiej? przystawki (mo?e na USB?) dzi?ki kt?rej wykorzystam
>> moje PC jako central? do wentylacji, o?wietlenia domu itp
>> szuka?em na google ale niewiele znalaz?em poza urz?dzeniami na rs232
>> (nie mam takiego portu w kompie)
>
> 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).

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.
>
> 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ć.

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.
>
> ZALETY: Pod LPT bardzo łatwo pisać oprogramowanie, prosta i niezawodna
> konstrukcja.

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



--
Pozdrawiam
MD

do góry

On Saturday 14 February 2009 14:18, Mario wrote:
> Gdy pracuje pod dosem to pc traci trochę ze swojej funkcjonalności.

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ę.

> Trudno zrealizować sterowanie i monitoring przez internet.

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. :)

> Interfejs
> użytkownika trochę skromny bo najczęściej przypomina linię poleceń.

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.

> Mało
> komu chciałoby się pisac programu graficzne pod DOS.

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

do góry

Użytkownik "T.M.F." napisał:
> Zawiesza sie bo jest napisany w jezyku wysokiego poziomu? Masz jakas
> literature na poparcie tej tezy?

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


> 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.

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


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

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


> 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.

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

do góry

Mateusz Viste pisze:
> On Saturday 14 February 2009 14:18, Mario wrote:
>> Gdy pracuje pod dosem to pc traci trochę ze swojej funkcjonalności.
>
> 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ę.
>
>> Trudno zrealizować sterowanie i monitoring przez internet.
>
> 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. :)

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.

>> Interfejs
>> użytkownika trochę skromny bo najczęściej przypomina linię poleceń.
>
> 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.

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).

>
>> Mało
>> komu chciałoby się pisac programu graficzne pod DOS.
>
> 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.

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

do góry

On Saturday 14 February 2009 17:26, Mario wrote:
> 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.

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

do góry