W dniu 2014-04-06 13:38, Mario pisze:
> W dniu 2014-04-06 09:59, Dariusz Dorochowicz pisze:
>
>> Oczywiście jest miejsce dla jednej jak i drugiej rodziny procesorów,
>> zresztą sama moc procesorów jest zupełnie inna. Bardzo bym się ucieszył
>> z ARMa, który byłby zrobiony jak XMega128A1, najlepiej gdyby była
>> również wersja z np 144 nogami,
>
> Cortex M4 z NXP
> http://www.nxp.com/parametrics/71496/#/p=1,s=0,f=c26
423:b2a06,c=,rpp=,fs=0,sc=,so=,es=Grouping324;Groupi
ng325

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

do góry

> 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ć...
Jeżeli się coś sprawdza, to warto jeszcze zaznaczyć dla kogo.
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.

do góry

Użytkownik Mario napisał:
> W dniu 2014-04-06 14:39, AlexY pisze:
[..]
>> 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.
>
> 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 będę się licytował, angielski mam słaby, nie programuję zawodowo i
nawet bym nie chciał bo to wypala mózg :)

[..]
>> Nikt nigdy nie wmówi mi że asm jest łatwy,
>
> 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.

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

>> jego podstawowa zaleta to
>> wiedza co w danym momencie się dzieje z każdym bitem, całkowita kontrola
>> sprzętu,
>
> Dopóki ten sprzęt jest wystarczająco prosty aby go ogarnąć.

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

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

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

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

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

do góry

Użytkownik Mario napisał:
> W dniu 2014-04-06 14:28, AlexY pisze:
[..]
>> 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ć?
>
> 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
[..]

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

>> 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.
>
> Napisz coś konkretnego o tych błędach kompilatora. I w czym są gorsze od
> błędów własnych?

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

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

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

>> a do tego mimo że
>> napisany prawidłowo zawiera błędy kompilatora, znane i nieznane.
>
> 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.

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

do góry

> >> jego podstawowa zaleta to
> >> wiedza co w danym momencie się dzieje z każdym bitem, całkowita
kontrola
> >> sprzętu,
> >
> > Dopóki ten sprzęt jest wystarczająco prosty aby go ogarnąć.
>
> Ogarniasz go na bieżąco podczas pisania, do tej pory nie miałem z tym
> problemu.
I tak to wygląda.
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.

do góry

"Sylwester Łazar" <i...@a...pl> wrote in message
news:lhrtgd$5p7$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ć...
> Jeżeli się coś sprawdza, to warto jeszcze zaznaczyć dla kogo.
> 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ę.

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 :-)

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

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

do góry

> Właśnie, i ten procek zamiast zrobić co trzeba to tańczy lambadę nagraną
> przez kompilator, dlatego musi być 10x szybszy.
:-)
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.

do góry

>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...
Aaa... uśpienia!
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.

> 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...
Gates miał na to 20 lat. Nie udało mu się.
Świadczy to o jego geniuszu czy głupocie?
S.

do góry

W dniu 2014-04-06 17:41, Dariusz Dorochowicz pisze:
> W dniu 2014-04-06 13:38, Mario pisze:
>> W dniu 2014-04-06 09:59, Dariusz Dorochowicz pisze:
>>
>>> Oczywiście jest miejsce dla jednej jak i drugiej rodziny procesorów,
>>> zresztą sama moc procesorów jest zupełnie inna. Bardzo bym się ucieszył
>>> z ARMa, który byłby zrobiony jak XMega128A1, najlepiej gdyby była
>>> również wersja z np 144 nogami,
>>
>> Cortex M4 z NXP
>> http://www.nxp.com/parametrics/71496/#/p=1,s=0,f=c26
423:b2a06,c=,rpp=,fs=0,sc=,so=,es=Grouping324;Groupi
ng325
>>
>
> Dzięki :)
> Przyjrzę się dokładniej.
> Czym się toto programuje (software i hardware)?

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.

> I dokumentacja - jak można tak zagmatwać proste sprawy? Tu już chyba
> nawet dwa monitory to za mało do robienia projektu...

Mi dwa wystarczają.


--
pozdrawiam
MD

do góry

"AlexY" <a...@i...pl> wrote in message
news:lhs0th$qtp$1@speranza.aioe.org...
> Wszystkiego idzie się samemu nauczyć, ja na razie jakoś nie mam motywacji,
> a jest ona mi niezbędna po pierwszych podejściach do C

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 :-)

>> Napisz coś konkretnego o tych błędach kompilatora. I w czym są gorsze od
>> błędów własnych?
>
> 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ł.

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

>> 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.
>
> Właśnie, i ten procek zamiast zrobić co trzeba to tańczy lambadę
> nagraną przez kompilator, dlatego musi być 10x szybszy.

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

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

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.

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

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!

do góry