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

Sun Apr 06, 2014 12:19 pm   

W dniu 2014-04-06 00:42, AlexY pisze:

A tego to nie rozumiem. Może chciałeś napisać "tylko to znam"?
Jaka jest korzyść z pisania w asemblerze? Tylko nie pisz o tym, że w
asemblerze łatwiej ci się uda napisać program, który będzie
wystarczająco szybki i zwarty żeby sobie poradzić z ograniczeniami
sprzętowymi 8-bitowca.

--
pozdrawiam
MD

Sun Apr 06, 2014 12:23 pm   

W dniu 2014-04-06 13:56, janusz_k pisze:



To tak jak w ARMach :)




--
pozdrawiam
MD

Sun Apr 06, 2014 12:28 pm   

Użytkownik Pszemol napisał:

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.
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ć?
3. Gdybym miał przesiąść się na coś pokroju ARM to prędzej byłby to
gotowiec typu raspberry.
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.

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

Sun Apr 06, 2014 12:39 pm   

Użytkownik Mario napisał:

Nie, nie tylko, ASM, pascal, basic. Tych potrzebowałem to się nauczyłem,
zrobiłem podejście do C i C++ ale chyba już za stary jestem bo mi się
odechciało, może to kwestia braku odpowiedniej literatury napisanej w
sposób dla mnie zrozumiały.


Nikt nigdy nie wmówi mi że asm jest łatwy, jego podstawowa zaleta to
wiedza co w danym momencie się dzieje z każdym bitem, całkowita kontrola
sprzętu, zawsze, wszystkie procedury bez skrępowania mogę okroić z
funkcji których nie użyję, nie wiem czy tak samo można grzebać w
bibliotekach C. np obsługa LCD HD44780 wyciąć obsługę 8bitowej
transmisji i odczyt stanu wyświetlacza.

Nikogo nie zamierzam przekonać do swoich racji wiem że rynek wymusił
pisanie szybko bo na chlebek nie zarobisz, ale czy to jest rzeczywiście
dobre?

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

Sun Apr 06, 2014 1:03 pm   

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

O jakich błędach mówisz? Używam gcc od bodajże 2009 roku i nie musiałem
poprawiać żadnych błędów kompilacji. No chyba, że za błąd uważasz to co
Sylwek opisał w swojej analizie kodu w sąsiednim wątku. Czyli, że
kompilator zastosował w kodzie wynikowym operacje na bajtach zamiast na
słowach. No i jak taki błąd wpływa na prawidłowe działanie kodu?


Uważasz, że żeby nauczyć się c to trzeba się odpłatnie szkolić u
specjalistów? No to może w tym jest twój problem. Ja po nastu latach
rzeźbienia w asm wziąłem się ze sporą niechęcią za c - przymuszony
koniecznością przejścia na coś mocniejszego od 51. Po zrobieniu kilku
projektów na AVRach w AVR-gcc, uznałem, że to nie tędy droga i
przeszedłem na ARMy. I nie żałuję. Nie muszę wiedzieć co program robi na
poziomie pojedynczych komend kodu maszynowego. Ważne czy robi to co
zapiszę w c i jakby co mogę to podejrzeć w debuggerze.
Rozumiem też twój sentyment do BASICa. Przy przesiadce tez żałowałem, że
nie mogę się przestawić na BASIC, czy Fortran lub Algol. C w porównaniu
do nich wydawał mi się jakiś zawiły. Ale uwierz nawet
pięćdziesięciolatek jest w stanie się go nauczyć bez pomocy specjalistów.


To oczywiście jest jakaś opcja. Ale raczej dla programisty linuksowego,
który chce sobie zrobić sterownik do domu czy drona. Nie wyobrażam sobie
dawanie Raspberry czy innych gotowych modułów do moich komercyjnych
produktów.


Napisz coś konkretnego o tych błędach kompilatora. I w czym są gorsze od
błędów własnych?


I wrzuca się go na 10 razy szybki procek. W efekcie czas realizacji
zadania jest mniejszy, koszt zarazem też niższe, a wydajność procka wraz
z oprogramowania wyższa.


Z błędami kompilatora jest tak jak z błędami w architekturze procka. Są
znane i nieznane. Jak masz pecha to możesz na nie trafić.
Jak siedzisz w temacie i korzystasz z wiedzy zawartej w dużej
społeczności masz duże szanse dowiedzieć się o tych błędach i ich
unikać. A największe społeczności są teraz zgromadzone wokół ARMów i gcc.


--
pozdrawiam
MD

Sun Apr 06, 2014 1:36 pm   

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

No to chyba młodszy jesteś ode mnie bo ja uczyłem się Algolu i Fortranu.
DO nauki c wystarczył mi Kernighan Ritchie oraz kieszonkowy leksykon c z
serii O'Reilly.


