WinAvr (avr-gcc) kontra Bacsom-AVR

I niewykluczone ze masz racje. Ale ten programik jest mniejszy, zadnych skomplikowanych operacji :-)

J.

Ja ci przyznam racje ze pomoca goto mozna narobic takiego bigosu ze sie nikt nie zorientuje jak to zadziala. Ale nie widze powodu dla ktorego rozsadne uzycie mialoby utrudniac - np wlasnie wyjscie z zagniezdzonej petli.

Hm .. jestem w stanie dowolny program zapisac w postaci jednej petli, w ktorej bedzie multum if i pomocniczych zmiennych logicznych. Ciekawe co na to weryfikator :-)

Taa .. tylko juz 8 bajtow pamieci powoduje liczbe stanow przekraczajaca mozliwosci praktyczne dzisiejszych komputerow :-)

Dla nieokreslonej ilosci liczb ?

Nawiasem mowiac - quick sort mi sie zawiesil. Podejrzewam ze powodem byla arytmetyka zmiennoprzecinkowa o mantysie innej niz 2 - w rezultacie srednia arytmetyczna dwoch liczb mogla wyjsc mniejsza niz obie liczby, co prowadzi do zawieszenia algorytmu .. chyba Dijkstry ?

J.

Oj, ale my od pewnego czasu rozmawiamy o zupelnie innym problemie. :-))) Mowa o "robieniu bigosu" przez goto byla w kontekscie prostych algorytmow analizy _przeplywu_. Pozniej rozmowa zeszla na temat analizy _zywotnosci zmiennych_.

Jesli tych zmiennych logicznych bedzie ograniczona liczba (tj. nie bedziesz ich sobie dorabial podczas dzialania programu), to nie uda Ci sie dokonac takiego przeksztalcenia. Rozpoznawanie dowolnego jezyka nieregularnego dla slowa o dlugosci n wymaga Omega(log log n) komorek pamieci, czyli wiecej, niz stalej ich liczby...

Wbrew pozorom one bardzo lubia takie grafy decyzyjne. :-) Powiem wiecej, one czesto w srodku trzymaja sobie opis podanego przez uzytkownika systemu w takiej wlasnie formie.

Jesli sie eksploracji przestrzeni stanow dokonuje metoda brute force, to tak wlasnie jest. Na szczescie wymyslono wiele algorytmow pozwalajacych analizowac za jednym zamachem olbrzymie grupy stanow -- w jaki inny sposob w ciagu 15 lat udaloby sie powiekszyc nasze mozliwosci o 113 rzedow? :-)

Nie dam glowy, ale chyba tak (dawno to czytalem). Tu znajdziesz kilka publikacji na ten temat:

Nie uwazam tak, napisalem ze trzeba zajac sie samemu tym problemem wiec przewidziec sytuacje ktorych kompilator nie potrafi przewidziec a czlowiek ktory pisze program jest je w stanie przewidziec.

PS. ;] troche niezrowumiale wyszlo.

Pozdrawiam Thomek

Jest sobie darmowy RTOS eCos napisany w asm (HAL), C (wszystkie podsystemy i sterowniki) i C++ (kernel!). Może lepiej rozwijać gotowe rozwiązania ?

On Mon, 27 Sep 2004 13:39:24 +0200, "Piotr Wyderski" snipped-for-privacy@ii.uni.wroc.pl> wrote: [.....]

IMHO to proste - tzw. "przemysł" nie lubi zmian. A skoro klient nie widzi kodu źródłowego aplikacji, to po co dbać o jego przejrzystość i elegancję jeśli aplikacja działa poprawnie? :-) Poza tym "wszyscy" znają C więc producenci produkują kompilatory i biblioteki C, a skoro producenci robią narzędzia do C, to "wszyscy" uczą się C. I błędne koło się zamyka. A przerwać je trudno bo w powszechnym mniemaniu C++ daje wielokrotnie wolniejszy i pamięciożerny kod wynikowy - ludzie również nie lubią zmian i nie przyjmują do wiadomości że pewne rzeczy się zmieniają. :-) Zobacz np. ile osób rzeźbi w assemblerze tam gdzie z praktycznego punktu widzenia nie ma z tego żadnych korzyści. No i jest jeszcze jedna rzecz - o ile stosnkowo łatwo jest nauczyć się C++, to aby je efektywnie wykorzystywać trzeba zmienić sposób myślenia. A to IMO jest znacznie trudniejsze. Zapewne sam widziałeś wiele programów napisanych w "C z obiektami". :-)

