Opinie na temat książki o programowaniu AVR w C - warto zainwestować?

Mon Jan 31, 2011 12:22 pm   

W dniu 31.01.2011 11:05, Marcin Wasilewski pisze:


--
Pozdrawiam
Michoo

Mon Jan 31, 2011 12:35 pm   

W dniu 31.01.2011 10:11, Piotr Gałka pisze:

wykonywać operacje atomowe.

Po drugie C (avr-gcc) udostępnia ładne makro po którym od razu widać, że
w tym miejscu zachodzi synchronizacja:
ATOMIC_BLOCK(ATOMIC_FORCEON)
{
flags |= 0b00001001;
}


--
Pozdrawiam
Michoo

Mon Jan 31, 2011 1:25 pm   

Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:ii66p3$56t$1@news.onet.pl...

Przypuszczam, że w tym kursie było coś takiego:
struct {int a:1;int b:1;...}flags;
i potem zapisy typu: flags.a=1; które prawdopodobnie nie były w nic
robiącego z tego operację atomową ujęte.
O ile widząc flags|=1 można się spodziewać kilku rozkazów, o tyle widząc
flags.a=1 można mieć większe problemy, aby wpaść na to, że to może wymagać
otoczenia blokowaniem przerwań.
Tak z czystej ciekawości:
Czy takie makro patrzy co jest w jego wnętrzu i albo blokuje przerwania,
albo nie (jeśli wnętrze z natury jest operacją atomową) ?
P.G.

Mon Jan 31, 2011 3:11 pm   

Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:ii6612$1o6$1@news.onet.pl...

Np. tak:

a) co jest zrzucane na stos i dlaczego w takiej kolejności,
b) że są rejestry w obszarze I/O i w ext. I/O, a w związku z tym sporo
inaczej je się obsługuje, w szczególności jeśli chodzi o operacje bitowe.
c) że czasami po zapisie do rejestru warto wstawić nop, zanim zaczniemy go
czytać.
d) że pewne instrukcje działają wyłącznie na dedykowanych rejestrach,
e) że wartość z rejestru PC to tak naprawdę liczba słów i trzeba ją pomnożyć
x2, jeśli chcemy tej wartości użyć poprzez lpm,
f) że używając w C zmiennej typu char do wymiany danych z proc. obsługi
przerwań, nie trzeba się tym przejmować, w odróżnieniu od int-ów i jeszcze
dłuższych zmiennych,
g) że znacznie lepiej mnożyć/dzielić przez 2, 4, 8 itd., niż przez 10.

I wiele, wiele innych rzeczy o których w tej chwili nie pamiętam.

Mon Jan 31, 2011 3:30 pm   

W dniu 31.01.2011 15:11, Marcin Wasilewski pisze:



możliwość ustawiania/gaszenia atomowo jednego bitu? (Co jest w
dokumentacji.)


rejestrów 16b.






- komunikację z przerwaniami zawsze lepiej objąć w ATOMIC, bo inaczej
łatwo o prosty błąd przy późniejszych przeróbkach kodu. (A koszt
zazwyczaj pomijalny - 2 cykle +1 cykl opóźnienia.)


cykl różnicy. Dzielenie przez stałą sensowny kompilator zamienia na
mnożenie.



--
Pozdrawiam
Michoo

Mon Jan 31, 2011 4:38 pm   

On Mon, 31 Jan 2011 15:30:22 +0100, Michoo wrote:

Mozna sie zastanowic nad glebokoscia wywolan, adresowaniem parametrow
itp.



Bywaja niuanse ze jedne maja, inne nie maja, a jeszce inne maja gdzie
indziej.

Albo ze np nie ma posredniego adresowania I/O.


W zasadzie tak.


No i tu moze byc problem, bo rejestry specjalne moga wymagac
specjalnie, a dla zwyklej pamiec rzadko jest potrzeba zawsze blokowac
przerwania - ale czasem jest.


Sprawdzic czy kompilator o tym wie :-)


No, tu faktycznie moze sie kompilator wykazac pomyslowoscia i
optymalizowac na rozne sposoby - nawet lepiej niz niedouczony
programista.


To mozliwe tylko dla zmiennego przecinka.


Albo musi, i nie tylko pamietac, ale wiedziec jak to jest w procku, i
jak z tego skorzystac w C. Timery, komunikacja, przerwania ..

J.

Mon Jan 31, 2011 5:22 pm   

i to zapewne znajdzie w tej książce... EOT

