W dniu 2014-04-06 19:51, Sylwester Łazar pisze:
>>> Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
> co
>>> stworzył, a to w sumie tak jakbyś od razu w asm pisał.
> Gdyby nie słowo "raczej", Twoje zdanie byłoby kompletną bzdurą.
> Obok masz przykład.
> Po podaniu kompilacji przez kolegę - po minucie widzę błędy w kodzie
> mikrokontrolera,


Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
oczekiwaniami.


--
pozdrawiam
MD

do góry

> Ceny pamięci DDR2 SA znacznie wyższe niż pamięci DDR3. Według twojej
> logiki nie ma popytu na pamięci DDR3 i dlatego producenci muszą zjeżdżać
> z ceny.
Rynek.
Ceny to możesz sobie kształtować w korporacjach AB czy KOMPUTRONIK.
Allegro jest bezlitosne.
Próbowałeś dokupić większą pamięć DDR2 do starszego komputera?
Dużo ludzi tak chce. I stąd wyższa cena.

> Przecież są takie. Nawet w DIP. LPC810 za 4,47 zł. Aha, dlatego takie
> tanie bo nikt ich nie chce. Dziwne, przecież mają jeden UART i 8 nóżek :(
2x droższy niż PIC12Fxxx.
Tak to nie działa.
Poza tym nie wiedziałem, że jest taki LPC810.
Dzięki.

> A poza tym sarkazm zupełnie niepotrzebny. Nie mów, że nie nie pisałeś
> programu w którym stosowałeś tylko jeden ADC czy PWM a procek miał ich
> do dyspozycji 10 czy 4.
Teraz tak robię.
S.

do góry

> Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
> jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
> oczekiwaniami.
Dla Ciebie może i nie.
Dla mnie błąd.

Idziesz w Hotelu na śniadanie i masz szwedzki stół, wliczony zresztą w cenę.
Jest tam wszystko:
jaja, szynka, owoce, sałatki, ryby, kawa, herbata, ciastko, po prostu w domu
w lodówce masz mniej.
Wybierasz grzankę i z samowaru nalewasz wodę.
Potem idziesz do pracy i po paru godzinach, w przerwie lecisz do biedronki i
kupujesz bułę i parówkę.

To jak to nazwiesz?
Błąd to mało powiedziane.
Mi sie wydaje, że to głupota.
S.

do góry

W dniu 2014-04-06 17:34, Dariusz Dorochowicz pisze:
> W dniu 2014-04-06 13:17, Pszemol pisze:
>>
>> OK, czyli nic nadzwyczajnego czego nie miałby typowy
>> 32-bitowy Cortex M3 czy M4 z ARMa do kupienia za 20zł.
>
> Oczywiście :)
> Tyle, że za taką XMegę płacę jednak sporo mniej, szczególnie biorąc pod
> uwagę "dodatki" typu wielkie złącze JTAGa w ARMie (koszt PCB, a raczej
> zajmowanego miejsca też jest ważny). Tak, wiem że nie musi być aż tak
> duże bo połowa to masy, a i resztę można ograniczyć.

Żartujesz, prawda? STM32 mają SWD. Inne pewnie też, ale nie znam.
Wystarczą cztery żyły (a może i trzy): dane, zegar, masa i Vcc. STM32:
kupujesz najtańszy STM32F0Discovery za niecałe 50zł i masz pełnoprawny
programator debugger wszystkich układów STM32 (wszystkie cortexy). Do
tego działa OpenOCD i w Eclipse debugujesz bez ograniczeń wielkości
kodu. Oczywiście ST-Link szybkością nie grzeszy, ale kilka sekund na
załadowanie kodu 50kB można poczekać. W przypadku NXP jest podobnie.
Czyli do zaprogramowania potrzebujesz _mniej_ miejsca na PC niż dla ISP
AVRów, tyle samo co w PDI ATxmega, ale masz jeszcze debugowanie!


> Marzy mi się ARM 8-16 nóg. Dostępny oczywiście u nas i programowany
> "byle czym", w sensie kompilatora i programatora ;)
> Z tym, że nóg może mieć więcej.

SSOP20 może być?
STM32F030F4P6, 4,69zł brutto w detalu, koło $0,5 przy 1000szt.
Ma boot loader przez UART. Pewnie Flash Loader od ST go obsługuje, a
może są i jakieś inne programy (do STM32F103 używałem chiński MCUISP
http://www.mcuisp.com/English%20mcuisp%20web/ruanjia
nxiazai-english.htm,
może inne też obsłuży). Ale i tak uważam, że obecnie SWD przebija zabawę
z UARTem.


--
Michał

do góry

Użytkownik Mario napisał:
> W dniu 2014-04-06 19:51, Sylwester Łazar pisze:
>>>> Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
>> co
>>>> stworzył, a to w sumie tak jakbyś od razu w asm pisał.
>> Gdyby nie słowo "raczej", Twoje zdanie byłoby kompletną bzdurą.
>> Obok masz przykład.
>> Po podaniu kompilacji przez kolegę - po minucie widzę błędy w kodzie
>> mikrokontrolera,
>
>
> Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
> jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
> oczekiwaniami.

