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

Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
co
stworzył, a to w sumie tak jakbyś od razu w asm pisał.
Gdyby nie słowo "raczej", Twoje zdanie byłoby kompletną bzdurą.
Obok masz przykład.
Po podaniu kompilacji przez kolegę - po minucie widzę błędy w kodzie
mikrokontrolera,

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.
Rynek.

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
2x droższy niż PIC12Fxxx.

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.
Teraz tak robię.

Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
oczekiwaniami.
Dla Ciebie może i nie.

W dniu 2014-04-06 13:17, Pszemol pisze:

OK, czyli nic nadzwyczajnego czego nie miałby typowy
32-bitowy Cortex M3 czy M4 z ARMa do kupienia za 20zł.

Oczywiście
Tyle, że za taką XMegę płacę jednak sporo mniej, szczególnie biorąc pod
uwagę "dodatki" typu wielkie złącze JTAGa w ARMie (koszt PCB, a raczej
zajmowanego miejsca też jest ważny). Tak, wiem że nie musi być aż tak
duże bo połowa to masy, a i resztę można ograniczyć.

Marzy mi się ARM 8-16 nóg. Dostępny oczywiście u nas i programowany
"byle czym", w sensie kompilatora i programatora
Z tym, że nóg może mieć więcej.

W dniu 2014-04-06 19:51, Sylwester Łazar pisze:
Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
co
stworzył, a to w sumie tak jakbyś od razu w asm pisał.
Gdyby nie słowo "raczej", Twoje zdanie byłoby kompletną bzdurą.
Obok masz przykład.
Po podaniu kompilacji przez kolegę - po minucie widzę błędy w kodzie
mikrokontrolera,


Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
oczekiwaniami.

Aaa... uśpienia!
A po co to uśpienie?
Bo inaczej ładowałby się ile czasu?

Użytkownik Pszemol napisał:
"AlexY" <alexy@irc.pl> wrote in message
[..]
1. Chcę wiedzieć co program robi a nie analizować i poprawiać błędy
kompilatora, zwłaszcza że co kompilator to inaczej program złożony.

Jakie błędy kompilatora chcesz poprawiać?? To jakieś mity.

Odpisałem w poście do Mario

2. ASM rozumiem, C C++ i pochodne to dla mnie sieczka stworzona żeby
wyrwać kasę na szkolenie specjalistów, bardzo lubiłem basic'a, jest
przejrzysty, nie można było go rozbudować?

Zostaw na chwilę C++, bo to trochę inna bajka, rzeczywiście, ale C,
stare dobre C, to właściwie asembler jest. To nie jest język wysokiego
poziomu. Jest właśnie bardzo krytykowany za "bliskość sprzętu".

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.

Poza specyficznymi przypadkami pisanie dziś w asemblerze to jakieś
hobby tylko, hardcore zupełnie niepraktyczny.

C/C++ to nie jest "sieczka" do wyrywania kasy - miliony programistów
go rozumie i używa na codzień. I wcale nie są geniuszami, więc może

Bo muszą

nie dołuj się i po prostu poczytaj trochę podstaw od C a przekonasz się
że trochę wprawy i poradzisz sobie. Dużo Ci to pracy zaoszczędzi.

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

[..]
Nie bardzo więc widzę gdzie Ty widzisz trudność że w AVR zrobisz
płytkę samemu a do ARMa musisz mieć jakiegoś gotowca...

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.

4. Czas pisania programu, to najbardziej mnie załamuje, prawda że asm
zajmuje dużo czasu, ale błędy są wtedy moje a nie kompilatora. Załamka
polega na tym że w imię przyśpieszenia programowania poświęca się
jakość ale to niestety normalne w obecnych czasach, program napisany
ze 3 razy szybciej wychodzi 2 razy większy i 5 razy wolniejszy, a do
tego mimo że napisany prawidłowo zawiera błędy kompilatora, znane i
nieznane.

Te Twoje mityczne "błędy kompilatora" to chyba błędy programisty
piszącego nieumiejętnie w C... Na codzień piszę programy w C i C++
i z błędami kompilatorów nie mam do czynienia wcale.

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.

Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
oczekiwaniami.
Dla Ciebie może i nie.
Dla mnie błąd.

Idziesz w Hotelu na śniadanie i masz szwedzki stół, wliczony zresztą w cenę.
Jest tam wszystko:
jaja, szynka, owoce, sałatki, ryby, kawa, herbata, ciastko, po prostu w domu
w lodówce masz mniej.
Wybierasz grzankę i z samowaru nalewasz wodę.

Potem idziesz do pracy i po paru godzinach, w przerwie lecisz do biedronki i
kupujesz bułę i parówkę.

To jak to nazwiesz?
Błąd to mało powiedziane.
Mi sie wydaje, że to głupota.

Zastanawiam czy świadomie trolujesz, czy faktycznie nie masz pojęcia
po co uśpienie i dlaczego (w kontekście w jakim pisał Przemol) nie
ma ono nic wspólnego z ładowaniem się czegokolwiek.
Czyli jak wyciągniesz w laptopie z Windowsem 7, baterię, włożysz na drugi

Użytkownik Mario napisał:
W dniu 2014-04-06 19:51, Sylwester Łazar pisze:
Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
co
stworzył, a to w sumie tak jakbyś od razu w asm pisał.
Gdyby nie słowo "raczej", Twoje zdanie byłoby kompletną bzdurą.
Obok masz przykład.
Po podaniu kompilacji przez kolegę - po minucie widzę błędy w kodzie
mikrokontrolera,


Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
oczekiwaniami.