Na wnętrznościach kompilatorów się nie znam, ale jestem przekonany że aplikacja "napisana obiektowo" w C i skompilowana kompilatorem C będzie trochę mniej wydajna niż ta sama aplikacja przepisana na C++. W przypadku nietrywailnej aplikacji kompilator C++ raczej lepiej niż człowiek "zaimplementuje" obiektowość. :-)

BTW. Bez RTTI i dynamic cast można spokojnie żyć, ale wyjątki by się przydały. Oglądałem kod wygenerowany przez g++ i tam try jest rozwijane w wywołanie procedury __cxa_allocate_exception, throw w wywołanie __cxa_throw itp. Jak się domyślam, są to funkcje wbudowane w kompilator. I tak się zastanawiam czy rzeczywiście stanowią one duży problem jeśli chodzi o wymagania szybkościowo- pamięciowe. Bo tak na chłopski rozum to wydaje mi się że one wykonują jakieś szybkie operacje na stosie (alokacja pamięci dla rzucanego obiektu) i ewentualnie wołają konstruktor (w przypadku "rzucania" typów złożonych). Co tutaj może być problemem? Przepełnienie stosu? Przecież takie coś może się zdarzyć nawet wtedy gdy używamy C lub assemblera. I jeszcze jedno - czy w throw/try/catch są thread safe z mocy standardu C++, nie są thread safe, czy też jest to zależne od kompilatora?

Regards, /J.D.

Tylko musisz sobie znale¼æ ze 2 miesi±ce wolnego ;)))

Sorry, ale rozbawi³y mnie te dywagacje nad wy¿szo¶ci± ¦wi±t .... Ludzie czy to ma znaczenie w jakim jêzyku piszemy ? Najwa¿niejsze, ¿eby program by³ napisany z g³ow± i dobrze zoptymalizowany ju¿ w trakcie pisania. Jakby nie spojrzeæ dobra optymalizacja jest wynikiem do¶wiadczenia. To, ¿e sam Bascom nie jest oszczêdny to wcale nie oznacza, ¿e jest gorszy. Ja tam wolê zamiast siê mêczyæ ze sk³adni± C , która jest ukierunkowana na sprzêt, a nie na programistê napisaæ ten program o wiele szybciej w Bascomie, który nie stwarza tylu problemów. Zamiast siedzieæ tydzieñ, zrobiæ to samo w 1 lub 2 dni. Wszystko jest oczywi¶cie kwesti± przyzwyczajenia i dopasowania siê oraz wprawy. A na zbyt du¿y kod jest prosta rada - do³o¿yæ 10z³ i kupiæ wiêkszego procka. Z reszt± dziwi± mniê czasami widziane projekty oparte na jakim¶ ma³ym procesorze, który dodatkowo wyposa¿ony jest w uk³ady we/wy w postaci PCF8574 oraz pamiêci EEPROM. Przecie¿ wydaj±c te same pieni±dze mo¿na spokojnie kupiæ bardziej wypasionego procka, dziêki czemu tak¿e zmniejszy siê nasz kod, poniewa¿ odejd± procedury obs³ugi I2C dodatkowych uk³adów.

Ja tam ceniê sobie wygodê, szybko¶æ pisania i uruchamiania uk³adu. A je¿eli zale¿y mi na szybko¶ci procedur wtedy wstawki assemblerowe. Suma-sumarum pisanie w Bascomie mo¿e okazaæ siê porównywalne z C++ Oczywi¶cie wszystko zale¿y co kto lubi i w czym siê dobrze czuje. Dla przyk³adu kiedy¶ postanowi³em nauczyæ siê ST-Realizera. Dla tych co nie wiedz± - jest to obrazkowy jêzyk programowania :) tzn. rysuje siê algorytmy. Niby ³atwiejszy od Assemblera, C++, czy nawet Bascoma. Jednak mi to nie le¿y i ³atwiej jest mi siê nauczyæ tych trudniejszych jêzyków ni¿ Realizera. Jednak nie jest to powód, ¿ebym go uwa¿a³ za co¶ gorszego - po prostu nie odpowiada mi i ju¿. Na nic siê zda³ zakup literatury do Realazera. Ale mo¿e kiedy¶ siê prze³amiê i siêgnê i po to narzêdzie :)

A w Bascomie przede wszystki ceniê sobie zwarte ¶rodowisko i masê gotowych procedur. Niestety AVR GCC nie daje takiej wygody pracy.

Jacek "Plumpi"

Bo to czasem ciekawe nawet :-)

To masz dobrze. U mnie kilka prockow, zadnych AVR :-) wiec co mialem wybrac? C/C++ jest i na procki i na PCty - wiec latwo bylo sie zdecydowac. Zreszta C++ na wieksze procki coraz bardziej mnie zaczyna wciagac - naprawde mocne narzedzie. (Dzieki Piotrowi Wyderskiemu sie tym troche zainteresowalem - warto).

