Użytkownik "T.M.F." <t...@n...mp.pl> napisał w wiadomości
news:hb790t$bbg$1@nemesis.news.neostrada.pl...

> jak pisze aplikacje na PC to rzadko kiedy mam 2 breakpointy, jesli mam to
> tylko dlatego, ze ktoregos zapomnialem skasowac :)

Dokladnie, a warunkowego uzylem moze trzy razy w zyciu - kwestia wprawy.

do góry

> Ale jakie konkretnie warunki mozna zapodac oprocz tych, ktore potrafi
> ATMega z JTAG?
>
>> Typowo jak piszę program naraz używam 4 do 6 pułapek. Jest do 8.
>
>
> Zdarzylo mi sie ustawic 4 pulapki, ale juz naprawde nie widze potrzeby,
> zeby ustawiac wiecej. W koncu jak szukam bledu to mam jakies
> podejrzenia, a nie ustawiam pulapek w calym kodzie. Wlasciwie to 1-2 mi
> w zupelnosci wystarczaja. Zeby nie bylo, ze sprzet mi wymusza takie
> zachowania - jak pisze aplikacje na PC to rzadko kiedy mam 2
> breakpointy, jesli mam to tylko dlatego, ze ktoregos zapomnialem
> skasowac :)

To pisz tak dalej, przeciwskazań nie ma.
K.

do góry

T.M.F. pisze:
> W dniu 15.10.2009 11:25, Konop pisze:
>>> Oj, jednak pola bitowe sa czytelniejsze. No i jesli zmienisz ich
>>> kolejnosc to nie pociaga to potem zazwyczaj uperdliwej zmiany we
>>> wszytkich plikach.
>>
>> Z kolejnością się nie zgodzę!! Tworzę jeden plik nagłówkowy i tam
>> umieszczam wszystkie definicje - nie ma problemu ze zmianą kolejności
>> ;D...
>> Jest jedno "za" tą metodą (i z tego względu tego też używałem). Z tego,
>> co gdzieś kiedyś czytałem [potrzebne źródło ;)] to kompilator ma prawo
>> dowolnie rozmieścić pola bitowe w bajcie. Niekoniecznie będą więc one
>> umieszczone w kolejności wpisywania... w momencie, w którym chce się
>> potem taki bajt gdzieś "wyświetlić", to koniecznie trzeba wiedzieć który
>> bit co oznacza, a używając pól bitowych (dwukropka ;)), możemy tego nie
>> wiedzieć...
>
> Cos sie zapetliles, to w koncu te pola bitowe sa rozmieszczane dowolnie
> czy nie?

Nie no, w MOIM ;) rozwiązaniu kolejność łatwo zmienić i jest ona
"pewna", a w polach bitowych też łatwo zmienić, ale jest ona niepewna...

> IMHO kompilator rozmieszcza je w kolejnosci w jakiej sa zdefiniowane - w
> koncu to struktura, a elementy struktury wystepuja w kolejnosci zgodnej
> z definicja.

Poszukam gdzieś informacji, bo na pewno gdzieś to czytałem... ale czy to
było wiarygodne źródło, to nie wiem... ale tak swoją drogą, robisz
strukturę (zapis skrócony):
Pole1 : 3
Pole2 : 4
Pole3 : 6
Pole4 : 1
Pole5 : 2

Proc o dostępie do pamięci bajtowym... jak pamięć przydzieli
kompilator?? Jak wrzuci jak leci, to Pole3 będzie podzielone pomiędzy
dwa bajty?? Czy może najstarszy bit zostanie "pusty" i Pole3 zacznie się
od drugiego bajtu - wówczas całość zajmie 3 bajty... a może kompilator w
ten 1 wolny bit pierwszego bajtu wrzuci Pole4??

Pozdrawiam
Konop

do góry

On 2009-10-15 16:25:30 +0200, Konop <k...@g...pl> said:

>
> Proc o dostępie do pamięci bajtowym... jak pamięć przydzieli kompilator??

man gcc

-mbit-align

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

do góry

Adam Dybkowski wrote:

> Darkac pisze:
>
>> Kompilator robi miliony różnych automatycznych operacji, mógłby robić
>> również i to. Wszystko powinno być podporządkowane wygodzie człowieka.
>> Po co zaśmiecać głowę i treść programu operacjami które może zrobić
>> maszyna.
>> Szybkość, łatwość i wygoda, to powinny być priorytety w pracy
>> programisty.
>
> Pomyliłeś języki, zacznij pisać raczej w Javie.
>

Raczej orginalny pytacz pomylil sie z wyborem zawodu.
Moja rada brzmi :
1. Albo pogodz sie z tematem i zwiaznymi z nim problemami czyli wez sie do
nauki
2. Albo daj sobie spokoj to jest nie dla Ciebie i mam to na mysli tworzenie
kodu jako takiego (bez wzgledu na jezyk) bo zawsze bedzi pod gorke i wiatr
w oczy ;)

do góry

> Cos sie zapetliles, to w koncu te pola bitowe sa rozmieszczane dowolnie
> czy nie?
> IMHO kompilator rozmieszcza je w kolejnosci w jakiej sa zdefiniowane - w
> koncu to struktura, a elementy struktury wystepuja w kolejnosci zgodnej z
> definicja.

