Powitanko,

> Oj, zaczyna sie :)

Alez ja wcale nie chce rozniecac flejma, poprostu poznajac asm poznajesz
sila rzeczy budowe procka, jego mozliwosci itp., a jest to IMHO
niezbedne. Jak mam pisac prosta obsluge wyswietlacza, albo wyslac cos na
I2C, to z lenistwa korzystam z Bascoma, ale 32bitowa liczbe binarna
przeliczam na kod BCD juz w asm, bo tak mi latwiej i szybciej. W C
pewnie sie to da zrobic ladniej (choc napewno nie szybciej w sensie
pracy programu). Takie moje czysto subiektywne przemyslenia, AVR wlasnie
zaczynam, pierwszy programik w Bascomie - maly sukces, do C nie moge sie
zmusic, choc jednoczesnie wiem, ze wczesniej czy pozniej sie nie obejdzie.


Pozdroofka,
Pawel Chorzempa
--
"-Tato, po czym poznać małą szkodliwość społeczną?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
******* >>> !!! UWAGA: ODPOWIADAM TYLKO NA MAILE ->:
> pavel(ten_smieszny_znaczek)aster.pl <<<<*******

do góry

Lukasz Sczygiel wrote:
> Ale docelowo bardzo popieram nauke asm-a bo pozwala robic dokladnie to co sie
> chce i bardzo oszczedza pamiec.

Ale nie czas.

Bascom: szybko pisane wolne aplikacje do mrugania diodami czy gadania z
LCD. Zrobienie czegoś pokroju FFT kończy się szybkim odlotem w kierunku
C bo albo ograniczenie na wielkość flasha albo nie ma gotowca. Język
jedyny w swoim rodzaju (jak każdy basic).

Asm: wolno pisane szybkie aplikacje do mrugania diodami. Jak chcemy
więcej to przydaje sie czas z gumy i dużo szczęścia. Robota dla
twardzieli. Raczej jako wstawki.

C: szybko pisane szybkie aplikacje do wszystkiego. W dodatku cały kod
logiki można debugowac na PC natywnie bez wiekszego wysiłku co daje od
razu Nx mniej błedów (o ile się potrafi pisac aplikacje z warstwa
abstrakcji sprzętu).

C++: szybko pisane szybkie aplikacje z 3x mniejszą ilością upierdliwych
błedów typu literówka (w stosunku do C).

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:hhb1a7$tkc$1@achot.icm.edu.pl...

............
> Bascom: szybko pisane wolne aplikacje do mrugania diodami czy gadania z
> LCD. Zrobienie czegoś pokroju FFT kończy się szybkim odlotem w kierunku
> C bo albo ograniczenie na wielkość flasha albo nie ma gotowca. Język
> jedyny w swoim rodzaju (jak każdy basic).
>
> Asm: wolno pisane szybkie aplikacje do mrugania diodami. Jak chcemy
> więcej to przydaje sie czas z gumy i dużo szczęścia. Robota dla
> twardzieli. Raczej jako wstawki.
>
> C: szybko pisane szybkie aplikacje do wszystkiego. W dodatku cały kod
> logiki można debugowac na PC natywnie bez wiekszego wysiłku co daje od
> razu Nx mniej błedów (o ile się potrafi pisac aplikacje z warstwa
> abstrakcji sprzętu).
>
> C++: szybko pisane szybkie aplikacje z 3x mniejszą ilością upierdliwych
> błedów typu literówka (w stosunku do C).

Podobno" Twardziele" piszą w kodzie maszynowym :-)))
Pzdr

do góry

In the darkest hour on Mon, 28 Dec 2009 20:34:06 +0100,
Pawel "O'Pajak" <o...@g...pl> screamed:
>> Oj, zaczyna sie :)
>
> Alez ja wcale nie chce rozniecac flejma, poprostu poznajac asm poznajesz
> sila rzeczy budowe procka,

Budowy procesora nie poznasz znając tylko jego instrukcje.
Ja znam tylko kilka instrukcji AVR, co nie przeszkadza pisać mi
większych programów w C.

> jego mozliwosci itp., a jest to IMHO
> niezbedne.

