PIC czy AVR? Doświadczenia z kompilatorami HiTech i GCC w programowaniu uC

Sun Apr 06, 2014 5:00 pm   

"Sylwester Łazar" <info@alpro.pl> wrote in message
news:lhrtgd$5p7$1@mx1.internetia.pl...

Nie wiem o czym mówisz...
Mój laptop ASUSa pracujący pod kontrolą MS Windows 7
wstaje z trybu uśpienia w 15-16 sekund... A kasę w banku
to można dziś sprawdzić byle apkiem na smartfona, pracującego
zwykle pod kontrolą procesora ARM nawiasem mówiąc :-)


Sylwester - jako biznes model Gatesowi sprawdził się model
oparty o pisanie kodu w C, C++, C# czy inne .NETy i nie
certolenie się z dopieszczaniem kodu do ostatniej usuniętej
niepotrzebnej instrukcji w asemblerze. To wymaga cholernie
dużo trudu i niestety nie jest odporne na błędy w programach.
Co innego gdy piszesz sobie kod mający 100-200 instrukcji
na konkretny hardware który kontrolujesz jako projektant
w 100% a co innego gdy piszesz przenośny kod MS Windows
który ma pracować na setkach tysięcy różnych komputerów
wyprodukowanych na przestrzeni ostatnich 25 lat i współpracować
z pierdylionem różnych urządzeń i sterowników od osób trzecich,
czego nie jesteś w stanie kontrolować w 100%.
Gdybyś miał za zadanie napisać takie MS Windows w asm
to szybko pogubiłbyś się bo zostałbyś w tyle - życia by Ci brakło
na pisanie kodu...

Sun Apr 06, 2014 5:12 pm   

Po prostu pięknie!
Dokładnie tak jest.
Jest tylko jeden problem.
Ludziom, coraz częściej nie przeszkadza, że procesor tańczy lambadę, skoro w
przerwie podejdzie do stołu
i poleje drinka.

Jeżeli będzie taka potrzeba, to zadowolą się tym, że tańczyć będzie od
wtorku do niedzieli,
a w Poniedziałek wykona całą robotę.

Ale po co się ograniczać!
Niech tańczy cały miech, 30-go każdego miesiąca przyjdzie i wykona plan, a
luty pal licho!
Co z tego!
6 rdzeni, 1GHz każdy, bateria malutka a gość e-maila odczytuje.
I tak już 18 lat trzeba komórkę przynajmniej raz w tygodniu doładować....
prądem ma się rozumieć.
Nawigacja w samochodzie - bez ładowania zacznie migać na czerwono już po
godzinie jazdy.
Ma ktoś taką, co po naładowaniu działa przez tydzień?
I to są fakty, a reszta to banialuki.
S.

Sun Apr 06, 2014 5:17 pm   

A po co to uśpienie?
Bo inaczej ładowałby się ile czasu?
Zwykła proteza.
Dzięki że podałeś ten przykład.
To was czeka. Ze względu na GIGABAJTOWĄ nadbudowę
już powoli strach przeładować system.


Świadczy to o jego geniuszu czy głupocie?
S.

Sun Apr 06, 2014 5:18 pm   

W dniu 2014-04-06 17:41, Dariusz Dorochowicz pisze:

Przydałby się jakiś toolchain. Można sobie skomponować na bazie Eclipse.
Opis jak to zrobić jest na stronie freddiego
http://www.freddiechopin.info/pl/artykuly/35-arm/59-arm-toolchain-tutorial
Można też kupić płytkę LPCXpresso:
http://www.kamami.pl/index.php?categoryID=7972
Płytka ma w sobie programator który możesz odłamać i używać osobno.
Możesz sobie ściągnąć i używać środowisko LPCXpresso - też na Eclipse
W ramach licencji możesz kompilować i programować do 256 kB kodu
wynikowego. Na poczatek warto bo te małe LPC ( 8xx, 11xx i 13xx) mają
tylko SWD nie mają pełnego JTAGA. LPCXPresso niestety nie jest
kompatybilne z OpenOCD ( chętnie stosowane środowisko do programowania i
debugowania - dające się zintegrować z toolchainem gcc + Eclipse)
Ale można je używać do programowania plikami hex z innego kompilatora.
Możesz tez ściągnąć darmowe środowisko CooCox z systemem operacyjnym RT.
Trzeba tylko zobaczyć czy obsługuje te rodziny procków z którymi chcesz
pracować. W ARMach - zwłaszcza gdy piszesz bardziej rozbudowany program,
warto stosować system czasu rzeczywistego. Ja stosuję Freedos i
toolchain od Freddiego. DO małych jak LPC1114 używam LPCXPresso.


