PICowanie

[stch...@gmail.com]

Witam,

Nigdy się w to nie bawiłem, bo potrzeby takowej nie było, aż tu nagle jest potrzeba picowania. Konkretnie PIC16F877A. Pytanko: jakie środowisko programistyczne proponujecie? Projekt w zasadzie duperelny, jednorazowy, więc wiadomo.., środowisko projektowe ma być za friko, ale na legalu!! Z Microchipa można zassać na legalu kompilator, ale chciałbym poznać opinię tych którzy na tym "zęby zjadli", czy jest ewentualnie coś innego godnego uwagi i zassania na zasadzie OpenGL czy jakoś tam..

[Marek]

On Tue, 8 Oct 2013 13:42:42 -0700 (PDT), stch...@gmail.com wrote:
> oś innego godnego uwagi i zassania na zasadzie OpenGL czy jakoś
tam..

Jest opensource'owy sdcc, ale generuje trochę spuchniety kod w
porównaniu z kompilatorem microchipa. Ale do nieskomplikowanych
rzeczy można go użyć, pod warunkiem że umiesz sobie napisac Makefile
(to nie jest "okienkowy" kompilator).

--
Marek

[AlexY]

Użytkownik Marek napisał:

Się przyłączę bo dostałem szynę tej serii, coś do pisania w assemblerze
się nadaje?

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

[Marek]

On Tue, 08 Oct 2013 23:23:51 +0200, Marek <fa...@fakeemail.com> wrote:
> Jest opensource'owy sdcc.

Z open source jest jeszcze great cow basic.
Jeśli chodzi o assembler to jest gputils.

--
Marek

[Zbych]

W dniu 08.10.2013 22:42, stch...@gmail.com pisze:

> Witam,
>
> Nigdy się w to nie bawiłem, bo potrzeby takowej nie było, aż tu nagle jest potrzeba picowania. Konkretnie PIC16F877A. Pytanko: jakie środowisko programistyczne proponujecie? Projekt w zasadzie duperelny, jednorazowy, więc wiadomo.., środowisko projektowe ma być za friko, ale na legalu!! Z Microchipa można zassać na legalu kompilator, ale chciałbym poznać opinię tych którzy na tym "zęby zjadli", czy jest ewentualnie coś innego godnego uwagi i zassania na zasadzie OpenGL czy jakoś tam..
>

Jak nie masz ochoty na zabawy w wynalazki, to najprościej będzie
ściągnąć MPLABX i kompilator microchipa (60 dniowa wersja próbna, potem
wyłącza się optymalizacja) albo hi-techa XC (45 dniowa wersja próbna).
Jeśli dobrze pamiętam, to wersje próbne można wykorzystać też do
projektów komercyjnych, ale upewnij się.

http://www.microchip.com/pagehandler/en-us/family/mplabx/
http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/

[stch...@gmail.com]

Dzięki za info!! Jeszcze tego nie zassałem, a już mam pytania.. Czy jest to środowisko "okienkowe"? Tak jak chociażby Delphi(Pascal) i czy jest to strasznie upierdliwe? Czy da się tam skrobać w Assemblerze tego procka?
Podejrzewam, że jest kompilator C, ale raczej nie jestem fanem tego potrąbionego języka programowania. a+=a, a=+a , toż tego czytać się nie da! O popierdolonych znakach funkcji logicznych nawet nie ma co wspominać...

[Sylwester Łazar]

> Nigdy się w to nie bawiłem, bo potrzeby takowej nie było, aż tu nagle jest
potrzeba
> picowania. Konkretnie PIC16F877A. Pytanko: jakie środowisko
programistyczne
> proponujecie? Projekt w zasadzie duperelny, jednorazowy, więc wiadomo..,
środowisko

Proponuję zacząć od PIC serii 18.
Tak się składa, że Microchip zazwyczaj ma podobnie/identycznie wyprowadzone
sygnały w obu seriach
PIC18 i PIC16.
PIC16F877A ma zdaje się przełączanie BANKów danych RAM,
więc przy ASM ma to znaczenie.
Można na tym polegnąć już przy kodzie >1kB, a już przynajmniej przyprawić
monitor,
o wysłuchiwanie niecodziennych komend, lub zbicie matrycy :-)
No i MPLAB v. 8+ sobie poradzi z tym bez problemu.
Jednak konieczny jest debugger ICD2, ICD3 lub inny.

--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.

[Piotr Gałka]

Użytkownik <stch...@gmail.com> napisał w wiadomości
news:fde47e5e-5b57-4222...@googlegroups.com...

> Podejrzewam, że jest kompilator C, ale raczej nie jestem fanem tego
> potrąbionego języka programowania. a+=a, a=+a , toż tego czytać się nie
> da!

Przecież czytał będziesz tylko to, co sam napiszesz, a nikt Ci nie każe
używać dziwnych zapisów.
P.G.

[inny punkt siedzenia...]

toż te zapisy to siła PO za co są ciągle nagradzani...

[Piotr Gałka]

Użytkownik "inny punkt siedzenia..." <NOSPAMte...@go2.pl> napisał w
wiadomości news:l33fh4$9b8$1...@node1.news.atman.pl...

> toż te zapisy to siła PO za co są ciągle nagradzani...
>

A w sposób zrozumiały dla ludzi to jakby to brzmiało?

[RoMan Mandziejewicz]

Hello Piotr,

Wednesday, October 9, 2013, 2:04:34 PM, you wrote:

>> toż te zapisy to siła PO za co są ciągle nagradzani...
> A w sposób zrozumiały dla ludzi to jakby to brzmiało?

"Nie lubię".


--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

[Marek]

On Wed, 9 Oct 2013 02:52:20 -0700 (PDT), stch...@gmail.com wrote:
> Podejrzewam, że jest kompilator C, ale raczej nie jestem fanem tego

potr=
> ąbionego języka programowania. a+=a, a=+a , toż tego czytać si=

Zobacz great cow basic.

--
Marek

[Piotr Gałka]

Użytkownik "RoMan Mandziejewicz" <ro...@pik-net.pl.invalid> napisał w
wiadomości news:835089144.20...@pik-net.pl.invalid...

>
>>> toż te zapisy to siła PO za co są ciągle nagradzani...
>> A w sposób zrozumiały dla ludzi to jakby to brzmiało?
>
> "Nie lubię".

:-)
- Dlaczego nie lubisz ?
- Bo tak.

[RoMan Mandziejewicz]

Hello Piotr,

Wednesday, October 9, 2013, 2:43:17 PM, you wrote:

>>>> toż te zapisy to siła PO za co są ciągle nagradzani...
>>> A w sposób zrozumiały dla ludzi to jakby to brzmiało?
>> "Nie lubię".
> :-)
> - Dlaczego nie lubisz ?
> - Bo tak.

No widzisz - doskonale rozumiesz Karolka P. ;)

[Zbych]

W dniu 09.10.2013 11:52, stch...@gmail.com pisze:

> W dniu środa, 9 października 2013 08:45:22 UTC+2 użytkownik Zbych napisał:
>> W dniu 08.10.2013 22:42, stch...@gmail.com pisze:
>>
>>> Witam,
>>
>>>
>>
>>> Nigdy się w to nie bawiłem, bo potrzeby takowej nie było, aż tu nagle jest potrzeba picowania. Konkretnie PIC16F877A. Pytanko: jakie środowisko programistyczne proponujecie? Projekt w zasadzie duperelny, jednorazowy, więc wiadomo.., środowisko projektowe ma być za friko, ale na legalu!! Z Microchipa można zassać na legalu kompilator, ale chciałbym poznać opinię tych którzy na tym "zęby zjadli", czy jest ewentualnie coś innego godnego uwagi i zassania na zasadzie OpenGL czy jakoś tam..
>>
>>>
>>
>>
>>
>> Jak nie masz ochoty na zabawy w wynalazki, to najprościej będzie
>>
>> ściągnąć MPLABX i kompilator microchipa (60 dniowa wersja próbna, potem
>>
>> wyłącza się optymalizacja) albo hi-techa XC (45 dniowa wersja próbna).
>>
>> Jeśli dobrze pamiętam, to wersje próbne można wykorzystać też do
>>
>> projektów komercyjnych, ale upewnij się.
>>
>>
>>
>> http://www.microchip.com/pagehandler/en-us/family/mplabx/
>>
>> http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/
>
> Dzięki za info!! Jeszcze tego nie zassałem, a już mam pytania.. Czy jest to środowisko "okienkowe"? Tak jak chociażby Delphi(Pascal) i czy jest to strasznie upierdliwe? Czy da się tam skrobać w Assemblerze tego procka?

Środowisko okienkowe i asembler masz za darmo. Do tego możesz dokupić
jakiś tani programator/debugger np. Pickit3.

> Podejrzewam, że jest kompilator C, ale raczej nie jestem fanem tego potrąbionego języka programowania. a+=a, a=+a , toż tego czytać się nie da! O popierdolonych znakach funkcji logicznych nawet nie ma co wspominać...

Kwestia przyzwyczajenia. Jak poszukasz, to pewnie znajdziesz też jakieś
kompilatory basica i pascala, ale nie wiem czy jest sens kupować na
jeden projekt.

http://www.mikroe.com/mikropascal/pic/

[Jakub Rakus]

On 08.10.2013 22:42, stch...@gmail.com wrote:
> Witam,
>
> Nigdy się w to nie bawiłem, bo potrzeby takowej nie było, aż tu nagle jest potrzeba picowania. Konkretnie PIC16F877A.
>

Ja walczyłem dokładnie z tym prockiem w starym mplabie i w mplabx.
Spodobał mi się wbudowany w mplabx debuger, a asemblerze wstawki też się
całkiem możliwie robi. Używałem kompilatora od hi-techa, wymagało to
chwili na skonfigurowanie środowiska i poczytanie dokumentacji (hi-tech
i kompilator od mikrocipa nieco odmiennie rozumieją niektóre zapisy np.
dotyczące ustawiania rejestrów konfiguracyjnych procka).

--
Pozdrawiam
Jakub Rakus

[Sebastian Biały]

On 2013-10-09 11:52, stch...@gmail.com wrote:
> Podejrzewam, że jest kompilator C, ale raczej nie jestem fanem tego potrąbionego języka programowania.

Kompilator C na PICe jest. Prawdziwy dramat że nie ma C++ [*]. Masz
jednak trzecie "wyjścia", np: http://www.rfc1149.net/devel/rforth1.html

> O popierdolonych znakach funkcji logicznych nawet nie ma co wspominać...

Zmartwie cie: C to *jedyny* naprawdę przenośny język programowania,
szczególnie w embedded. Albo się z nim przeproś albo pisz to samo w
Ada/Lisp i szukaj arch na której ktoś łaskawie napisał kompilator (który
i tak zapewne nie działa) ...

[*] Akademicko patrząc nigdzie nie ma C++, ale na PiCe jakby najbardziej
nie ma.

[Marek]

On Wed, 09 Oct 2013 21:46:39 +0200, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> Kompilator C na PICe jest. Prawdziwy dramat że nie ma C++ [*]. Masz

Matko jedyna, po co c++ na 8bit? Twierdzenie, że nie ma c++ dla pic
na pod jest nie do końca prawdą bo microchip od jakiegoś czasu
udostępnił swoje patche do g++ na pic32, g++ się już można
skomplikować przy kompilacji całego kompilatora c32 i ma już
wymagane liby.

--
Marek

[Marek Borowski]

On 10/9/2013 10:26 PM, Marek wrote:
> On Wed, 09 Oct 2013 21:46:39 +0200, Sebastian Biały<he...@poczta.onet.pl>
> wrote:
>> Kompilator C na PICe jest. Prawdziwy dramat że nie ma C++ [*]. Masz
>
> Matko jedyna, po co c++ na 8bit?

Sebastian twierdzi ze takie rzeczy jak RAII, silne typowanie, statyczny
polimorfizm sa niezbedne przy projektach na max kilka tys lini kodu :-).

Moim zdaniem uzywanie C++ ma sens kiedy robimy cos duzego, gdzie
faktycznie enkapsulacja danych ulatwia ogranianie projektu.

Dodam ze zysk z uzycia C++ skutecznie niweluja problemy ze srodowiskami.
Przenosnosc kodu dramatycznie spada.... bo wiekszosc z nich
po prostu C++ nie wpiera.


Pozdrawiam

Marek

[Sebastian Biały]

On 2013-10-09 22:26, Marek wrote:
> Matko jedyna, po co c++ na 8bit?

Zdarłem już klawiaturę wyjasniając w kilku wątkach w ostatnich kilku
latach :)

> Twierdzenie, że nie ma c++ dla pic na
> pod jest nie do końca prawdą bo microchip od jakiegoś czasu udostępnił
> swoje patche do g++ na pic32

Czyli nie na pic tylko na mips.

[Marek Borowski]

On 10/10/2013 7:23 AM, Sebastian Biały wrote:
> On 2013-10-09 22:26, Marek wrote:
>> Matko jedyna, po co c++ na 8bit?
>
> Zdarłem już klawiaturę wyjasniając w kilku wątkach w ostatnich kilku
> latach :)
>

Ale to co napisalem odpowiadajac przedpiscy mozna uznac za summary ?

Pozdrawiam

Marek

[Sylwester Łazar]

> > Matko jedyna, po co c++ na 8bit?
>
> Zdarłem już klawiaturę wyjasniając w kilku wątkach w ostatnich kilku
> latach :)

A możesz podać jakiś konkretny, krótki (kilkanaście linijek kodu) przykład
na jakikolwiek
mikrokontroler MICROCHIP (może być C32)
który pokazałby różnicę w jakości programu napisanego w C++
i C--.
Pytam, bo zawsze są przeciwnicy i zwolennicy, ale nigdy nie ma przykładu.

[Sebastian Biały]

On 2013-10-10 10:09, Marek Borowski wrote:
>> Zdarłem już klawiaturę wyjasniając w kilku wątkach w ostatnich kilku
>> latach :)
> Ale to co napisalem odpowiadajac przedpiscy mozna uznac za summary ?

Mniej więcej w wersji lite.

[Sebastian Biały]

On 2013-10-10 11:08, Sylwester Łazar wrote:
> A możesz podać jakiś konkretny, krótki (kilkanaście linijek kodu) przykład
> na jakikolwiek
> mikrokontroler MICROCHIP (może być C32)