Dosyć zbędne. Tzn. instrukcje, nie budowa. Zwłaszcza poczatkującym.

> Jak mam pisac prosta obsluge wyswietlacza, albo wyslac cos na
> I2C, to z lenistwa korzystam z Bascoma, ale 32bitowa liczbe binarna
> przeliczam na kod BCD juz w asm, bo tak mi latwiej i szybciej.

Szybciej staremu wydze AVR-owemu (za przeproszeniem).

> W C pewnie sie to da zrobic ladniej (choc napewno nie szybciej w sensie
> pracy programu).

Ale szybciej jeśli o czas napisania chodzi. A fistaszkowe kilka
milisekund więcej można pominąć.

> Takie moje czysto subiektywne przemyslenia, AVR wlasnie
> zaczynam, pierwszy programik w Bascomie - maly sukces, do C nie moge sie
> zmusic, choc jednoczesnie wiem, ze wczesniej czy pozniej sie nie obejdzie.

W pewnym momencie przestaje się liczyć mniejszy rozmiar kodu w asm (choć
nie zawsze), przestajesz skrupulatnie liczyć cykli a zaczyna się dla
Ciebie liczyć czas napisania kodu. I jego przenośność. Tutaj C/C++
pokazuje swoje pazurki.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:226B ]
[ 08:34:26 user up 12301 days, 20:29, 1 user, load average: 0.05, 0.95, 0.00 ]

BREAKFAST.COM halted... cereal port not responding!

do góry

In the darkest hour on Mon, 28 Dec 2009 21:37:23 +0100,
henry1 <h...@i...pl> screamed:
>> C: szybko pisane szybkie aplikacje do wszystkiego. W dodatku ca?y kod
>> logiki mo?na debugowac na PC natywnie bez wiekszego wysi?ku co daje od
>> razu Nx mniej b?edów (o ile sie potrafi pisac aplikacje z warstwa
>> abstrakcji sprzetu).
>>
>> C++: szybko pisane szybkie aplikacje z 3x mniejsz? ilo?ci? upierdliwych
>> b?edów typu literówka (w stosunku do C).
>
> Podobno" Twardziele" pisz? w kodzie maszynowym :-)))
>

Prawdziwi twardzi elektronicy powinni pisać od razu w .hex. :P

ps. ustaw MIME, wysyłasz śmieci (http://www.grush.one.pl/mime)

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:237B ]
[ 08:39:50 user up 12301 days, 20:34, 1 user, load average: 0.05, 0.95, 0.00 ]

Doing nothing is very hard to do... you never know when you're finished.

do góry

Hello Artur,

Tuesday, December 29, 2009, 8:40:38 AM, you wrote:

[...]

>>> C++: szybko pisane szybkie aplikacje z 3x mniejszą ilością upierdliwych
>>> b3edów typu literówka (w stosunku do C).
>> Podobno" Twardziele" piszą w kodzie maszynowym :-)))
> Prawdziwi twardzi elektronicy powinni pisać od razu w .hex. :P

Prawdziwy, twardy elektronik może najwyżej schematy rysować. To
programiści piszą w .hex - elektronik programiście może co najwyżej
zbudować urządzenia do zaprogramowania.

--
Best regards,
RoMan mailto:r...@p...pl
Spam: http://www.allegro.pl/sklep/7416823_squadack :)

do góry

In the darkest hour on Tue, 29 Dec 2009 09:32:15 +0100,
RoMan Mandziejewicz <r...@p...pl> screamed:
>>>> C++: szybko pisane szybkie aplikacje z 3x mniejszą ilością upierdliwych
>>>> b3edów typu literówka (w stosunku do C).
>>> Podobno" Twardziele" piszą w kodzie maszynowym :-)))
>> Prawdziwi twardzi elektronicy powinni pisać od razu w .hex. :P
>
> Prawdziwy, twardy elektronik może najwyżej schematy rysować. To
> programiści piszą w .hex - elektronik programiście może co najwyżej
> zbudować urządzenia do zaprogramowania.
>

Masz rację. Czyli wychodzi na to, że prawdziwy elektronik schemat robi na
pająku... :P

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:234B ]
[ 11:47:09 user up 12301 days, 23:42, 1 user, load average: 0.05, 0.95, 0.00 ]

