Freddy -> po tym jak porównałem kod asemblera dla pętli opóźniającej 300ms przez FastAVR (krótszy nieco kod) do kodu wygenerowanego przez MikroPascal (nieco dłuższy) to - jasno widać, iż autor FastAVR'a przyłożył się bardziej do optymalizacji kodu. Z tego co mówisz zapewne nie tylko przy fragmnetach odpowiadających za pętle opóźniające. Więc jest to na pewno jakiś plus. Jednak sam chyba przyznasz? a może nie , że bardzo istotna jest i ma dużą wagę cała otoczka środowiska jak:
- IDE (cała wygoda jego obsługi)
- dostępne przy zakupie gotowe biblioteki
- bardzo istotne - dobry HELP, który chłopaki z mikroe zrobili naprawdę zaje-fajnie. Zresztą widać, że sporo ktoś w całość zainwestował. Całe jasne i przejrzyste dokumentacje, PDFy
naprawdę porównując to wszystko tak obiektywnie to jednak produkty mikroe są chyba troszkę lepiej dopieszczone. Takie jest oczywiście moje zdanie i wcale nie jedynie słuszne
... poza tym jak na kompilator Basica to FastAVR ma dużego plusa w porównaniu do Bascoma chociażby z tego powodu, że pozwala na takie rzeczy jak:
A = B+(C/2)+D*E
Dodano po 2 [minuty]:
Freddie Chopin -> hyhyhy no absolutna racja, że asembler daje najkrótszy kodzik

ale zastanawia mnie porównanie i na pewno to zrobię - kodu pisanego własnie w MikroPascalu w porównianiu do MikroC albo AVRGCC.
Dodano po 5 [godziny] 33 [minuty]:
no i moje podniecenie kompilatorami team'u Mikroelektronika spadło do ZERA po przeczytaniu tego wątku na ich forum.
http://www.mikroe.com/forum/viewtopic.php?t=15848&postdays=0&postorder=asc&start=0
proponuję jednak zapoznać się z tym, zanim ktoś popełni błąd i zakupi tę wersję kompilatorów dla AVR (bo to one są do bani - tak piszą) te dla PICów są ponoć OK. (podejrzewam, że proste programy pisane przy użyciu bibliotek ząb w ząb zgodnie z błędną czasm ideą autorów nna pewno działają. Ale np od razu poraziło mnie to, że niby jest biblioteka do obsługi alfanumerycznego LCD i to w wersji 4bitowej i 8bitowej - ale żadna nie umożliwia korzystania z pinu R/W tegoż wyświetlacza !!! a że nie ma źródeł to trza pisać samemu. Nie analizowałem innych bibliotek ale podejrzewam podobne "zasadzki". Co przy słabszej optymalizacji kodu niż np w FastAVR - stawia jednak chyba właśnie FastAVR na czele. Dodatkowo (choć sam jeszcze w wersji demo nie doświadczyłem jakichś znacząych - ale są babole i w samych kompilatorach.
Tak na gorąco - jeden - może błachy ale zawsze - te dokowalne okienka są jakby "pseudo dokowalne" wystarczy je "wyjąć" z okna IDE - pojawią się jako oddzielne okienka windows - ale już z powrotem je tam umieścić to wielka rzecz - uzyskałem to dopiero po skasowaniu i odzyskaniu z instalki jednego z plików ini - ot taka mała niedoróbka
piszą w tym wątku, że team przygotowuje całkiem nową serię kompilatorów dla AVR, całkowicie zmienioną wraz z nowymi przykładowymi programami i bibliotekami. Ale jak się czyta posty sfrustrowanych klientów , którzy wyłożyli kaskę na ulubiony kompilator MikroPascal a potem okazało się, że gdy zgłaszają błędy czy prośby o pomoc to nawet banują ich IP, żeby nie mogli zagłuszać jedynie słusznych - pochwalnych wypowiedzi i opinii .... hmmm a może autorzy są jednak wprost z Korei Północnej ??? i wdrażają w życie jakąś wizję niewidzianego już od dawna (tak nawiasem mówiąc) KIM-DZONG-IL'A hyhyhy
Jednak coś mi śmierdziało gdy czytałem ich informacje, że nie udostępniają źródeł bibliotek.
Zostaję więc narazie nadal przy Bascomie, wstawkach asemblerowych no i nadal uczę się AVR GCC ..... choć łezka zakręciła mi się w oku na wieść iż mógłbym niczym w Delphi na PC - programować procki w Pascalu