Mi dwa wystarczają.


--
pozdrawiam
MD

Sun Apr 06, 2014 5:24 pm   

"AlexY" <alexy@irc.pl> wrote in message
news:lhs0th$qtp$1@speranza.aioe.org...

Długo na samym asemblerze nie pociągniesz...
Kiedyś znudzi Ci się miganie LEDem z pinu procesora i będziesz
chciał napisać coś bardziej ambitnego - coś, co napisane w asemblerze
będziesz poprawiał aż do emerytury a napisane w C/C++ zajmie Ci
dwa dni :-)


Są dwie możliwości błędów kompilatora: błąd ujawnia się w postaci
błędnie działającego kodu wynikowego (takie wyłapiesz) lub nie
ujawnia się w postaci błędnie działającego kodu wynikowego...
Tych drugich nie ma potrzeby wyłapywać ani się nimi przejmować.


Obawiam się, że sztucznie demonizujesz coś, czego nie znasz..
Uważaj, bo strach przed nieznanym ma wielkie oczy ! :-)


Podchodząc do życia w taki sposób chyba nie wychodzisz z domu... ???
Nie dasz rady nad wszystkim panować, nad wszystkim mieć 100%
kontroli. Nawet jak autobusem jedziesz to polegasz na kierowcy
i na innych użytkownikach drogi. Owszem, jadąc rowerem (asembler)
pojedziesz najkrótszą drogą do celu, krótszą niż autobusem (C/C++)
ale niekoniecznie najszybszą... A wypadki zdarzają się i busom i rowerom.


Nie przypomniało Ci się tylko na szybko coś wygooglałeś...
I powiem Ci, że pudło - to raczej właśnie był komentarz o błędach
jakie popełniają programiści piszący w C++ lub PHP. I to była
pochwała właśnie kompilatora C++ który zgłosi programiście
błąd w tym co napisał i nie utworzy błędnego kodu wynikowego
a piszący w php dowie się o swoich błędach dopiero od klienta.

Podsumowując - nie bój się C, poczytaj książki (są po polsku!) i powodzenia!

Sun Apr 06, 2014 5:29 pm   

"Sylwester Łazar" <info@alpro.pl> wrote in message
news:lhs2p0$n77$1@mx1.internetia.pl...

Fakty są takie, że nawigacja napisana w całości w asemblerze
po pierwsze nie pracowałaby na tej samej baterii 24*7 razy
dłużej a po drugie kosztowałaby tyle że mało kto byłby nią
zainteresowany...

Już to widzę jak taki Garmin czy innny TomTom co dziś
zleca pisanie softu w Indiach programistom C++ każe
pisać ten sam kod w asemblerze aby mniej prądu pobierał...
Ech... poza tym - w takich urządzeniach najwięcej prądu bierze
wyświetlacz i jego podświetlenie - procesor idzie w uśpienie
dosyć często i nie jest głównym konsumentem prądu z baterii.

Sun Apr 06, 2014 5:38 pm   

W dniu 2014-04-06 18:14, AlexY pisze:

Nic nie pisałem, że Kernighana czytałem w oryginale. Jest polski
przekład. Jest sporo podręczników do c, tłumaczonych z angielskiego lub
napisanych przez polskich autorów.



Ja tak właśnie nie podchodzę. Ale wydaje mi się że ci co się trzymają
asemblera niestety są przez to często zmuszeni do pracy z prockami w
których ledwo się mieszczą.


Zazwyczaj operując w ramach jednej rodziny. Przejście na coś całkiem
innego boli. Sam przechodziłem z 51 na AVR i szybko stwierdziłem, ze
wgryzanie się w pisanie w asm wymaga ode mnie dużo wysiłku. Po jednym
małym projekcie wolałem się nauczyć c i kilka projektów zrobiłem w
AVR-gcc. Przejście z c na AVR do c na ARM było już znacznie łatwiejsze.
Podejrzewam, że ci co upierają się przy asm, z oporami sięgają po
bardziej złożone architektury twierdząc, że to co mają w zupełności im
wystarcza.


