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

do góry

> > 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.

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

do góry

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.

do góry

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ść.

do góry

W dniu 10.10.2013 17:26, Sebastian Biały pisze:
> 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!
> ...
> }

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

do góry

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?

do góry

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.

do góry

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.

do góry

> 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 :-)
--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.

do góry

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. :-)

do góry