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

--
-- .
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 Fri, 11 Oct 2013 11:59:22 +0200, Sylwester Łazar<i...@a...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

do góry

> 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

do góry

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ł

do góry

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.

do góry

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

do góry

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ł

do góry

On Fri, 11 Oct 2013 14:49:49 +0200, Sylwester Łazar<i...@a...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

do góry

> On Fri, 11 Oct 2013 14:49:49 +0200, Sylwester Łazar<i...@a...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
Od 4 marca do 4 kwietnia.
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.

do góry

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ł

do góry