sterowanie urządzeniami el. przez PC?

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.

Reply to
T.M.F.
Loading thread data ...

steruj?cymi

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
Reply to
Mario

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

Reply to
Mateusz Viste

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

Reply to
gargamel

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
Reply to
Mario

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

Reply to
Mateusz Viste

Jak 'nie wiesz' to i w C/C++/C#/VB nie napiszesz.

Mam kilka kompow windzianych i z linuxem - musza byc zepsute bo sie nie chca wieszac (uptime po pol roku jest).

Jak masz miesiac na soft to nic dziwnego. Z asm w ogole nie byloby telefonu, bo soft by sie pisal 2 lata.

Roboczogodzina 20 lat temu miala inna wartosc niz teraz.

Ja tam mam kontrole.

Po opisie kilku mega w asm to ja juz bym znalazl ten program - zeby go zobaczyc.

Tutaj to juz bzdury piszesz. Dobrze napisany program w C nie rozni sie niczym od asemblera. No, oczywiscie trzeba wiedziec jak kompilator ustawic, jakie konstrukcje w C uzyc itp. Ja np: nie pisze juz czasowo krytycznych przerwan w asemblerze (dla prockow w ktorych znam kompilator). Bardzo czesto napisanie w C wystarcza - jeden rzut oka na wynik w asm i stwierdzam ze nie da sie szybciej.

A co do Twojego 3D - wiesz, algorytmy przyspieszaja dzialanie wielu programow duzo bardziej niz rozne kompilatory.

Jak programista dupa to oczywisty fakt. Jak wie co robi, to mozesz sie zdziwic.

--
Jerry1111
Reply to
Jerry1111

Zapewne tak jest. Ale za $100 mozesz kupic plytke np. ANGW100 z

32-prockiem, Linuxem na pokladzie, USB, 2xeth itd. ktora jest mala, zuzywa pare watow, a programujesz to sobie wygodnie chociazby na PC, po czym tylko rekompilujesz program na cross-kompilatorze i wrzucasz do tego sterownika. Jesli umiesz programowac, rozumiem, ze znasz cos w stylu C/C++ to to czy to bedzie DOS, czy Linux nie robi roznicy. Kompatybilnosc zapewniaja biblioteki systemowe.

dobrze

Zapewne, niechec do nauki to jest argument:) Ale nie zmienia to faktu, ze sterowanie paroma przekaznikami za pomooca PC to strzelanie z armaty do muchy.

Reply to
T.M.F.

gargamel pisze:

Za³ó¿my, ¿e jeste¶ w stanie napisaæ krótsz± pêtlê ni¿ wygenerowana z C przez kompilator. Ale musisz napisaæ znacznie wiêcej kodu, we którym masz znacznie wiêksze szanse pomyliæ sie. A pêtla w C jest prosta jak konstrukcja cepa. Nawet je¶li kod wynikowy jest troszkê d³u¿szy to jest wygenerowany automatycznie i ma³e s± szanse ¿eby zawiera³ b³±d. Zdarza siê, ¿e kompilatory zawieraj± b³êdy ale do¶æ szybko s± wykrywane ³atane. Zak³adam, ¿e bardziej niezawodna jest zbiorowa praca programistów od avr-gcc ni¿ rze¼bienie rozbudowanego projektu przez programistê asemblerowego. Sam od dawna pisa³em w asemblerze ale przy okazji przej¶cia na nowe procki przerzuci³em siê na C. Nigdy wiêcej pisania w asemblerze obliczeñ zmiennoprzecinkowych na logarytmach :) Bêdzie konieczno¶æ przyspieszenia jakiej¶ obs³ugi przerwania to najwy¿ej przepiszê kawa³ek kodu w asemblerze ale jeszcze nie mia³em takiej potrzeby.

A sk±d wniosek ¿e je¶li go nie obchodzi jak funkcja dzia³a to znaczy ¿e go nie obchodzi stabilno¶æ kodu wynikowego. Przecie¿ ty pisz±c w asemblerze te¿ nie interesujesz siê jak to jest realizowane na poziomie mikrokodu. Skoro tego nie wiesz to mo¿e twoje instrukcje s± zamieniane na b³êdne mikroinstrukcje?

>
--
Pozdrawiam
MD
Reply to
Mario

Nad swoim kodem ma taka sama. Nie ma kontroli nad kodem bibliotek, ktorych uzywa i o to chodzi. Dowolna biblioteka systemowa jest lepiej przetestowana niz to co sam napiszesz. Ergo - mniej bedzie bledow jesli korzystasz z kodu bibliotek niz piszesz samemu. Jesli uwazasz inaczej to znaczy, ze jestes lepszym programista niz setki osob, ktore zawodowo te biblioteki pisaly i wylapujesz bledy lepiej niz pewnie setki tysiecy testerow/programistow, ktorzy je wykorzystywali. Gdyby bylo tak jak piszesz to w kazdej ksiazce na poczatku byloby ostrzezenie, zeby nie uzywac jezykow wysokiego poziomu. A jest dokladnie odwrotnie, w kazdej ksiazce znajdziesz stwierdzenie, ze lepiej pisac np w .NET niz assemblerze.

