Aktyw Forum
Zarejestruj się na forum.ep.com.pl i zgłoś swój akces do Aktywu Forum. Jeśli jesteś już zarejestrowany wystarczy, że się zalogujesz.
Sprawdź punkty Zarejestruj sięKurs C++ builder dla elektroników - obsługa urządzeń
Moderatorzy:Jacek Bogusz, Moderatorzy
Witam!
Chciałbym zwrócić się do Was z pewną refleksją. Mianowicie w prasie poświęconej elektronice, jak i internecie dostępnych jest wiele bardzo przydatnych kursów, np. obsługa Protela, programowanie mikrokontrolerów w Bascom i C, kurs ST6 realizera, AutoTrax i wiele innych.
Do tej pory jednak nie spotkałem się z kursem rzeczy niezwykle ważnej, a mianowicie z kursem pisania aplikacji służących do obsługi urządzeń budowanych fizycznie. Drogą do obsługi urządzeń są, jak wiadomo, porty wejścia-wyjścia komputera PC.
Sugeruję, że wielkim powodzeniem mógłby się cieszyć kurs popularnego języka programowania (najlepiej C++ Builder), napisany pod kątem elektroników, chcących tworzyć aplikacje sterujące do budowanych przez siebie urządzeń.
Kurs wyobrażam sobie jako rzecz od podstaw, czyli od instalacji kompilatora, poprzez krótkie wprowadzenie do wizualnego programowania (builder) obiektowego, po przejrzyste przykłady obsługi portów I/O (LPT, RS232, może USB?).
Wydaje mi się, że temat, jak znalazł, w sam raz na łamy Elektroniki dla Wszystkich, a może nawet Elektroniki Praktycznej.
Ciekawe, czy zainteresowanie byłoby takie, jak przypuszczam, czyli... duże
Co myślicie o takim kursie? Może macie jakieś sugestie odnośnie takiego kursu?
Osobiście proponowałbym otwarcie ankiety z pytaniem:
Czy byłabyś/byłbyś zainteresowany kursem C++ buildera dla elektroników?
• Tak
• Nie
Pozdrawiam serdecznie
Chciałbym zwrócić się do Was z pewną refleksją. Mianowicie w prasie poświęconej elektronice, jak i internecie dostępnych jest wiele bardzo przydatnych kursów, np. obsługa Protela, programowanie mikrokontrolerów w Bascom i C, kurs ST6 realizera, AutoTrax i wiele innych.
Do tej pory jednak nie spotkałem się z kursem rzeczy niezwykle ważnej, a mianowicie z kursem pisania aplikacji służących do obsługi urządzeń budowanych fizycznie. Drogą do obsługi urządzeń są, jak wiadomo, porty wejścia-wyjścia komputera PC.
Sugeruję, że wielkim powodzeniem mógłby się cieszyć kurs popularnego języka programowania (najlepiej C++ Builder), napisany pod kątem elektroników, chcących tworzyć aplikacje sterujące do budowanych przez siebie urządzeń.
Kurs wyobrażam sobie jako rzecz od podstaw, czyli od instalacji kompilatora, poprzez krótkie wprowadzenie do wizualnego programowania (builder) obiektowego, po przejrzyste przykłady obsługi portów I/O (LPT, RS232, może USB?).
Wydaje mi się, że temat, jak znalazł, w sam raz na łamy Elektroniki dla Wszystkich, a może nawet Elektroniki Praktycznej.
Ciekawe, czy zainteresowanie byłoby takie, jak przypuszczam, czyli... duże
Co myślicie o takim kursie? Może macie jakieś sugestie odnośnie takiego kursu?
Osobiście proponowałbym otwarcie ankiety z pytaniem:
Czy byłabyś/byłbyś zainteresowany kursem C++ buildera dla elektroników?
• Tak
• Nie
Pozdrawiam serdecznie
-
- -
- Posty:651
- Rejestracja:13 sty 2005, o 18:38
- Lokalizacja:Krasnystaw
- Kontaktowanie:
Re: Kurs C++ builder dla elektroników - obsługa urządzeń
ej, a moj kurs RS-owy to pies? . Wprawdzie dotyczy tylko RS232 i wisi od 5 miesiecy, ale jest gotowy i traktuje sprawe w sposob dosc uniwersalny. Jak tylko ruszy znow pokazana bedzie obsluga od strony Win32 API i uniwersalna klasa C++ ktora mozna sobie uzyc w Builderze (choc opis tworzenia prostych aplikacju GUI bedzie zrobiony z wykorzystaniem Qt).kursem pisania aplikacji służących do obsługi urządzeń budowanych fizycznie.
Natomisat co do samego kursu tworzenia "aplikacji służących do obsługi urządzeń budowanych fizycznie" z wykorzystaniem Buildera, to sprawa jest tak obszerna, ze trzeba by przepisywac ksiazki o Builderze. Bo samo korzystanie z takiego czy innego portu to tylko 1 klasa (lub np. komponent w narzedziach RAD) - a reszta zalezy po prostu od tego, co dana aplikacja ma robic .
Re: Kurs C++ builder dla elektroników - obsługa urządzeń
No właśnie gdzieś się zapodział - a tak się ladnie zapowiadał. Temat poruszony przez elemid'a pewnie bylby dość atrakcyjny - w końcu PCet mogłby służyć do tworzenia wielu pożytecznych aplikacji. Nie wiem jak sie dalej potoczy kurs Arka, ale ja chetnei widzialbym projekt aplikacji w której jest pokazana osługa np RS'a ale i też np zapisywanie i otwieranie pliku, wynajdowanie i uzywanie "elektronicznych" komponentów (np analogowego wskażnika napięcia) itp krok po kroczku może nawet ze zrzutami ekrenów. To wszytsko jako wskazówki dla zdecydowanie i zupełnie zielonych w temecie Biuldera ( oczywiście nie w temacie C)ej, a moj kurs RS-owy to pies? . Wprawdzie dotyczy tylko RS232 i wisi od 5 miesiecy, ale jest gotowy i traktuje sprawe w sposob dosc uniwersalny. .......kursem pisania aplikacji służących do obsługi urządzeń budowanych fizycznie.
Re: Kurs C++ builder dla elektroników - obsługa urządzeń
Racja, pamiętam, pamiętam (jeśli to ten cykl w EP, który mam na myśli ).ej, a moj kurs RS-owy to pies? . Wprawdzie dotyczy tylko RS232 i wisi od 5 miesiecy, ale jest gotowy i traktuje sprawe w sposob dosc uniwersalny.kursem pisania aplikacji służących do obsługi urządzeń budowanych fizycznie.
Ja zastanawiałem się jednak nad czymś dla, wręcz, zupełnych laików, bardziej ogólnym, dotyczące obsługi portów (dowolnych, nie tylko RS) od strony programisty.
Po co to wszystko?
Generalnie zasada jest (wg mnie) taka:
1. Jest wiele kursów (takich ABC - dla początkujących) środowisk wizualnych, gdzie każdy uczy się pisać swoje pierwsze programy, w profesjonalnym środowisku, takim jak Borland C++ Builder, ale w tych kursach niewiele pisze się (albo i wcale) o sterowaniu portami we/wy. Z jednej strony słusznie, bo potencjalny informatyk - algorytmiarz nie będzie zainteresowany tą problematyką.
2. W przypadku elektronika, chcącego nawiązać komunikację po RS, lub choćby zapalić sobie LEDy włożone do LPT, sytuacja może wyglądać dokładnie odwrotnie. Taki "standardowy" kurs może więc zniechęcać klasycznego elektronika do programowania w C++ czy Delphi, bo nie oferuje tego, czego chce elektronik.
I koło się zamyka.
Stąd moja refleksja dotycząca kursu C++ buildera "inaczej".
Chodzi o nauczenie czytelnika podstawowych rzeczy, i pokazanie mu przykładowych rozwiązań. Nie oznacza to jednak, że początkujący programista ma, czy też musi ograniczyć się do podanego wzorca, ma on raczej poznać podstawowe zasady i możliwości sterowania portami zewnętrznymi. Kurs ma dać mu podstawy i zachęcić go do dalszego rozwijania jego programistycznego warsztatu.
-
- -
- Posty:651
- Rejestracja:13 sty 2005, o 18:38
- Lokalizacja:Krasnystaw
- Kontaktowanie:
W takim razie mozna by stworzyc pewien kurs w stylu "C++ Biulder dla elektronikow", gdzie przedstawione bylyby podstawowe zasady tworzenia aplikacji w konteksie "elektronicznym". Calego, czy to Buldera, czy innego srodowiska, nie przerobi sie w kursie, ktory skonczylby sie przed osiagnieciem pelnoletnosci przez Futrzaka . A tym bardziej haslo "programowanie obiektowe" to temat rzeka (i to nie jakas tam Wisełka, Nil co najmniej).
IMHO Mariusz ma bardzo dobry pomysl z ta ankieta .
http://www.trolltech.com/products/qt
IMHO Mariusz ma bardzo dobry pomysl z ta ankieta .
Jest gotowy juz od jakiegos czasu . Lezy sobie na redakcyjnym HDD .No właśnie gdzieś się zapodział
Coz, kurs jest jak w tytule - o obsludze RS-a a nie srodowisc programistycznych. Jako przyklad przenosnej biblioteki pokazalem Qt Trolltech'a . Biblioteka ciekawa, DZIALAJACA, i od 2005 w wersji Open Source takze dla Windows .Nie wiem jak sie dalej potoczy kurs Arka, ale ja chetnei widzialbym projekt aplikacji w której jest pokazana osługa np RS'a ale i też np zapisywanie i otwieranie pliku, wynajdowanie i uzywanie "elektronicznych" komponentów (np analogowego wskażnika napięcia) itp krok po kroczku może nawet ze zrzutami ekrenów. To wszytsko jako wskazówki dla zdecydowanie i zupełnie zielonych w temecie Biuldera ( oczywiście nie w temacie C)
http://www.trolltech.com/products/qt
Dokładnie o coś takiego mogłoby chodzić.W takim razie mozna by stworzyc pewien kurs w stylu "C++ Biulder dla elektronikow", gdzie przedstawione bylyby podstawowe zasady tworzenia aplikacji w konteksie "elektronicznym".
No, teraz to już tylko od dobrej woli Administratora / Moderatora zależy. Może niebawem pojawi się ankieta, jak tutaj.IMHO Mariusz ma bardzo dobry pomysl z ta ankieta .
Pozdrawiam
-
- -
- Posty:651
- Rejestracja:13 sty 2005, o 18:38
- Lokalizacja:Krasnystaw
- Kontaktowanie:
-
- -
- Posty:651
- Rejestracja:13 sty 2005, o 18:38
- Lokalizacja:Krasnystaw
- Kontaktowanie:
No, a to już jest plus. Podobnie było z kursem (kilkanaście odcinków w EDW) Protela 99SE, rozprowadzanego za free również w dystrybucji trialowej. Myślę, że tamto było jak najbardziej OK. Podobnie może być z kursem BCB. Miesiąc czasu to formalnie wystarczająco długi kawałek czasu na sporządzenie prostej aplikacji do obsługi jakiegoś urządzenia własnej konstrukcji.Najnowsza wersja BCB 2006 dostepna jest jako trial (nie ma okrojonego personala).
-
- -
- Posty:651
- Rejestracja:13 sty 2005, o 18:38
- Lokalizacja:Krasnystaw
- Kontaktowanie:
Witam,
Pomysł ciekawy, ale....
w takim ujęciu jak napisałeś to przysłowiowy wierzchołek góry lodowej...
Zauważ, że oprogramowanie komunikacji z jakimkolwiek nietrywialnym urządzeniem
to nie tylko 'zapalenie i zgaszenie kilku ledów na LPT'...to konieczność wygenerowania
całych sekwencji sygnałow, czasem z zachowaniem odpowiednich zależności czasowych.
a one będą ściśle zależały od specyfiki danego sprzętu...
przecież inaczej będziesz pobierał dane w przetownika A/C typu ADC0804 a inaczej z np. TLC549
a te przetworniki to i tak banalny przykład - ponieważ wystarczy firmowa dokumentacja....
Ciekawie zrobi się, gdy one będą pracowały w wiekszym, bardziej złożonym układzie i program powinien
też być w stanie wpływać na jego ustawienia np. przełączać źródła sygnałow, zmieniać nastawy
dzielników na wejściach, etc...
Więc moim zdaniem aby to miało sens - należy też chyba podać przykład takiego sprzętu,
sama elektronika to jeden aspekt, ale jak ona wygląda z punktu widzenia oprogramowania to troszkę inna rzecz.
No, a potem krok po kroku pokazać w jaki sposób napisać oprogramowanie pozwalające
takim urządzeniem sensownie sterować, zmieniać jego nastawy i odbierać dane...
To w uproszczeniu sprowadza się do opracowania takiego jakby abstrakcyjnego, softwarowego modelu urządzenia
(w formie obieku, czy zestawu funkcji) i sprzęgnięcia z nim intefrejsu użytkownika (okienek) - fajna rzecz....
Druga sprawa...C++ Builder...
Ja nie kwestionuję wyboru (choć w sumie można zapytać czemu nie MSVC, Delphi czy DevC++)
ale czy pomyślałeś o pokaźnym stadku użytkowników Linuxa?
Czytałeś pewnie artykuły Arkadiusza o RS232...ten tutorial jest w miarę ponadplatformowy i jest (będzie?)
użyteczny dla znakomitej większości...
a jeżeli pójdziesz w kierunku jednego konkretnego narzędzia i systemu operacyjnego to dla pewnej
grupy ludków będą to tylko zapisane kartki...takie mam wrażenie
Tak czy inaczej fajnie, że (jak rozumiem) chcesz coś takiego napisać....
powodzenia życzę,
tasza
ps.
hmm, kiedyś postanowiłam sprawdzić czy i jak da się pożenić Javę z prostym sprzętem zapiętym do LPT...
i w sumie udało mi sie osiągnąć taki stan, że ta sama prościutka aplikacja skompilowana i zapakietowana w jar-a
migała właśnie ledami na porcie, zarówno w RedHat jak i w WinXP...po prostu JVM ładowała sobie maleńką
bibliotekę dającą dostęp do przestrzeniu I/O procesora, natywna biblioteka napisana odpowiednio w gcc/MSVC,
a reszta to już była czysta sunowska Java...ot, taka zabawka....
Pomysł ciekawy, ale....
w takim ujęciu jak napisałeś to przysłowiowy wierzchołek góry lodowej...
Zauważ, że oprogramowanie komunikacji z jakimkolwiek nietrywialnym urządzeniem
to nie tylko 'zapalenie i zgaszenie kilku ledów na LPT'...to konieczność wygenerowania
całych sekwencji sygnałow, czasem z zachowaniem odpowiednich zależności czasowych.
a one będą ściśle zależały od specyfiki danego sprzętu...
przecież inaczej będziesz pobierał dane w przetownika A/C typu ADC0804 a inaczej z np. TLC549
a te przetworniki to i tak banalny przykład - ponieważ wystarczy firmowa dokumentacja....
Ciekawie zrobi się, gdy one będą pracowały w wiekszym, bardziej złożonym układzie i program powinien
też być w stanie wpływać na jego ustawienia np. przełączać źródła sygnałow, zmieniać nastawy
dzielników na wejściach, etc...
Więc moim zdaniem aby to miało sens - należy też chyba podać przykład takiego sprzętu,
sama elektronika to jeden aspekt, ale jak ona wygląda z punktu widzenia oprogramowania to troszkę inna rzecz.
No, a potem krok po kroku pokazać w jaki sposób napisać oprogramowanie pozwalające
takim urządzeniem sensownie sterować, zmieniać jego nastawy i odbierać dane...
To w uproszczeniu sprowadza się do opracowania takiego jakby abstrakcyjnego, softwarowego modelu urządzenia
(w formie obieku, czy zestawu funkcji) i sprzęgnięcia z nim intefrejsu użytkownika (okienek) - fajna rzecz....
Druga sprawa...C++ Builder...
Ja nie kwestionuję wyboru (choć w sumie można zapytać czemu nie MSVC, Delphi czy DevC++)
ale czy pomyślałeś o pokaźnym stadku użytkowników Linuxa?
Czytałeś pewnie artykuły Arkadiusza o RS232...ten tutorial jest w miarę ponadplatformowy i jest (będzie?)
użyteczny dla znakomitej większości...
a jeżeli pójdziesz w kierunku jednego konkretnego narzędzia i systemu operacyjnego to dla pewnej
grupy ludków będą to tylko zapisane kartki...takie mam wrażenie
Tak czy inaczej fajnie, że (jak rozumiem) chcesz coś takiego napisać....
powodzenia życzę,
tasza
ps.
hmm, kiedyś postanowiłam sprawdzić czy i jak da się pożenić Javę z prostym sprzętem zapiętym do LPT...
i w sumie udało mi sie osiągnąć taki stan, że ta sama prościutka aplikacja skompilowana i zapakietowana w jar-a
migała właśnie ledami na porcie, zarówno w RedHat jak i w WinXP...po prostu JVM ładowała sobie maleńką
bibliotekę dającą dostęp do przestrzeniu I/O procesora, natywna biblioteka napisana odpowiednio w gcc/MSVC,
a reszta to już była czysta sunowska Java...ot, taka zabawka....
-
- -
- Posty:651
- Rejestracja:13 sty 2005, o 18:38
- Lokalizacja:Krasnystaw
- Kontaktowanie:
Oprocz podzielenia mojej refleksji dotyczacej uniwersalnosci, Tasza poruszyla kolejny istotny aspekt: na jakim poziomie abstrakcji nalezaloby potraktowac komunikacje? Czy wyjasnic jedynie jak dobrac sie do portu (przeslac/odebrac bajt itp.), czy tez wejsc w wyzsze warstwy i pokazywac takie czy inne protokoly wymiany danych (ramki). W tym drugim przypadku konflikt uniwersalnosc/specyficznosc jest juz b. duzy, bo kazdy system na swoja specyfike i trudno jest podac uniwersalny, abstrakcyjny model komunikacji, ktory dal by sie ot tak zaaplikowac do wszystkiego...
Moj bierzacy kurs daje przyslowiowa wedke dot. RS-a, a nie rybe: pokazuje podstawowe mechanizmy pozwalajace zrealizowac skuteczna komunikacje w Win32 i Linuksie, niezaleznie od kompilatora C++. W kursie pokazano przyklad wykorzystania Qt wraz z gcc/mingw (prosty efekt tu: http://www.antoniak.ep.com.pl/index.php?id=rs_guide ), ale taka sama klasa zostala np. wykorzystana z Builderem, np. tu: http://www.antoniak.ep.com.pl/index.php?id=dbg167
Moj bierzacy kurs daje przyslowiowa wedke dot. RS-a, a nie rybe: pokazuje podstawowe mechanizmy pozwalajace zrealizowac skuteczna komunikacje w Win32 i Linuksie, niezaleznie od kompilatora C++. W kursie pokazano przyklad wykorzystania Qt wraz z gcc/mingw (prosty efekt tu: http://www.antoniak.ep.com.pl/index.php?id=rs_guide ), ale taka sama klasa zostala np. wykorzystana z Builderem, np. tu: http://www.antoniak.ep.com.pl/index.php?id=dbg167
no cóż, w sumie co wynika z samego dobrania się do portu? szeregowego czy równoległego...?
że powołam się na swoją starą pisaninę LPT-XP...
wynika, że można sobie zrobić od ręki komputerowe lampki choinkowe...raczej niewiele.
ale jeżeli przykładowe urządzonko będzie miało w sobie dajmy na to - kilka rejestrów?
taki, co zwraca dane, taki co trzyma konfigurację i taki co podaje aktualny status elektroniki (np. busy/ready/error...)
o wbudowanej pamięci na jakieś próbki danych nie wspominając?
to tylko przykład, ale niczym przysłowiowy kijek ma dwa końce - jak zaprojektować część elektroniczną,
która będzie miała takie właśnie funkcjonalności (możliwość dwustronnej komunikacji przez dany port)
i jak sensownie tę elektronikę oprogramować...
jak uniknąć pułapek, ryzyka- że zrobimy sprzęt, którego oprogramowanie będzie koszmarem
i jak napisać stabilny soft, który będzie w stanie maksymalnie kontrolować urządznie, obsługiwać sytuacje awaryjne i inne niespodzianki...
podsumowując - zamiast malować ponownie 'wędkę' - może opracować lepiej całościowy projekt (hardware+software),
ale rozebrany na czynniki pierwsze: z dokładnym wyjaśnieniem dlaczego takie, a nie inne decyzje zostały
podjęte przy jego projekcie, budowie i pisaniu oprogramowania....
i taki 'inżynierski' tutorial - o, to byłoby coś...
tasza
że powołam się na swoją starą pisaninę LPT-XP...
wynika, że można sobie zrobić od ręki komputerowe lampki choinkowe...raczej niewiele.
ale jeżeli przykładowe urządzonko będzie miało w sobie dajmy na to - kilka rejestrów?
taki, co zwraca dane, taki co trzyma konfigurację i taki co podaje aktualny status elektroniki (np. busy/ready/error...)
o wbudowanej pamięci na jakieś próbki danych nie wspominając?
to tylko przykład, ale niczym przysłowiowy kijek ma dwa końce - jak zaprojektować część elektroniczną,
która będzie miała takie właśnie funkcjonalności (możliwość dwustronnej komunikacji przez dany port)
i jak sensownie tę elektronikę oprogramować...
jak uniknąć pułapek, ryzyka- że zrobimy sprzęt, którego oprogramowanie będzie koszmarem
i jak napisać stabilny soft, który będzie w stanie maksymalnie kontrolować urządznie, obsługiwać sytuacje awaryjne i inne niespodzianki...
podsumowując - zamiast malować ponownie 'wędkę' - może opracować lepiej całościowy projekt (hardware+software),
ale rozebrany na czynniki pierwsze: z dokładnym wyjaśnieniem dlaczego takie, a nie inne decyzje zostały
podjęte przy jego projekcie, budowie i pisaniu oprogramowania....
i taki 'inżynierski' tutorial - o, to byłoby coś...
tasza
-
- -
- Posty:651
- Rejestracja:13 sty 2005, o 18:38
- Lokalizacja:Krasnystaw
- Kontaktowanie:
czyli wedka ogolna + ryba szczegolna . w sumie takie cos bedzie (jest) w moim kursie, choc ryba jest tam bardzo podstawowa - woltomierz odczytywany przez RS232. Z tym jeszcze, ze wedke powtorzono by jedynie dla RS-a, bo AFAIR nie bylo takich kursow dla np. LPT.podsumowując - zamiast malować ponownie 'wędkę' - może opracować lepiej całościowy projekt (hardware+software),
ale rozebrany na czynniki pierwsze
wiedza jak to się robi . po prostu niektorzy wiedza, a niektorzy nie i dla tych drugich to cenne info (tak jak z kazda inna tematyka). Ale masz racje, ze zaraz pojawia sie pytanie "no dobra, LEDy migaja, ale co dalej?".no cóż, w sumie co wynika z samego dobrania się do portu? szeregowego czy równoległego...?
Widzę, że podczas mojej nieobecności, temat nabrał tempa.
Takie moje refleksje:
Tasza, zbyt głęboko wchodzisz w temat. Nie próbójmy od razu, i to w sposób bezpośredni, sterować specjalizowanymi scalakami. Może jeszcze w ramach kursu dla laików zaczniemy podawać informacje, jak tworzyć nowe pseudo-magistrale i standardy wykorzystując do tego poszczegulne linie portów pracujących w innym standardzie LPT, RS.
Nie tak szybko
Zaplanujmy na początek kurs, w którym, ktoś, kto nawet specjalnie nie zna języka C, a jest wystarczająco biegły w mikrokontrolerach (niech sobie programuje w ass, bascom, może nawet niech sobie układa zera i jedynki bezpośrednio w kodzie maszynowym ) i potrafi wykorzystywać UART - stworzy sobie prosty soft za pomocą którego będzie potrafił nawiązać łączność z mikrokontrolerem (załóżmy RS), i dopiero za pomocą mikrokontrolera sterować specjalizowanymi peryferiami, czyli dokładnie tak, jak się to robi w praktyce.
Kiedy czytałem wypowiedź Taszy, naszła mnie nagle taka myśl: "a po co, u diabła, tak komplikować sobie życie?". To ma być kurs dla laików, zupełnie od podstaw, z omówieniem podstawowych właściwości i funkcji kompilatora, niezbędnych elektronikowi, zaprezentować mu niezbędne procedury - fragmenty kodu, całość powinna być zwieńczona gotowymi rozwiązaniami, z prezentacją pełnych listingów i plików wynikowych takich aplikacji.
W naszej dyskusji padło hasło "tutorial". Myślę, że "tutorial" to jest właśnie to, o czym myślę. "Kurs" - to może zbyt wiele powiedziane.
No i ta kwestia z linuxem. Z całym szacunkiem dla zagorzałych fanów linuxa, ale z tego, co mi wiadomo, np. Protel nie był napisany dla linuxa, a kurs w EDW się odbył, i nikt z tego powodu nie płakał, a wręcz przeciwnie. Odbiór cyklu, z tego co się orientuję, był bardzo pozytywny.
Nie widzę powodów, dla których na rzecz linuxa i jego dostępności open-source, rezygnować z rozwiązań opartych na systemach komercyjnych i na odwrót.
O ile linux jest fantastyczną alternatywą dla innych, w tym komercyjnych systemów, o tyle bojówki o jeden z nich, jedynie słuszny, bo "lepszy", czy "niekomercyjny", wydają mi się po prostu niesmaczne
Takie moje refleksje:
Tasza, zbyt głęboko wchodzisz w temat. Nie próbójmy od razu, i to w sposób bezpośredni, sterować specjalizowanymi scalakami. Może jeszcze w ramach kursu dla laików zaczniemy podawać informacje, jak tworzyć nowe pseudo-magistrale i standardy wykorzystując do tego poszczegulne linie portów pracujących w innym standardzie LPT, RS.
Nie tak szybko
Zaplanujmy na początek kurs, w którym, ktoś, kto nawet specjalnie nie zna języka C, a jest wystarczająco biegły w mikrokontrolerach (niech sobie programuje w ass, bascom, może nawet niech sobie układa zera i jedynki bezpośrednio w kodzie maszynowym ) i potrafi wykorzystywać UART - stworzy sobie prosty soft za pomocą którego będzie potrafił nawiązać łączność z mikrokontrolerem (załóżmy RS), i dopiero za pomocą mikrokontrolera sterować specjalizowanymi peryferiami, czyli dokładnie tak, jak się to robi w praktyce.
Kiedy czytałem wypowiedź Taszy, naszła mnie nagle taka myśl: "a po co, u diabła, tak komplikować sobie życie?". To ma być kurs dla laików, zupełnie od podstaw, z omówieniem podstawowych właściwości i funkcji kompilatora, niezbędnych elektronikowi, zaprezentować mu niezbędne procedury - fragmenty kodu, całość powinna być zwieńczona gotowymi rozwiązaniami, z prezentacją pełnych listingów i plików wynikowych takich aplikacji.
W naszej dyskusji padło hasło "tutorial". Myślę, że "tutorial" to jest właśnie to, o czym myślę. "Kurs" - to może zbyt wiele powiedziane.
No i ta kwestia z linuxem. Z całym szacunkiem dla zagorzałych fanów linuxa, ale z tego, co mi wiadomo, np. Protel nie był napisany dla linuxa, a kurs w EDW się odbył, i nikt z tego powodu nie płakał, a wręcz przeciwnie. Odbiór cyklu, z tego co się orientuję, był bardzo pozytywny.
Nie widzę powodów, dla których na rzecz linuxa i jego dostępności open-source, rezygnować z rozwiązań opartych na systemach komercyjnych i na odwrót.
O ile linux jest fantastyczną alternatywą dla innych, w tym komercyjnych systemów, o tyle bojówki o jeden z nich, jedynie słuszny, bo "lepszy", czy "niekomercyjny", wydają mi się po prostu niesmaczne
-
- -
- Posty:651
- Rejestracja:13 sty 2005, o 18:38
- Lokalizacja:Krasnystaw
- Kontaktowanie:
przepraszam za cytaty w zmienionej kolejności
bo czytać po raz n-ty jak na najniższym poziomie oprogramować RS232 czy LPT to średnio tak...
jest książka w Helionie do RS232, jest kurs Arka....stron internetowych o tej tematyce jest naprawdę bardzo dużo...
a jeżeli chodzi o same podstawy tworzenia aplikacji - w artykule (czy nawet cyklu) poruszysz zaledwie
ułamek tego co oferuje pierwsza z brzegu sensowna i przystępna książka o tej tematyce - i sądzę, że zbytnio się nie mylę.
czy zmuszania elektroniki do udawania drukarki (vide kit AVT270) i w ten sposób jej obsługiwania
myślę, że taki bardziej zaawansowany materiał wniesie coś nowego - nie będzie
luźną wariacją na temat 'tego co juz było', ale wskaże nowe kierunki poszukiwań,
być może da cenne wskazówki, a może tylko zainspiruje...
tylko teraz wydaje mi się, że troszkę za bardzo podniosłam poprzeczkę
no cóż, sorry....
tasza
PS.
uwaga o Javie w kontekście Win i Linuxa to było tylko zasygnalizowanie pewnych możliwości
a nie przyczynek do dyskusji o wyższości X nad Y...
wiesz, ja po prostu szukam rzeczy ciekawych, nowych, w jakiś sposób nietypowych - a takie właśnie
wydało mi się oprogramowanie działające w/g zasady - "załaduj raz, używaj wszędzie"
a jednocześnie rozmawiające z własnej konstrukcji sprzętem...
to tyle w kwestii wyjaśnienia.
"niezbędnych elektronikowi "- co nalezy przez to rozumieć?zupełnie od podstaw, z omówieniem podstawowych właściwości
i funkcji kompilatora, niezbędnych elektronikowi
bo czytać po raz n-ty jak na najniższym poziomie oprogramować RS232 czy LPT to średnio tak...
jest książka w Helionie do RS232, jest kurs Arka....stron internetowych o tej tematyce jest naprawdę bardzo dużo...
a jeżeli chodzi o same podstawy tworzenia aplikacji - w artykule (czy nawet cyklu) poruszysz zaledwie
ułamek tego co oferuje pierwsza z brzegu sensowna i przystępna książka o tej tematyce - i sądzę, że zbytnio się nie mylę.
orazi dopiero za pomocą mikrokontrolera sterować specjalizowanymi peryferiami,
czyli dokładnie tak, jak się to robi w praktyce
ależ w praktyce tak właśnie się robi - i jest to dużo trudniejsze ale też ciekawsze od zwykłej komunikacji szeregowej,podawać informacje, jak tworzyć nowe pseudo-magistrale i standardy wykorzystując
do tego poszczegulne linie portów pracujących w innym standardzie LPT, RS
czy zmuszania elektroniki do udawania drukarki (vide kit AVT270) i w ten sposób jej obsługiwania
myślę, że taki bardziej zaawansowany materiał wniesie coś nowego - nie będzie
luźną wariacją na temat 'tego co juz było', ale wskaże nowe kierunki poszukiwań,
być może da cenne wskazówki, a może tylko zainspiruje...
hmm, wiesz jak nie zamierzam nikomu komplikować życia...Kiedy czytałem wypowiedź Taszy, naszła mnie nagle taka myśl: "a po co,
u diabła, tak komplikować sobie życie?".
tylko teraz wydaje mi się, że troszkę za bardzo podniosłam poprzeczkę
no cóż, sorry....
tasza
PS.
dostrzegam drobną nadinterpretację tego co napisałam...Nie widzę powodów, dla których na rzecz linuxa i jego dostępności open-source,
rezygnować z rozwiązań opartych na systemach komercyjnych i na odwrót .
O ile linux jest fantastyczną alternatywą dla innych, w tym komercyjnych systemów,
o tyle bojówki o jeden z nich, jedynie słuszny, bo "lepszy", czy "niekomercyjny",
wydają mi się po prostu niesmaczne
uwaga o Javie w kontekście Win i Linuxa to było tylko zasygnalizowanie pewnych możliwości
a nie przyczynek do dyskusji o wyższości X nad Y...
wiesz, ja po prostu szukam rzeczy ciekawych, nowych, w jakiś sposób nietypowych - a takie właśnie
wydało mi się oprogramowanie działające w/g zasady - "załaduj raz, używaj wszędzie"
a jednocześnie rozmawiające z własnej konstrukcji sprzętem...
to tyle w kwestii wyjaśnienia.
Kto jest online
Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 18 gości