Twój wybór. Możesz korzystać z pracy społeczności na zdefiniowanych
przez nią warunkach albo pisać wszystko sam. Naprawdę każdy musi sam
wymyślać stos TCP, albo obsługę HD44780?



Tylko po co w takim razie argumentacja, że pisanie w c jest
niebezpieczne z powodu błędów kompilatora czy ogólnie mówiąc szybkie
tanie i kiepskie? Skoro kod skompilowany z c jest poprawny i stabilny w
routerach czy w serwerach to czemu miałby być niepoprawny w przypadku
atmelkowego migania LEDem?


Jakoś nie robią tego na Basicu. Widocznie c jest do tego lepszy.


--
pozdrawiam
MD

Sun Apr 06, 2014 5:42 pm   

W dniu 2014-04-06 19:18, Mario pisze:


Miałem na myśli programowanie procka (zapis do pamięci flash) przez
JTAG a nie programowanie w ogóle :)

--
pozdrawiam
MD

Sun Apr 06, 2014 5:44 pm   

Pewnie ARM jest lepszy od innych, może nawet najleszy.

Ale mnie to nie bardzo rusza; mi jest potrzebne coś co łyknie skompilowany
kod w jęz C i będzie działało, może być 8,16 czy też 32 bitów; co mnie to
interesuje, niech kompilator się tym martwi.
Na chwilę obecną wystarcza mi coś co ma 2XUART, SPI, 64kB ROM i kilka KB.
Prawdę mówiąc jeśli dzisiaj byłby popularny HD64180 (rozbudowany klon Z-80)
to bym go użył.

Kiedyś się zabierałem za ARM ale nie było takiego prostego programatora jak
do PIC czy też AVR (16zł na allegro) żeby można coś popróbować i szybko
zaprojektować PCB do finalnego wyrobu.

jp

Sun Apr 06, 2014 5:46 pm   

Użytkownik Pszemol napisał:

Odpisałem w poście do Mario


Tak też mi to przedstawiono, kłopot w tym że mam problem z akceptacją
rzeczy nielogicznych, z tego powodu np liczby urojone w technikum zdałem
ale nigdy ich nie zrozumiem, oraz nigdy nie będę politykiem.


Bo muszą


Poleć jakąś książkę/kurs dla starego assemblerowca, do tej pory nikt nie
dał mi wędki która idealnie leży mi w rękach :)

[..]

Może to jakieś zabobony, ARM to dla mnie procesory wydajności średniej
klasy PC, wysokie zegary, masa nóżek a najlepiej BGA, zwyczajnie nie na
moje potrzeby, być może faktycznie cenowo to jest na poziomie 89C2051
ale to tak jakbym do pracy dojeżdżał limuzyną z szoferem i obstawą 6
ochroniarzy.


Błędy mogą objawiać się np przycięciem się programu w jakiejś pętli z
której sam wyjdzie, tyle że zdecydowanie za dużo czasu mu to zajmie,
takich rzeczy nie wyłapiesz jeśli nie robisz analizy asm.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

Sun Apr 06, 2014 5:51 pm   

Obok masz przykład.
Po podaniu kompilacji przez kolegę - po minucie widzę błędy w kodzie
mikrokontrolera,
na który w życiu nie napisałem nawet linijki.
A ja nie jestem nadczłowiekiem.




Faktem jest, że niemal jedyna w Twoich postach, ale ważna.
Nie ma się co bać C.
Nie musisz nic czytać, ani po polsku, ani po angielsku.
Nauką jest Twój kompilator. Często darmowy lub w promocji czasowej po
zalogowaniu.
Przykłady w liczbie 3+ masz w katalogu EXAMPLES.
Otwierasz projekt, kompilujesz i otwierasz plik *.lst
Tam masz pięknie rozrysowane:
instrukcja w C
i 10-20 linijek kodu w czystym ASM, który znasz i rozumiesz.
Jak widzisz, że za dużo, to zostaw sobie:
void main() {
ALMAKOTA =1;
}
i popatrz na Lambadę ;-)