No wiem. Tak sie sklada, ze np. gcc robi petle tak optymalnie jak w assemblerze.

Pokasz jakies zrodla na potwierdzenie tej tezy.

Gratuluje, napisac program o funkcjonalnosci kilku MB w assemblerze i nie pamietac jak sie nazywal... Moze czas zaczac brac Nootropil.

Tak, bo w sprzecie nie ma bledow. Czy ty wiesz, ze np. w takim Pentium instrukcje sa tlumaczone na mikrokod, a nie sa realizowane sprzetowo?

Nie? A widziales np. C.U.D.A. dla NVidii? Widze, ze zahibernowales jakies 20 lat temu i sie jeszcze nie obudziles. GPU to juz od lat nie jest po prostu bufor ramki, tylko zestaw rownoleglych procesorow realizujacych obliczenia matematyczne tysiace razy czybciej niz CPU. BTW, NVidia masowo produkuje sprzet.

Reply to
T.M.F.

Dnia Fri, 13 Feb 2009 18:09:09 +0100, gargamel napisał(a):

Zawieszaja sie nie dlatego, ze sa pisane w jezyksach wysokiego problemu, ale dlatego ze producenci sie spiesza - kiedys nowy model komorki wychodzil raz na rok, dzisiaj w miesiacu mamy parenascie nowych modeli albo i wiecej

- a testy tego co napisali programisci sa przeprowadzane na uzytkownikach. Liczy sie kasa - zeby cos szybko sprzedac, a nie stabilnosc. Gdyby jezyki wysokopoziomowe byly takie zle jak mowisz, to przy zlozonosci dzisiejszych systemow z jakich dzis korzystamy mielibysmy restart co minute.

m.

Reply to
Madz

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

no więc na ile komend asemblera kompilator gcc kompiluje pętlę for? bo w asemblerze wystarczą dwie, trzy instrukcje

ojej, czytaj za zrozumieniem, nie pisałem w asemblerze, pisałem w C i mój program w C miałem okazję porównać z programem w asemblerze (jego nazwa ani kto go napisał wsale mnie nie interesowało)

Reply to
gargamel

Użytkownik "Mario" napisał:

tak, wiem że kod w C jest piękny, te wszystki odstępy, tabulatory, komentarze, wszystko tak piękne że tylko podziwaić i takie proste, dlatego stosuje sie języki wysokopoziomowe, ale jest dróga strona, kosztem łątwizny jest niestabilnosć, bnłęduy io brak kontroli, to są fakty a nie moje widzimisie, acha a co do błędów w kompilatoraach to każdy kto sie świeżo uczy jakiegoś języka to takie błędy znajduje w ilościach huirtowych na porządku dziennym:O( acha, no i cały brak kontroli polega na tyum że nasz funkcję jako czarne pudełeczka, a wiec nie masz kontroli nad tym co w środku a włąsnie te nieprzewidywalnme błędy biorą się gównie z niewiedzy a nie z nieumiejętnosciu programowania

przecież instrukcje w asemblerze to jest wąłśnie mikrokod (jedna instrukcja jest zamieniana na ciąg zer i jedynek (i dokłądnie wiesz na jaki a jak znasz arhitekturę to i wiesz jak te instrukcje są wykonywane)

p.s. zboczyło sie trochę z tematu a wiec do sterowania wentylatorem mo zna kupić sobie taki mały sterowniczek mieszczący się w puszce eleltrycznej

9mozliwy do programowania z PC, kupujesz, programuijesz, podłączasz i zapominasz:O)
Reply to
gargamel

Użytkownik "Madz" napisał:

to teraz policz ile w tym procku PC jest milionów tranzystorów, dodaj do tego resztę milionów tranzystorów w płycie głównej i podzespołąch i porównaj to z liczbą tranzystorów w całym sterowniczku opartym na procku jednoukładowym, to ci popkaże skalę prawdopodobieństwa awarii sprzętu:O)