Mon Jan 31, 2011 6:00 pm   

W dniu 31.01.2011 16:38, J.F. pisze:

stosie przy danej konwencji wywołań.




assemblerze adresujący IO pośrednio i tak samo się zastanawiać dlaczego
nie działa.



jest niezależne od tego czy asm czy c.


Division by invariant integers using multiplication


wiedza wynikająca z programowania w ASM nie jest konieczna.

P.S.
Pisanie na początku w asm potrafi zostawić brzydkie nawyki jak
przesunięcia binarne zamiast dzielenia, czy "optymalizację" liczników w
pętlach, które nie mają praktycznego znaczenia a zaciemniają kod. Imo
optymalizować należy jeżeli są problemy z wydajnością a nie "na zapas".

--
Pozdrawiam
Michoo

Mon Jan 31, 2011 6:27 pm   

On Mon, 31 Jan 2011 18:00:48 +0100, Michoo wrote:

I w dokumentacji procesora jaki ten stos moze byc.


Na przyklad okresla co jest niemozliwe czy tez bardzo pracochlonne.
Pamietasz 51 z jej pamieciami ?


Jak juz znasz dokumentacje na takim poziomie to znasz i asma


albo nie mozna, bo nie ma takiego rozkazu. Przy czym latwiej da sie
przeczytac w opisie konkretnej instrukcji niz sie zastanawiac o co
temu glupiemu kompilatorowi chodzi przy banalnej instrukcji
out(p,v).



C moze to kompilowac inaczej niz myslisz.


O ile pamietam wyniki nie zawsze sa calkowicie zgodne.


No, polemizowalbym nieco czy to brzydki nawyk.
Za to brak w C operacji "obrotu" bitow, i to juz jest czasem problem.


Od procka zalezy, bo jak sie ma 16 rejestrow po 32 bit to sie pisze
fajnie, a jak trzy po 8 to kompilator musi sie bardzo mocno wykazac, a
i programista, zeby sie nie okazalo ze zapasu nie ma :-)

J.

Mon Jan 31, 2011 8:39 pm   

Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:ii6h1t$djb$1@news.onet.pl...


Takie, że jak się pisze w C na scalaki typu Tiny13, które mają "aż" 64
bajty RAMu to się można zdziwić, jaką sieczkę odwala (a raczej odkłada na
stos) kompilator C wchodząc w przerwanie. A zasada jest prosta zrzuca się na
stos SR i używane w przerwaniu rejestry, a nie wszystko co się da na zapas
jak robi to kompilator C.


Tak, szczególnie jak masz np. 1K Flash-a i 64B ramu
Ale wtedy co robi programista w C? Zamiast ATtiny13, ładuje się ATtiny2313 i
problem rozwiązany.


Po pierwsze zajmuje 2 takty samo mnożenie, ale jego wynik ląduje w
rejestrach R0/R1, co powoduje, że tracimy nast. kilka taktów aby je stamtąd
wydobyć. A przypominam, że R0-R15 są rejestrami w pewnym stopniu
upośledzonymi i nie wszystkie instrukcje dostępu do nich działają (np. ldi).
Rolowanie zajmuje jednak mniej.


Do momentu jak mu się program "zesra", bo stos wlezie na zmienne.

Podsumowując - pisanie w C wymaga sporo mniej czasu, jednak pewne rzeczy
dostępne w asm od ręki C ma wyjątkowo upierdliwie rozwiązane (np. dostęp do
zmiennych w pamięci FLASH). Poza tym, jak ktoś zna assembler, to sobie ze
wstawkami w newralgicznych miejscach poradzi.

Mon Jan 31, 2011 9:04 pm   

On 2011-01-31 20:39, Marcin Wasilewski wrote:

To bug w kompilatorze jeśli wrzuca za dużo. Nikt nie twierdzi ze avr-gcc
jest doskonały bo sam wiem że *za* dużo rejestrów używa w przerwaniach.


Kompilator C tak nie robi. Tak robi tylko *zły* kompilator C.


I ma wiele racji. Dla $0.50 oszczędności per sztuka może sie okazać że
nie ma co robić rekodzieła w kodzie asm przez 4 miesiące aż się
*zmieścisz* co do bajta tylko od razu wziąść na zapas i program napisać
w dwa wieczory.


Jesli kompilator nie potrafi zamienić a *= 2; na operacje shift bitów to
jest marnym kompilatorem.