Kiedy procek ma jakieś time critical tasks to takie "nieoptymalne
rozkazy" stają się błędami które trzeba nadgonić szybszym procem albo
ręcznie poprawić w asm.


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

do góry

On Sun, 6 Apr 2014 19:17:31 +0200, Sylwester Łazar<i...@a...pl>
wrote:
> Aaa... uśpienia!
> A po co to uśpienie?
> Bo inaczej ładowałby się ile czasu?

Zastanawiam czy świadomie trolujesz, czy faktycznie nie masz pojęcia
po co uśpienie i dlaczego (w kontekście w jakim pisał Przemol) nie
ma ono nic wspólnego z ładowaniem się czegokolwiek.

--
Marek

do góry

W dniu 2014-04-06 19:46, AlexY pisze:
> Użytkownik Pszemol napisał:
>> "AlexY" <a...@i...pl> wrote in message
> [..]
>>> 1. Chcę wiedzieć co program robi a nie analizować i poprawiać błędy
>>> kompilatora, zwłaszcza że co kompilator to inaczej program złożony.
>>
>> Jakie błędy kompilatora chcesz poprawiać?? To jakieś mity.
>
> Odpisałem w poście do Mario

W którym miejscu bo jakoś nie zapamiętałem nic konkretnego.

>
>>> 2. ASM rozumiem, C C++ i pochodne to dla mnie sieczka stworzona żeby
>>> wyrwać kasę na szkolenie specjalistów, bardzo lubiłem basic'a, jest
>>> przejrzysty, nie można było go rozbudować?
>>
>> Zostaw na chwilę C++, bo to trochę inna bajka, rzeczywiście, ale C,
>> stare dobre C, to właściwie asembler jest. To nie jest język wysokiego
>> poziomu. Jest właśnie bardzo krytykowany za "bliskość sprzętu".
>
> Tak też mi to przedstawiono, kłopot w tym że mam problem z akceptacją
> rzeczy nielogicznych, z tego powodu np liczby urojone w technikum zdałem
> ale nigdy ich nie zrozumiem, oraz nigdy nie będę politykiem.
>
>> Poza specyficznymi przypadkami pisanie dziś w asemblerze to jakieś
>> hobby tylko, hardcore zupełnie niepraktyczny.
>>
>> C/C++ to nie jest "sieczka" do wyrywania kasy - miliony programistów
>> go rozumie i używa na codzień. I wcale nie są geniuszami, więc może
>
> Bo muszą
>
>> nie dołuj się i po prostu poczytaj trochę podstaw od C a przekonasz się
>> że trochę wprawy i poradzisz sobie. Dużo Ci to pracy zaoszczędzi.
>
> Poleć jakąś książkę/kurs dla starego assemblerowca, do tej pory nikt nie
> dał mi wędki która idealnie leży mi w rękach :)

Chyba jesteś tak wybredny jak identyfikator. Jemu też żadna książka nie
pasuje.

> [..]
>> Nie bardzo więc widzę gdzie Ty widzisz trudność że w AVR zrobisz
>> płytkę samemu a do ARMa musisz mieć jakiegoś gotowca...
>
> Może to jakieś zabobony, ARM to dla mnie procesory wydajności średniej
> klasy PC, wysokie zegary, masa nóżek a najlepiej BGA, zwyczajnie nie na
> moje potrzeby, być może faktycznie cenowo to jest na poziomie 89C2051
> ale to tak jakbym do pracy dojeżdżał limuzyną z szoferem i obstawą 6
> ochroniarzy.

Zobacz procki NXP.
Od DIP8 przez SO (16, 20) , TSSOP (24), QFN (32 i 48), QFP (64, 80, 100,
144), do BGA. Większość obudów taka jakie są w ATMEGA.
RAM od 8 kB do 1MB, UARTy od 1 do 5 tak samo różna liczba PWM, ADC itp.
Zegar z reguły dość niski np 12MHZ, który jest powielany wewnętrznie do
50 czy nawet 200 MHz.


>>> 4. Czas pisania programu, to najbardziej mnie załamuje, prawda że asm
>>> zajmuje dużo czasu, ale błędy są wtedy moje a nie kompilatora. Załamka
>>> polega na tym że w imię przyśpieszenia programowania poświęca się
>>> jakość ale to niestety normalne w obecnych czasach, program napisany
>>> ze 3 razy szybciej wychodzi 2 razy większy i 5 razy wolniejszy, a do
>>> tego mimo że napisany prawidłowo zawiera błędy kompilatora, znane i
>>> nieznane.
>>
>> Te Twoje mityczne "błędy kompilatora" to chyba błędy programisty
>> piszącego nieumiejętnie w C... Na codzień piszę programy w C i C++
>> i z błędami kompilatorów nie mam do czynienia wcale.
>
> Błędy mogą objawiać się np przycięciem się programu w jakiejś pętli z
> której sam wyjdzie, tyle że zdecydowanie za dużo czasu mu to zajmie,
> takich rzeczy nie wyłapiesz jeśli nie robisz analizy asm.

