HomeMade

Większości osób wydaje się że bejziki na procesory to tylko na avr i bascom. Tu do nauczenia polecam świetną książkę Piotra Góreckiego Mikrokontrolery dla początkujących. Bascom do 8kB jest darmowy w zastosowaniach niekomercyjnych.
Są również całkowicie darmowe bejziki obsługujące np. pic-e i avr
np. wielka krowa
http://gcbasic.sourceforge.net/
na pic-e bardzo dobry ze świetną pomocą
http://picforge.interfree.it/
darmowy na większość procków pic-a bez pgraniczeń kodu
jeszcze jeden na pic-e
http://www.oshonsoft.com/pic.html

na arm-y
http://www.mikroe.com/eng/product_downloads/download/
micro basic darmowy do 8 kb kodu
I tutaj bardzo ważna uwaga ten basic daje np. bardziej optymalny kod wynikowy w większości zastosowań niż np. eclipse (język c), jakość kodu wynikowego nie zależy od zastosowanego języka a od jakości kompilatora. Chciałbym w tym miejscu podziękować Danowi Andersonowi M0DFI od któego pochodzi duża część z zamieszczonych tu informacji.

jeszce kilka gdzies spotkałem.. ale jest tego więcej...

http://www.fastavr.com/


http://www.protonbasic.co.uk/


http://pl.wikipedia.org/wiki/BASIC_Stamp
http://www.parallax.com/tabid/295/Default.aspx


http://www.picaxe.com/

Cześć,
Jest jeszcze PASCAL to znaczy mikroPascal for AVR oraz mikropascal for Pic. Do Pascala czuję największy sentyment, były to moje pierwsze poważne projekty w Delphi Borland for Windows (a jeszcze wcześniej pod MS-DOS z intefejsem okienkowym Turbo Pascal - co to były za czasy hi!). Polecam bardzo dobrą książkę Pawła Borkowskiego "Programowanie mikrokontrolerów AVR&ARM7 dla każdego", gdzie "łopatologicznie" każdy z projektów (od diody poprzez LCD i w końcu USART, EPROM) jest bardzo szczegółowo przedstawiany każdy projekt od A-Z w kolejnych językach: Asembler, C, Basic i Pascal.
73 Bogdan, SP3IQ.

(19-02-2012 23:26)SQ4AVS napisał(a): [ -> ]I tutaj bardzo ważna uwaga ten basic daje np. bardziej optymalny kod wynikowy w większości zastosowań niż np. eclipse (język c), jakość kodu wynikowego nie zależy od zastosowanego języka a od jakości kompilatora.

Rafał, niestety problem jakości kodu jest bardziej złożony. Jakość kodu wynikowego zależy od:
- umiejętności i doświadczenia programisty;
- języka programowania;
- jakości użytego kompilatora oraz strategii kompilacji.

Przy złożonych projektach programista jest najważniejszy, jego doświadczenie oraz wiedza pozwala budować optymalne algorytmy i zwięzły kod programu. Brak wiedzy i doświadczenia skutkuje robieniem wszystkiego prostymi metodami "na piechotę". Przykład, procesory AVR mają sprzętowy I2C, SPI a część programistów stosuje obsługę programową (czas obsługi, wielkość kodu).

Istotnym czynnikiem decydującym o kodzie wynikowym jest język programowania. Dlaczego ?
Ponieważ możliwości poszczególnych języków są bardzo różne. Basic daje spore możliwości ale nie posiada wielu mechanizmów języka C (tablice wielowymiarowe, wskaźniki, struktury danych, unie, rekurencja, alokacja pamięci itd.) co przy rozbudowanych algorytmach decyduje o efektywności generowanego kodu. Powstawanie nowych języków programowania zawsze było związane z dodawaniem nowych możliwości poprawiających efektywność programowania.

