Zalecane środowiska programistyczne dla PIC16F877A: opinie i darmowe opcje

Wed Oct 09, 2013 7:26 pm   

On 08.10.2013 22:42, stchebel@gmail.com wrote:

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

Wed Oct 09, 2013 7:46 pm   

On 2013-10-09 11:52, stchebel@gmail.com wrote:

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


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.

Wed Oct 09, 2013 8:26 pm   

On Wed, 09 Oct 2013 21:46:39 +0200, Sebastian
Biały<heby@poczta.onet.pl> wrote:

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

Wed Oct 09, 2013 9:32 pm   

On 10/9/2013 10:26 PM, Marek wrote:

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

Thu Oct 10, 2013 5:23 am   

On 2013-10-09 22:26, Marek wrote:

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


Czyli nie na pic tylko na mips.

Thu Oct 10, 2013 8:09 am   

On 10/10/2013 7:23 AM, Sebastian Biały wrote:


Pozdrawiam

Marek

Thu Oct 10, 2013 9:08 am   

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.

Thu Oct 10, 2013 3:19 pm   

On 2013-10-10 10:09, Marek Borowski wrote:

Mniej więcej w wersji lite.

Thu Oct 10, 2013 3:26 pm   

On 2013-10-10 11:08, Sylwester Łazar wrote:

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


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

Thu Oct 10, 2013 4:13 pm   

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

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

Thu Oct 10, 2013 4:18 pm   

On 2013-10-10 18:13, Zbych wrote:

I wtedy mamy jaki język?

Thu Oct 10, 2013 4:23 pm   

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



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.

Thu Oct 10, 2013 4:43 pm   

On 2013-10-10 18:23, JDX wrote:

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


Zdefiniuj najlepsze.


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.


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


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.


Pomyłka.


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.

Thu Oct 10, 2013 6:00 pm   

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.

Thu Oct 10, 2013 6:07 pm   

On 2013-10-10 18:43, Sebastian Biały wrote:

mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
też C++.


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


ma znaczącego (w sensie czasu wykonania) kodu.


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.


być chronione za pomocą CS. Tak, abym nie musiał snuć domysłów.