Jeśli robisz coś bardzo wrażliwe czasowo to może być, że musisz ten
kawałek kodu zanalizować. Możesz go też napisać w asm. Ale to dotyczy
jakichś ułamków procenta kodu, np obsługi przerwań. Nie jest to powód
żeby całe np. prawie 100 kB kodu wynikowego pisać w asemblerze. U mnie
program składa się głównie z obliczeń, obsługi komunikacji, parsowania
poleceń itp. To co dla mnie wrażliwe czasowo (obsługa szybkich zdarzeń
na wejściu i praca z szybkimi przetwornikami i tak załatwiam w FPGA)


--
pozdrawiam
MD

do góry

W dniu 2014-04-06 20:34, Sylwester Łazar pisze:
>> Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
>> jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
>> oczekiwaniami.
> Dla Ciebie może i nie.
> Dla mnie błąd.
>
> Idziesz w Hotelu na śniadanie i masz szwedzki stół, wliczony zresztą w cenę.
> Jest tam wszystko:
> jaja, szynka, owoce, sałatki, ryby, kawa, herbata, ciastko, po prostu w domu
> w lodówce masz mniej.
> Wybierasz grzankę i z samowaru nalewasz wodę.

Ale czemu grzankę a nie chleb z szynką?
Można też iść do baru i pilnować żeby gryźć tylko kawałki po 16 gramów i
żuć każdy około 1500 milisekund popijając po 64 mililitry soku po
każdych 8 ugryzieniach chleba. Tak chyba je assemblerowiec.

> Potem idziesz do pracy i po paru godzinach, w przerwie lecisz do biedronki i
> kupujesz bułę i parówkę.
>
> To jak to nazwiesz?
> Błąd to mało powiedziane.
> Mi sie wydaje, że to głupota.

To jest już jakaś paralela całkiem oderwana od tego o czym dyskutujemy.
Ja w każdym razie nie widzę związku. Kod ma realizować algorytm. Wymóg
aby ten algorytm był do ogarnięcia przez programistę z dokładnością do
każdego cyklu maszynowego jest absurdalny, bo redukuje możliwe zadania
do jedynie prostych przypadków. Z reguły nie ma potrzeby mieć pewności,
że procedura wykona się w 121 cyklach maszynowych. Jeśli jest
konieczność żeby wykonała się możliwie szybko to wystarczy zaszyć ją w
tasku o wysokim priorytecie. Można też napisać krytyczny czasowo (mały
zazwyczaj) kawałek kodu w asm.


--
pozdrawiam
MD

do góry

> Zastanawiam czy świadomie trolujesz, czy faktycznie nie masz pojęcia
> po co uśpienie i dlaczego (w kontekście w jakim pisał Przemol) nie
> ma ono nic wspólnego z ładowaniem się czegokolwiek.
Czyli jak wyciągniesz w laptopie z Windowsem 7, baterię, włożysz na drugi
dzień i obudzisz - masz to samo
na ekranie co było wczoraj?
S.

do góry

W dniu 2014-04-06 20:39, AlexY pisze:
> Użytkownik Mario napisał:
>> W dniu 2014-04-06 19:51, Sylwester Łazar pisze:
>>>>> Błędów kompilatora raczej nie wyłapiesz, chyba że zaczniesz analizować
>>> co
>>>>> stworzył, a to w sumie tak jakbyś od razu w asm pisał.
>>> Gdyby nie słowo "raczej", Twoje zdanie byłoby kompletną bzdurą.
>>> Obok masz przykład.
>>> Po podaniu kompilacji przez kolegę - po minucie widzę błędy w kodzie
>>> mikrokontrolera,
>>
>>
>> Chyba jednak to nie był błąd tylko nieoptymalne rozkazy. Błąd jest wtedy
>> jeśli kod będzie działał błędnie czyli będzie dawał wyniki niezgodne z
>> oczekiwaniami.
>
> Kiedy procek ma jakieś time critical tasks to takie "nieoptymalne
> rozkazy" stają się błędami które trzeba nadgonić szybszym procem albo
> ręcznie poprawić w asm.
>
>

Możesz napisać je w asm i nadać im wysoki priorytet aby reszta kodu nie
blokowała ich wykonania. Ale zazwyczaj procedury krytyczne czasowo to
ułamek procenta całego kodu. To nie jest powód żeby wszystko rzeźbić w
assemblerze. Ja w każdym razie wyrosłem już z tego żeby w asm wyliczać
funkcje przez rozwijanie w szereg Taylora.

--
pozdrawiam
MD

do góry