Prawdą jest, że kompilator kompilatorowi nie jest równy co skutkuje jakością kodu wynikowego. Komercyjne kompilatory dedykowane na wybrany procesor zawsze będą bardziej optymalne od kompilatorów darmowych (prz. GCC vs. CodeVision na AVR). Porównywanie kodu wynikowego różnych języków jest już trudniejsze i nie zawsze jednoznaczne. Oczywiście może tak się zdarzyć, że marny kompilator C da przy prostych algorytmach kod gorszy niż Basic. Generalnie jednak przy tym samych umiejętnościach programisty najoptymalniejszy będzie kod w assemblerze potem w C a najsłabszy w Basicu. Proponuję napisać sobie prostą obsługę przerwania sprzętowego w poszczególnych językach i zobaczyć generowany kod wynikowy.

Ważnym czynnikiem jest strategia programisty: co jest ważniejsze szybkość pracy czy wielkość kodu wynikowego. Czasem programista świadomie rezygnuje z optymalizacji wielkości kodu w celu uzyskania maksymalnej szybkości realizacji algorytmu. Takie języki jak C oraz ich kompilatory mają zaimplementowane mechanizmy pozwalające na elastyczną zmianę strategii w poszczególnych modułach programu.

(22-02-2012 1:50)SP5FCS napisał(a): [ -> ]... Brak wiedzy i doświadczenia skutkuje robieniem wszystkiego prostymi metodami "na piechotę". Przykład, procesory AVR mają sprzętowy I2C, SPI a część programistów stosuje obsługę programową (czas obsługi, wielkość kodu).

Proszę o wyjaśnienie - na chłopski rozum, sprzętowe, np. I2C powinno chodzić szybciej.
Czy się mylę ?

Adamie dzięki za wyjaśnienia. Powiem szczerze opierałem się głównie na opini Dana któy programować umie i tak naprawde chodziło mu o porównanie darmowego kompilatora C na ARM z wymienionym Basicem na ARM. Na pewno masz rację wszystko może zależeć od sposobu realizacji projektu i wymagań mu stawianych w konkretnym przypadku i stąd jakaś przewaga jednego kompilatora nad innym a konkretnie C i AVR. Ponadto bejziki na procesory są sobie bardzo nierówne i odbiegają bardzo między sobą możliwościami, poleceniami. Jeśli sie myle popraw mie. Bardzo pozytywnie byłem zaskoczony Twoją opinią na temat Bascoma w dziale Marcina o C ;-). Apropo CodeVision obejrzałem go sobie i jest to naprawdę bardzo sympatyczny kompilator.

(22-02-2012 10:13)SP4EJT napisał(a): [ -> ]Proszę o wyjaśnienie - na chłopski rozum, sprzętowe, np. I2C powinno chodzić szybciej.

Nie chodzi tutaj o samą komunikację I2C, bo jej prędkość określa standard i wynosić maksymalnie 100kbps czyli sygnal zegara SCL powinien maksymalnie mieć 100kHZ. Później dodany tryb pracy Fast Mode gdzie szybkość zegara poniesiono do 400 kbps, a jeszcze później 3,4Mbps.

Mam tutaj tą samą różnicę co miedzy sprzętowym i programowym UART-em.

Napisanie programowej komunikacji wymaga od nas trzymania się norm czasowych dotyczące czasów trwania sygnałów. Najczęściej procesor stoi i czeka na odliczenie pewnego opóźnienia, (przykładowo dla 10MHz zegara procesora i 100kbps jest to 50 cyklów zegarowych) w czasie którego nic nie robi.

Jeśli program jest mały i obsługuje tylko jeden układ nie jest to problem, ale w przypadku bardziej złożonych ten czas jest cenny i wykorzystuje się na przykład przerwanie od timera, aby co odpowiedni czas zmieniać stan lini SDA i SCL.

W przypadku programowego, sprawa jest prosta i wymaga od nas kontroli czterech rejestrów, aby sprawdzić czy dane sekwencja transmisji się zakończyła, czy odbiorca potwierdził poprawność i przygotować do kolejnej sekwencji. Samą transmisją zajmuje się układ sprzętowy, a my możemy w tym czasie zająć procesor czymś innym. Musimy tylko co pewien czas sprawdzać czy dane sekwencja transmisja się skończyła.

