W dniu 2014-04-06 23:01, AlexY pisze:
> Użytkownik Mario napisał:
>> W dniu 2014-04-06 19:46, AlexY pisze:
>>> Użytkownik Pszemol napisał:
>>>> "AlexY" <a...@i...pl> wrote in message
> [..]
>>>> 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.
>
> "Co do błędów kompilatorów nie podam konkretów bo ich nie mam, co jakiś
> czas gdzieś trafie na jakieś info że coś źle z kompilatora wychodzi ale
> nie kolekcjonuje tego, mam zakodowane że przy kompilatorach mój program
> z moimi błędami jest nakładany na cudzy program (kompilacja) z cudzymi
> błędami, tak jak piszesz trzeba być na bieżąco z danym kompilatorem aby
> znać i omijać jego bolączki. Przy ASMie trzeba być na bieżąco jedynie z
> erratą procka. "
>
> Nawet odpowiedziałeś na to

Czyli tak jak napisałem nie było nic konkretnego :) Hint:
"Co do błędów kompilatorów nie podam konkretów"

> [..]
>>> 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.
>
> Teraz to pojechałeś po bandzie... normalnie dałeś mi taką mokrą szmatą
> po myciu kibli w twarz.. chyba się obrażę ;>

Bo nie rozumiem takich pretensji :) Dla mnie jedyne książki z których
nic się nie da zrozumieć to książki Bieleckiego. Z reszty można się
nauczyć. A na styl pisania i umiejętności autora podręcznika
technicznego można narzekać w takim stopniu jak na styl pisania w
dataszicie układu. Ważne są jego funkcje i sposób stosowania. Po to się
jest inżynierem żeby nie grymasić tylko stosować wiedzę (np przykłady)
podawaną w źródle. I nie nauczysz się podczas lektury tylko poprzez
rozpoznanie w walce. Czyli próbując coś wykonać.

> Wiele ich nie przeglądałem, raczej kilka kursów on-line, nie mam parcia
> na C więc się nie zagłębiam aczkolwiek przy linuxie czasem by się przydał.
>
> [..]
>> 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.
>
> Brzmi sensownie.
> Powiem tak, teraz to nie, ale jak nadejdzie ten dzień kiedy będę musiał
> sięgnąć po coś mocniejszego czego w barku nie mam to się grupy poradzę
> co na chwilę obecną jest "na czasie" postęp jest taki że za rok wszystko
> może się wywalić do góry nogami.

Podałem przykłady z NXP, bo te najlepiej znam. Ale podobnie jest z STM.
Nawet w pewnym momencie rozważałem przejście na STM bo mieli szerszą
ofertę w Cortex M4 na który zamierzałem przejść. Więcej pamięci przy
mniejszych ilościach nóżek.


> [..]
>>> 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)
>
> Paaanie... ja nie ta liga... ja latawce strugam a Ty właśnie marsa
> kolonizujesz.

Bez przesady. Coś tam dłubię na najsłabszych Xilinxach - Spartan3. Ale
zamierzam wkrótce przejść na Spartan6 bo potrzebuję działań DSP do
szybkiej aproksymacji przebiegów. Ograniczeniem są tu niestety typy
obudów. Tylko dwa najsłabsze SPartan6 mają obudowę LQFP - 144 pinów.
Pozostałe to BGA, a na to nie jestem gotowy :)

>
>
> PS: Bardzo podoba mi się dyskusja prowadzona w tym wątku.

W sumie to takie advocacy się zrobiło. Albo inaczej mówiąc naparzanka :)
Ale może przy okazji parę osób dowiedziało się o innych możliwościach.


--
pozdrawiam
MD

do góry