Na Microchipa nie. Na *dowolny* podam do znudzenia ten sam co zawsze:

struct CriticalSection{ CriticalSection() { cli(); } ~CriticalSection()
{ sei(); } };

void foo()
{
CriticalSection cs;
...
return UART_D;
...
return UART_D;
...
}

w C:

void foo()
{
cli();
...
char temp = UART_D;
sei();
return temp;
...
return UART_D; // <-- oops!
...

}

> Pytam, bo zawsze są przeciwnicy i zwolennicy, ale nigdy nie ma przykładu.

Ten przykład był tu kilka razy. Nie czytasz wątków :) C++ nie sprawia że
jest szybciej, ale "lepiej" przy czym w jedym zdaniu tego lepiej nie da
się sensownie opisać. I nie, nie chodzi o klasy, żeby była jasność.

[Zbych]

W dniu 10.10.2013 17:26, Sebastian Biały pisze:

Słaby przykład, w gcc można zrobić destruktor w C.

[Sebastian Biały]

On 2013-10-10 18:13, Zbych wrote:
> Słaby przykład, w gcc można zrobić destruktor w C.

I wtedy mamy jaki język?

[JDX]

On 2013-10-10 17:26, Sebastian Biały wrote:
[...]

> Na Microchipa nie. Na *dowolny* podam do znudzenia ten sam co zawsze:

Dowolny? To cli() i sei() to są standardowe funkcje C++ (i C)? :-D

> Ten przykład był tu kilka razy. Nie czytasz wątków :) C++ nie sprawia że
> jest szybciej, ale "lepiej" przy czym w jedym zdaniu tego lepiej nie da
> się sensownie opisać. I nie, nie chodzi o klasy, żeby była jasność.

C++ jest bardziej eleganckie, ale w tym konkretnym przypadku, tj. tak
zaimplementowanej sekcji krytycznej IMO *nie jest* lepsze. IMO lepsza
jest "ręczna" kontrola nad CS ponieważ tak w ogólności to chcemy jak
najszybciej odblokować przerwania a nie czekać do momentu wyjścia z
funkcji gdy zawołany zostanie destruktor. No i IMO tak zaimplementowana
CS może prowadzić do jeszcze większych i trudniejszych do wykrycia
ooops-ów jeśli ktoś będzie tworzycł CS na początku jakiejś dużej funkcji.

A tak poza tym to niezbyt rozumiem zwracanie jakiejś wartości z funkcji
typu void. No i przydało by sie też jakieś info na temat tego co to jest
UART_D - domyślam się, że jest to jakiś rejestr zmieniany
(asynchronicznie) przez moduł UART-ów.

[Sebastian Biały]

On 2013-10-10 18:23, JDX wrote:
>> Na Microchipa nie. Na *dowolny* podam do znudzenia ten sam co zawsze:
> Dowolny? To cli() i sei() to są standardowe funkcje C++ (i C)? :-D

Odróżniasz idiom RAII od kodu natywnego, prawda?

> tak
> zaimplementowanej sekcji krytycznej IMO *nie jest* lepsze.

Zdefiniuj najlepsze.

> IMO lepsza
> jest "ręczna" kontrola nad CS ponieważ tak w ogólności to chcemy jak
> najszybciej odblokować przerwania

To nie jest prawda. Czasem chcemy mieć pewność że UART_D zostanie
odczytany jeszcze w sekcji krytycznej. Efektem czego jest workaround z
temp w C. Nie ma rozwiązań załatwiających wszystkie przypadki. To jest
rozwiązujące pewna sporą grupę czestych sytuacji w przerwaniach.

> a nie czekać do momentu wyjścia z
> funkcji gdy zawołany zostanie destruktor.

Destruktor nie "czeka" tylko wołany jest natychmiast po return.
Dokładnie tak jak chcę.

> No i IMO tak zaimplementowana
> CS może prowadzić do jeszcze większych i trudniejszych do wykrycia
> ooops-ów jeśli ktoś będzie tworzycł CS na początku jakiejś dużej funkcji.

Taki idiom daje znacznie wieksze gwarancje w dobrze zrobionym kodzie. W
kodzie napisanym byle jak czyli z wielkimi funkcjami - nic nie daje
gwarancji poza modlitwą. Subiektywnie patrząc: RAII genaruje mniej
błedów niż jego ręczna emulacja i miałem w życiu na to milion przykładów.

> A tak poza tym to niezbyt rozumiem zwracanie jakiejś wartości z funkcji
> typu void.

Pomyłka.

> No i przydało by sie też jakieś info na temat tego co to jest
> UART_D - domyślam się, że jest to jakiś rejestr zmieniany
> (asynchronicznie) przez moduł UART-ów.

To jest coś chronione przez sekcję krytyczna. Nie ma znaczenia co to
jest. Probolemem wielu programistów embedded jest wlasnie to że *musza*
wiedzieć co to jest, choć wiedza taka zazwyczaj kończy się pisaniem
nieprzenośnego kodu.

[Sylwester Łazar]

> struct CriticalSection{ CriticalSection() { cli(); } ~CriticalSection()
> { sei(); } };
>
> void foo()
> {
> CriticalSection cs;
> ...
> return UART_D;
> ...
> return UART_D;
> ...
> }
>
> w C:
>
> void foo()
> {
> cli();
> ...
> char temp = UART_D;
> sei();
> return temp;
> ...
> return UART_D; // <-- oops!
> ...
> }

Proszę mnie poprawić jeśli się mylę,
jednak spróbuję zrozumieć.
1) tak jak kolega JDX zauważył, dla foo powinien być typ char, gdyż RETURN
ma zwrócić wartość z RS-a.
2) I teraz w C (drugi przykład) jest problem, gdyż po przepisaniu do
zmiennej temp,
zostały ponownie włączone przerwania przez sei() (SEt Interrupt jak sądzę)
Wtedy temp zwróci wartość odczytaną z UART_D i jest "cool",
ale zwracając UART_D może być "klopsik", bo w międzyczasie mogło przyjść
inne przerwanie od RS'a i zmienić wartość rejestru UART_D (UART Data jak
sądzę)
3) W C++ jest na tyle wygodnie, że wystarczy wpisać (czy jak to się fachowo
nazywa w obiektowym języku programowania) na początu, że
to jest: CriticalSection cs;
I teraz wiadomo, że jak foo się skończy, to przerwania same się odblokują.

Czyli chodzi o to, że nie trzeba pamiętać gdzie włączyć sei(), a gdzie
wyłączyć cli() (CLear Interrupt jak sądzę)
tylko zapisać, że w foo() nie przejmujemy się przerwaniami, tylko robimy
swoje?

Przepraszam, jeśli coś pokiełbasiłem, ale mam wrażenie, że dyskutują sami
fachowcy,
a reszta przygląda się i podziwia :-)

[JDX]

On 2013-10-10 18:43, Sebastian Biały wrote:
> On 2013-10-10 18:23, JDX wrote:
>>> Na Microchipa nie. Na *dowolny* podam do znudzenia ten sam co zawsze:
>> Dowolny? To cli() i sei() to są standardowe funkcje C++ (i C)? :-D
>
> Odróżniasz idiom RAII od kodu natywnego, prawda?

Ale o co chodzi? Co ma RAII do kodu natywnego? W każdym razie chodziło
mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
też C++.

>> tak
>> zaimplementowanej sekcji krytycznej IMO *nie jest* lepsze.
>
> Zdefiniuj najlepsze.
>
>> IMO lepsza
>> jest "ręczna" kontrola nad CS ponieważ tak w ogólności to chcemy jak
>> najszybciej odblokować przerwania
>
> To nie jest prawda. Czasem chcemy mieć pewność że UART_D zostanie
> odczytany jeszcze w sekcji krytycznej. Efektem czego jest workaround z
> temp w C. Nie ma rozwiązań załatwiających wszystkie przypadki. To jest
> rozwiązujące pewna sporą grupę czestych sytuacji w przerwaniach.

No to przecież sam pokazałeś że w C obudowujemy czytanie w cli()/sei().
A jeśli z jakiegoś powodu w tej samej funkcji potrzebujemy przeczytać
zasób jeszcze raz, no to jeszcze raz obudujemy operację czytania. Zdaję
sobie sprawę, że kod się komplikuje i tym samym jest bardziej podatny na
błędy, ale w sam raz IMO w tak, nomen omen, krytycznych przypadkach jak
CS lepiej jest sterować ręcznie a nie zdawać się na automatykę.

>> a nie czekać do momentu wyjścia z
>> funkcji gdy zawołany zostanie destruktor.
>
> Destruktor nie "czeka" tylko wołany jest natychmiast po return.
> Dokładnie tak jak chcę.

Zakładając, że pomiędzy odczytaniem z chronionego zasoby a returnem nie
ma znaczącego (w sensie czasu wykonania) kodu.

>> No i IMO tak zaimplementowana
>> CS może prowadzić do jeszcze większych i trudniejszych do wykrycia
>> ooops-ów jeśli ktoś będzie tworzycł CS na początku jakiejś dużej funkcji.
>
> Taki idiom daje znacznie wieksze gwarancje w dobrze zrobionym kodzie. W
> kodzie napisanym byle jak czyli z wielkimi funkcjami - nic nie daje
> gwarancji poza modlitwą. Subiektywnie patrząc: RAII genaruje mniej
> błedów niż jego ręczna emulacja i miałem w życiu na to milion przykładów.

W każdym razie ja w podanym przykładzie jakoś nie widzę wyższości C++
nad C. Zyskujesz większą odporność na błędy ale płacisz za to mniej
precyzyjną kontrolą nad CS. Nie twierdzę, że C++ jest gorsze od C w
zastosowaniach embedded. Twierdzę jedynie, że przykład jest słaby.

>> No i przydało by sie też jakieś info na temat tego co to jest
>> UART_D - domyślam się, że jest to jakiś rejestr zmieniany
>> (asynchronicznie) przez moduł UART-ów.
>
> To jest coś chronione przez sekcję krytyczna. Nie ma znaczenia co to
> jest. Probolemem wielu programistów embedded jest wlasnie to że *musza*
> wiedzieć co to jest, choć wiedza taka zazwyczaj kończy się pisaniem
> nieprzenośnego kodu.

No nie wiem, mi w sam raz wystarczyłaby informacja, że to jest coś co ma
być chronione za pomocą CS. Tak, abym nie musiał snuć domysłów. :-)

[Sebastian Biały]

On 2013-10-10 20:00, Sylwester Łazar wrote:
> Proszę mnie poprawić jeśli się mylę,
> jednak spróbuję zrozumieć.
> 1) tak jak kolega JDX zauważył, dla foo powinien być typ char, gdyż RETURN
> ma zwrócić wartość z RS-a.

To oczywiste że to czeski błąd, przeciez kod jest z palca i ma tylko
pokazać ideę.

> 2) I teraz w C (drugi przykład) jest problem, gdyż po przepisaniu do
> zmiennej temp,
> zostały ponownie włączone przerwania przez sei() (SEt Interrupt jak sądzę)
> Wtedy temp zwróci wartość odczytaną z UART_D i jest "cool",
> ale zwracając UART_D może być "klopsik", bo w międzyczasie mogło przyjść
> inne przerwanie od RS'a i zmienić wartość rejestru UART_D (UART Data jak
> sądzę)

W tym cały pomysł: żeby uzyskac odczyt w sekcji krytycznej i natychmiast
go zwrócić. W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
znacznie czytelniejszy.

> 3) W C++ jest na tyle wygodnie, że wystarczy wpisać (czy jak to się fachowo
> nazywa w obiektowym języku programowania) na początu, że
> to jest: CriticalSection cs;
> I teraz wiadomo, że jak foo się skończy, to przerwania same się odblokują.

To się nazywa RAII, nie ma nic wspólnego z obiektami poza tym że
akuratnie na nich można ją uzyskać. Wiekszość języków programowania nie
ma RAII choć ma obiekty.

> Czyli chodzi o to, że nie trzeba pamiętać gdzie włączyć sei(), a gdzie
> wyłączyć cli() (CLear Interrupt jak sądzę)
> tylko zapisać, że w foo() nie przejmujemy się przerwaniami, tylko robimy
> swoje?

Owszem, cała sztuka w tym żeby *nie* przejmować się sei. Ono się samo
zrobi tam gdzie powinno. W 99% wypadków poza patologicznymi chcesz mieć
parę cli/sei bez wzgledu na formę wyjścia z funkcji. I o tym nie
pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
nie różni od pisania w asm i świadczy o ubogim warsztacie.

[Sebastian Biały]

On 2013-10-10 20:07, JDX wrote:
>> Odróżniasz idiom RAII od kodu natywnego, prawda?
> Ale o co chodzi? Co ma RAII do kodu natywnego? W każdym razie chodziło
> mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
> też C++.

Wyobraź sobie że napiszę ten sam example bez cli/sei. Co on niby miałby
ilustrować? Sam idiom RAII nie jest przydatny, jego konkretna
implementacja już jest.

>> To nie jest prawda. Czasem chcemy mieć pewność że UART_D zostanie
>> odczytany jeszcze w sekcji krytycznej. Efektem czego jest workaround z
>> temp w C. Nie ma rozwiązań załatwiających wszystkie przypadki. To jest
>> rozwiązujące pewna sporą grupę czestych sytuacji w przerwaniach.
> No to przecież sam pokazałeś że w C obudowujemy czytanie w cli()/sei().

Ale musisz uzyć zmiennej tymczasowej i musisz *pamiętac* o sei. kod robi
się podatny na czynnik ludzki.

> A jeśli z jakiegoś powodu w tej samej funkcji potrzebujemy przeczytać
> zasób jeszcze raz, no to jeszcze raz obudujemy operację czytania. Zdaję
> sobie sprawę, że kod się komplikuje i tym samym jest bardziej podatny na
> błędy, ale w sam raz IMO w tak, nomen omen, krytycznych przypadkach jak
> CS lepiej jest sterować ręcznie a nie zdawać się na automatykę.

Dlaczego lepiej zdawać się na czlowieka a nie na automatyke absurdalnie
automatycznej rzeczy? RAII to mechanizm który obecnie jest testowany
biliony razy na sekundę na calym swiecie na wszystkich architekturach i
działa. Dlaczego miałby tu być problematyczny? Znam tylko jeden powód:
gównanie kompilatory na gówniane architektury (PIC < 32).