I drive way too fast to worry about cholesterol. -- Steven Wright

do góry

Użytkownik "RoMan Mandziejewicz" <r...@p...pl> napisał w wiadomości
news:429542131.20091229093215@pik-net.pl...
>
> Prawdziwy, twardy elektronik może najwyżej schematy rysować. To
> programiści piszą w .hex - elektronik programiście może co najwyżej
> zbudować urządzenia do zaprogramowania.
>
RoMan,
Moim zdaniem granica (jeśli istnieje) między elektronikiem, a programistą
przebiega nieco wyżej niż to sugerujesz. Osobę piszącą oprogramowanie bardzo
bliskie sprzętu (kiedy trzeba wiedzieć, które dane ma się we flashu, a które
w RAMie, jak długa może być procedura obsługi przerwania, którą flagę da się
zmodyfikować jednym rozkazem, jak obniżyć zakłócenia w czasie pracy
przetwornika A/D, jak na jednej pastylce przepracować kilka lat itp.) nazwę
elektronikiem, a nie programistą. Ale to tylko moje zdanie.
P.G.

do góry

Hello Piotr,

Tuesday, December 29, 2009, 12:15:37 PM, you wrote:

>> Prawdziwy, twardy elektronik może najwyżej schematy rysować. To
>> programiści piszą w .hex - elektronik programiście może co najwyżej
>> zbudować urządzenia do zaprogramowania.
> RoMan,
> Moim zdaniem granica (jeśli istnieje) między elektronikiem, a programistą
> przebiega nieco wyżej niż to sugerujesz. Osobę piszącą oprogramowanie bardzo
> bliskie sprzętu (kiedy trzeba wiedzieć, które dane ma się we flashu, a które
> w RAMie, jak długa może być procedura obsługi przerwania, którą flagę da się
> zmodyfikować jednym rozkazem, jak obniżyć zakłócenia w czasie pracy
> przetwornika A/D, jak na jednej pastylce przepracować kilka lat itp.) nazwę
> elektronikiem, a nie programistą. Ale to tylko moje zdanie.

Gdybyś nie rżnął cytatów, to widziałbyś, do czego się odnoszę - do
dyskusji na temat wyższości C++ nad C i zdania wypowiedzianego w tym
kontekście.
Bo mnie - jako elektronika - naprawdę boli to, że obecni "elektronicy"
dyskutują o wyższości jednego języka programowania nad drugim a
_zastosować_ prawo Ohma czy prawa Kirchoffa nie potrafią. O bardziej
skomplikowanych zależnościach szkoda pisać (mam nadzieję, że
dyskutanci nie wezmą tegodo siebie, bo to uwaga natury ogólnej).

Jako były programista - żyłem z tego przez 20 lat - naprawdę potrafię
odróżnić elektronika od programisty.

--
Best regards,
RoMan mailto:r...@p...pl
Spam: http://www.allegro.pl/sklep/7416823_squadack :)

do góry

RoMan Mandziejewicz wrote:
> Bo mnie - jako elektronika - naprawdę boli to, że obecni "elektronicy"
> dyskutują o wyższości jednego języka programowania nad drugim a
> _zastosować_ prawo Ohma czy prawa Kirchoffa nie potrafią.

To nie są elektronicy. Podobnie jak cieżko nazwać kogoś elektronikiem
kto szyje sterownik silnika krokowego na przekaźnikach (przypadek
autentyczny z przed 2 tygodni) znikając ostatnie 30 lat rozwiju tej
dziedziny. Pogodzić się musisz, że granica pomiedzy programatorem a
operatorem lutownicy już od dawna jest cieżko dostrzegalna.

PS. Ostatnio miałem taki przypadek, kiedy to "prawdziwy elektronik"
zeszyl sliczny i bezużyteczny dla programisty kawałek PCB. Wszelka
dyskusja kończyła się o przepaść między dziedzinami. I nic mi po tym że
człek świetnie znał prawo ohma kiedy nie potrafił zrozumieć systemu
przerwań w cpu do którego szył schemat "bo panie, reszte się pewno w
sofcie da zrobic, nie?".

do góry