> > No to teraz mi powiedz:
> > a) dlaczego uważasz się, że hibernacja 15 sekundowa jest lepsza niż
> > uruchomienie urządzenia w 50 ms?
>
> Przecież on nigdzie nie napisał ze woli uruchamianie w 15 sekund zamiast
> w 50ms. A przede wszystkim ty nigdzie nie wykazałeś, że jest możliwe
> napisanie na laptopa czy pc sensownego programu który będzie się
> uruchamiał wraz z urządzeniem w 50 ms.
Nie chciałbym stawiać Cię pod ścianą, ale tam było jeszcze pytanie b),
które nie wiedzieć dlaczego pominąłeś.
Moim zdaniem dużo istotniejsze.
Skoro program warto pisać, nie zważając na 40%-90% marnotrastwo czasu
procesora,
to dlaczego nie dać 10x szybszego, skoro to rozwiąże problem?
S.

do góry

W dniu 2014-04-06 22:49, AlexY pisze:
> Użytkownik Mario napisał:
>> W dniu 2014-04-06 20:17, AlexY pisze:
>>> Użytkownik Mario napisał:
>>>> W dniu 2014-04-06 18:14, AlexY pisze:
> [..]
>>>>> Tu jest sedno sprawy, uC to ściśle określony sprzęt, system operacyjny
>>>>> ma działać na całej rodzinie sprzętu, ponadto poziom komplikacji
>>>>> jednak
>>>>> przewyższa atmelkowe miganie diodką, na uC program napiszesz, produkt
>>>>> sprzedasz i możesz o nim zapomnieć,
>>>>
>>>> Tylko po co w takim razie argumentacja, że pisanie w c jest
>>>> niebezpieczne z powodu błędów kompilatora czy ogólnie mówiąc szybkie
>>>> tanie i kiepskie? Skoro kod skompilowany z c jest poprawny i stabilny w
>>>> routerach czy w serwerach to czemu miałby być niepoprawny w przypadku
>>>> atmelkowego migania LEDem?
>>>
>>> Nie wiem w czym windows jest pisany ale daleko mu do bycia stabilnym.
>>> Linuxa ciężko ale też da się wywalić.
>>
>> Weź pod uwagę, że te systemy działają na bardzo szerokiej platformie
>> sprzętowej z obcymi sterownikami i na nich chodzą z kolei tysiące lepiej
>> czy gorzej napisanych programów
>
> Czyż nie to właśnie napisałem powyżej? To jest słuszny argument użycia
> języka wysokiego poziomu, w uC argumentem jest czas pisania programu i
> to uważam za niewłaściwe.

Czas wdrożenia produktu jest jednym z istotniejszych parametrów. Produkt
ma możliwie szybko uzyskać postać gotową do sprzedaży i zarobić na
programistę i innych biorących udział w produkcji. Nie musi być
najdoskonalszy na świecie, pozbawiony nadmiarowych instrukcji. Ma
realizować swoje zadanie i być bezawaryjny. Dla mnie błąd w kodzie jest
wtedy gdy urządzenie nie działa zgodnie z przeznaczeniem lub jest
awaryjne (np podatne na zakłócenia). Nie sądzę żeby był gorszy przyrząd
z prockiem, który 90% czasu krąży w pustej pętli, a przez 100 ms
realizuje zadanie (a mógłby realizować 65 ms gdyby był w asm), od
przyrządu, który ma procek wytężony na 95% ale napisany przez wybitnego
fachowca w asm (bo pisany w c by się w tym procku nie zmieścił albo nie
wyrabiał by czasowo).


--
pozdrawiam
MD

do góry

"janusz_k" <J...@o...pl> wrote in message news:op.xdwtndean0u1o8@moj...
>> Wybierasz takiego ARMa który ma to, co potrzebujesz.
>> I co się zwykle okazuje, że ma wydajność 10 razy większą
>> niż 8-bitowiec w tej samej cenie.
> Tylko po co? żeby młócił powietrze w delay ?

Nie ma powodu aby młócił powietrze, możesz go uśpić jak
nie potrzebujesz procesora - przerwanie od portu lub licznika
Ci go obudzi...