>> Destruktor nie "czeka" tylko wołany jest natychmiast po return.
>> Dokładnie tak jak chcę.
> Zakładając, że pomiędzy odczytaniem z chronionego zasoby a returnem nie
> ma znaczącego (w sensie czasu wykonania) kodu.

A skąd on miałby się tam wziąść? Nawej najgorsze kompilatory C++ nie
będą robiły zadnego obiektu sc. On nie istnieje w kodzie wynikowym,
zostaje po nim tylko sei w miejscach gdzie wychodzisz z funkcji. Puffff
i cała sekcja krytyczna, klasa, konstruktor itd zamienia się w dwie
instrukcje asm. To jest wlasnie ten moment którego programiści embedded
nie czają. Tam *nie* ma obiektu ani narzutu w kodzie. Kod jest taki sam
jak z C a bywa że lepszy.

>> Taki idiom daje znacznie wieksze gwarancje w dobrze zrobionym kodzie. W
>> kodzie napisanym byle jak czyli z wielkimi funkcjami - nic nie daje
>> gwarancji poza modlitwą. Subiektywnie patrząc: RAII genaruje mniej
>> błedów niż jego ręczna emulacja i miałem w życiu na to milion przykładów.
> W każdym razie ja w podanym przykładzie jakoś nie widzę wyższości C++
> nad C. Zyskujesz większą odporność na błędy ale płacisz za to mniej
> precyzyjną kontrolą nad CS.

Jesli potrzebujesz precyzyjniejszej kontroli nad cs to mozna taką zrobić
bez rezygnacji z RAII.

> Nie twierdzę, że C++ jest gorsze od C w
> zastosowaniach embedded. Twierdzę jedynie, że przykład jest słaby.

Bo miał być jakikolwiek. Np. często liczę na szablonach rozmiary typów
co pozwala mi kod przenieść między różnymi procesorami. Często
specjalizuję generyczną funckję za pomocą obiektu co pozwala mi kod z uC
testować na PC używając mocków. Jest sporo zastosowań. Żadne nie ma nic
wspólnego z obiektowością.

>> To jest coś chronione przez sekcję krytyczna. Nie ma znaczenia co to
>> jest. Probolemem wielu programistów embedded jest wlasnie to że *musza*
>> wiedzieć co to jest, choć wiedza taka zazwyczaj kończy się pisaniem
>> nieprzenośnego kodu.
> No nie wiem, mi w sam raz wystarczyłaby informacja, że to jest coś co ma
> być chronione za pomocą CS. Tak, abym nie musiał snuć domysłów. :-)

Przecież właśnie w tym kodzie to doskonale widać.

[Grzegorz Niemirowski]

JDX <j...@onet.pl> napisał(a):

> W każdym razie chodziło
> mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
> też C++.

Standardowość tych funkcji w żadnym stopniu nie zmienia sensowności tego
przykładu.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 1 day, 22 hours, 16 minutes and 13 seconds

[Marek Borowski]

A w wersji full ?

Pozdrawiam

Marek

[Sebastian Biały]

On 2013-10-10 21:43, Marek Borowski wrote:
>>> Ale to co napisalem odpowiadajac przedpiscy mozna uznac za summary ?
>> Mniej więcej w wersji lite.
> A w wersji full ?

Np. statyczny polimorfizm (pomaga unit testować kod na PC bez utraty
szybkości na uC) bądź obliczenia na szablonach.

[JDX]

On 2013-10-10 20:46, Sebastian Biały wrote:
[...]

> On 2013-10-10 20:07, JDX wrote:
>>> Destruktor nie "czeka" tylko wołany jest natychmiast po return.
>>> Dokładnie tak jak chcę.
>> Zakładając, że pomiędzy odczytaniem z chronionego zasoby a returnem nie
>> ma znaczącego (w sensie czasu wykonania) kodu.
>
> A skąd on miałby się tam wziąść? Nawej najgorsze kompilatory C++ nie
> będą robiły zadnego obiektu sc. On nie istnieje w kodzie wynikowym,
> zostaje po nim tylko sei w miejscach gdzie wychodzisz z funkcji. Puffff
> i cała sekcja krytyczna, klasa, konstruktor itd zamienia się w dwie
> instrukcje asm. To jest wlasnie ten moment którego programiści embedded
> nie czają. Tam *nie* ma obiektu ani narzutu w kodzie. Kod jest taki sam
> jak z C a bywa że lepszy.

Nie, nie, zupełnie nie zrozumiałeś o co mi chodzi. A chodzi mi o coś w
tym stylu:

struct CriticalSection{ CriticalSection() { cli(); } ~CriticalSection()
{ sei(); } };

void foo()
{
CriticalSection cs;

char tmp = UART_D;
do_some_very_time_consuming_stuff();
}

Przydałoby się opuścić CS zaraz po odczycie z chronionego zasobu a się
nie da. No chyba że zastosujemy trick w postaci jawnego zawołania cli(). :-D

[JDX]

On 2013-10-10 20:57, Grzegorz Niemirowski wrote:
> JDX <j...@onet.pl> napisał(a):
>> W każdym razie chodziło
>> mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
>> też C++.
>
> Standardowość tych funkcji w żadnym stopniu nie zmienia sensowności tego
> przykładu.

Ech, to taki żart był...

[Sebastian Biały]

On 2013-10-10 22:05, JDX wrote:
> Nie, nie, zupełnie nie zrozumiałeś o co mi chodzi. A chodzi mi o coś w
> tym stylu:
> struct CriticalSection{ CriticalSection() { cli(); } ~CriticalSection()
> { sei(); } };
>
> void foo()
> {
> CriticalSection cs;
> char tmp = UART_D;
> do_some_very_time_consuming_stuff();
> }
>

void foo()
{
chat tmp;
{
CriticalSection cs;
tmp = UART_D;
}
do_stuff();
}

[JDX]

On 2013-10-10 22:11, Sebastian Biały wrote:
[...]

> void foo()
> {
> chat tmp;
> {
> CriticalSection cs;
> tmp = UART_D;
> }
> do_stuff();
> }

Znaczy się de facto jawnie wołamy cli()/sei(). Tak jak w przykładzie w
C. :-)

[Sebastian Biały]

On 2013-10-10 22:26, JDX wrote:
>> void foo()
>> {
>> chat tmp;
>> {
>> CriticalSection cs;
>> tmp = UART_D;
>> }
>> do_stuff();
>> }
> Znaczy się de facto jawnie wołamy cli()/sei(). Tak jak w przykładzie w
> C. :-)

Ponieważ przy skrajnym uproszczeniu nie ma oczywistych zalet. Teraz
zamiast tmp=UART_D; wsadź dwupoziomowy case w pętli i wtedy zobaczysz
różnicę. Zadaniem RAII jest pomoc w przypadkach skomplikowanych a nie
trywialnych.

[Marek Borowski]

On 10/10/2013 9:49 PM, Sebastian Biały wrote:
> On 2013-10-10 21:43, Marek Borowski wrote:
>>>> Ale to co napisalem odpowiadajac przedpiscy mozna uznac za summary ?
>>> Mniej więcej w wersji lite.
>> A w wersji full ?
>
> Np. statyczny polimorfizm (pomaga unit testować kod na PC bez utraty

To akutrat wymienilem.

> szybkości na uC) bądź obliczenia na szablonach.
>

Czyli metaprograming. Jeszcze cos ?

Pozdrawiam

Marek

[Sylwester Łazar]

> pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
> nie różni od pisania w asm i świadczy o ubogim warsztacie.

Tu bym się nie zgodził.
Spotkamy się tu za 20 lat i ubogim warsztatem okaże się Twój C++.
Zresztą niektórzy twierdzą, że już tak jest.
Warsztat to chyba nie jest dobre słowo na metody pracy.
Wydaje mi się, że mieszasz. Uznajesz, że wybór języka programowania
wpływa na warsztat.
Na to jest już szereg innych określeń: inteligencja, umiejętność myślenia
przestrzennego,
dobra realizacja zadań. I moim zdaniem nie ma to kompletnie nic wspólnego
z rodzajem języka, którego używasz.
Choć, przyznaję, nauka kolejnego może rozwijać "warsztat".
Zupełnie tak samo, jak nauka budowy kolejnego ukontrolera.
A ja właśnie piszę w ASM tak gdzieś od 28 lat mniej więcej.
Mój warsztat jest bardzo "ubogi":
1) kod jest napisany zwięźle i czytelnie.
2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to szybkie
tablice LUT.
3) każda linijka ma swój komentarz.
4) nigdy nie analizuje kodu w ASM. Nie używam klawiszy Page Up/Down w tym
celu.
5) strukturę logiczną kodu mam zawartą w przestrzeni 2 wymiarowej w postaci
algorytmu
lub innych form zapisu, takich jak tabela stanów, opis struktur danych itp.
6) samo kodowanie sprowadza się do zamiany bloków logicznych na mnemoniki
konkretnego mikrokontrolera 8,16,32 bitowego
7) kodowanie jest czynnością przyjemną choć dość prymitywną.
8) najprzyjemniejsze jest uruchamianie. IDE mnie interesuje tylko w celu
postawienia Breakpointa i odczytanie stanu procesora.
9) cała analiza opiera się na oglądaniu kolorowych algorytmów.
10) przy moim toku pracy nie interesuje mnie na jaki typ procesora piszę.
Może być to MICROCHIP, Freescale, 8051core, MIPS - cokolwiek.
W szczególności nie interesuje mnie nawet język programowania.
Mógłby to być C++ czy C bez różnicy.
Tylko tak się składa, że asm sprawdza się najlepiej.

I teraz. Twój przykład mnie po prostu zastrzelił.
Nie pamiętam kiedy używałem w ogóle całkowitego blokowania przerwań.
(twoje cli())
Ja je najczęściej tylko włączam na początku kodu po włączeniu zasilania.
Cała reszta oparta jest na logicznym przemyśleniu sposobu wykorzystania
sprzętu.
Ważna jest komunikacja POP (ISR) i programu głównego.
Czasem ważne są priorytety przerwań.

W związku z powyższym proponuję zmienić przykład, gdyż usiłuje on udowodnić,
że:
1) wyższość jednego sposobu komunikacji (tutaj niby C++) nad drugim
(C )polega na tym, że wygodniej jest wyłączać przerwania, co jest po prostu
dość śmieszne.
Poniekąd wskazał to też kolega, który twierdzi, jeśli dobrze zrozumiałem,
że woli sobie sam decydować, gdzie włączyć, a gdzie wyłaczyć przerwania.
A okazuje się, że nikt się nie zastanawia: W jakim celu w ogóle je wyłączać?
Mogła by paść odpowiedź: bo mój kod nie zdąży, gdyż jest obiektowy :-)
2) Twoja argumentacja:

"W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
znacznie czytelniejszy"

Czy ja wiem?
Toż przecież - spójrz w swój kod po kompilacji.
Jestem ciekaw, jak niby to Twój destruktor przekazuje UART_D, czyli fizyczny
rejestr,
bez pośrednictwa nawet rejestru?
3) Jeden z tu obecnych kolegów, powiedział mi przed laty, że on pisze w C, a
potem podgląda skompilowany kod i poprawia idiotyzmy kompilatora.
Ja uważam, że ta metoda jest dobra. Sam próbowałem, ale...
Czas leci do przodu, a kompilatory operują już na wysokiej klasie
abstrakcji.
Po skompilowaniu powstają tak niebosiężne bzdury, że poprawianie zajmowałoby
mi mnóstwo czasu, więc jest to dla mnie zbyt kosztowne.
No bo jak poprawiać kod asm wygenerowany przez kompilator,
który odczytuje timer w przerwaniu i zachowuje na stosie 20 rejestrów
procesora,
wykonuje jedno podstawienie i przywraca te rejestry.
Niestety zwiększając częstotliwość przerwań, okazuje się, że szybki procesor
spędza swój żywot na zapisywaniu stosu w tą i z powrotem, tracąc głupio
swoją moc obliczeniową
oraz potencjalną gotowość do błyskawicznej reakcji na inne zmienne
środowiskowe.

[Sebastian Biały]

On 2013-10-10 22:49, Marek Borowski wrote:
>>>> Mniej więcej w wersji lite.
>>> A w wersji full ?
>> Np. statyczny polimorfizm (pomaga unit testować kod na PC bez utraty
> To akutrat wymienilem.
>> szybkości na uC) bądź obliczenia na szablonach.
> Czyli metaprograming. Jeszcze cos ?

Rzadziej:

Programowanie obiektowe (ze względu na heap raczej arm7 i więcej). Sporo
SFINAE w różnych postaciach. Obciętą wersję template expressions w
jednym z projektów. Silnie typowane flagi bitowe. Namespaces
powszechnie, często anonimowe. Type traits. Inicjalizacja przed main
(szczególnie peryferiów).

Natomiast latwiej będzie czego nie używam:

Smart pointerów, bo fragrmentują pamięć, boosta (tylko dlatego że nie ma
zazwyczaj na mniejsze uC), stla ze względu na fragmentacje. Boosta
żałuję najbardziej.

[Sebastian Biały]

On 2013-10-11 00:11, Sylwester Łazar wrote:
>> pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
>> nie różni od pisania w asm i świadczy o ubogim warsztacie.
> Tu bym się nie zgodził.
> Spotkamy się tu za 20 lat i ubogim warsztatem okaże się Twój C++.

Zauważ ciekawostkę. Każdy programista C powie, że u niego też się da "bo
tu panie, można takie makro zrobić i już". Trudno się z tym nie zgodzić,
skoro oba języki są identyczne w sensie Turinga. Tylko co z tego wynika?
Wymyslanie kwadratowych kół. Takich jak "przecież gcc ma destruktory w
C". Absurd. C++ ma destruktory i jest wspierany *wszędzie* poza niszami.
I cały problem sprawadza się do wymiany gcc na g++ w makefile. Jeśli
"wszystko też się da zrobić w C" to masz ubogi warsztat. Bo masz tylko
młotek i wkręcasz nim śrubki.