Zapewne asm jest tak magiczny że to się nie ma prawa popsuć w ten
sposób, nie?


To raczej brak supportu ze strony kompilatora. C nie ma nic do tego że
są jakieś rózne pamięci, choć było by miło gdyby miał.


Rzecz w tym że:

a) niektórzy programisci starej daty w C piszą dokładnie tak samo jak w
asm (wlacznie z uzywaniem goto). Dla nich nie ma różnicy bo i tak nie
potrafia w gruncie rzeczy wykorzystać C.

b) niektórzy uważają że wstawką może być cały program.

Wiec jest kwestią zdrowego rozsądku sensownie to podzielić. Osobiście
jestem zdania że najlepszy jest podział 100% C++ i 0% asm.

Mon Jan 31, 2011 9:13 pm   

Rozwój informatyki w sprzęcie i oprogramowaniu śledzę od czasów ZX spectrum,
5051, Z1, ...

Zawsze zastanawiała mnie pewna sprawa.
Jeżeli program który chodził na kompie XT (procesor intel 86 , zegar coś
około 4 MHz) uruchomimu na
komputerze nowszej generacji ( AT - Intel 286) to wynik działania programu
otrzymamy relatywnie szybciej.

Biorąc pod uwagę postęp geometryczny w rozojwu sprzętu obecne komputery
klasy PC powinny śmigać w zastraszającym tempie.

Ale co ciekawe cały przyrost mocy obliczeniowej skutecznie konsumowany jest
przez rozdmuchane oprogramowanie zarówno systemowe jak i aplikacje.
Wiadom, że kiedyś programy były toporne i robiły jedynie to co się od nich
oczekiwało.
Teraz program musi się jakoś prezentować - nie wystarczy sam wynik obliczeń.
Liczy się forma przekazu.

Ale czasami wk...wia mnie do białości sytuacja gdy np instaluję drukarkę
gdzie sterowniki do niej zamieszczone są na dwóch płytach DVD.
Choć wiem, że wystarczą góra dwa pliczki dll + inf i po sprawie.
Ale zwykłemu userowi ciągle sprzedaje się kit, że tak ma być. Że instalacja
musi trwać 2 godziny, żę musi zainstalować sobie całe to gówno, że musi
podać dane osobowe swoje, szefa i strukturę produkcji firmy oraz obowiązkowo
zamówić oryginalne materiały eksploatacyjne.

Odbiegam od tematu ...
A chciałem tyko napisać o oprogramowaniu.
Patrząc na teorię oprogramowania i twory jakie trzeba póżniej eksploatować
często się bebechy gotują.
Najczęściej jest to niestety przerost formy nad treścią.

Mon Jan 31, 2011 9:54 pm   

On 2011-01-31 21:13, kk wrote:

Złożonośc rozwiązaywanych problemów również rośnie w zastraszającym tempie.

Mon Jan 31, 2011 10:20 pm   

Głównym problemem jest jak namówić klienta do kupna czegoś co mu zupełnie do
niczego nie będzie potrzebne.

Machina sprzęt-oprogarmowanie jest samonapędliwa ( piszę tu o PC i
programach pod windows) tak jak biurokracja.
Z jednej strony postęp w sprzęcie, z drugiej oprogramowanie które zmusza do
kupowania co raz lepszego i mocniejszego sprzętu.
Widząc to co się dzieje uważam, że twórcy oprogramowania komercyjnego nie
wiedzą co to optymalizacja.
A pewnie świadomie tworzą potworki typu pakiety office czy kolejne wersje
przeglądarek Adobe Reader które poza tym, że są coraz większe objetościowo i
wymagają coraz lepszego sprzętu to właściwie nic nowego poza formą nie
wnoszą.

Mon Jan 31, 2011 10:27 pm   

On 2011-01-31 16:38, J.F. wrote:
[.....]


Każdy programista systemowy musi mieć jakieś pojęcie o sprzęcie. I to
nie tylko o CPU/MCU ale również musi wiedzieć np. jak wygląda mapa
pamięci czy też w jaki sposób są podłączone i jak się komunikują z MCU
peryferia, np. jakiś RTC na I2C. Poza tym żaden programista systemowy
rzeźbiący w C dla MCU raczej nie uniknie chociażby szczątkowego kontaktu
z assemblerem. Natomiast rzeźbiarstwo w assemblerze "dla zasady"
najzwyczajniej w świecie nie jest uzasadnione ekonomicznie.