Sekwencje to: Zainicjowanie transmisji i wysłanie sygnału start, wysłanie adresu, wysłanie (odebranie danej), sygnał stop.

Przy okazji słów Adama, tak dla przykładu chciałbym pokazać pewien problem, który niedawno miałem przy pisaniu programu w C na AVR-a, i chciałbym również aby koledzy zaproponowali jak by to rozwiązali, na końcu porównam i pokaże jak ja to rozwiązałem.

Problem jest prostu, w danym bajcie zamienić kolejność bitów, dla ścisłości chodzi tylko o 4 pierwsze bity, czyli zamienić miejscami 1<-->4, 2<-->3. Rozwiązanie tego problemu w Asemblerze jest banalnie proste, bo są odpowiednie rozkazy do operacji na bitach, ale C który nie ma takich operacji już stwarza pewne problemy. Chodzi oczywiście o zastosowanie takiego kodu, który po kompilacji da nam najmniejszy kod wynikowy.

napisze Ci mój pomysł chociaż Cię nie lubię bo uciekłeś z mojego wątku o C - miałeś wyjaśnić jak sie tworzy pliki nagłówkowe !
to oczywiście tylko dla pierwszego i czwartego bitu.

Trochę mnie zaskoczyłeś rozwiązaniem, nie olśniło nie, ale ciekawy jestem jaka wielkość kodu wyjdzie.

(23-02-2012 19:48)SP4EJT napisał(a): [ -> ]miałeś wyjaśnić jak sie tworzy pliki nagłówkowe !

Jeszcze wrócę

(22-02-2012 10:53)SQ4AVS napisał(a): [ -> ]Bardzo pozytywnie byłem zaskoczony Twoją opinią na temat Bascoma w dziale Marcina o C ;-).

Pisanie programów na procesory wymaga znajomości języka, dokładnego poznania wewnętrznej struktury procesora oraz poznania technik programowania. W hobby najważniejsze jest jak najszybsze osiągnięcie zamierzonego celu przy minimalnych nakładach czasowych. W oparciu o taką filozofię został opracowany Bascom, język o prostej i czytelnej składni z maksymalnym wsparciem obsługi zasobów procesora. Gotowe funkcje języka do obsługi zasobów procesora zwalniają nas z konieczności studiowania setek stron jego wewnętrznej budowy. Dobra dokumentacja, help po polsku, dostępność setek różnych przykładów, wiele gotowych aplikacji ułatwia naukę i pisanie własnych programów. Jeśli możliwości Bascoma zaspakajają nasze potrzeby to wszystko jest OK i możemy skupić się na doskonaleniu technik programowania i zdobywaniu doświadczenia. Z powyższych powodów uważam, że Bascom jest dobrym wyborem na wstępnym etapie nauki programowania.

(22-02-2012 10:53)SP4EJT napisał(a): [ -> ]Proszę o wyjaśnienie - na chłopski rozum, sprzętowe, np. I2C powinno chodzić szybciej.

Różnica pomiędzy sprzętową a programową obsługą różnych interfejsów procesora wiąże się z różną wielkością generowanego kodu programu oraz pochłanianym czasem pracy procesora.
Podczas obsługi programowej np. transmisji szeregowej procesor cyklicznie w pętli wystawia na pin pojedyncze bity, oblicza opóźnienie, sprawdza zakończenie nadania całego bajtu. Taki algorytm generuje spory kod programu oraz pochłania dużo czasu procesora.
Sprzętowa obsługa komunikacji wymaga bardzo mało kodu i minimalnie absorbuje procesor ponieważ to zadanie wykonuje sprzętowo określony fragment procesowa. W trakcie sprzętowego nadawania bajtu CPU jest wolne i może realizować inny fragment algorytmu. Sprzętowa obsługa zasobów procesora na przerwaniach jest najbardziej efektywną metodą wykorzystania czasu procesora oraz pozwala na równoległe obsługiwanie wielu wątków algorytmu.

Dlatego w wielu przypadkach jakość programu bardziej zależy od wiedzy i doświadczenia programisty niż od języka programowania .