> A ja właśnie piszę w ASM tak gdzieś od 28 lat mniej więcej.
> Mój warsztat jest bardzo "ubogi":
> 1) kod jest napisany zwięźle i czytelnie.

Asm jest językiem write-only i 100% nie przenośnym. I turing complete,
bez wątpienia. Meta assemblery które robią abstrakcję na cpu muszą i tak
robić jakieś założenia ktore sa nieprzenośne.

> 2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to szybkie
> tablice LUT.

Mój kod ma taki rozmia jaki jest w nim algorytm. Twierdzenie że asm
magicznie zmniejsza rozmiar jest nadużyciem. LUT (w jakiejkolwiek
formie) w C++ jest jakims problemem?

> 3) każda linijka ma swój komentarz.

No właśnie, kod jest tak nieczytelny że bez komentarzy nie da rady. Tak,
wiem że to co teraz napisałem powoduje skok ciśnienia. Dobrze się
zastanów czy obecnośc komentarzy świadczy o czytelności *kodu*, czyli
punkt 1. Niektórzy twierdzą że *kod* prawidłowo napisany nie zawiera
komentarzy. Sa zbędne i nie zawsze synchroniczne względem kodu czesto
wproawadzają w bład.

> 4) nigdy nie analizuje kodu w ASM. Nie używam klawiszy Page Up/Down w tym
> celu.

Trudno mi się zgodzić z hipotezą że każdy komentarz jest aktualny do
każdego kawałka kodu. Zazwyczaj nie jest. Jesli trzymasz to w ryzach to
gratuluje. Nikt nie dałby rady. Widziałem wiele prób.

> 5) strukturę logiczną kodu mam zawartą w przestrzeni 2 wymiarowej w postaci
> algorytmu
> lub innych form zapisu, takich jak tabela stanów, opis struktur
danych itp.

Strukturę logiczną masz porozmywaną na detalach obsługi stosu, rolowania
bitów i tym podobnych elementarnych operacji ktore ukrywają sens
algorytmu skupiając sie na emulacji mnożenia. Jesli istnieje
wysokopoziomowy opis to naduzyciem jest twierdzenie że to jest assembler.

> 6) samo kodowanie sprowadza się do zamiany bloków logicznych na mnemoniki
> konkretnego mikrokontrolera 8,16,32 bitowego

Oczywiście o ile ilośc rejestrów się zgadza. Albo Neumann zamienil się w
Harvard. Wiem że można sporo zrobić w ten sposób ale po co skoro po to
powstal C i masa innych jezyków?

> 7) kodowanie jest czynnością przyjemną choć dość prymitywną.

Bo kazdy język write-only przyjemnie się koduje. Zapytaj programistów
perla. Oni kochają pisać. Czytać nienawidzą.

> 8) najprzyjemniejsze jest uruchamianie. IDE mnie interesuje tylko w celu
> postawienia Breakpointa i odczytanie stanu procesora.

To dośc interesujące bo wiekszość moich projektów nie ma ani kawałka
IDE. Makefile, konsola, edytor. Ponadto polemizowalbym że odczytywanie
stanu procesora jest wygodniejsze niż chodzący po ekranie IDE kursor i
podgląd zmiennych pod myszką.

> 9) cała analiza opiera się na oglądaniu kolorowych algorytmów.

Z chęcią zobacze jak wygląda taki zapis w *assemblerze*.

> 10) przy moim toku pracy nie interesuje mnie na jaki typ procesora piszę.
> Może być to MICROCHIP, Freescale, 8051core, MIPS - cokolwiek.
> W szczególności nie interesuje mnie nawet język programowania.
> Mógłby to być C++ czy C bez różnicy.
> Tylko tak się składa, że asm sprawdza się najlepiej.

Piszesz najprawdopodobniej dość określone algorytmy, gdzie metoda się
sprawdza.

Ja też nie jestem zainteresowany na co piszę. Co gorsza kod zazwyczaj
jest przetestowany w sporym stopniu przed pierwsza wrzutą w uC. I nie
chodzi tutaj o emulatory, tylko o unit testy.

> I teraz. Twój przykład mnie po prostu zastrzelił.
> Nie pamiętam kiedy używałem w ogóle całkowitego blokowania przerwań.
> (twoje cli())

Ja pamiętam. Wtedy gdy to konieczne. Na przykład wczoraj musiałem w
ciągu 5 cykli zegara coś wystawić na piny. Nie mam czasu na obslugę timera.

> Ja je najczęściej tylko włączam na początku kodu po włączeniu zasilania.
> Cała reszta oparta jest na logicznym przemyśleniu sposobu wykorzystania
> sprzętu.

Co czasem wymaga wylaczenia przerwań. O takich drobnostkach jak atomowe
operacje na typach > niż slowo maszynowe ciezko mi wspominać.

> W związku z powyższym proponuję zmienić przykład, gdyż usiłuje on udowodnić,
> że:
> 1) wyższość jednego sposobu komunikacji (tutaj niby C++) nad drugim
> (C )polega na tym, że wygodniej jest wyłączać przerwania, co jest po prostu
> dość śmieszne.

Nie znasz kontekstu więc śmieszne jest twierdzenie że jest o
nieprzydatny. A kontekst co gorsza jest niepotrzebny bo to po prostu
czesto spotykany idiom.

Pamietaj że to nie jest *jedyny* przykład. To tylko najprostsza rzecz
jaką programista embedded może uzyć po zamianie gcc na g++. Jest tego od
groma.

> Poniekąd wskazał to też kolega, który twierdzi, jeśli dobrze zrozumiałem,
> że woli sobie sam decydować, gdzie włączyć, a gdzie wyłaczyć przerwania.

Zazwyczaj robi to w parach i upiera się że robienie pary ręcznie jest
lepsze niż automatycznie. Nie wiem dlaczego.

> A okazuje się, że nikt się nie zastanawia: W jakim celu w ogóle je wyłączać?

Jest wiele celów. Zazwyczaj sprawdzają się do RT albo atomowych
operacji. Przykladow jest tak wiele że aż cieżko coś wybrać. jęsli nie
napotykasz na takie zastosowania gdzie jest to konieczne to być może nie
miałeś do dzisiaj okazji.

> Mogła by paść odpowiedź: bo mój kod nie zdąży, gdyż jest obiektowy :-)

Kod nie jest ani troche obiektowy. ANI TROCHĘ. Dlaczego każdy kto widzi
C++ od razu wrzeszczy obiektowość!? Przeciez to ficzer zazwyczaj bez
znaczenia dla uC.

> 2) Twoja argumentacja:
> "W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
> znacznie czytelniejszy"
> Czy ja wiem?
> Toż przecież - spójrz w swój kod po kompilacji.

Jest identyczny z C. Tak sama ilośc instrukcji kodu maszynowego.

> Jestem ciekaw, jak niby to Twój destruktor przekazuje UART_D, czyli fizyczny
> rejestr,
> bez pośrednictwa nawet rejestru?

Przecież czytelnośc nie dotyczy asm. Czytelnośc dotyczy kodu źrodłowego.
kod maszynowy wygeneruje się w obu wypadkach taki sam.

> 3) Jeden z tu obecnych kolegów, powiedział mi przed laty, że on pisze w C, a
> potem podgląda skompilowany kod i poprawia idiotyzmy kompilatora.

Jaki kompilator takie efekty.

> Ja uważam, że ta metoda jest dobra. Sam próbowałem, ale...
> Czas leci do przodu, a kompilatory operują już na wysokiej klasie
> abstrakcji.
> Po skompilowaniu powstają tak niebosiężne bzdury, że poprawianie zajmowałoby
> mi mnóstwo czasu, więc jest to dla mnie zbyt kosztowne.

Stajesz okrakiem w stosunku do faktów. Kompilatory stosują wysokie
poziomy abstrakcji aby poprawnie korzystając z C++ móc generować kod
lepszy niż ręcznie wydziobany w C. Niestety to wymaga dużego
doświadczenia w znajomosci architektury, języka i idiotyzmów c++.
Ogólnie twierdzenie ze kompilatory C++ generują marny kod jest
absurdalne. To jest prostu nieprawda. Natomiast niektóre z nich tak
robią z róznych przyczyn wlaczając w to debilizm programisty czy bledy
projektowe samego kompilatora a sytuacji nie poprawia fakt że z tego
powodu nikt ich nie chce używać, szczególnie w embedded.

> No bo jak poprawiać kod asm wygenerowany przez kompilator,
> który odczytuje timer w przerwaniu i zachowuje na stosie 20 rejestrów
> procesora,

A używa 20 rejestów? Mój odkłada tyle ile użyje. Ponadto temat RT jest
delikatny: tam nalezy uzyć czasem asm, czasem C, czasem C++. Zależy.
Jesli wydaje Ci się że C+ jest w/g mnie dobry na wszystko to się mylisz.
Mam setki wstawek assemblerowych bo muszę rozkladać cykle *perfekcyjnie*
i żaden język wysokiego poziomu do tego sie nie nada.

> wykonuje jedno podstawienie i przywraca te rejestry.

Masz popsuty kompilator. Weź lepszy.

[Marek]

On Fri, 11 Oct 2013 00:11:51 +0200, Sylwester Łazar<in...@alpro.pl>
wrote:

> 1) kod jest napisany zwięźle i czytelnie.
> 2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to
szybkie

> 3) każda linijka ma swój komentarz.

Tak się zastanawiam ile czasu Ci zajmuje realizacja jakiegoś
zadania/projektu, czy sa to projekty rozwojowe czy jednorazowe
zadania, które po realizacji nie są dalej rozwijane.

--
Marek

[Zbych]

W dniu 10.10.2013 18:18, Sebastian Biały pisze:

> On 2013-10-10 18:13, Zbych wrote:
>> Słaby przykład, w gcc można zrobić destruktor w C.
>
> I wtedy mamy jaki język?

Jeśli pijesz do tego, że nie jest to czyste C, to argument jest
chybiony. Przerwań też nie masz w C (ani w C++).

[Marek]

On Fri, 11 Oct 2013 00:53:30 +0200, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> Asm jest językiem write-only i 100% nie przenośnym. I turing
complete,
> bez wątpienia. Meta assemblery które robią abstrakcję na cpu muszą
i tak
> robić jakieś założenia ktore sa nieprzenośne.

Trudno się nie zgodzić z Twoimi argumentami.
Sam osobiście nie jestem entuzjastą programowania obiektowego, ale
pewnie to wynika z przyzwyczajenia i uprzedzeń.

Natomiast jako pracodawca zatrudniający kilkunastu programistów
obecnie (nie embeded), a w skali kilkunastu lat kilkudziesięciu się
przewinęło, zauważyłem ciekawą statystykę:
1. Najwięcej poroblemów jest z kodem progranistów, którzy deklarują
się jako programiści jedynie w c++ lub (najczęściej) java. Głównie
problemy jakie mam na myśli to brak nawyków testowania tego co piszą.

2.Najczęściej programiści (z tymi ci miałem do czynienia) "obiektowi"
nie maja wyobrażenia jak działa procesor czy jakie są różnice w arch.
Neumann/Harvard. Kompletnie nie zastanawiają się nad kwestia jak
będzie wyglądał kod wynikowy tego ci piszą.
Chodzi mi o sytuacje, w których można czasami trochę "pomóc"
kompilatorowi aby nie wygenerował jakiegoś potworka. Ale ok,
powiedzmy, że to raczej cecha języka, że nie muszą się o to martwić.

3. Mimo deklaracji, że jest się programistą obiektowym programują
strukturalnie (sic!), nie wykorzystując zalet/cech deklarowanego
języka.

4. Ogromne problemy z bezpieczeństwem. Pierdyliąt zewnętrznych
"gotowców" (biblioteki, frameworki, konektory i inne dziwactwa)
powoduje nawyk korzystania z nich i mamy oprócz błędów w "własnym"
kodzie błędy innych.

Natomiast najmniej problemów jest tymi, którzy deklarują się jako
"multi-kulti" z naciskiem na C, lizneli kiedyś embeded i uwaga, nie
stosują żadnych IDE tylko sam vim lub emacs + makefile (!).

--
Marek

[RoMan Mandziejewicz]

Hello Marek,

Friday, October 11, 2013, 8:56:17 AM, you wrote:

[...]

> Natomiast najmniej problemów jest tymi, którzy deklarują się jako
> "multi-kulti" z naciskiem na C, lizneli kiedyś embeded i uwaga, nie
> stosują żadnych IDE tylko sam vim lub emacs + makefile (!).

Ale stać Cię na takich?


--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

[Marek]

On Fri, 11 Oct 2013 09:51:52 +0200, RoMan Mandziejewicz
<ro...@pik-net.pl.invalid> wrote:
> > stosują żadnych IDE tylko sam vim lub emacs + makefile (!).
> Ale stać Cię na takich?

Dobre pytanie, tylko na kilku takich, niestety. Ale muszą być, aby
pilnować resztę (głowinie jako team leaderzy). Trzeba uważać bo, jak
mawiał Jobs, kiepski programista przyciąga do siebie innych
kiepskich. W końcu możesz się ocknąć, że firmie masz samych
kiepskich. Inwestując w tych kilku najlepszych udaje się na razie
uniknąć takiej sytuacji. Ale bywało że nie było stać i faktycznie to
powiedzenie się sprawdzało.

--
Marek

[RoMan Mandziejewicz]

Hello Marek,

Friday, October 11, 2013, 10:18:12 AM, you wrote:

>> > stosują żadnych IDE tylko sam vim lub emacs + makefile (!).
>> Ale stać Cię na takich?
> Dobre pytanie, tylko na kilku takich, niestety.

Albo jesteś bardzo bogaty albo jednak ci programiści nie są tak
dobrzy...

> Ale muszą być, aby pilnować resztę (głowinie jako team leaderzy).
> Trzeba uważać bo, jak mawiał Jobs, kiepski programista przyciąga do
> siebie innych kiepskich. W końcu możesz się ocknąć, że firmie masz
> samych kiepskich. Inwestując w tych kilku najlepszych udaje się na
> razie uniknąć takiej sytuacji. Ale bywało że nie było stać i
> faktycznie to powiedzenie się sprawdzało.