Nie zaleca się korzystać z pól bitowych jeżeli soft ma być kompilowany pod
różnymi platformami gdyż standard NIE DEFINIUJE kolejności przypisania
bitów.

W niektórych sytuacjach jest to bardzo istotna przeszkoda.


Pozdrawiam
MiSter

do góry

In the darkest hour on Thu, 15 Oct 2009 14:47:53 +0200,
T.M.F. <t...@n...mp.pl> screamed:
>> Jest jedno "za" tą metodą (i z tego względu tego też używałem). Z tego,
>> co gdzieś kiedyś czytałem [potrzebne źródło ;)] to kompilator ma prawo
>> dowolnie rozmieścić pola bitowe w bajcie. Niekoniecznie będą więc one
>> umieszczone w kolejności wpisywania... w momencie, w którym chce się
>> potem taki bajt gdzieś "wyświetlić", to koniecznie trzeba wiedzieć który
>> bit co oznacza, a używając pól bitowych (dwukropka ;)), możemy tego nie
>> wiedzieć...
>
> Cos sie zapetliles, to w koncu te pola bitowe sa rozmieszczane dowolnie
> czy nie?

Zależnie od architektury CPU i od kompilatora. Jeśli zapiszesz strukturę
z polem bitowym do pliku, taki plik nie będzie przenośny.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:214B ]
[ 20:12:08 user up 12226 days, 8:07, 1 user, load average: 0.30, 0.10, 0.54 ]

God: Darwin's chief rival.

do góry

In the darkest hour on Wed, 14 Oct 2009 23:49:13 +0200,
Adam Dybkowski <a...@4...pl> screamed:
> Tam kod wynikowy wykonywany przez procesor jest znacząco oddalony od
> tego, co napisał programista (oprócz kompilatora po drodze jest maszyna
> wirtualna tłumacząca bytecode na asembler danego procka). Nawet
> skomplikowane akcje pisze się szybciej i krócej niż w C, ale wynikiem
> tego jest kod działający znacznie wolniej niż napisany od razu w języku
> C no i przy tym znacznie dłuższy (po kompilacji w JRE, bytecode może być
> nawet krótszy). No ale jeżeli przedkładasz koszt developmentu nad
> wydajność aplikacji to Java będzie w sam raz dla Ciebie.
>

Bez przesady znowu z tą wydajnością. Różnice nieistotne zwłaszcza
w przypadku programów z GUI. Dużo programów napisałem w Pythonie, dla
Ciebie pewnie taki program stoi w miejscu i ani piśnie... ;)
A dlaczego w nim? Szybciej, zwięźlej, czytelniej, przenośniej.
Ale to już na jakieś advocacy.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:233B ]
[ 20:14:39 user up 12226 days, 8:09, 1 user, load average: 0.30, 0.10, 0.54 ]

It's here at last: We've released a 26-week project in 48 weeks.

do góry

In the darkest hour on Wed, 14 Oct 2009 15:17:47 +0200,
Konop <k...@g...pl> screamed:
> jak do pamięci RAM. Uważam, że dobrze, że pamięć Flash w AVRze obsługuje
> się nie jak zwykłe zmienne, bo wymusza to na programiście odpowiednie
> podejście do tego typu zmiennych.

Z punktu widzenia programisty piszącego program w C jest to jedynie
upierdliwe (mam tu na myśli tablice z const char *).

> jest jak zwykła zmienna. W komputerach klasy PC stałe (const) trzymane
> są w pamięci RAM, bo nie ma innego wyjścia. W ARMach trafiają do pamięci
> Flash z reguły, bo jest jedna przestrzeń adresowa. Czemu dla AVRów
> miałby być wyjątek??
>

Zużywa na ARV niepotrzebnie RAM dla vtable w przypadku C++.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:227B ]
[ 21:54:16 user up 12226 days, 9:49, 1 user, load average: 0.30, 0.10, 0.54 ]

Death is life's way of telling you you've been fired.

do góry

Użytkownik "Artur M. Piwko" <m...@b...pl> napisał w
wiadomości news:slrnhdepht.6fu.milusi.pysiaczek@buziaczek.pl...
> In the darkest hour on Thu, 15 Oct 2009 14:47:53 +0200,
> T.M.F. <t...@n...mp.pl> screamed:
>>> Jest jedno "za" tą metodą (i z tego względu tego też używałem). Z tego,
>>> co gdzieś kiedyś czytałem [potrzebne źródło ;)] to kompilator ma prawo
>>> dowolnie rozmieścić pola bitowe w bajcie. Niekoniecznie będą więc one
>>> umieszczone w kolejności wpisywania... w momencie, w którym chce się
>>> potem taki bajt gdzieś "wyświetlić", to koniecznie trzeba wiedzieć który
>>> bit co oznacza, a używając pól bitowych (dwukropka ;)), możemy tego nie
>>> wiedzieć...
>>
>> Cos sie zapetliles, to w koncu te pola bitowe sa rozmieszczane dowolnie
>> czy nie?
>
> Zależnie od architektury CPU i od kompilatora. Jeśli zapiszesz strukturę
> z polem bitowym do pliku, taki plik nie będzie przenośny.

Podobnie jak swobodny strumien swiadomosci jest slabo przenosny, ale
przeciez zdajemy sobie z tego sprawe, wiec bez przesady.

do góry