Nie piszę, że łatwy tylko, że większe ma się szanse na to, że program
będzie wystarczająco mały i wystarczająco szybki aby zmieścić się w
osmiobitowcu i maksymalnie wykorzystać jego słabą wydajność. Czyli
ciężką pracą kodera, bohatersko zwalcza się problemy wynikające ze
słabej architektury.


Dopóki ten sprzęt jest wystarczająco prosty aby go ogarnąć.


Możesz to zrobić. Jeśli biblioteka ma dużo kodu, a wykorzystujesz tylko
małą część to możesz wyciąć te funkcje, wkleić wprost do swojego kodu
albo zapisać jako inną bibliotekę. Tu ograniczeniem może być licencja.
Często się korzysta z dorobku innych zawartego w domenie publicznej.
Dołączenie czyjegoś kodu np. na GPL wprost do twojego kodu powodowałoby
wymóg opublikowania twojego kodu. Często jest jednak tak, że licencja
zezwala na używanie zamkniętego kodu twojego własnego programu, a
publikować trzeba jedynie zmiany w środowisku jak funkcje biblioteczne
czy sterowniki. Wtedy lepiej zmianę jakiejś biblioteki zapisać jako nową
bibliotekę i ewentualnie opublikować w razie potrzeby.


Czy pisanie w c pod linuksa czy systemy BSD jest twoim zdaniem
niewłaściwe, bo nie panuje się nad efektem kompilacji? Superkomputery,
routery, duża część serwerów internetowych, systemy dowodzenia i
prowadzenia ognia. Lepiej i bezpieczniej byłoby gdyby to wszystko pisać
w asemblerze?


--
pozdrawiam
MD

Sun Apr 06, 2014 2:13 pm   

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

Myślę że Gates udowodnił swoim portfelem który model biznesu się sprawdza.
Ty masz satysfakcję że Twoja pętla ma tylko 40 instrukcji a on ma miliardy
dolarów i nie wie co z nimi zrobić...

Sun Apr 06, 2014 2:21 pm   

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

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


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

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


Każdy ma inne oczekiwania - gotowiec to jakiś tam start i dobrze
służy do poznania rodziny procesorów, zrobienia pierwszych kroków,
ale potem warto pójść dalej - implementacja ARMa na własnej płytce
nie jest jakimś wyczynem do którego wymagana jest znajomość
prowadzenia wysokomegaherzowych magistral pamięci DDR3...
Tu też masz do czynienia z mikrokontrolerami gdzie wszystko masz
zamknięte wewnątrz kostki, jak w AVR czy 8051 czy PICu...
Nie bardzo więc widzę gdzie Ty widzisz trudność że w AVR zrobisz
płytkę samemu a do ARMa musisz mieć jakiegoś gotowca...


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.

Sun Apr 06, 2014 2:40 pm   

"janusz_k" <Janusz_kk@o2.pl> wrote in message news:op.xdv8rwspn0u1o8@moj...

Nie każdy ARM ma wszystko... zgoda.
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.

Zrozum, ceny procesorów 8-bitowych dzisiaj są nadmuchane.
Dlaczego są nadmuchane? Bo producenci trzymają Cię w garści.
Płacisz jak za zboże bo musisz. Musisz, bo tylko te znasz...
Tylko tego proca zastosujesz jak mniejszy Ci okaże się za mały.
Producent wie, że przesiadka na inną rodzinę to koszty zaporowe
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
lub niższe jak wolniejszych, starszych procków LGA775 dlaczego?
Bo DDR2 czy procek LGA775 wstawia się jako retrofity do starszych
maszyn, aby robić upgrade... Rynek zdyskontował fakt, że aby
przesiąść się na inna platformę trzeba wydać więcej: nowa płyta,
nowy ram, nowy proc, często nowy zasilacz itp, itd... Więc Cię rypią
bez mydła za stary procek czy pamięć więcej niż za nowe...

To samo jest z prockami 8-bitowymi w stosunku do procków ARM.


No to samo masz w ARMach... nie widze tu żadnej rewelacji.


Co ma swoje?
Ja mówię o standardowej bibliotece CMSIS:
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php


Dla początkujących... i potem co? Zainwestujesz czas w naukę
a potem zmiana i od nowa będziesz się uczył od początku?
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.

To coś tak jak byś powiedział że docelowo chcesz się nauczyć języka
niemieckiego i wyemigrować do Berlina... Ale ponieważ jesteś początkujący
to na początek nauczysz się języka ruskiego, bo jest dla Ciebie, Polaka,
łatwiejszy niż niemiecki, "na początek"... Widzisz bezsens w tej logice? :-)

