On 07.07.2012 12:38, Mario wrote:
> W dniu 2012-07-06 17:50, Michoo pisze:
>> On 06.07.2012 17:22, janusz_kk1 wrote:
>>> Dnia 06-07-2012 o 13:39:15 Michoo <m...@v...pl> napisał(a):
>>>
>>>> AVR - bo ma niezłą wartość dydaktyczną a jednocześnie nie odrzuca,
>>>> dużo przykładów w sieci, dostępne w DIPie
>>> Koszmarny asembler, z tego powodu polecam 51 albo jeszcze lepiej Z80 :)
>> Brrr. Po co na początku uczyć assemblera?
>>
>
> Przy okazji zaznajamiania z listą rozkazów. Trudno uczyć budowy i zasady
> działania mikroprocesora/mikrokontrolera bez stosowania rozkazów
> procesora.
Po co inżynier potrafiący zaprojektować/zaimplementować system
mikroprocesorowy ma znać "bebechy procesora"? To jest broszka
projektanta procesorów - nauki mechanika samochodowego nie zaczynamy
przecież od górnictwa i przetwórstwa stali i ropy.

Rozumiem jeszcze kogoś zaawansowanego[1], kto potrzebuje znać
architekturę, sposób działania użytej magistrali, peryferia w
procesorze, bo coś robi na FPGA z microblaze/openrisc/etc.

Nie rozumiem po co ktoś, kto się uczy podstaw uC ma wiedzieć jaki jest
dokładnie pipeline w procesorze, skoro tego nie widzi a interesująca i
potrzebna jest informacja np.:
- najszybszy na te architekturze typ zmiennej to (u)int16_t
- 2 cykle na rozkaz
- nie używać floating-point jeżeli nie jest to _konieczne_
- nie używać busy-wait jeżeli można to zrobić inaczej (automaty
skończone + zegar)
- wykorzystywać przerwania gdzie się da
- dokumentować przebieg algorytmu
- przy częstotliwościach zegara powyżej xxx MHz krytyczne czasowo
funkcje oznaczać yyy przy czym należy skontrolować czy to za bardzo nie
uszczupla ramu.

[1] Raczej na studiach magisterskich, albo bardzo specyficznym kierunku
inżynierskich.

> A assembler to po prostu bardziej czytelny zapis kodu
> maszynowego.
Ale zaczynanie od kodu maszynowego prowadzi do "liczenia cykli" i
przesadnego komplikowania programu. Optymalizację należy przeprowadzać
gdy jest to potrzebne, a nie od początku tworzyć "unmaintainable code".


--
Pozdrawiam
Michoo