W dniu 2014-04-06 18:14, AlexY pisze:
> 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 :)

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.


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

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

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

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.

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

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?


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

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?

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


--
pozdrawiam
MD