Zalezy jaki program, jaka rodzina prockow, itp, itd... U mnie zwiekszenie kodu ponad 256kB bedzie skutkowac koniecznoscia zmieniania plytki 6 warstwowej (tylko taki RAM tam siedzi).

avr-gcc nie znam, ale skoro gcc to moze... emacs? :-)

On Mon, 27 Sep 2004 20:47:28 +0200, point snipped-for-privacy@.org wrote: [.....]

Znamy, znamy. :-) Tzn. teoretycznie ponieważ wielokrotnie studiowałem źródła eCosa, ale nigdy go nie uruchamiałem na żadnym sprzęcie. Ja myślałem o czymś mniejszym, np. czymś w stylu Nut/OSa ale z wywłaszczaniem a nie cooperative multitasking i napisanego w języku wspierającym obiektowość.

Regards, /J.D.

On Mon, 27 Sep 2004 22:22:14 +0200, "Jacek \"Plumpi\"" snipped-for-privacy@wp.pl wrote: [.....]

No nie wiem. Zdaje się Knuth powiedział że "premature optimization is the root of all evil". Innymi słowami po prostu lepiej klepać soft jak leci a potem, jeśli okaże się że nie spełnia on wymagań, szukać wąskich gardeł i eliminować je poprzez poprawianie/dobór odpowiedniego algorytmu, struktur danych i na końcu stosowanie sztuczek typu ręczne rozwijanie petli czy też stosowanie wstawek assemblerowych. Oczywiście obecnie odpowiednie algorytmy i struktury danych można dobrać przed rozpoczęciem pisania softu ponieważ można wcześniej przeczytać sobie książkę, np. autorstwa wspomnianego Knutha. :-)

Bascom ma jedną zasadniczą wadę - przesiądziesz się na coś innego niż AVR czy MCS-51 i nie będziesz miał Bascoma. A kompilator C będzie prawie napewno.

W jaki sposób jest składnia ukierunkowana na sprzęt? A jeśli nawet, to jest dobrze ukierunkowana ponieważ sporo softu przeniesionego z jednej platformy na inną da się skompilować bez żadnych modyfikacji. :-)

A to już zależy od aplikacji. Bascom nic nie pomoże jeśli będziesz chciał zaimplementować np. PPP. Bo dominującym czynnikiem będzie tutaj czas poświęcony na studiowanie RFC dotyczących PPP. A jest tego trochę. No i jeszcze trzeba doliczyć czas potrzebny na debugowanie i testowanie - kto wie czy nie dłuższy od tego pierwszego.

Regards, /J.D.

A to jest ciekawe zjawisko. Przeciez (z drobnymi wyjatkami) kod napisany w C daje sie od skompilowac kompilatorem C++. Schematy translacji sa takie same, optymalizator i generator kodu wynikowego sa wspolne. Roznice sa praktycznie tylko w czesci odpowiedzialnej za przeksztalcenie kodu zrodlowego na wewnetrzna reprezentacje posrednia (ktora podlega nastepnie optymalizacji i z ktorej sie generuje kod wynikowy). Co do pamieciozernosci, to tu jest troche prawdy, ale to w sporej czesci wynika z braku doswiadczenia w projektowaniu obiektowym. A jak ktos chce, to sobie moze przeciazyc operator new i dostac _calkowita_ kontrole nad przydzialem pamieci.

Hm, to bardzo odwazna opinia. :-) Mam taka hipoteze, ze nikt na swiecie nie zna calego C++. Owszem, mozna latwo opanowac podstawy i zyc w przekonaniu, ze sie doskonale opanowalo ten jezyk, ale z czasem sie odkrywa jak malym jego fragmentem jego wlasnosci sie poslugiwalo. Wez na przyklad programowanie generyczne, tam sie bez przerwy odkrywa nowe rozwiazania. Jesli masz ochote, to sprobuj zdobyc np. "Modern C++ Design" Andrei'a Alexandrescu, zobaczysz, co mam na mysli.

BTW, sam system typow w C++ jest Turing-zupelny, czyli rownowazny dowolnemu komputerowi. Innymi slowy: mozna w samych typach zapisac dowolny program komputerowy, wykonywany w czasie kompilacji. :-)