:(

[Sylwester Łazar]

> Tak się zastanawiam ile czasu Ci zajmuje realizacja jakiegoś
> zadania/projektu, czy sa to projekty rozwojowe czy jednorazowe
> zadania, które po realizacji nie są dalej rozwijane.
>
> --
> Marek

Nawyk dokumentowania kodu mam już od 15 roku życia.
Wtedy na ZX81 pisałem w asm (nie było innego wyjścia - miał 1kB)
i komentowałem kod.
Po kilkunastu latach praktyki odwróciłem metodę.
Rysuję sobie w zwykłym edytorze bloczki logiczne,
używając koloru. Jest w PC, jest w drukarce, dlaczego ma być czarne?
Dzięki temu od razu widzę, że jak jest na czerwono, to zmienna,
Jak na niebiesko to stała, jak na seledynowo to bit.
Po lewej stronie bloczka piszę sobie komentarz, a po prawej kod - już w asm.
Na końcu po prostu kopiuję kod z prawej i komentarz z lewej, bloczek po
bloczku.
Wklejam do IDE, choć może faktycznie nie ma to znaczenia, że jest to IDE.
Raczej używany tylko do kompilacji.

Jak widać musi być to szalenie żmudny proces- wydawać by się mogło.
Jednak wyrobienie sobie takiego nawyku przez kilkanaście lat pracy,
powoduje, że teraz to idzie szybko.
Wiadomym jest, że jak stukasz w klawiaturę wpisując ~destruktory w C++,
czy inne konstrukcje, nie dodając żadnych komentarzy zawsze będzie to
szybsze,
niż rysowanie algorytmu, dokładanie opisu słownego po polsku czy angielsku,
kopiowanie tekstu, czy tworzenie historii zmian.
Oszczędności czasu przychodzą później:
a) przyjemność zabrania się za analizę kodu przedstawionego na kolorowym
algorytmie,
przyspiesza pracę wykładniczo, wraz z jakością dokumentacji
b) poprawianie, czy adaptacja kodu nie zabiera już tyle czasu, a wręcz
przyspiesza.
c) uruchamianie jest już formalnością i czasem jest tak, że rysujesz/piszesz
program 3 dni,
a samo uruchamianie z oscyloskopem czy analizatorem stanów - kilka godzin.
Gdy znajdziemy błąd, często pada od razu po spojrzeniu w dokumentację
zdania:
" No tak... śmieszny błąd"
Dzieje się tak, gdyż poświęcając dużo czasu na przygotowanie kodu, zanim
zacznie się pisać słowa w dowolnym języku programowania, już wcześniej
korygujemy wiele błędów natury logicznej, składni, nazwy, czy zwykłych
pomyłek.
Po wpisaniu kodu - jest on już niemal pewny.
Zmiany zwyczajowo dokonują się poprzez poprawę kilkunastu znaków w kodzie.
A w większości pewnie w komentarzach i historii zmian.
Samo wpisanie daty 2013103 to już 7 znaków :-)

Odpowiadając na Twoje zapytanie - tak kod jest zawsze rozwojowy.
I tak miało być w założeniu.
Jednak czy faktycznie nastąpi jego rozwój - nie wiem, gdyż zależy to od
popytu.
Wszystkie są tak przygotowywane. Nie rozróżniam, czy coś ma być jednorazowe
czy nie.

Mam na dysku kilkaset algorytmów na różne procesory, LCD, termometry,
ultradźwięki
i wiele innych.
Jest też tego zaleta taka, że doskonale się rozumiemy z żoną, co do zasad
dokumentacji.
W związku z tym czasem podrzucam żonie mój algorytm sprzed nastu lat na
8051,
a żona przerabia go na PIC32 zmieniając (bardzo optymalnie zresztą) kod.

Uczę tej pracy też dzieci, więc już trójka z mojej całej piątki opanowała
rysowanie algorytmów,
choć są dopiero na poziomie <liceum.


Wielokrotnie wracam, do swoich projektów sprzed kilku, kilkunastu lat
i zmieniam. Wtedy zmienia się tylko kod najczęściej i czasem coś
optymalizuję,
gdy dziwie się, jak kiedyś taki "młodzik" nie widział prostrzej metody :-)

W razie potrzeby mogę przesłać gdzies próbki, ale raczej nie publicznie,
gdyż
nie mam zbyt wiele czasu (w ujęciu masowym) nad przekonywaniem do moich
metod działań :-)

[Marek]

On Fri, 11 Oct 2013 11:59:22 +0200, Sylwester Łazar<in...@alpro.pl>
wrote:

> a żona przerabia go na PIC32 zmieniając (bardzo optymalnie zresztą)
kod.

Pic32 w asemblerze? Z całym szacunkiem, ale nie widzę ekonomicznego
uzasadnienia (ani nawet praktycznego) do pisania w asmna tej
architekturze. Jeśli piszesz wyłącznie w asm na pic32 to oznacza to,
że albo projekty nie są zaawansowane (przysłowiowe już zapalanie
podświetlenia "wyjścia awaryjnego" ;) albo jesteś geniuszem.
Wychodzi jeszcze inna refleksja, że przewymiarowujesz mcu do zadania,
skoro zadanie ogarniasz w asm...

--
Marek

[Sylwester Łazar]

> Pic32 w asemblerze? Z całym szacunkiem, ale nie widzę ekonomicznego
> uzasadnienia (ani nawet praktycznego) do pisania w asmna tej
> architekturze. Jeśli piszesz wyłącznie w asm na pic32 to oznacza to,
> że albo projekty nie są zaawansowane (przysłowiowe już zapalanie
> podświetlenia "wyjścia awaryjnego" ;) albo jesteś geniuszem.

Dobre :-)
Nie. Projekt nie był aż tak trywialny.
Chodziło o obsługę wyświetlacza LCD 24bpp, szyną równoległą 24-bitową.
próbowałem w C i się nie dało...
Po skompilowaniu były bzdury. Mogłem osiągąć transfer
na poziomie 0,5MBs przy 24 bitach.
Niestety zadawalało mnie min. 10MBs i tak też zrobiłem.
No ale to już w asm.

> Wychodzi jeszcze inna refleksja, że przewymiarowujesz mcu do zadania,
> skoro zadanie ogarniasz w asm...

To nie tak.
Raczej odwrotnie. Ma za małe możliwości.
Głównie chodzi o transmisję 24 bitową.
Nie ma takiego portu, więc musiałem podzielić na transmisję 8+16bitów,
a to już składanie i czas minimum *3.
Wybrałem MICROCHIPA, bo wydawało mi się, że mogę sprawdzić jak to jest z
32-bitowymi Microchipa.
Dość pochopnie stwierdziłem, co to dla mnie za różnica - jakieś nowe
mnemoniki.
Głównie kolejkowanie programu i danych wymaga rozeznania.
No ale poczytałem myślę, że kilkadziesiąt+ stron, co do tego jak posługiwać
się rdzeniem MIPS, no i się udało.
Program działa, jestem zadowolony i właśnie w ASM.
Zajęło to może kilka tygodni pracy, ale teraz mam już opracowany projekt
sterowania TrueColor, dobry refresh rate i jakieś 30%-40% czasu wolnego dla
jądra procesora na prawdziwą pracę :-)
I to właśnie lubię: Ujarzmić sprzęt.

--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.



>

> --
> Marek

[Michał Lankosz]

W dniu 2013-10-11 11:59, Sylwester Łazar pisze:

>> Tak się zastanawiam ile czasu Ci zajmuje realizacja jakiegoś
>> zadania/projektu, czy sa to projekty rozwojowe czy jednorazowe
>> zadania, które po realizacji nie są dalej rozwijane.

> W razie potrzeby mogę przesłać gdzies próbki, ale raczej nie publicznie,
> gdyż
> nie mam zbyt wiele czasu (w ujęciu masowym) nad przekonywaniem do moich
> metod działań :-)

Zdobyta wiedza zapewne przydatna przy optymalizacji kodu ze względu na
szybkość i rozmiar, ale pisanie całego programu w asm to katowanie
siebie i innych.
Ile czasu potrzeba, żeby przenieść kod ASM chociażby z M3 na M0, albo
M4? A może za trzy lata będzie PIC32 bądź jakiś Freescale? Nie mówię tu
o programie, którego kod wynikowy to 1-5kB (po odliczeniu tablic
stałych). Tu chodzi o biblioteki graficzne, obsługę USB, TCP/IP, systemu
plików czy chociaż proste systemy operacyjne.

Za młodu hobbystycznie 8051 tylko w asemblerze programowałem, bo
kompilatory C dopiero się pojawiały i to komercyjne. AVR typu AT90S1200
czy 2313 w ASM ogarniałem. Ale to były małe projekty. Jak zacząłem
programować w C to już mi przeszła ochota na ASM.

--
Michał

[J.F]

Użytkownik "Michał Lankosz" napisał w wiadomości

>Zdobyta wiedza zapewne przydatna przy optymalizacji kodu ze względu
>na szybkość i rozmiar, ale pisanie całego programu w asm to katowanie
>siebie i innych.
>Ile czasu potrzeba, żeby przenieść kod ASM chociażby z M3 na M0, albo
>M4? A może za trzy lata będzie PIC32 bądź jakiś Freescale? Nie mówię
>tu o programie, którego kod wynikowy to 1-5kB (po odliczeniu tablic
>stałych). Tu chodzi o biblioteki graficzne, obsługę USB, TCP/IP,
>systemu plików czy chociaż proste systemy operacyjne.

Hm, a ile czasu trzeba aby przeniesc program mocno wykorzystujacy
system na inny procesor, z innymi timerami, licznikami, przerwaniami,
a takze innym wyswietlaczem, ekranem dotykowym zamiast klawiatury itp,
nawet jak jest napisany w C ?

Owszem, jak juz zejdziemy na bilblioteki graficzne, TCP/IP, USB,
system plikow ... ale albo masz to gotowe, albo program nie liczy 5kB.

A i tak Automapa na Androida przenosila sie cos dwa lata.

J.

[Sylwester Łazar]

> Ile czasu potrzeba, żeby przenieść kod ASM chociażby z M3 na M0, albo
> M4? A może za trzy lata będzie PIC32 bądź jakiś Freescale? Nie mówię tu

Kod z Microchipa na Freescale był przenoszony w marcu tego roku :-)
Dokładnie i w całości pisany w asemblerze.
Był to system odczytujący kilka DS18B21 pracujących na 1-Wire, z obsługa
wyświetlacza,
i jak to nazwaleś .... z bibliotekami graficznymi. Całość w ASM.

Jednak myślenie na poziomie C jest nieco inne.
W C przenosimy kod, mając nadzieję, że on się skompiluje po prostu innym
kompilatorem i na dodatek będzie działał.
Ja, przy moim podejściu nie przenoszę kodu asm pisanego za pomoca mnemoników
na inny kod pisany za pomoc innych mnemoników.
W ogóle nie interesuje mnie listing źródłowy.
Ja po prostu na poziomie algorytmu - takiego na wydrukowanym papierze z
programu 2D,
skreślam stare mnemoniki i wpisuje nowe. Bloczki pozostają te same.
Mało tego, ja nie muszę pisać w asm. Czasem wpisuje po prostu instrukcje C,
BASIC,
czy inne.
Bazą jest zawsze algorytm i jego bloczki, a nie kod źródłowy.
Dzięki takiemu podejściu kod jest zwięzły i jest do niego pełna dokumentacja
graficzna.
Jeżeli powstanie nowszy język programowania - baza zostanie ta sama.

> o programie, którego kod wynikowy to 1-5kB (po odliczeniu tablic
> stałych). Tu chodzi o biblioteki graficzne, obsługę USB, TCP/IP, systemu
> plików czy chociaż proste systemy operacyjne.

Często jest tak, że kod 5kB odpowiada systemowi opracowanemu na innym
poziomie abstrakcji, który ma 1MB.
Pisanie w ASM jest zawsze krótsze i szybsze niż w czymkolwiek innym.
To co zrobisz w systemie operacyjnym, z obcymi bibliotekami i własnym kodem,
może zająć i 10MB.
Jeżeli zrobisz to w asm, to może być i 5kB+tablice i RAM.

Wymaga jednak w części znajomości tematu, czyli procesora.
Nie jest to jednak złe, gdyż wszystkie procesory mają bardzo podobną budowę.
Różnią się szczegółami i liczbą stron karty katalogowych wraz z erratami.

> Za młodu hobbystycznie 8051 tylko w asemblerze programowałem, bo
> kompilatory C dopiero się pojawiały i to komercyjne. AVR typu AT90S1200
> czy 2313 w ASM ogarniałem. Ale to były małe projekty. Jak zacząłem
> programować w C to już mi przeszła ochota na ASM.
>
> --
> Michał

Programowanie w ASM daje dużo przyjemności.
Ja to robię nieprzerwanie od 28 lat i tylko kilka projektów napisałem w
innych językach,
a kilka innych ze wstawkami w ASM.
Nie boję się już nowych mikroprocesorów, bo po prostu jak już tyle razy
rozpracowywałem kilkanaście rdzeni, to do kolejnych podchodzimy z żoną jak
do SUDOKU.
A ile ludzi traci czas na Sudoku i krzyżówki :-)
S.

[Michał Lankosz]

W dniu 2013-10-11 14:11, J.F pisze:

> Hm, a ile czasu trzeba aby przeniesc program mocno wykorzystujacy system
> na inny procesor, z innymi timerami, licznikami, przerwaniami, a takze
> innym wyswietlaczem, ekranem dotykowym zamiast klawiatury itp, nawet jak
> jest napisany w C ?

Na pewno dużo mniej niż w asemblerze.
Podajesz mocno skrajny przykład. Jeśli program jest dobrze napisany
wtedy podmienia się tylko HAL. Jeśli nie, to i tak sporą część kodu,
zawierającą logikę działania urządzenia, można skopiować. I nie trzeba
rozwodzić się nad tym, czy dodawanie trzeba wykonać na raty czy
wystarczy jeden rozkaz, a może od razu wraz z inkrementacją wskaźnika,
przesunięciem.

>
> Owszem, jak juz zejdziemy na bilblioteki graficzne, TCP/IP, USB, system
> plikow ... ale albo masz to gotowe, albo program nie liczy 5kB.

