On 2012-01-08 23:24, Sebastian Biały wrote: [.....]
Ale to nie znaczy, że C tudzież C++ jest takie świetne a Pascal jest do bani. Jeśli mówimy o programowaniu uC to w C da się "szybo pi..ąć szybkiego pacza" i to jest IMO główny powód dla którego C jest popularne wśród ludzi piszących soft na uC. :-) Co z kolei w połączeniu z brakiem doświadczenia i bliską zeru wśród elektroników wiedzą na temat prowadzenia projektów software-owych prowadzi do powstawania programistycznych koszmarów. C daje dużą swobodę i dlatego IMO nie jest to dobry język dla początkujących ponieważ trzeba wiedzieć co się robi. Z drugiej strony działającej i powszechnie dostępnej alternatywy wymuszającej dobre praktyki (np. Ada) na popularne uC za bardzo nie ma...
Poza tym AFAIR to informatycy (ci zajmujący się dydaktyką) twierdzą, że Pascal *nadal* jest niezłym językiem do dydaktyki.
On 2012-01-09 02:04, RoMan Mandziejewicz wrote: [.....]
Dla wygody, kolego, dla wygody. Wygody programowania. Odpada wiele problemów, zwłaszcza wtedy, gdy rozmiar kodu i/lub danych zacznie ocierać się o granicę 64KiB. IMO w przypadku projektów które mają być wdrożone w małej ilości egzemplarzy zupełnie nie ma co zawracać sobie głowy ośmiobitowcami aby zoptymalizować koszty.
Plus wymienione w wątku Wiring i Ada, jest python na mikrokontrolery, NesC też jest bardzo przyjemne i wydajne, znajdzie się pewnie jeszcze kilka innych języków. Jest w czym wybierać.
Ja też zaczynałem otumaniony bo za dużo tego na raz, w końcu kupiłem sobie
formatting link
razem z zestawem uruchomieniowym i programatorem. Wiadomo że płytkę można sobie samemu, ebooka w pdf się ściągnie itp. ale tutaj masz wszystko podane na tacy, zestaw jest akurat dla średnio kumatego elektronika który chce sobie pomrugać diodami i ponaciskać guziki.
O ile MSP uważam za wspaniałą rodzinkę procesorów, to jednak bym uważał z polecaniem Launchpada komuś kto dopiero zaczyna zabawę. A jeśli już to razem z samplami MSP430G2553. O ile TI nie uaktualnił zestawu dołączanych kostek, to procesory w zestawie mają bardzo ograniczone możliwości sprzętowe.
Może i ograniczone, ale dostajesz je praktycznie za darmo. A parę rzeczy można na tym zrobić. Mój miernik impedancji elektrod, na przykład, chodzi też na kostkach z zestawu. Trochę akademicko sprawdzałem, bo już mam gotową płytkę na F2013, ale się da. Albo proste międzymordzie do klawiatury pojemnościowej. Program jest już gotowy, dorabiasz tylko wyjście do reszty systemu i jazda. A te trochę większe procki serii G można sobie zasamplować. W każdym razie polecam zainteresowanie się tym procesorem, bo świetnie nadaje się do zastosowań bateryjnych. A
16-bitowe ADC w niektórych prockach serii F też piechty nie chodzi. OK, wyciągnie się 14 bitów, ale te bez specjalnej gimnastyki i modłów do wszystkich bogów.
Podpisuję się pod tym wszystkimi łapami. Ale tylko jeśli ktoś wie co robi. IMHO brak sprzętowego UARTU dyskwalifikuje małe procesory z serii G2 do zaczynania zabawy z mikrokontrolerami. Programowy uart może być za trudny do opanowania, a poza tym zjada sporo zasobów. Na 2kB flasha też się nie poszaleje. Dlatego też wspomniałem o samplach MSP430G2553. Ma wszystkie peryferia niezbędne do rozpoczęcia zabawy i 16kB flasha. Sensowną alternatywą dla launchpada i sampli jest zestaw Experimenter Board dla nowej serii procesorów MSP z pamięcią FRAM zamiast flasha. Ale kosztuje trochę drożej niż launchpad :(
Pascal JEST językiem do dydaktyki. Ma jednak lekką niechęć do programowania blisko hardware. Konkretnie w Pascalu tak jak bóg (znaczy Wirth) go stworzył nie ma możliwości adresowania komórek pamięci (ok, da się poprzez przypisanie stałej do wskaźnika, ale ładnie to nie wygląda), a do przerwań czy, o zgrozo, multithreadingu wogóle nie ma ładnej możliwości. Delphi jest pewnym krokiem od dydaktyki do produkcji, ale ten koń też już zaczyna śmierdzieć.
Co do mikroprocesorów, to C jest kompromisem między assemblerem, a "porządnym" językiem. Im mniejszy mikrokontroller, tym bardziej mamy tylko te 2 języki jako alternatywy. A ładnie programować można w dowolnym języku i na odwrót. Jak mamy większe kostki, to już zaczyna być wygodniej, aż do składania programów z graficznych "kostek", jak to mają co poniektóre PLC. Albo LEGO MasterMind (R). Tam sobie układasz klocki LEGO na ekranie i toto nawet działa ;-).
Osobiście znam trochę tych języków programowania. Programy popełniłem chyba w 30 językach, większość jednak to dydaktyka na uczelni (też jako nauczyciel). Poczynając od Fortranu, przez wsie Algole, Prolog, LISP (od tego miałem rekurencyjne sny ;-)), a nawet jakiś śmieszny programik w Cobolu na zaliczenie. W tej chwili używam C lub C++ na PCcie, C lub Assembler na mikroprocesory. No i ostatnio jakiś Arduino ze swoim "prawie-C", albo procesor graficzny z 3GC, czy jak temu dialektowi. Jak się umie programować, to język właściwie obojętny. Ale to chyba tak, jak z językami obcymi: tych 0x10 pierwszych sprawia problemy, następne wchodzą jak przez masło ;-). Warto wiedzieć, że im bardziej abstrakcyjny (i wymuszający dobre praktyki) język, tym trudniej jest optymalizować kod. Pisząc program zajmujący mało pamięci i szybki musi się myśleć kategoriami procesora. Trzeba wiedzieć gdzie są tworzone zmienne, unikać konwersji między różnymi strukturami danych, conieco pozostawić w rejestrze. Przy przerwaniach ratować tylko te rejestry, na których operujemy i podobne cuda. Już w C coponiektórzy wywalili się na prostym printf. Program miał powiedzmy 1k, dodano jedną linijkę z printf i już ma 20k, albo i więcej. Bo się całą bibliotekę zmiennoprzecinową dolinkowało, choć tego nie trzeba.
On 2012-01-09 16:53, Jacek Radzikowski wrote: [.....]
W przypadku Ady wybór jest raczej czysto teoretyczny ponieważ nie ma dobrego taniego bądź darmowego kompilatora. A przynajmniej ja takowego nie znam. Zresztą Green Hills nie oferuje narzędzi na "drobnicę" typu AVR, H8 czy MSP430. Natomiast AVR-GCC jest AFAIK od kilku ładnych lat w powijakach. Swoją drogą swego czasu nawet sam myślałem aby zrobić coś takiego dla H8/300H i H8S.
Python? Ale to chyba masz na myśli (typowe) używanie go jako embedded command interpreter a nie jako kompilowany język masowego rażenia do którego wkładasz źródła a wyjmujesz binarkę do wypalenia w jakimś ROM-ie. Zresztą Python ze względu na dynamiczność typów i automatyczne zarządzanie pamięcią IMO raczej słabo nadaje się do tworzenia oprogramowania systemowego. Chociaż jako język osadzony rzeczywiście jest w porządku.
Wiring? O tym mówisz
formatting link
Nie znam, ale wygląda na to, że używanymi tam językami są C i C++. :-) Poza tym Wiring nie jest językiem programowania. :-)
NesC? O to chodzi
formatting link
Nie znam, ale wygląda na jakiś mocno specjalizowany język. Bazowany na C. :-)
IMO jeśli się przyjrzysz to za bardzo nie ma w czym wybierać. Bo albo brakuje kompilatorów (wspomniana Ada) albo sam język programowania niejako z definicji niezbyt pasuje do (takiego prawdziwego niskopoziomowego) embedded software developement (wspomniany Python czy tez mój ulubiony Eiffel).
Dłubanie po gołej pamięci odbywa się znacznie sprawniej w C niż w Pascalu. Ludzie od uC lubią dłubać jak w asm. Z resztą wiekszość kodu na uC wyglada jak asm. Pascal mocno to ogranicza. Zapewne z tego powodu przyjął się też Verilog. VHDL jest zbyt restrykcyjny i gadatliwy, a korzenie z Pascalem wspólne.
Albowiem? Przy czym zaznaczam że też byłem rzeczonym informatykiem zajmującym się dydaktyką. Nie jestem w stanie, mimo najlepszych chęci, znaleźć choćby pół powodu.
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.