A zapas mocy przyda Ci się choćby po to, aby nie przejmować
się jakimiś drobnymi nieefektywnościami kodu generowanego
przez kompilator i zamiast dłubać coś godzinami w asemblerze
napisać coś w pięć minut w C.

>> Zrozum, ceny procesorów 8-bitowych dzisiaj są nadmuchane.
> Wiesz sam dobrze że cena to kwestia popytu sprzedaży a nie złozoności
> układu.
>
>> Dlaczego są nadmuchane? Bo producenci trzymają Cię w garści.
>> Płacisz jak za zboże bo musisz. Musisz, bo tylko te znasz...
> Mylisz się niczego nie muszę, są wygodne, bo np małe 51 się gorzej
> programuje.

Musisz bo nie że mógłbyś małe 51 tylko musisz bo nie umiesz ARMa,
którego też się wygodnie programuje a kosztuje tyle co mały 51 i ma
10x więcej mocy, portów, liczników 32-bitowych, UARTów, Ethernet,
parę portów USB i jeszcze sterownik wyświetlacza LCD lub eInk...

>> Tylko tego proca zastosujesz jak mniejszy Ci okaże się za mały.
>> Producent wie, że przesiadka na inną rodzinę to koszty zaporowe
> Eee przesadzasz, cała rodzina avr-ów jest spójna, piszę w c i przejście na
> większy nie stanowi żadnego problemu.

Największy AVR sięga Cortexowi do pięt... albo do kostek conajwyżej.

>> i dlatego ustawia takie ceny na procki 8-bitowe bo jeszcze jest
>> na nie jako taki popyt.
>>
>> To jest analogia jak z pamięciami DDR czy starymi prockami do
>> pecetów... Ceny DDR2 o tej samej pojemności sa WIĘKSZE niż
>> ceny szybszych DDR3 - Ceny szybszych procków i3 są takie same
> Nie ma analogii, nie porównuj rynku konsumenckiego z hobbystycznym.

Czemu nie? Ja tą analogię widzę. Ty nie widzisz?

>> No to samo masz w ARMach... nie widze tu żadnej rewelacji.
> Może, pdf-y są tak kiepsko napisane że nie doczytałem, army chcą dogodzić
> wszystkim i nawpierdalali tam wszystkiego skolko ugodno, tak że trudno się
> w tym połapać.

Tak jak napisał Ci Sylwester obok - nie potrzebujesz ADC - nie włączasz go.
Od początku, od resetu nie działa, nie marnuje prądu.
Niby masz a tak jakby go nie było...

>>>> na pokładzie czas AVRów jest policzony
>>> Mylisz się, wcale nie jest policzony. Dla początkujących to s ą idealne
>>> procki stosunkowo proste do opanowania i zaprogramowania.
>>
>> Dla początkujących... i potem co? Zainwestujesz czas w naukę
>> a potem zmiana i od nowa będziesz się uczył od początku?
> A czego się uczyć od początku? to tam inny c jest?
> trzeba tylko peryferia ogarnąć i tyle.
> Nie taki straszny arm tyle że w 99% zbędny.

Uczyć się rodziny procesora, jego możliwości, jego specyfiki,
jego rejestrów kontrolnych, tego co on umie a czego nie umie...
Oswoić się też warto z bibliotekami, narzędziami do tworzenia
kodu (środowisko), sposobem programowania/debuggowania itp.

>> To jest bez sensu - jak już robisz inwestycję czasu i gromadzisz wiedzę
>> to lepiej uczyć się procesorów z dużej rodziny i dziś popularnej a nie
>> procesorów popularnych 20-30 lat temu wychodzących dziś z użycia.
> Ale bajdurzysz, avr powstał 30 lat temu? :)

Może 20. Wrzuciłem go do jednego wora z PICem, 8051 i ich klonami.

