Zalecane środowiska programistyczne dla PIC16F877A: opinie i darmowe opcje

Fri Oct 11, 2013 6:43 am   

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

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

Fri Oct 11, 2013 6:56 am   

On Fri, 11 Oct 2013 00:53:30 +0200, Sebastian
Biały<heby@poczta.onet.pl> wrote:

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

Fri Oct 11, 2013 7:51 am   

Hello Marek,

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

[...]


Ale stać Cię na takich?


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

Fri Oct 11, 2013 8:18 am   

On Fri, 11 Oct 2013 09:51:52 +0200, RoMan Mandziejewicz
<roman@pik-net.pl.invalid> wrote:

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

Fri Oct 11, 2013 9:00 am   

Hello Marek,

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


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


:(

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

Fri Oct 11, 2013 9:59 am   

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

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

Fri Oct 11, 2013 10:53 am   

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


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

Fri Oct 11, 2013 11:13 am   

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.


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.

Fri Oct 11, 2013 11:21 am   

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

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ł

Fri Oct 11, 2013 12:11 pm   

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

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.

Fri Oct 11, 2013 12:49 pm   

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.


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.



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.

Fri Oct 11, 2013 1:05 pm   

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

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.


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ł

Fri Oct 11, 2013 1:23 pm   

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

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

--
Marek

Fri Oct 11, 2013 2:04 pm   

Spojrzałem na kolejne wersje projektu.
Ale to tak z przerwami.
BTW. To były akurat DS18B20.
--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.

Fri Oct 11, 2013 2:13 pm   

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

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.


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?


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



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.


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ł