Chcę starszego kolegę (inżynier, były naucziciel informatyki i wt) wyciągnąć z bagna o nazwie Bascom. Zaczyna w Bascomie rozwiązywać problemy nieistniejące w innych językach więc myślę, że czas nas zmianę. Niech już zostanie przy tych swoich Atmegach ale chcę pokazać mu inny lepszy świat i przestawić go na C. Nie znam się na Atmegach, jakie środowisko do C byłoby najlepsze? Bascom przyzwyczaił go, że ma tam wbudowaną obsługę do popularnych peryferiów typu lcd, 1wire itp. Jakie środowisko darmowe zawiera już biblioteki do takich popularnych peryferiów? Nie chcę go zniechcąc na początku koniecznością szukania bubliotek lub pisaniem własnych (co uważam osobiście za mega puczającą frajdę). AvrStudio posiada biblioteki czy to samo C? Która wersja? W sieci odradzają najnowszą bo podobno kobyła wymagająca szybkiego PC (kolega pracuje tylko na laptopie z win XP), polecają wersję starszą 4.18. A może WnAVR? Środowisko nie musi być mega wypasione, byle była absługa atmegi
8/16/32. No i trochę gotowych bibliotek do peryferiów.
A jest jakieś takie małe IDE do Arduino. Zgooglaj, to nawet C++ niby. Kompilator gcc. Bardzo fajna społeczność, do wszystkiego łatwo znaleźć biblioteczki.
Z drugiej strony C nie jest dużo lepsze od Basica, to co naprawdę ważne to architektura i takie tam. W C da się napisać gorszy kod źródłowy niż w Basicu.
ja dawno dawno temu pisałem prościuteńkie programy w basicu na zx spectrum. Dzisiaj siadam i piszę taki sam program który m 5 linijek i robi cośtam widowiskowego. to samo w C da się zrobić na 2 "linijkach". tyle że wcześniej musisz mieć 5 linijek wstępu, deklaracji, czegoś co właśnie nie istnieje w innych językach i nie musisz o tym mieć pojęcia. Nie ważne czy Ty się zgadzasz z powyższą tezą, ważne czy Twój kolega się znią zgadza. Co więcej, on Ci niekoniecznie o tym powie.
ale facet pisze programy kolosy jakieś? sztuczna inteligencja? rozwiązywanie sudoku? Bo mnie się wydawało że na atmegę, w sensie nie PCta to raczej proste programy się pisze....
tak jak Slawek wspomniał arduino. Czyli atmega+złącze usb. od takich co maja 6 nóżek do ponad 50siąt. Środowisko do programowania raczej ubogie. W sensie słabo się koloruje składnia, klamry się nie kolorują, wykonywać linia po lini się nie da. Niemniej jednak napisać się da, bibliotek jest dużo, te których niema są dostępne na necie, poradników jak zacząć na YT dużo. W zasadzie tyle. kompiluje się i działa. Wrócę jednak do mojej pierwszej myśli. Ja podchodziłem do nauki C/C++ klilka razy. zawsze wymiękałem na pierwszym rozdziale ksążki, nie umiąc zrozumieć, po kija mam decydować jak dużą, dokładną liczbę będzie przechowywać zmienna "i" użyta w pętli for. Tym bardziej że głupi sterownik do karty dźwiękowej zgodnej z sound blaster zajmuje 81 dyskietek. mnie bolało i boli dalej to, że "migaj diodą" ma dłuższy wstęp niż kod programu. bolał i boli, że każda linia kończy się średnikiem. No chyba że to jest "for", to jak dam średnik to się skompiluje ale nie wykona. myślę że Twój kolega też sie z tym zderzy. no chyba że na lekcjach informatyki uczył c++
Wejdź na stronę Atnel... Osobiście uważam, że jak ktoś chcę zacząć pisać w C to nie ma lepszych pozycji książkowych. Również o środowisko Eclipse można dużo się dowiedzieć. Pozdrawiam
Marek snipped-for-privacy@fakeemail.com napisał(a):
W C będzie rozwiązywać problemy nieistniejące w Bascomie.
Lepszy bo możliwości więcej, w tym możliwości strzelenia sobie w stopę. Żeby nie było: też przeszedłem z Bascoma na C, ale nie uważam że należy potępiać Bascoma.
Tutaj bezkonkurencyjne jest Arduino.
AVR Studio to jest samo IDE, które wymaga doinstalowania WinAVR (GCC i dodatkowe narzędzia). Ja bym jednak zostawił w spokoju ten zabytek i zainstalował współczesne Atmel Studio. Kobyła to to nie jest jak na dzisiejsze standardy, chyba że Twój kolega ma jakiegoś starego rzęcha.
Przy 100 linijkach Basic daje radę. Przy 2000 linijkach jakby mniej. Przy 10000 zaczynają być problemy z C. C++ teoretycznie nadaje się do rzeczy mających parę milionów linijek.
Jeżeli chcesz pomrugać LED to Basic jest ok. Jeżeli napisać mały system operacyjny na Atmegę, to C jest ok. Jeżeli piszesz np. program AI mający kierować samochodem, to C++ jest jedną z opcji.
On Fri, 2 Oct 2015 23:52:29 +0200, "Grzegorz Niemirowski" snipped-for-privacy@poczta.onet.pl> wrote:
Nie miałem zamiaru komentować w tym wątku Bascoma (bo de facto nie o niego było pytanie) ale mnie niestety sprowokowałeś. Bascom to policzek dla Basica bo podobno jemu ma być podobny. Nazywa się "kompilatorem" a de facto jest czymś w rodzaju konsolidatora bibliotecznych (gotowych) asmeblerowych instrukcji i makr użytych w kodzie. Język, który kpi sobie z programisty (o tym niżej).Bałaganiarska składnia dopuszcza case insensitive co pozwala na tworzenie mało czytelnego kodu. Osoba, którą znam co poświęciła mu zbyt dużo czasu szybko doszła do ściany w rozwoju i koniec. Język kompletnie nie rozwija, ogranicza wyobraźnię do kontekstu "jednego programu" przez co trudno ogarnąć takiemu programiście wielozadaniowość nawet opartą na prostej maszynie stanów. Brak możliwości pisania własnych bibliotek (uwaga, można ale w asemblerze, kpina nr 1), brak możliwości porozdzielania projektu na skompilowane obiekty aby za każdym razem nie "kompilować" całości. Brak jakiejkolwiek optymizacji, kod jest składany z gotowych klocków, więc jego rozmiar rośnie dość szybko. Niezgodność dokumentacji producenta w opisie instrukcji, znalazłem takie, które nie chcą działać mimo, że zostały użyte wg przykładów. Brak sensownej i logicznej konsekwencji w instrukcjach/makrach. Tam nie da się nic przewidzieć (co do poprawnej składni). Raz argumenty instruckji są bez nawiasów a raz w nawiasach, np. skladnia instrukcji rysowania linii na LCD graf wyglada tak:
line(x1,y1)-(x2,y2) a zapalenia pixla: pset x,y,z
logiczne, prawda? Raczej kpina nr 2.
Niektóre funkcjonalności nie działają jak powinny, ostatnio kolega męczył się przez tydzień z fontami na LCD graficznym. Użycie instrukcji wyboru fontu do pisania powodowało niedziałający w ogóle kod (niestartujący w ogóle mcu). Sprawa była o tyle dziwna, że posiłkował sie przykladami kodu z artykułów, ktorych autorzy twierdzili, że im działa. Po kilku dniach szukania przyczyn poddał się i przepisał jota w jote kod z przykladu, o dziwo kod zadział. Co się okazalo? Że kod działa jeśli instrukcje grafiki są w procedurach a nie w pętli głównej (sic!). Czemu? Nie wiadomo. Faktycznie we wszystkich przykładach użyto podobnej konstrukcji z procedurami, ale nikt się nie zająknął, że tak być musi bo nie zadziała. Jest to piękny przyklad, jak próba inwencji w inną koncepcję konstrukcji kodu (bez procedur) sprowadza na ziemię, bo tak się nie da, bo coś nie działa. Tylko traci się czas, kpina z programisty nr 3. Najlepsze zostawiam na deser. Ktoś może powiedzieć, że te powyższe zarzuty są przesadzone, bo język ma być prosty dla prostych rozwiązań, dla nie-programistów a bardziej elwktroników więc nikomu niepotrzebne dołączanie skompilowanych obiektów czy rozdzielanie kodu na wiele plików. Składnia jest jaka jest, po to jest help aby z niego korzystać. I nawet jestem w stanie mu przyznać rację. Ale jak się dowiedziałem, że wyrażenia arytmetyczne są ograniczone do dwóch operandów (sic) i jednego operatora to mi już wszystko odpadło. Tak, w Bascomie nie da się napisać prostego wyrażenia x=3*y+23*z, o bardziej skomplikowanym nie wspominając. Programista musi rozłożyć wyrażenie na kilka prostych wyrażeń jednooperatorowych wprowadzając najczęściej dotatkowe zmienne pomocnicze. Kolejna kpina, nawet nie liczę która.
Co można powiedzieć dobrego o Bascomie? No lista instrukcji obsługi peryferiów robi wrażenie, trzeba przyznać ogrom pracy jaką włożono w rozwój. I na tym koniec bo zaraz za tym idzie zadziwienie z tej liczby doklejanych do tego jezyka instrukcji-potworków aby obsłużyć kolejną taką czy inną kolejną funkcjonalność. Przy niektórych mityczne b=---*a++, którym straszy sie przyszłych adeptów C to pikuś. A miał to być język prosty, do prostych zastosowań.
W dniu piątek, 2 października 2015 18:15:56 UTC+2 użytkownik ToMasz napisał:
Znaczy wada C/C++ jest to, ze trzeba z grubsza rozumiec, jak dziala komputer i pamiec RAM? :) Jestes pierwsza osoba, o ktorej slysze, ktora polegla na tym. Wiekszosc osob pada na wskaznikach i z tego powodu zostaja programistami Javy, zarabiajac 2x tyle co na programowaniu niskopoziomowym:D
Czytelność kodu źródłowego zależy od programisty. Widziałem programy w Asemblerze napisane strukturalne i czytelnie. A zapewniam cię, że Basic nie jest jedynym językiem case insensitive.
[--ciach-] Niestety Marku masz rację, sam kiedyś próbowałem w tym pisać ale każdy trochę bardziej skomplikowany program to walka z baskomem, gdzie help swoje a kompilator swoje. Więc po tych doświadczeniach także uważam że baskom to nieporozumienie.
Otóż to, każdy język dopuszczający case ins. jest bałaganiarski z natury, szczególnie dla winusera, który jest do tego przyzwyczajony np. FS. Jeden czy drugi pedant tego nie zmieni.
Dziwi mnie ta opinia. Z czasów programowania w pascalu pamiętam ile dobrego dla porządku w kodzie wynikało z niewrażliwości na wielkie litery. Choćby stosując pary BEGIN-END, Begin-End, begin-end dawało się lepiej przedstawić strukturę programu. Bardzo cenne w czasach, kiedy nie było edytorów kolorujących kod i sprawdzających składnię.
Jasne, że są języki, w których szczególnie łatwo nabałaganić, ale nigdy bym nie wpadł na to, że "case ins." ktoś może uznać za główny element sprzyjający.
To że tak można nie oznacza że trzeba. Można puszczać bąki, ale przecież nie robi się tego publicznie.
Pierwszy błąd: dlaczego a, dlaczego b? Czy b jest też wskaźnikiem? Nic nie mówiące nazwy, sugerujące że a, b, c to tego samego typu... Ale jaki sens ma zmiana znaku wskaźnika?!
"Nie czepiał się"?! Przecież tu się nawet nie na czego czepiać, ani na co przymykać oka -- bo to "case ins." w kontekscie porządku w kodzie nie jest mankamentem, a wręcz przeciwnie. O innych wadach różnych języków można długo, ale są to rzeczy dość powszechnei znane. A w każdym razie nie tak zaskakujące, jak opinia o dowolności stosowania wielkich liter, która prowadzi do bałaganu w programie.
Fortran jest językiem zaprojektowanym w czasach, gdy komputery posługiwały się alfabetem sześciobitowym, w którym były tylko wielkie litery. Więc nawet trudno go wprost zaliczyć do "case ins." -- po prostu ten problem tam nie istnieje. Ma on za to osobliwe podejście do spacji -- tego znaku nie ma w jego alfabecie, jest on całkowicie ignorowany przez kompilator, spacje można umieszczać w dowolnych miejscach. Nawet we wnętrzu nazw zmiennych i słów kluczowych. Ta oszczędnośc jest poważnym mankamentem, jego najbardziej znaną implikacja jest całkowita zmiana sensu instrukcji gdy przecinek zostanie omyłkowo zamieniony na kopkę. Zapis "DO 10 I=1,32" oznacza pętlę wykonywaną 32 razy z inkrementacja zmiennej "i". Natomiast "DO 10 I=1.32" jest równoważnie stworzeniu zmiennej rzeczywistej "do10i" i przypisaniu do niej wartości "1,32". O tym wszyscy wiedza i się pilnują. Ale z drugiej strony wiedzą też, że można w tym języku tworzyć czytelne wielowyrazowe nazwy dla zmiennych i funkcji -- "TABLICA STANOW WEJSCIA" to w tym języku całkiem dobra nazwa. Po prostu mając "space ins." da się napisać bardziej czytelny kod (choć nabałaganić też można).
Otóż to, każdy język dopuszczający case ins. jest bałaganiarski z natury, szczególnie dla winusera, który jest do tego przyzwyczajony np. FS. Jeden czy drugi pedant tego nie zmieni.
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.