Kiedy procek ma jakieś time critical tasks to takie "nieoptymalne
rozkazy" stają się błędami które trzeba nadgonić szybszym procem albo
ręcznie poprawić w asm.

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.
Rynek.
Ceny to możesz sobie kształtować w korporacjach AB czy KOMPUTRONIK.
Allegro jest bezlitosne.
Próbowałeś dokupić większą pamięć DDR2 do starszego komputera?
Dużo ludzi tak chce. I stąd wyższa cena.

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
2x droższy niż PIC12Fxxx.

Wybierasz takiego ARMa który ma to, co potrzebujesz.
I co się zwykle okazuje, że ma wydajność 10 razy większą
niż 8-bitowiec w tej samej cenie.
Tylko po co? żeby młócił powietrze w delay ?

Zrozum, ceny procesorów 8-bitowych dzisiaj są nadmuchane.
Wiesz sam dobrze że cena to kwestia popytu sprzedaży a nie złozoności

Dlaczego są nadmuchane? Bo producenci trzymają Cię w garści.
Płacisz jak za zboże bo musisz. Musisz, bo tylko te znasz...
Mylisz się niczego nie muszę, są wygodne, bo np małe 51 się gorzej

Tylko tego proca zastosujesz jak mniejszy Ci okaże się za mały.
Producent wie, że przesiadka na inną rodzinę to koszty zaporowe
Eee przesadzasz, cała rodzina avr-ów jest spójna, piszę w c i przejście na

i dlatego ustawia takie ceny na procki 8-bitowe bo jeszcze jest
na nie jako taki popyt.

To jest analogia jak z pamięciami DDR czy starymi prockami do
pecetów... Ceny DDR2 o tej samej pojemności sa WIĘKSZE niż
ceny szybszych DDR3 - Ceny szybszych procków i3 są takie same
Nie ma analogii, nie porównuj rynku konsumenckiego z hobbystycznym.

No to samo masz w ARMach... nie widze tu żadnej rewelacji.
Może, pdf-y są tak kiepsko napisane że nie doczytałem, army chcą dogodzić

na pokładzie czas AVRów jest policzony
Mylisz się, wcale nie jest policzony. Dla początkujących to s ą idealne
procki stosunkowo proste do opanowania i zaprogramowania.

Dla początkujących... i potem co? Zainwestujesz czas w naukę
a potem zmiana i od nowa będziesz się uczył od początku?
A czego się uczyć od początku? to tam inny c jest?

To jest bez sensu - jak już robisz inwestycję czasu i gromadzisz wiedzę
to lepiej uczyć się procesorów z dużej rodziny i dziś popularnej a nie
procesorów popularnych 20-30 lat temu wychodzących dziś z użycia.
Ale bajdurzysz, avr powstał 30 lat temu?

w tej logice?
Może daruj sobie te porównania.

:-)

Naprawdę nie ma się czego bać ARMów.
Ale ja się ich nie boję, nawet mam takiego na biurku z wyświetlaczemn i

Użytkownik Mario napisał:
W dniu 2014-04-06 18:14, AlexY pisze:
[..]
Źle do tego podchodzisz, rozpoczynając projekt sprawdzasz który sprzęt
spełni wymagania i na nim dłubiesz, dłubanie na siłę w zbyt słabym
sprzęcie jest skazane na porażkę.

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ą.

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.

[..]
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.

A może faktycznie im wystarcza?

[..]
Tu jest sedno sprawy, uC to ściśle określony sprzęt, system operacyjny
ma działać na całej rodzinie sprzętu, ponadto poziom komplikacji jednak
przewyższa atmelkowe miganie diodką, na uC program napiszesz, produkt
sprzedasz i możesz o nim zapomnieć,

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?

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

systemy operacyjne co rusz się
aktualizuje, co w przypadku asm jest szczególnie ciężkie. To wymusza
użycie języka wysokiego poziomu, moje "ale" jest co do jego wyboru.

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

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.

AVRów, tyle samo co w PDI ATxmega, ale masz jeszcze debugowanie!
W atxxmega też jest na pdi debug.

Żartujesz, prawda? STM32 mają SWD. Inne pewnie też, ale nie znam.
Wystarczą cztery żyły (a może i trzy): dane, zegar, masa i Vcc. STM32:
kupujesz najtańszy STM32F0Discovery za niecałe 50zł i masz pełnoprawny
programator debugger wszystkich układów STM32 (wszystkie cortexy). Do

tego działa OpenOCD i w Eclipse debugujesz bez ograniczeń wielkości
kodu. Oczywiście ST-Link szybkością nie grzeszy, ale kilka sekund na
załadowanie kodu 50kB można poczekać. W przypadku NXP jest podobnie.

Czyli do zaprogramowania potrzebujesz _mniej_ miejsca na PC niż dla ISP
AVRów, tyle samo co w PDI ATxmega, ale masz jeszcze debugowanie!

SSOP20 może być?

STM32F030F4P6, 4,69zł brutto w detalu, koło $0,5 przy 1000szt.
Ma boot loader przez UART. Pewnie Flash Loader od ST go obsługuje, a
może są i jakieś inne programy (do STM32F103 używałem chiński MCUISP
http://www.mcuisp.com/English%20mcuisp%20web/ruanjianxiazai-english.htm,
może inne też obsłuży). Ale i tak uważam, że obecnie SWD przebija zabawę
z UARTem.