Przede wszystkim w taki sposob, by nie trzymac sie slepo jednego paradygmatu (np. obiektowego, strukturalnego itd.) w nadziei, ze gwarantuje on sukces. Gdyby tak bylo, to by dzis istnial jeden doskonaly, uniwersalny jezyk programowania, a nie tysiace. Wielu rzeczy po prostu nie wolno robic np. obiektowo, bo -- jak to ktos obrazowo ujal -- ta obiektowosc pasuje do problemu jak garbaty do sciany. :-)

Sam w taki sposob pisalem, gdy uwazalem, ze znam C++. :-)

No, to zalezy jak sie ten program napisze, ale... czytelnie, wydajnie, w C

-- wybierz dwie dowolne cechy. :->

Calkowicie sie zgadzam, nigdy z tego mechanizmu w praktyce nie korzystalem. Jak sie okazuje konieczne uzycie w C++ takich rzeczy, to najczesciej jest to glosny dzwonek ostrzegawczy, ze z cos jest zle ze struktura koncepcyjna programu.

Wydajnosc spada niewiele, byc moze prawie wcale. Problem stanowia wymagania pamieciowe: zazwyczaj wyjatki sa impelmentowane z wykorzystaniem pomocniczego stosu. Na pececie to zaden problem, bo kogo obchodzi ten dodatkowy kilobajt zuzycia RAMu, ale jak ma sie mikrokontroler o 256 bajtach pamieci, to nie bardzo jest gdzie umiescic dwa stosy i jeszcze obszar danych statycznych. A ze sie bardzo przydaja, to inna sprawa. :-)

Heh, znalezienie miejsca na ten stos w ogole. :-)

Szczerze mowiac nie bardzo rozumiem problem. Wyjatki to jest mechanizm wybitnie lokalny, kazdy watek ma osobny stos wyjatkow i niezaleznie obsluguje sekcje try/catch, wiec w ktorym miejscu ma sie pojawic interferencja?

Pozdrawiam Piotr Wyderski

Na 51 tak¿e jest Bascom. A co do Bascoma - no có¿ ? Póki co rozwijany jest przez jednego autora w porównaniu do C czy C++ I to chyba jest problemem. Chocia¿ istniej± kompilatory Basica na ró¿ne rodziny mikrokontrolerów.

Nie przesadzaj i nie opowiadaj bajek. Tak samo mo¿na powiedzieæ o Basicu czy konkretnie o Bascomie. Niestety zarówno w Bascomie jak i w C++ istniej± odwo³ania do konkretnych bloków mikrokontrolera, do portów lub innych urz±dzeñ funkcjonalnych np. przetworników, sprzêtowych PWM, ISP czy kwestia innej konfiguracji UART lub przerwañ, które uniemo¿liwiaj± bespo¶rednie przeniesienie programu na inny procesor.

A mo¿e nie wywa¿aæ otwartych drzwi i skorzystaæ z gotowych rozwi±zañ, nieco modyfikuj±c do w³asnych potrzeb ?

A co do studiowania - to chyba nie jest zale¿ne od jêzyka programowania, poniewa¿ i tak aby wykorzystaæ taki czy inny protokó³, czy to w C czy w Bascom musisz go poznaæ. Tak wiêc dla mnie nie jest to argumentem. Za¶ argumentem s± gotowe procedury wielu protoko³ów zaimplementowane w kompilatorze Bascom, których nie musisz szukaæ po sieci, a których jest brak w kompilatorach C , C++ czy Assemblerze. :)))

U¿ytkownik "Jan Dubiec" snipped-for-privacy@SPAMTRAP.slackware.pl> napisa³ w wiadomo¶ci news: snipped-for-privacy@hs001.slackware.pl...

W dosc prosty sposob mozna zaimplementowac wyjatki w C. Da sie to zrobic za pomoca makr i nie rozni sie prawie od skladnie C++.

Pozdr AK

On Tue, 28 Sep 2004 02:51:51 +0200, "Piotr Wyderski" snipped-for-privacy@ii.uni.wroc.pl> wrote: [.....]

Wiesz, ja C (bez plusów) używam nie od wczoraj a jednak czasami zadarza mi się odkryć jakąś nowość. :-)

Z pewnością. Ale chodziło mi o to że np. po latach "myślenia strukturalnego" ciężko jest przestawić się na coś innego. Ot, taka ludzka natura. Ja np. kiedyś próbowałem trochę pobawić sie w programowanie funkcyjne i nic z tego nie wyszło. :-)

No masz, chyba każdy takie pisał. :-) Tyle tylko że ja zacząłem dostrzegać wady moich pierwszych wypocin nie dlatego że zacząłem się uważać za mistrza C++ (którym zdecydowanie nie jestem) ale po zrozumieniu co to jest OOA i OOD.

Ja raz użyłem RTTI gdy rzeźbiłem jakiegoś małego toola używając MFC. :-)