>> w tej logice?
> Może daruj sobie te porównania.
>
>
>> :-)
>>
>> Naprawdę nie ma się czego bać ARMów.
> Ale ja się ich nie boję, nawet mam takiego na biurku z wyświetlaczemn
> i peryferiami.

Ciekawe czemu tego wyświetlacza nie podłączyli do jakiegoś AVRa, co?

do góry

"Dariusz Dorochowicz" <_...@w...com> wrote in message
news:lhsajs$8r1$1@node2.news.atman.pl...
> W dniu 2014-04-06 20:34, Michał Lankosz pisze:
>
>> Ż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
>
> OK, SWD jest (wg opisu 4 piny plus zasilania), ale standardu małego złącza
> (mniej niż 10 pinów) nie widziałem (fakt, zbyt długo jeszcze nie
> szukałem), a warto byłoby tak do sprawy podejść.

A po co Ci jakiś standard? Wstawisz w płytkę dziurki pod goldpiny i już.

> No to wygląda, że trzeba się dokładniej przyglądać. Początek oznaczenia
> mnie niepokoi - jakoś nie za bardzo mam zaufanie do tej firmy jeżeli
> chodzi o ARMy (od czasu STR912), ale grunt że jest początek.

Ja używam kostek od NXP.

do góry

jacek pozniak <j...@f...pl> wrote:

> No właśnie. Wydaje mi się, że avr-gcc jest bliższy poprawnie działającemy
> softowi.

To nie do konca tak...

Fakt, ze opisanych problemow nie mialem na avr-gcc, ale ogolnie i AVR-y i
PIC-e maja swoje zalety i wady. O PIC-ach tylko czytalem, a na wady AVR-ow
natknalem sie w praktyce.

Ciekawa lektura:

http://www.electricstuff.co.uk/picvsavr.html

Ale fakt, ze na kompilator nigdy nie moglem narzekac.

--
SELECT finger FROM hand WHERE id = 3;
http://www.chmurka.net/

do góry

W dniu 2014-04-06 23:53, Sylwester Łazar pisze:
>>> No to teraz mi powiedz:
>>> a) dlaczego uważasz się, że hibernacja 15 sekundowa jest lepsza niż
>>> uruchomienie urządzenia w 50 ms?
>>
>> Przecież on nigdzie nie napisał ze woli uruchamianie w 15 sekund zamiast
>> w 50ms. A przede wszystkim ty nigdzie nie wykazałeś, że jest możliwe
>> napisanie na laptopa czy pc sensownego programu który będzie się
>> uruchamiał wraz z urządzeniem w 50 ms.

Ale według mnie to jest bardziej istotne. Nigdzie nie wykazałeś, że jest
możliwe napisanie takiego programu startującego w 50 ms. Więc punkt b
jest bez sensu.

> Nie chciałbym stawiać Cię pod ścianą, ale tam było jeszcze pytanie b),
> które nie wiedzieć dlaczego pominąłeś.
> Moim zdaniem dużo istotniejsze.
> Skoro program warto pisać, nie zważając na 40%-90% marnotrastwo czasu
> procesora,
> to dlaczego nie dać 10x szybszego, skoro to rozwiąże problem?

Bo nie ma takich procków? To znaczy pewnie są, ale nie opłaca się ich
stosować w urządzeniach mających kosztować między 1,5 a 4 kpln.
Ale też pytanie dlaczego nie ma takich programów jak Windows i użytkowy
soft na niego, ale napisanych w asm i startujących w 50ms zamiast w 30
sekund. Bo kosztowałyby 20 razy więcej niż teraz, a startowałyby np w 15
sekund czy ewentualnie 10 zamiast 30, a nie w 50 ms. Nikt nie zapłaci
za nie ogromnych pieniędzy po to żeby były trochę szybsze.




--
pozdrawiam
MD

do góry