Biblioteka może być gotowa, przerobiona lub napisana przez siebie.
Chodzi o uniwersalność. W dzisiejszych czasach tylko proste sterowniki
mogą mieć krótki kod i napisany w asm. Ale wymagania są obecnie dużo
większe to i złożoność programu rośnie. Dynamika zmian nie sprzyja
utrzymywaniu kodu napisanego w asemblerze. Co najwyżej sekcje krytyczne
w czasie, wymagające specyficznego podejścia powinny być napisane w tym
języku.

--
Michał

[Marek]

On Fri, 11 Oct 2013 14:49:49 +0200, Sylwester Łazar<in...@alpro.pl>
wrote:

> Był to system odczytujący kilka DS18B21 pracujących na 1-Wire, z
obsługa
> wyświetlacza,
> i jak to nazwaleś .... z bibliotekami graficznymi. Całość w ASM.

Ile czasu to pisałeś aby osiągnąć działający portotyp?

--
Marek

[Sylwester Łazar]

Od 4 marca do 4 kwietnia.
Spojrzałem na kolejne wersje projektu.
Ale to tak z przerwami.
BTW. To były akurat DS18B20.

[Michał Lankosz]

W dniu 2013-10-11 14:49, Sylwester Łazar pisze:

>> Ile czasu potrzeba, żeby przenieść kod ASM chociażby z M3 na M0, albo
>> M4? A może za trzy lata będzie PIC32 bądź jakiś Freescale? Nie mówię tu
> Kod z Microchipa na Freescale był przenoszony w marcu tego roku :-)
> Dokładnie i w całości pisany w asemblerze.
> Był to system odczytujący kilka DS18B21 pracujących na 1-Wire, z obsługa
> wyświetlacza,
> i jak to nazwaleś .... z bibliotekami graficznymi. Całość w ASM.

Ile tego kodu było i na jakie uC? Do odczytania temperatury i
wyświetlenia danych to i 1kB pamięci flash na kod jest za dużo. 200
linii źródeł w C będzie odpowiadało 400 liniom w asemblerze - do opanowania.
Co do bibliotek graficznych można mieć namyśli np. taką
http://www.ramtex.dk/ lub taką http://www.segger.com/emwin.html
albo tylko zestaw funkcji putpixel, line, circle, rectangle, color,
ewentualnie prosty bitmap i print. W tym drugim przypadku akurat wiele
kodu nie ma, w 300-700 bajtach kodu się zamknie ten zestaw funkcji
graficznych. Ale jak się chce coś poważniejszego zrobić to niestety kodu
bardzo szybko przybywa niezależnie od języka.

> Jednak myślenie na poziomie C jest nieco inne.
> W C przenosimy kod, mając nadzieję, że on się skompiluje po prostu innym
> kompilatorem i na dodatek będzie działał.
> Ja, przy moim podejściu nie przenoszę kodu asm pisanego za pomoca mnemoników
> na inny kod pisany za pomoc innych mnemoników.
> W ogóle nie interesuje mnie listing źródłowy.
> Ja po prostu na poziomie algorytmu - takiego na wydrukowanym papierze z
> programu 2D,
> skreślam stare mnemoniki i wpisuje nowe. Bloczki pozostają te same.

Chyba czegoś nie rozumiem. Asemblery nie różnią się tylko mnemonikami,
ale listą rozkazów, argumentami, liczbą rejestrów, ograniczeniami
każdego rejestru. Czym jest bloczek? i gdzie się podziewa ten asembler?
Bo chyba nie zastępujesz kompilatora wyższego poziomu?

> Mało tego, ja nie muszę pisać w asm. Czasem wpisuje po prostu instrukcje C,
> BASIC,
> czy inne.
> Bazą jest zawsze algorytm i jego bloczki, a nie kod źródłowy.

Tak chyba jest zawsze. Mamy algorytm i go zapisujemy za pomocą jakiegoś
języka programowania.

> Dzięki takiemu podejściu kod jest zwięzły i jest do niego pełna dokumentacja
> graficzna.
> Jeżeli powstanie nowszy język programowania - baza zostanie ta sama.
>
>> o programie, którego kod wynikowy to 1-5kB (po odliczeniu tablic
>> stałych). Tu chodzi o biblioteki graficzne, obsługę USB, TCP/IP, systemu
>> plików czy chociaż proste systemy operacyjne.
> Często jest tak, że kod 5kB odpowiada systemowi opracowanemu na innym
> poziomie abstrakcji, który ma 1MB.
> Pisanie w ASM jest zawsze krótsze i szybsze niż w czymkolwiek innym.
> To co zrobisz w systemie operacyjnym, z obcymi bibliotekami i własnym kodem,
> może zająć i 10MB.
> Jeżeli zrobisz to w asm, to może być i 5kB+tablice i RAM.

Co to są biblioteki obce? Czy biblioteka obcą jest ta napisana przez
mojego kolegę z pracy? Kilka tygodni pracy i działa na AVR.
Przeniesienie na STM32 to tylko grzebnięcie w HAL (jeśli występuje). Nie
skreślam przy tym mnemoników.
Co do objętości kodu to się zgodzę, że w C jest większy, ale bez
przesady - nie 5kB->10MB! Jeśli w bibliotece są niewykorzystane funkcje
to linker może je po prostu wyciąć z automatu.

>
> Wymaga jednak w części znajomości tematu, czyli procesora.
> Nie jest to jednak złe, gdyż wszystkie procesory mają bardzo podobną budowę.
> Różnią się szczegółami i liczbą stron karty katalogowych wraz z erratami.

To jest na plus. Zawsze dogłębna wiedza jest cenna. Pytanie jednak, jak
głęboko powinniśmy sięgać. No bo kupując w sklepie mleko, lody, chleb,
płatki kukurydziane, czekoladę, wodę powinniśmy czytać ich skład.
Napotykając powiedzmy karagen zgłębić wiedzę o nim czy jest rakotwórczy
czy nie. Wiedza bardzo cenna dla Twojego zdrowia - wybierasz pod tym
kątem wszystkie produkty, czy zdajesz się na odgórne przepisy, które nie
pozwalają na sprzedaż żywności zagrażającej życiu? Takich obszarów z
naszego otoczenia jest za dużo, żeby je zgłębiać.


--
Michał

[Michał Lankosz]

W dniu 2013-10-11 16:13, Michał Lankosz pisze:

Fragment od wyrazów
> Pytanie jednak, jak głęboko...
nie wyszedł mi, rozproszyło mnie kilka 'lokalnych zakłóceń', reszta OK.

--
Michał

[Marek]

On Fri, 11 Oct 2013 16:04:23 +0200, Sylwester Łazar<in...@alpro.pl>
wrote:

> Od 4 marca do 4 kwietnia.

No to masz bardzo dużo czasu albo Twój czas jest niewiele wart, bo
wartość poświęconych roboczogodzin ma się nijak do wartości projektu
(tak, wiem zdobywane doświadczenie też się liczy). Nawet poświęcając
1 roboczogodzinę dziennie.

Taki projekt w C robi się w weekend (od zera bez bibliotek do 1wire).
Nie wyobrażam sobie już ile czasu zajęłoby Ci zrobienie logera tej
temperatury np. na karcie sd z systemem plików vfat lub transmisją po
USB. Zakładam, że raczej trudno byłoby znaleźć lib vfat (usb) w asm
na konkretny mcu i na pewno zacząłbyś pisać własną implementację,
albo niedaj Bóg, skompilowałbyś jakiś istniejący lib vfat a kod
wynikowy byś "zaincludował" do swojego kodu w asm ;-)

--
Marek

[Sylwester Łazar]

> Co do objętości kodu to się zgodzę, że w C jest większy, ale bez
> przesady - nie 5kB->10MB! Jeśli w bibliotece są niewykorzystane funkcje
> to linker może je po prostu wyciąć z automatu.

Czasem jedna błędna deklaracja typu w C powoduje, że brakuje Ci pamięci.
No może to skrajny przykład,
ale 5kB w ASM i 50kb w C to chyba się zgodzisz?

> > Wymaga jednak w części znajomości tematu, czyli procesora.
> > Nie jest to jednak złe, gdyż wszystkie procesory mają bardzo podobną
budowę.
> > Różnią się szczegółami i liczbą stron karty katalogowych wraz z
erratami.
>
> To jest na plus. Zawsze dogłębna wiedza jest cenna. Pytanie jednak, jak
> głęboko powinniśmy sięgać. No bo kupując w sklepie mleko, lody, chleb,
> płatki kukurydziane, czekoladę, wodę powinniśmy czytać ich skład.

Ty tego nie robisz?
Mleko dzisiaj kupowałem od kobiety, która ma gospodarstwo,
chleb też mamy sprawdzony. Czekolada - tylko Terravita i to gorzka.
Woda - są tego hektolitry w sklepie. Dzisiaj żona przeczytała,
że na wodzie "Czar Mazowsza" jest napisane, że jest wzbogacona (!)
ozonem.

> Napotykając powiedzmy karagen zgłębić wiedzę o nim czy jest rakotwórczy
> czy nie. Wiedza bardzo cenna dla Twojego zdrowia - wybierasz pod tym
> kątem wszystkie produkty, czy zdajesz się na odgórne przepisy, które nie
> pozwalają na sprzedaż żywności zagrażającej życiu? Takich obszarów z
> naszego otoczenia jest za dużo, żeby je zgłębiać.

Im więcej zgłębisz, tym lepiej dla Ciebie.
Zazwyczaj nie zdaję się tylko na odgórne przepisy,
bo to by oznaczało 100% zaufania do polityków, którzy je ustalają.
A w przypadku kompilatora... to samo.
S.

[Sylwester Łazar]

> No to masz bardzo dużo czasu albo Twój czas jest niewiele wart, bo
> wartość poświęconych roboczogodzin ma się nijak do wartości projektu
> (tak, wiem zdobywane doświadczenie też się liczy). Nawet poświęcając
> 1 roboczogodzinę dziennie.

Daleki jestem od oceny jakości czyjegoś czasu na podstawie określenia czasu
w jakim powstał projekt.
W szczególności daleki jestem od przeliczenia pracy projektanta na
roboczogodziny.
Kilka razy mi się tak zdażyło, zlecając pracę innym.
Zawsze podziwiam kogoś, kto w 20 roboczogodzin potrafi napisać
kod do dowolnego urządzenia z wybranym procesorem, które ktoś postawi Ci na
stole z adnotacją:
mi się to nie udało - może spróbujesz?

Czyli koszt tego zlecenia według Ciebie powinien wynosić?
20x ile?

[Sylwester Łazar]

> USB. Zakładam, że raczej trudno byłoby znaleźć lib vfat (usb) w asm
> na konkretny mcu i na pewno zacząłbyś pisać własną implementację,

Chcesz powiedzieć, że dla Ciebie typową praktyką, jest szukanie
gotowych programów/bibliotek, dopisanie 100 linijek kodu, wspólne
kompilowanie w pudełko i do widzenia?
S.

[J.F]

Użytkownik "Michał Lankosz" napisał w wiadomości

W dniu 2013-10-11 14:11, J.F pisze:
>> Hm, a ile czasu trzeba aby przeniesc program mocno wykorzystujacy
>> system
>> na inny procesor, z innymi timerami, licznikami, przerwaniami, a
>> takze
>> innym wyswietlaczem, ekranem dotykowym zamiast klawiatury itp,
>> nawet jak
>> jest napisany w C ?

>Na pewno dużo mniej niż w asemblerze.
>Podajesz mocno skrajny przykład. Jeśli program jest dobrze napisany
>wtedy podmienia się tylko HAL.

Bo ja wiem czy taki wydumany ... robisz np sterownik silnika
spalinowego.
Albo windy, czy serwonapedu, albo plottera, UPS, ... czy np sterownik
PLC (tzn nie uzyc gotowego, tylko robic wlasny).

>Jeśli nie, to i tak sporą część kodu, zawierającą logikę działania
>urządzenia, można skopiować.

Mozna, ale mozna sie tez zastanowic czy teraz nie mozna/trzeba zrobic
lepiej i napisac od poczatku :-)

Owszem, teraz takie czasy ze warto sie zastanowic czy nie zaczac od
wyboru ARM z linuxem i qt, a jak sie okaze ze on nie bardzo RT, to sie
wstawi 300MHz zamiast planowanych 100.
Ale dawniej ... trzeba sie bylo zmiescic w rynkowej cenie i znacznie
mniejszym hardware.
I na HAL nie bylo miejsca. I teraz nie ma z czego kopiowac :-)

J.

[Piotrek]

On 2013-10-11 16:57, Sylwester Łazar wrote:
> Chcesz powiedzieć, że dla Ciebie typową praktyką, jest szukanie
> gotowych programów/bibliotek, dopisanie 100 linijek kodu, wspólne
> kompilowanie w pudełko i do widzenia?
> S.
>

Czy budowę domu też zaczynasz od wytopienia stali na łopatę, którą
wykopiesz glinę na cegły? ;-)

Piotrek

[Sebastian Biały]

On 2013-10-11 08:43, Zbych wrote:
>>> Słaby przykład, w gcc można zrobić destruktor w C.
>> I wtedy mamy jaki język?
> Jeśli pijesz do tego, że nie jest to czyste C, to argument jest
> chybiony. Przerwań też nie masz w C (ani w C++).

Rozróżnij:

a) implementacje funckjonalności od idiomu RAII.

b) implementacje w C++ od impelmentacji w "czymś" nieprzenośnym.

ad a) Muszę wypełnić idiom RAII jakimś kodem, cli/sei nadawało się
najlepiej.

ad b) Pisanie w wynalazkach kończy się nieprzenosnym kodem, a na
horyzoncie sprintem zapierd... clang.

[Sylwester Łazar]

> Czy budowę domu też zaczynasz od wytopienia stali na łopatę, którą
> wykopiesz glinę na cegły? ;-)
>
> Piotrek

To jest zły przykład. Ja nie hoduje sobie kryształka kwarcu, a potem z niego
robię procka.
Zapytam tak:
Czy kupujesz gotowy projekt domu z muratora za 1000zł,
czy projektujesz sobie dom w taki sposób jakim chciałbyś go mieć?
S.

[Marek]

On Fri, 11 Oct 2013 16:57:07 +0200, Sylwester Łazar<in...@alpro.pl>
wrote:

> Chcesz powiedzieć, że dla Ciebie typową praktyką, jest szukanie
> gotowych programów/bibliotek, dopisanie 100 linijek kodu, wspólne
> kompilowanie w pudełko i do widzenia?