Jak zaczniesz czytać książki, to może się okazać, że dowiesz się
jakie są "dobre zwyczaje".
Dobre zwyczaje są dobre, jeśli są dobre.
Cały kod w C jest i tak zamieniany na kod maszynowy,
gdzie BASICowy rozkaz GOTO jest najważniejszy.


Lecąc F16 (ASM) będziesz szybciej niż drezyną (C) u celu.
Na dwoje babka wróżyła.
Jeśli operujesz z rozdzielczością 20 ns, to rób sobie w C i szukaj procków,
co spełnią Twoje
założenia i tańczą Lambadę (R)Alex od wtorku do niedzieli.

S.

Sun Apr 06, 2014 5:53 pm   

W dniu 2014-04-06 18:55, AlexY pisze:

Tak jak pisałem dla mnie wystarczającą motywacją było przejście z asm na
51 do asm na AVR.


No ale na błędy kompilacji narzekają chyba tylko ci co nie kompilują.
Chyba to jest dla nich odpowiednik takich niedostępnych winogron które
zapewne i tak są kwaśne.


Dostajesz kod np 1.6 wolniejszy niż byś go napisał sam w asm a
uruchamiasz go na 10 razy szybszym procku. Nie opłaca się? W dodatku
czas przesiadki programisty na ten 10 razy szybszy procek jest też
wielokrotnie szybszy w przypadku c niż asm.


Tylko, że z błędami spowodowanymi przez siebie programista walczy co
chwila, a błąd kompilatora masz szansę spotkać raz na dziesięć lat. No
chyba, że używasz ne opartych na gcc, komercyjnych kompilatorów dla
niezbyt popularnych architektur.


No ale to jest o błędach programisty :)



--
pozdrawiam
MD

Sun Apr 06, 2014 6:03 pm   

Nie możesz, bo musisz napisać w ASM i w C,
a potem porównać, a Ty tego nie robisz.
1,6x wolniejszy kod w C vs, ASM dla TEGO samego procka, to kłamstwo,
które próbujesz przeforsować.
Nie uda Ci się.
Z moich obliczeń częściej wynika dokładnie co napisałeś, ale bez kropki,
czyli 16x.
I dlatego musisz wybrać coś 10x szybszego.
Dopóki nie udowodnisz - nie masz prawa pokazywać mnożników.
Możesz podać jedynie link do RZETELNYCH analiz.
S.

Sun Apr 06, 2014 6:12 pm   

W dniu 2014-04-06 18:59, Sylwester Łazar pisze:

Ceny pamięci DDR2 SA znacznie wyższe niż pamięci DDR3. Według twojej
logiki nie ma popytu na pamięci DDR3 i dlatego producenci muszą zjeżdżać
z ceny.


Przecież są takie. Nawet w DIP. LPC810 za 4,47 zł. Aha, dlatego takie
tanie bo nikt ich nie chce. Dziwne, przecież mają jeden UART i 8 nóżek :(


No i tak to mniej więcej działa. Z poprawką na to, że często nie musisz
ustawiać bitu. Wystarczy, ze użyjesz bibliotekę wykorzystującą
sterowniki CMSIS. Przy inicjalizacji (np portu UART czy SPI) podajesz
który to numer portu, jaka prędkość bodowa i na którym pinie jest Tx a
na którym Rx.
A poza tym sarkazm zupełnie niepotrzebny. Nie mów, że nie nie pisałeś
programu w którym stosowałeś tylko jeden ADC czy PWM a procek miał ich
do dyspozycji 10 czy 4.


--
pozdrawiam
MD

Sun Apr 06, 2014 6:17 pm   

Użytkownik Mario napisał:

To nie tak że ledwo się mieszczę, po prostu czasem trzeba zrezygnować z
jakiejś extrasowej funkcji bo nie wejdzie, założona funkcjonalność musi
się zmieścić albo procek za mały.

[..]

A może faktycznie im wystarcza?

[..]

Nie wiem w czym windows jest pisany ale daleko mu do bycia stabilnym.
Linuxa ciężko ale też da się wywalić.


Nie znam powodów innych niż ten co podałem (kasa).
Co stało na przeszkodzie zaadoptowania basic'a?
A już wiem... kasa... nie byłoby jej za kursy, książki, poradniki i
trzeba by było zabulić za licencje/prawa autorskie do basic'a.


--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html