wątpię, bo w PC sam restart nie musi rozwiazać problemu, wiec i sensu stosowania brak:O(

Reply to
gargamel

gargamel pisze:

Skoro to sa fakty to z latwoscia podasz przyklady w literaturze, ktore je potwierdzaja.

Jasne. Bredzisz.

Znowu palnales. Poczytaj czym jest mikrokod.

Reply to
T.M.F.

I dokladnie tyle samo w gcc. I o czym to ma swiadczyc?

Reply to
T.M.F.

Czlowieku, na kazdy temat na ktory sie wypowiadasz pokazujesz swoja ignorancje. Prawdopodobienstwo awarii zalezy od procesu technologicznego a nie ilosci tranzystorow. Taki AVR32 ma zblizone prawdopodobienstwo awarii jak malutki 8-bitowy AVR. A kazdy z tych procesorow ma wielokrotnie nizsze prawdopodobienstwo awarii niz np. kondensator czy dyskretny tranzystor.

Jasne, dlatego np. sprzedawane w setkach milonow egzemplarzy routerki/AP z linuxem na pokladzie wg ciebie nie maja prawa dzialac. Jak dla mnie EOT.

Reply to
T.M.F.

Programowanie to nie tylko zadanie napisania kodu który raz zadziała, przejdzie 2 proste testy i już. Kod często ma też sprawdzać zakresy oczekiwanych danych i wyników aby wyłapywać ewentualne inne mniej oczywiste błędy przetwarzania. Samo dodawanie czy pomnożenie to nie wszystko. Sprawdzanie zakresu wyniku, przekroczenie tabeli itd jest ważnym elementem prawie każdego programu. Jesli tego nie robisz w swoich programach to są one marne. Nawet nikt nie wie, że występują błędy i wychodzą bzdurne wyniki. Stąd takie proste x+y może być obudowane większym sprawdzonym kodem kompilatora czy biblioteki.

Czepiasz się niesłusznie. Nie musi go obchodzić efektywność kodu który wykonuje się sporadycznie, ważniejsza jest wtedy jego pewność poprawności działania. A poprawność kodu na pewno jest wyższa z kompilatora C niż wklepanego ręcznie w asm. Ilość błędów jest związana z ilością linijek kodu, im prostrzy i czytelniejszy zapis tym mniej pomyłek.

Także optymalizacja kodu to inne zadanie kiedy piszesz prosty program dla prostego 8 bitowca i możesz to zrobic ręcznie niż kiepski C, a inne kiedy tworzysz kod dla robudowanych procków mających mnóstwo schematów adresowania i dla których kompilator szuka optymalnego kodu, wykorzystania banków rejestrów , analizuje i eliminuje martwy kod, itd

Pisałem kiedyś program w C - implementując prosto dla próby własne FFT a następnie skorzystałem z gotowej biblioteki intela - była ona ponad 10 x szybsza od mojego kodu, ale to nie zasługa języka programowania tylko wykorzystania wbudowanych zaawansowanych instrukcji sygnałowych procka!. Jest ich teraz tak dużo i są związane ściśle z konkretnymi prockami, w kazdym są inne zestawy, że sami ani w asm ani w C tego nie oprogramujemy - biblioteki tworzy producent procków i ma popisane różne kawałki dla różnych procków..

Takie filtry i inne o których piszesz właśnie mają piękne wsparcie sprzętowe (SIMD) w procesorach.

zbyszek

Reply to
zbyszek

gargamel pisze:

Ja widzę u ciebie błędy io :) Kod w asemblerze też może być piękny z tabulatorami i komentarzami. Kod w języku wysokopoziomowym jest przede wszystkim zwięzły. Fakt pisania w C (i automatycznej generacji kodu wynikowego) nie jest przyczyną niestabilności i błędów io. Systemy operacyjne pisze się w C i to jest najlepszym przykładem na to że jest to najlepsze rozwiązanie. Nie sądzę żeby napisany w asemblerze system był stabilny i dawał się rozwijać.

to są

Z reguły to nie są błędy kompilatora tylko brak wiedzy programisty. Jak się przerzucisz z jednego kompilatora asm na inny to też będzie ci się kompilacja sypać.

Czytasz opis funkcji i wiesz jak ona działa. Jak masz wątpliwości to przeglądasz kod. Jeśli chcesz w c wysłać przez UART liczbę typu int to użyjesz np printf("%d",a) - najpierw inicjując port rprintfInit(uartSendByte). Nie musisz znać architektury. Aby to zrobić w asm musisz napisać sobie konwersję bin > dec > ascii potem załadować do bufora i dopiero potem uruchomić procedurę wysyłania przez UART. W każdej z tych procedur musisz pilnować jakie wartości odłożyć na stos jakie rejestry użyć itp. Jednym słowem nawet do trywialnych operacji matematycznych musisz znać dokładnie architekturę. Trudno jest ci dołączyć kod z biblioteki - zwłaszcza pisany przez kogoś innego a w dodatku gdy przechodzisz na inny procek to trzeba wszystko przepisywać od nowa.

Jedna instrukcja już jest ciągiem zer i jedynek :)

(i dokłądnie wiesz na

Doczytaj o mikrokodzie i zastanów się czemu np. w prockach typu CISC cykl maszynowy składa się z kilku cykli zegarowych.

Można też kupić mieszczące się w puszce sterowanie światłem czy roletami a to wszystko na pilota radiowego.

Reply to
Mario

gargamel pisze:

Pod warunkiem, że w pętli będzie inkrementacja/dekrementacja o 1 a licznik ma wielkość równą długości słowa danych.

Może nie potrafiłeś wydajnie pisać?

Reply to
Mario

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.