Oczywiście, bo ma to ekonomiczne uzasadnienie, liczy się czas od
pomysłu do gotowego produktu. Poza tym po co wymyślać coś, co już
jest wymyślone i przede wszystkim przetestowane i sprawdzone?

Jak myślisz dlaczego w Androidzie użyto kernel Linuxa? Najprostszy
przykład jaki mi przyszedł do głowy.

--
Marek

[Piotrek]

On 2013-10-11 17:31, Sylwester Łazar wrote:
> To jest zły przykład. Ja nie hoduje sobie kryształka kwarcu, a potem z niego
> robię procka.
> Zapytam tak:
> Czy kupujesz gotowy projekt domu z muratora za 1000zł,
> czy projektujesz sobie dom w taki sposób jakim chciałbyś go mieć?
> S.
>

Może zostawmy analogie budowlane na boku - to nie był zbyt szczęśliwy
pomysł.

Generalnie to jest tak, że przy programach (systemach) nieco bardziej
skomplikowanych niż "Hello world" wybudowanie wszystkiego od początku
nie ma ani sensu ekonomicznego, ani (najczęściej) nie spełnia kryteriów
jakościowych. Przy czym przez kryteria jakościowe rozumiem również
dotrzymanie terminów.

Dlatego między innymi wymyślono takie "wynalazki" jak biblioteki,
komponenty, frameworki i inne cuda wianki.

Piotrek

[Sylwester Łazar]

> Jak myślisz dlaczego w Androidzie użyto kernel Linuxa? Najprostszy
> przykład jaki mi przyszedł do głowy.
>
> --
> Marek

To akurat proste.
Główny projektant nie miał swoich własnych bibliotek do obsługi
4''wyświetlacza LCD,
rezystancyjnego panelu dotykowego, Wi-Fi, USB i karty SD.
Uznał, że skoro tak, to potrzebuje systemu operacyjnego, bo tam ma już
uruchomione wszystkie biblioteki razem, które jakoś działają.
Tutaj miał do wyboru:
Windows ze swoimi bibliotekami - razem ze 300MB
Linux, gdzieś ze 30MB
Jego syn, będący w 1 klasie podstawówki, słusznie zauważył:
"Tato bierz ten Linux! Tylko głupiec pakowałby się w system 10x większy i
bardziej zawodny."
No i dorzucił trochę koloru do Linuxa i zmieścił się w procku.
Teraz po naciśnięciu książki telefonicznej czeka tylko 100ms i już ma 10
pierwszych numerów z bazy danych na ekranie.
A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms
:-)
S.

[Piotrek]

On 2013-10-11 17:43, Sylwester Łazar wrote:
> A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms

Chyba nie doceniasz znaczenia testowania. Zwłaszcza przy deploymencie na
miliony (różnych) urządzeń ...

Piotrek

[Sylwester Łazar]

> Dlatego między innymi wymyślono takie "wynalazki" jak biblioteki,
> komponenty, frameworki i inne cuda wianki.
>
> Piotrek

Zauważ, że te biblioteki możesz mieć swoje lub obce, a nawet swojo-obce,
czyli kolegi, z którym jeszcze się nie pokłóciłeś.

Jeżeli ja mam bazę swoich projektów/bibliotek, do których interfejsy mam
znane,
potrzebuję tyle samo lub mniej czasu, niż ktoś kto wchodzi do zasobów
globalnych,
szuka biblioteki, wgłebia się w interfejs, includuje a na koniec
uruchamia....

Jeżeli jednak ktoś, kto pisał 10 lat w C i 3 razy w asm,
pragnąłby napisać kod na 32-bitowy uC w ASM - nie da rady.
Polegnie na opisie sprzętowego 8xPWM.

Jeden lubi Hi-level z milionami kolegów, a inny Extream z małą ekipą.
Nic nie poradzisz. Dopóki nie musisz...
S.

[Sylwester Łazar]

> > A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms
>
> Chyba nie doceniasz znaczenia testowania. Zwłaszcza przy deploymencie na
> miliony (różnych) urządzeń ...
>
> Piotrek

Może.
Skomentuj proszę te 100ms.
S.

[Sebastian Biały]

On 2013-10-11 11:59, Sylwester Łazar wrote:
> Nawyk dokumentowania kodu mam już od 15 roku życia.

Ja od 12-go, mając w ręku ZX Spectrum - Z80, przez 6502, 8051, 680x0,
8086, arm, mips. Znam(łem) assemblery wszystkich i we wszystkich
pisałem. I obecnie programuje ogromna aplikację w C++ na duzym systemie
i w wolnych chwilach roluje bity na GPIO AVRka. Skażenie asm nie
przeszkodziło mi znajdywać zalety zarówno programowania
wysokopoziomowego jak i asm, dosuje obie techniki, wliczając to takie
ciekawoski jak programowanie deklaratywne czy constrains a nawet
ostatnio kawalek w prawie-prologu się trafił (na uC :). Używam wielu
narzedzi, a nie tylko młotka asm, bo problemy mam różne więc i narzędzia
też.

> Jednak wyrobienie sobie takiego nawyku przez kilkanaście lat pracy,
> powoduje, że teraz to idzie szybko.

Mam znajomego ktory niezwykle szybko kopie doły łopatą. Do tego stopnia
ze konkuruje z minikoparkami. Czy jesteś pewny że kopanie łopatą ma
jednak przyszłość? Bo ja tak, sprawdza mi się w ogródku.

> Wiadomym jest, że jak stukasz w klawiaturę wpisując ~destruktory w C++,
> czy inne konstrukcje, nie dodając żadnych komentarzy zawsze będzie to
> szybsze,
> niż rysowanie algorytmu, dokładanie opisu słownego po polsku czy angielsku,
> kopiowanie tekstu, czy tworzenie historii zmian.

Szybsze będzie tworzenie unit testów, abstrakcji oraz czytelnego kodu
które pozwolą w pełni przetestować kod zamiast pisania komentarzy które
po miesiącu nie mają nic wspólnego z rzeczywistością bo nie istnieje
żadnej przymus aby były synchronicznie zmieniane z kodem. W "zespole"
jednoosobowym bywają z tym problemy. Wobraź sobie jak to wygląda w
zespole N>1.

> a) przyjemność zabrania się za analizę kodu przedstawionego na kolorowym
> algorytmie,

Ja mam przyjemnośc nie analizowania kodu tylko stwierdzenia jakie
warunki brzegowe ma realizować widząc testy. Implementacja ma tylko tyle
na znaczeniu że musi mieć założoną złożoność bądź restryckje czasowe.

> b) poprawianie, czy adaptacja kodu nie zabiera już tyle czasu, a wręcz
> przyspiesza.

Refaktoring kodu przyspiesza kiedy masz testy.

> c) uruchamianie jest już formalnością i czasem jest tak, że rysujesz/piszesz
> program 3 dni,
> a samo uruchamianie z oscyloskopem czy analizatorem stanów - kilka godzin.

Patrz, zupełnie jak przetestowany kod in virto.

> Gdy znajdziemy błąd, często pada od razu po spojrzeniu w dokumentację
> zdania:
> " No tak... śmieszny błąd"

Albo jak padnie unit test to patrzymy w kod i naprawiamy.

> Dzieje się tak, gdyż poświęcając dużo czasu na przygotowanie kodu, zanim
> zacznie się pisać słowa w dowolnym języku programowania, już wcześniej
> korygujemy wiele błędów natury logicznej, składni, nazwy, czy zwykłych
> pomyłek.

Dzieie się tak gdy przygotujesz sobie test suide na długo przed
napisaniem pierwszego słowa kluczowego algorytmu.

> Po wpisaniu kodu - jest on już niemal pewny.

Ba, przetestowany kod jest nie tylko pewny, ale i *przetestowany*.

> Zmiany zwyczajowo dokonują się poprzez poprawę kilkunastu znaków w kodzie.
> A w większości pewnie w komentarzach i historii zmian.

Która to historia znajduje się w systemie kontroli wersji który bez
watpienia używasz.

> Samo wpisanie daty 2013103 to już 7 znaków :-)

Tym bardziej że zbędne.

> Odpowiadając na Twoje zapytanie - tak kod jest zawsze rozwojowy.
> I tak miało być w założeniu.

Nie wątpie że łopata można kopać dziury różnych kształtów.

> W związku z tym czasem podrzucam żonie mój algorytm sprzed nastu lat na
> 8051,
> a żona przerabia go na PIC32 zmieniając (bardzo optymalnie zresztą) kod.

Zupełnie jak kompilator pawie każdego języka.

> Uczę tej pracy też dzieci, więc już trójka z mojej całej piątki opanowała
> rysowanie algorytmów,
> choć są dopiero na poziomie <liceum.

3 łopaty kopią szybciej niż jedna :P

Odkryłeś kwadratowe koło i je pielęgnujesz piłując pieczołowicie rogi aż
wyjdzie romb. Bez wątpienia warsztat masz znakomity, znajomość asm w
jednym palcu, ale czy na pewno widziałeś jak wygląda warsztat
przeciętnego programisty poza twoim domem? Wiesz ile i jakich narzędzi
używa, jak pracuje w zespole bądź samotnie, ile twoich problemów
rozwiązano w latach 70-tych i gdzie obecnie znajdują się jezyki
programowania? Programiści embedded to czesto skansen osobliwości i
rozwiązań poroblemów które albo nie istnieją albo zostały rozwiązane
dziesięciolecia temu. Nie dalej jak miesiac temu trafilem na mistrza
ktory programuje 8051 w edytorze hex pod dosem znając na pamięc kod
*maszynowy*. Nie dalej jak wczoraj musiałem zmagaś się z
systemverilogiem w którym ktoś intensywnie wymyśla nowe "lepsze"
programowanie obiektowe ignorując to co wiemy od smalltalka.

Nie zrozum mnie źle: szanuje Twoją pracę i wiedzę. Ale proszę, dla dobra
ludzkosci, nie przedstawiaja jej jako wzorca dla kogokolwiek. Jesli Ci
pasuje to ok, jesli sprawia radość to tym lepiej.

Koniecznie obejrzyj to:

http://vimeo.com/71278954

Od 4:00 jest pouczający kawałek na temat "assembler jest najfajniejszy
do wszystkiego".

Tak, ten film to rodzaj żartu, ale czy nie ciekawy? Polecam dla
wszystkich aby to obejrzeć do końca.

[Sebastian Biały]

On 2013-10-11 16:35, Sylwester Łazar wrote:
>> Co do objętości kodu to się zgodzę, że w C jest większy, ale bez
>> przesady - nie 5kB->10MB! Jeśli w bibliotece są niewykorzystane funkcje
>> to linker może je po prostu wyciąć z automatu.
> Czasem jedna błędna deklaracja typu w C powoduje, że brakuje Ci pamięci.
> No może to skrajny przykład,
> ale 5kB w ASM i 50kb w C to chyba się zgodzisz?

Bzdura. Kod wynikowy zajmuje tyle ile powinien, nawet w skrajnie
popsutych współczesnych kompilatorach jest ciągle nieźle a nie 10x
gorzej bez powodu.

[Sebastian Biały]

On 2013-10-11 17:43, Sylwester Łazar wrote:

> No i dorzucił trochę koloru do Linuxa i zmieścił się w procku.
> Teraz po naciśnięciu książki telefonicznej czeka tylko 100ms i już ma 10
> pierwszych numerów z bazy danych na ekranie.
> A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms

Po 10 latach pisania kodu. Taki system operacyjny i GUI w asm nie
istnieje *nigdzie* jako działający poważnie produkt. Nie dlatego że się
nie da tylko dlatego że nie ma to żadnego sensu.

[Piotrek]

On 2013-10-11 17:55, Sylwester Łazar wrote:
> Może.
> Skomentuj proszę te 100ms.

A co tu komentować?

W podanym przez Ciebie przykładzie kompletnie nie ma sensu ściganie się,
w celu przyspieszenia wyświetlania książki telefonicznej w ciągu 1ms.

Główne z tego powodu, że i tak userowi zajmie pewnie dobrą sekundę
poskrobanie się po głowie w celu ustalenia czy to o tego "Ziutka" z
książki telefonicznej mu chodziło, czy o jakiegoś innego.

Piotrek

[Piotrek]

On 2013-10-11 17:51, Sylwester Łazar wrote:
> Zauważ, że te biblioteki możesz mieć swoje lub obce, a nawet swojo-obce,
> czyli kolegi, z którym jeszcze się nie pokłóciłeś.
>
> Jeżeli ja mam bazę swoich projektów/bibliotek, do których interfejsy mam
> znane,

Acha. Czyli jednak zaczynasz od "szukania gotowych programów/bibliotek".
Zanotowałem ;-)

> potrzebuję tyle samo lub mniej czasu, niż ktoś kto wchodzi do zasobów
> globalnych,
> szuka biblioteki, wgłebia się w interfejs, includuje a na koniec
> uruchamia....

Problem zaczyna się w momencie, kiedy zaczynasz się poruszać poza swoją
niszą.

A przecież sprawny projektant powinien sobie poradzić z zaprojektowaniem
"czegobądź".

Dobierając co najwyżej ekspertów dziedzinowych, którzy doradzą mu jakich
komponentów użyć. :-)

>
> Jeżeli jednak ktoś, kto pisał 10 lat w C i 3 razy w asm,
> pragnąłby napisać kod na 32-bitowy uC w ASM - nie da rady.
> Polegnie na opisie sprzętowego 8xPWM.

No dokładnie o to chodzi. Dlatego IMHO - jeśli już masz spełnić jakieś
szczególne wymagania - lepiej użyć gotowych i sprawdzonych narzędzi, niż
rzeźbić samemu.

>[...]

Piotrek

[Sylwester Łazar]

> Nie zrozum mnie źle: szanuje Twoją pracę i wiedzę. Ale proszę, dla dobra
> ludzkosci, nie przedstawiaja jej jako wzorca dla kogokolwiek. Jesli Ci
> pasuje to ok, jesli sprawia radość to tym lepiej.