Naprawdę nie ma się czego bać ARMów.
To jest dzisiaj procesor do nauki dla początkującego.
Masz całą rodzinę Cortexów do poznania: M0, M1, M3 a nawet
M4 z koprocesorem zmiennoprzecinkowym... Do wyboru do koloru.
Najmniejsze, najtańsze M0 w małych obudowach kosztować Cię
będą DUŻO, DUŻO MNIEJ niż 8-bitowce dzisiaj...

Sun Apr 06, 2014 3:34 pm   

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

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


Bo o to chodzi, żeby było coś, czego inni nie mają itd - trzeba dobrze
nazwać. Ale to jest jednak więcej niż system przerwań. Raczej coś w
stylu prostego FPGA nałożonego okrakiem "na procek".
http://www.atmel.com/Images/Atmel-8385-8-and-16-bit-AVR-Microcontroller-ATxmega64A1U-ATxmega128A1U_datasheet.pdf
strona 18
Nie to, żeby się z tego często korzystało, ale można i trochę ułatwia
pewne rozwiązania.


Ale z tym nie dyskutuję - też tak uważam, chociaż na koniec 8-bitowców
jeszcze trochę trzeba poczekać.



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.

Pozdrawiam

DD

Sun Apr 06, 2014 3:41 pm   

W dniu 2014-04-06 13:38, Mario pisze:

Dzięki
Przyjrzę się dokładniej.
Czym się toto programuje (software i hardware)?
I dokumentacja - jak można tak zagmatwać proste sprawy? Tu już chyba
nawet dwa monitory to za mało do robienia projektu...

Pozdrawiam

DD

Sun Apr 06, 2014 3:42 pm   

Gatesowi się sprawdził, a miliony ludzi na świecie włącza komputer, aby po
kilku już minutach móc
się zalogować do banku i sprawdzić, czy ma kasę na kolejną ratę.
Jakoś nie widzę, że ludzie którzy próbują naśladować tych co wpuszczają w
maliny innych,
stawali się miliarderami. Nawet po 20 latach wpuszczania w maliny.
No może czasem sami dają się wpuścić w Raspberry Pi.
S.

Sun Apr 06, 2014 4:14 pm   

Użytkownik Mario napisał:

Nie będę się licytował, angielski mam słaby, nie programuję zawodowo i
nawet bym nie chciał bo to wypala mózg :)

[..]

Ź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ę.


Ogarniasz go na bieżąco podczas pisania, do tej pory nie miałem z tym
problemu.


Licencja... no właśnie...


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ć, 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.

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

Sun Apr 06, 2014 4:55 pm   

Użytkownik Mario napisał:


Wszystkiego idzie się samemu nauczyć, ja na razie jakoś nie mam
motywacji, a jest ona mi niezbędna po pierwszych podejściach do C


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


Właśnie, i ten procek zamiast zrobić co trzeba to tańczy lambadę nagraną
przez kompilator, dlatego musi być 10x szybszy.


Co do błędów kompilatorów nie podam konkretów bo ich nie mam, co jakiś
czas gdzieś trafie na jakieś info że coś źle z kompilatora wychodzi ale
nie kolekcjonuje tego, mam zakodowane że przy kompilatorach mój program
z moimi błędami jest nakładany na cudzy program (kompilacja) z cudzymi
błędami, tak jak piszesz trzeba być na bieżąco z danym kompilatorem aby
znać i omijać jego bolączki. Przy ASMie trzeba być na bieżąco jedynie z
erratą procka.

Przypomniało mi się coś:
http://bash.org.pl/4845689/
<Lukasz> w C++ o błędach mówi nam kompilator
<Lukasz> w PHP klient

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

Sun Apr 06, 2014 4:59 pm   

Ceny 32-bitowców są na poziomie 3$.
Wszystkie inne 8 i 16 bitowe, które mają jakąś sensowną pamięć, kosztują już
2x więcej.
Wygląda na to, że nie ma popytu na 32-bitowe uC.
Pytanie dlaczego?
Ja je lubię, ale większość ludzi zobaczy kartę katalogową i ucieka na
drzewo.
Gdyby taki 32-bitowiec miał tylko jeden prosty UART,
2 przerwania, 1 timer i kartę katalogową 50 stron, to ludzie by się nie
bali.
A tak, same zalety wymienione na początku, zamiast zachęcać,
to odstraszają wydumanymi nazwami.
Przyszły użytkownik zadaje sobie pytanie: Po co właściwie to jest?

A tak jak powiedział Alex, nie przejmować się, że ma tyle bloków
dodatkowych.
Jak będę jakiś potrzebował, to sobie poszukam rejestru konfiguracyjnego o
nazwie:
bardzo_fajny_blok_CON i ustawię sobię w nim bit bardzo_fajny_blok_ON.
Do tego czasu udajemy, że się nie znamy
S.