W dniu 2014-04-06 23:53, Sylwester Łazar pisze:
>>> No to teraz mi powiedz:
>>> a) dlaczego uważasz się, że hibernacja 15 sekundowa jest lepsza niż
>>> uruchomienie urządzenia w 50 ms?
>>
>> Przecież on nigdzie nie napisał ze woli uruchamianie w 15 sekund zamiast
>> w 50ms. A przede wszystkim ty nigdzie nie wykazałeś, że jest możliwe
>> napisanie na laptopa czy pc sensownego programu który będzie się
>> uruchamiał wraz z urządzeniem w 50 ms.
> Nie chciałbym stawiać Cię pod ścianą, ale tam było jeszcze pytanie b),
> które nie wiedzieć dlaczego pominąłeś.


Ale według mnie to jest bardziej istotne. Nigdzie nie wykazałeś, że jest
możliwe napisanie takiego programu startującego w 50 ms.

> Nie chciałbym stawiać Cię pod ścianą, ale tam było jeszcze pytanie b),
> które nie wiedzieć dlaczego pominąłeś.
> Moim zdaniem dużo istotniejsze.
> Skoro program warto pisać, nie zważając na 40%-90% marnotrastwo czasu
> procesora,
> to dlaczego nie dać 10x szybszego, skoro to rozwiąże problem?

Bo nie ma takich procków? To znaczy pewnie są, ale nie opłaca się ich
stosować w urządzeniach mających kosztować między 1,5 a 4 kpln.
Ale też pytanie dlaczego nie ma takich programów jak Windows i użytkowy
soft na niego, ale napisanych w asm i startujących w 50ms zamiast w 30
sekund. Bo kosztowałyby 20 razy więcej niż teraz, a startowałyby np w 15
sekund czy ewentualnie 10 zamiast 30, a nie w 50 ms. Nikt nie zapłaci
za nie ogromnych pieniędzy po to żeby były trochę szybsze.



--
pozdrawiam
MD

do góry

On Sun, 6 Apr 2014 23:16:52 +0200, Sylwester Łazar<i...@a...pl>
wrote:
> 4)Ja z kolei uważam, że gdyby program obsługujacy urządzenie był
napisany
> zwięźle,
> to mógłby się włączyć po 50ms od włączenia urządzenia i być gotowy
do pracy.

Współczesne "programy" są na tyle złożone, że do ich uruchomienia
potrzebne jest skomplikowane środowisko (SO) które nie jest w stanie
uruchomić się w 50ms a potrzebuje do tego grube dziesiątki sekund.
To pierwsze. Po drugie, właśnie po to jest hibernacja czy uśpienie
aby procesu uruchamiania nie wywolywac, bo po co? "Program" ma
wznowić działanie tam gdzie się go zatrzymało.
Sugerowanie, że należałoby by pisać programy i so w asm to by były
szybsze i uruchamiały się w 50ms jest niedorzeczne. Zdradza jedynie
to, że autor takiego pomysłu nie zdaje sobie sprawy z złożoności i
komplikacji współczesnego so, czy nawet współczesnych aplikacji
które robią trochę bardziej skomplikowane rzeczy niż miganie ledami
czy sortowanie tablicy liczb.

--
Marek

do góry

W dniu 2014-04-07 00:04, Pszemol pisze:
> "Dariusz Dorochowicz" <_...@w...com> wrote in message
> news:lhsajs$8r1$1@node2.news.atman.pl...
>> W dniu 2014-04-06 20:34, Michał Lankosz pisze:
>>
>>> Ż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
>>
>> OK, SWD jest (wg opisu 4 piny plus zasilania), ale standardu małego
>> złącza (mniej niż 10 pinów) nie widziałem (fakt, zbyt długo jeszcze
>> nie szukałem), a warto byłoby tak do sprawy podejść.
>
> A po co Ci jakiś standard? Wstawisz w płytkę dziurki pod goldpiny i już.

Można użyć takich z rastrem 1,25. złącze 2*5 zajmuje bardzo mało
miejsca. Do SWD wystarczyłoby dać 2*2.


--
pozdrawiam
MD

do góry