Widzę, że piszesz szybko i bardzo nowocześnie.
Skutki są, jakie są, ale każdy widzi to inaczej.
W czasie tej polemiki zrobiłeś mnóstwo błędów.
Do tego je bagatelizujesz i często się złościsz na kogoś kto Ci zwraca
uwagę,
że jest źle.
Liczy się nie tylko szybkość, ale też i jakość.
Nie da się szybko bez utraty jakości.
Doceniasz wagę testów. Myślę, że w tym przypadku zupełnie słusznie.
Ja mam inną metodę pracy.
Ja również szanuję Twoją pracę i wiedzę, ale proszę, dla dobra ludzkości
nie przedstawiaj jej jako wzorca dla kogokolwiek.
Wzorce są różne w każdej dziedzinie.
Nigdy człowiek nie wie, które naśladować, aby być poprawnym.
S.

[Marek]

On Fri, 11 Oct 2013 17:56:54 +0200, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> Nie zrozum mnie źle: szanuje Twoją pracę i wiedzę. Ale proszę, dla
dobra
> ludzkosci, nie przedstawiaja jej jako wzorca dla kogokolwiek. Jesli
Ci
> pasuje to ok, jesli sprawia radość to tym lepiej.

Mam nadzieję, że Sylwek jedynie nas trochę tr... prowokuje ;)

--
Marek

[Sylwester Łazar]

> Dobierając co najwyżej ekspertów dziedzinowych, którzy doradzą mu jakich
> komponentów użyć. :-)

O! To by było dobre.
W szczególności wszyscy marzymy o systemie z mikrofonem,
gdzie wypowiemy tajmnicze zaklęcie:
"Zrób mi sterownik z ładnym i funkcjonalnym ekranem, który będzie zarządzał
domem i ogrzeje mi go w sezonie za 300 Euro"
i staniemy się takimi ekspertami dziedzinowymi.

Po czym, (gdzie tam w weekend!) w minutę z kompilacją, testami i realizacją
system zintegruje się z inteligentnym domem i zacznie pracę.

Pozostaje do wypłaty honorarium.
Stawka roboczogodzinowa zdewaluowała się już w tym przypadku kompletnie z
przyczyn oczywistych,
więc jako, że zaoszczędziliśmy jakieś 600 Euro, wychodzi gdzieś tak po 20
Euro za słowo.

Wszelki sprzęt produkowany w Chinach kupimy w Farnelu za cenę jednego
wypowiedzianego słowa :-)

> No dokładnie o to chodzi. Dlatego IMHO - jeśli już masz spełnić jakieś
> szczególne wymagania - lepiej użyć gotowych i sprawdzonych narzędzi, niż
> rzeźbić samemu.
>
> >[...]
>
> Piotrek

Zawsze lepiej jest coś kupić niż zrobić.
A jeszcze lepiej mieć za darmo.
Dokładnie tą polityką kieruje się cała Europa, ale nie Chińczycy, u
których cały świat kupuje, bo się tak lepiej opłaca i jest czytelniej.
Poczekamy tylko na skutki.

S.

[Sebastian Biały]

On 2013-10-11 18:45, Sylwester Łazar wrote:
> W czasie tej polemiki zrobiłeś mnóstwo błędów.

Z chęcią dowiem się jakich.

> Do tego je bagatelizujesz i często się złościsz na kogoś kto Ci zwraca
> uwagę,
> że jest źle.

Nikt nie zwrócił mi jeszcze uwagi lub też nie zauważyłem poza czeskim
błędem z void.

> Liczy się nie tylko szybkość, ale też i jakość.

I dlatego asm nie ma żadnego sensu. Pisnanie w asm nie ma żadnego
związku z jakością ma za to duzo wspólego z RealTime albo archeologią
(do wyboru).

[Sylwester Łazar]

> Mam nadzieję, że Sylwek jedynie nas trochę tr... prowokuje ;)
>
> --
> Marek

Też :-)
Ale dziś już poświęciłem zbyt wiele czasu na to bagno jakim jest internet.
Jednak telewizora nie posiadam jakieś 12 lat, więc czasem trudno mi się
zbliżyć do mainstreamowych poglądów :-)
Idę coś zrobić w weekend.
Miałem dzisiaj podłączyć oscyloskop i pokazać/omówić transmisję 1-wire
dzieciakom.
Nie wiem jednak, co lepiej kupić dodatkowe łopaty, czy poszukać gotowych
bibliotek do
DALLASa.
Miłego wieczoru, jak mawiają!
EOTFM
S.

[Sylwester Łazar]

> > W czasie tej polemiki zrobiłeś mnóstwo błędów.
>
> Z chęcią dowiem się jakich.

Voilà!
"nie zauważyłem poza Pisnanie duzo wspólego"
Nie chciałem, ale prosiłeś.
Nie bierz do siebie, ale trenuj.
Mi też się zdarza, ale wiesz: kod w asm krótszy :-)
S.

[Sebastian Biały]

On 2013-10-11 19:14, Sylwester Łazar wrote:
>> Z chęcią dowiem się jakich.
> Voilà!
> "nie zauważyłem poza Pisnanie duzo wspólego"

I tak oto zeszło powietrze z argumentów. A już miałem nadzieje na coś
merytorycznego.

A literówki popełniam z powodu pospolitego lenistwa.

[Marek Borowski]

On 10/9/2013 11:52 AM, stch...@gmail.com wrote:
> W dniu środa, 9 października 2013 08:45:22 UTC+2 użytkownik Zbych napisał:

> Dzięki za info!! Jeszcze tego nie zassałem, a już mam pytania.. Czy jest to środowisko "okienkowe"? Tak jak chociażby Delphi(Pascal) i czy jest to strasznie upierdliwe? Czy da się tam skrobać w Assemblerze tego procka?
> Podejrzewam, że jest kompilator C, ale raczej nie jestem fanem tego potrąbionego języka programowania. a+=a, a=+a , toż tego czytać się nie da! O popierdolonych znakach funkcji logicznych nawet nie ma co wspominać...
>
To jest wylacznie kwestia gustu. Ja tam wlasnie bardzo lubie C
za mozliwosc bardzo zwiezlego zapisu. To jest wylacznie
kwestia przyzwyczajenia.

v++; v+=5; *p = v ? v : v+1; while(f); sa bardzo ok.

zato niedobrze mi sie robi na mysl ze mialbym to zapisywac w postaci:

let v := v + 1

if v<>0 then
begin
derefrence p := v
end
else
begin
derefrence p := v + 1
end
endif

itd.

Pozdrawiam

Marek

[Marek Borowski]

On 10/11/2013 12:19 AM, Sebastian Biały wrote:
> On 2013-10-10 22:49, Marek Borowski wrote:
>>>>> Mniej więcej w wersji lite.
>>>> A w wersji full ?
>>> Np. statyczny polimorfizm (pomaga unit testować kod na PC bez utraty
>> To akutrat wymienilem.
>>> szybkości na uC) bądź obliczenia na szablonach.
>> Czyli metaprograming. Jeszcze cos ?
>
> Rzadziej:
>
> Programowanie obiektowe (ze względu na heap raczej arm7 i więcej). Sporo
> SFINAE w różnych postaciach. Obciętą wersję template expressions w
> jednym z projektów.
To mozna podciagnac pod metaprogramowanie.

> Namespaces
> powszechnie, często anonimowe.
Jako zamiennik do slowa kluczowgo static ?
Tak pozatym to namespace to znow cos co sie przydaje przy wiekszych
projektach. Ew. kwestia niecheci do prefixow w nazwach.


> Type traits.
Jakis przyklad ?

> Inicjalizacja przed main
> (szczególnie peryferiów).
>
A jaka to jest zaleta w stosunku do funkcji init() wolanej z main ?


> Natomiast latwiej będzie czego nie używam:
>
> Smart pointerów, bo fragrmentują pamięć, boosta (tylko dlatego że nie ma
> zazwyczaj na mniejsze uC), stla ze względu na fragmentacje. Boosta
> żałuję najbardziej.
>
A akurat zastanawialem sie nad smart pointerami z wlasnym allokatorem.
Niestety zarzadzane pamiecia jest czyms na co w uC nalezy zwracac
szczegolna uwage, bo do efektywnych algorytmow zarzadzania pamiecia
potrzeba jej po prostu duzo a w przypadku uC raczej jej nadmiar
nie wystepuje.


Pozdrawiam

Marek

[Marek Borowski]

Nie bez powodu tylko poprzez gigantyczne powinowactwo do dolaczania
wszystkiego co mozliwe. Walka z tym jest dosyc mozolna.
W asm masz dokladnie to co chcesz, w C juz musisz sie zastawiac
nad dodatkami w postaci startup code i bibliotekami, a w C++ te dodatki
na dodatek sa "ciezkie". Owszem mozna to ogarnac ale wymaga to
pracy i nie dziw sie ze odczucie jest jakie jest.

Pozdrawiam

Marek

[Michał Lankosz]

W dniu 2013-10-11 23:19, Marek Borowski pisze:

> To jest wylacznie kwestia gustu. Ja tam wlasnie bardzo lubie C
> za mozliwosc bardzo zwiezlego zapisu. To jest wylacznie
> kwestia przyzwyczajenia.
>
> v++; v+=5; *p = v ? v : v+1; while(f); sa bardzo ok.
>
> zato niedobrze mi sie robi na mysl ze mialbym to zapisywac w postaci:
>
> let v := v + 1
>
> if v<>0 then
> begin
> derefrence p := v
> end
> else
> begin
> derefrence p := v + 1
> end
> endif
>

Masz rację, kwestia przyzwyczajenia. Zaczynałem od Pascala (uczono w
szkole) i niedobrze mi się robiło widząc C. Taki switch/case na przykład:
switch(c)
{
case 'a':fun1();
break;
case 'b':fun2();
break;
}

case pascal of
'a': proc1;
'b': fun1(7);
end;

i sporo innych dziwactw i pułapek C ( if(a=b) ). Ale przesiadłem się na
C i przyzwyczaiłem.




--
Michał

[Michał Lankosz]

W dniu 2013-10-11 16:57, J.F pisze:
> Bo ja wiem czy taki wydumany ... robisz np sterownik silnika spalinowego.
> Albo windy, czy serwonapedu, albo plottera, UPS, ... czy np sterownik
> PLC (tzn nie uzyc gotowego, tylko robic wlasny).

Winda: główna logika działania stała, albo lepiej - odrębna, bo można
zmienić logikę bez zmiany sprzętu i odwrotnie. Maszyna stanów otrzymuje
sygnały typu wciśnięto przycisk n kasety, impuls z m czujnika położenia,
teraz ma załączyć bieg 1 silnika (czy podać napięcie na falownik),
wysłać do displeja/ów że jest na piętrze takim, porusza się góra/dół
itp. Może warto podzielić na kilka maszyn. Osobno mamy funkcję czytania
powiedzmy kasety windy - może każdy klawisz jest na osobnym kablu, może
jakiś RS485, CAN, czy inny - tym się zajmie zestaw funkcji, które będą
zależały od sprzętu. Program główny robi init urządzenia czytającego
przyciski, jakie by ono nie było. W ten sposób można zmienić logikę
działania już istniejącej windy zrealizowanej na innym (starszym) sprzęcie.
PLC? tak samo. Masz jakiś interpreter kodu programu, który nie zależy od
sprzętu. Masz I/O zależne od sprzętu więc te funkcje przerabiasz pod
konkretny uC.

> Ale dawniej ... trzeba sie bylo zmiescic w rynkowej cenie i
> znacznie mniejszym hardware. I na HAL nie bylo miejsca.

Zgadzam się w 100%. Tylko że wtedy (rok '90 +/- 4) nie było w
urządzeniach dotykowych wyświetlaczy lcd kolorowych, nie było ethernetu,
USB, kart SD. Wszystko było mocno ograniczone. Pewne zastosowania
wymagały żyłowania sprzętu, teraz byle nowszy procek za 15zł zrobi to
samo z użyciem 20% jego zasobów. Teraz każdy chce bezprzewodowo,
szyfrowane, kompatybilne z pozostałymi urządzeniami itd. Procesory się
zmieniają, są coraz lepsze, szybsze, tańsze i kto nie nadąży za tym
galopującym postępem zostanie w tyle, niezauważony.


--
Michał

[Zbych]

W dniu 11.10.2013 17:28, Sebastian Biały pisze:

> On 2013-10-11 08:43, Zbych wrote:
>>>> Słaby przykład, w gcc można zrobić destruktor w C.
>>> I wtedy mamy jaki język?
>> Jeśli pijesz do tego, że nie jest to czyste C, to argument jest
>> chybiony. Przerwań też nie masz w C (ani w C++).
>
> Rozróżnij:
>
> a) implementacje funckjonalności od idiomu RAII.

A ty spróbuj rozróżnić krytykę przykładu, od krytyki idei.

> b) implementacje w C++ od impelmentacji w "czymś" nieprzenośnym.

To coś nieprzenośne ma taką samą przenośność jak gcc, czyli i tak sporą.

> ad a) Muszę wypełnić idiom RAII jakimś kodem, cli/sei nadawało się
> najlepiej.
>
> ad b) Pisanie w wynalazkach kończy się nieprzenosnym kodem, a na
> horyzoncie sprintem zapierd... clang.

Clang i tak powoli implementuje różne wynalazki z gcc, bo jest ciśnienie
na kompilowanie tym kernela, który nie stroni od różnych rzeczy
specyficznych dla gcc.

[AlexY]

Użytkownik Sebastian Biały napisał:

Sens jest, ale nakład pracy niewspółmierny zwłaszcza że są to obecnie
produkty na rok góra 2 a nie 10 jak dawniej. Widzę taki głupi trend w
komórkach że nawet poprawek się unika bo produkt przechodzi phase out
szybciej niż cykl wprowadzenia poprawki. A pamiętam sprzed bodaj 8 lat
SE T68i gdzie po zmianie parametrów sieci operatora (chyba era)
wypuszczono nowy soft i był wgrywany na koszt producenta mimo że model
już dawno był po gwarancji i nie produkowany.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

[Michał Lankosz]

W dniu 2013-10-11 14:49, Sylwester Łazar pisze:
> W C przenosimy kod, mając nadzieję, że on się skompiluje po prostu innym
> kompilatorem i na dodatek będzie działał.

W przypadku kompilatorów asemblera jest dużo gorzej. Przynajmniej było
jak pisałem na '51 w asemblerze.

--
Michał