No ale dlaczego mają mieć jakieś specjalne tzn. duże wymagania pamięciowe? Czy użycie wątków, z punktu widzenia zapotrzebowania na stos, różni się zasadniczo np. od wywołania pewnej liczby zagnieżdżonych funkcji albo jakiejś nie dającej się zamienić na pętlę rekurencji? No i dlaczego muszą mieć oddzielny stos? Czy nie można zaalokować pamięci dla wyjątków w ramach stosu bieżącego wątku? Taki stos w stosie.

No właśnie o tą lokalność chodzi. Czy jest ona wymuszona przez standartd czy też nie. Bo przykro by było gdyby się okazało że po napisaniu większego kawałka wielowątkowego kodu okazało się że implementacja wyjątków w jakimś kompilatorze korzysta jednak ze zmiennych globalnych nie zapewniając przy tym żadnego mechanizmu synchronizacji. :-)

Regards, /J.D.

On Tue, 28 Sep 2004 11:51:19 +0200, "Plumpi" snipped-for-privacy@wp.pl wrote: [.....]

No dobrze, to co z tego wynika? Że Bascom jednak "ma składnię ukierunkowaną na sprzęt"? :-)

No przecież właśnie o to mi chodziło. Nawet gdyby Bascom miał niewiadomo jak bogatą biblitekę standartową, to zawsze będzie można znaleźć taką aplikację, gdzie ta biblioteka praktycznie do niczego się nie przyda albo tylko nieznacznie skróci czas tworzenia softu. Tak więc nie można stwierdzić że Bascom jest lekiem na całe zło tego świata. :-) Chociaż zapewne jest znakomity do trywialnych projektów typu "odczytaj temperaturę z czujnika i wyślij wynik na wyświetlacz i/lub UARTa".

Regards, /J.D.

ukierunkowan±

Tu powinienem rozdzieliæ te my¶li, poniewa¿ w wypowiedzi chodzi³o mi tylko i wy³±cznie o przenoszenie programów pomiêdzy sprzêtami. A co do ukierunkowania to Bascom ukierunkowany jest na programistê, poniewa¿ sk³adnia tego jêzyka jest bardziej ergonomiczna i ³atwiejsza do zrozumienia oraz zapamiêtania w przeciwieñstwie do sk³adni C. Nie mówi±c ju¿ o wspania³ej rzeczy jak± jest help za³±czony do tego oprogramowania tak¿e w wersji polskiej, który pomaga rozwi±zywaæ wiêkszo¶æ problemów, z którymi mo¿e zetkn±æ siê programista. Zawarte w nim s± przyk³ady u¿ycia komend czy procedur.

Ale jest i mo¿na j± wykorzystaæ - i to w³a¶nie jest plus. Pewnym minusem jest jednak to, ¿e ukierunkowany jest tylko pod pewn± grupê procesorów jednego producenta. Jednak trzeba powiedzieæ, ¿e jak na jedn± osobê, która tworzy Bascoma to jest to naprawdê kawa³, wspania³ej roboty.

Czê¶ciej jednak o wiele. Prawdopodobnie niewiele osób - zwolenników C, C++ wie, ¿e w Bascomie mo¿na podobnie tworzyæ w³asne procedury i zapisywaæ je jako oddzielne bloki, do których mo¿na siê odwo³ywaæ w tworzonych programach - jak include.

Ale¿ ja tego nie twierdzê. Twierdzê natomiast, ¿e przyspiesza i u³atwia tworzenie kosztem wiêkszego zapotrzebowania na zasoby sprzêtowe, których nie zawsze siê wykorzystuje do koñca podczas tworzenia. I pozwala w sposób naturalny i bezstresowy na szybkie zrozumienie zasad programowania. Przecie¿ maj±c do dyspozycji procesor z 8 czy 16 lub 128kB flash i kod wynikowy np. 2kB w przypadku C oraz 4kB Bascom - jaka jest dla mnie ró¿nica ? Zarówno w pierwszym jak i w drugim przypadku nie wykorzystujê mo¿liwo¶ci procesora. Znaczenie bêdzie mia³o dopiero jak zacznê pisaæ co¶ wiêkszego. Ale i wtedy jest na to rada, aby u¿yæ procka z wiêkszym flashem. Ewentualnie, kiedy krytycznym jest prêdko¶æ wykonywania programu. Wtedy pomagaj± wstawki assemblerowe.

Dok³adnie! Choæ wcale te projekty bascomowe nie musz± byæ trywialne, je¿eli tylko bêd± pisane z g³ow± :)

Jacek "Plumpi"