NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - PIC czy AVR? Doświadczenia z kompilatorami HiTech i GCC w programowaniu uC
Goto page Previous 1, 2, 3 ... 8, 9, 10 ... 14, 15, 16 Next
Mario
Guest
Guest
Sun Apr 06, 2014 9:46 pm
W dniu 2014-04-06 23:01, AlexY pisze:
Quote:
Użytkownik Mario napisał:
W dniu 2014-04-06 19:46, AlexY pisze:
Użytkownik Pszemol napisał:
"AlexY" <alexy@irc.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
W dniu 2014-04-06 19:46, AlexY pisze:
Użytkownik Pszemol napisał:
"AlexY" <alexy@irc.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"
Quote:
[..]
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żę ;
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ć.
Quote:
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 4
, 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.
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 4
, 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.
Quote:
[..]
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.
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 :)
Quote:
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
Sylwester Ĺazar
Guest
Guest
Sun Apr 06, 2014 9:53 pm
Quote:
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),
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.
Mario
Guest
Guest
Sun Apr 06, 2014 9:59 pm
W dniu 2014-04-06 22:49, AlexY pisze:
Quote:
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.
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
Pszemol
Guest
Guest
Sun Apr 06, 2014 10:00 pm
"janusz_k" <Janusz_kk@o2.pl> wrote in message news:op.xdwtndean0u1o8@moj...
Quote:
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 ?
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.
Quote:
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.
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...
Quote:
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.
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.
Quote:
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.
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?
Quote:
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ć.
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...
Quote:
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.
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.
Quote:
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?
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.
Quote:
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.
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?
Pszemol
Guest
Guest
Sun Apr 06, 2014 10:04 pm
"Dariusz Dorochowicz" <_dadoro_@wp.com> wrote in message
news:lhsajs$8r1$1@node2.news.atman.pl...
Quote:
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ść.
Ż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ż.
Quote:
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.
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.
Mario
Guest
Guest
Sun Apr 06, 2014 10:23 pm
W dniu 2014-04-06 23:53, Sylwester Łazar pisze:
Quote:
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.
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.
Quote:
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?
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
Mario
Guest
Guest
Sun Apr 06, 2014 10:26 pm
W dniu 2014-04-06 23:53, Sylwester Łazar pisze:
Quote:
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ś.
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.
Quote:
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?
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
Marek
Guest
Guest
Sun Apr 06, 2014 10:26 pm
On Sun, 6 Apr 2014 23:16:52 +0200, Sylwester Łazar<info@alpro.pl>
wrote:
Quote:
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.
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
Mario
Guest
Guest
Sun Apr 06, 2014 10:27 pm
W dniu 2014-04-07 00:04, Pszemol pisze:
Quote:
"Dariusz Dorochowicz" <_dadoro_@wp.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ż.
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
Pszemol
Guest
Guest
Sun Apr 06, 2014 10:32 pm
"Michał Baszyński" <mbaszyns@ga.ze.ta.pl> wrote in message
news:lhsbpl$l8t$2@dont-email.me...
Quote:
W dniu 2014-04-06 17:34, Dariusz Dorochowicz pisze:
Wśród ARMów są też układy z małą ilością nóg.
:)
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.
LPC81x - na Farnellu od 4,5zł
Wśród ARMów są też układy z małą ilością nóg.
:)
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.
LPC81x - na Farnellu od 4,5zł
No ale LPC810 to taki scalak dla Sylwestra, aby sobie
pisał w asemblerze i liczył instrukcje... 4k flash i 2k ram.
Marek
Guest
Guest
Sun Apr 06, 2014 10:35 pm
On Sun, 6 Apr 2014 22:06:19 +0000 (UTC), gof@somewhere.invalid (Adam
Wysocki) wrote:
Quote:
Autor tej lektury chyba porównywał starszą arch. pic14 z avr zamiast
pic16.
--
Marek
Sylwester Ĺazar
Guest
Guest
Sun Apr 06, 2014 10:55 pm
Quote:
No ale LPC810 to taki scalak dla Sylwestra, aby sobie
pisał w asemblerze i liczył instrukcje... 4k flash i 2k ram.
pisał w asemblerze i liczył instrukcje... 4k flash i 2k ram.
Dziękuję za uznanie.
Tylko do swojego notebooka go nie wstaw,
bo będzie się budził 2 lata.
S.
Sylwester Ĺazar
Guest
Guest
Sun Apr 06, 2014 11:04 pm
Quote:
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.
potrzebne jest skomplikowane środowisko (SO) które nie jest w stanie
uruchomić się w 50ms a potrzebuje do tego grube dziesiątki sekund.
Powoli nabieram respektu.
Oczywiście SO jest warunkiem koniecznym i bezdyskusyjnym.
Quote:
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.
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.
Czyli w wojsku, lotnictwie, aparaturze medycznej po prostu nie zdają sobie
sprawy
ze złożoności i komplikacji itd. itp.
Ciekawe, jak oni tam z tym złożonym systemem operacyjnym działają,
czekając 15 sekund, aż system będzie gotowy do odpalenia rakiety :-)
- Panie pułkowniku Leci na nas rakieta!
- Spokojnie kapralu. Naciśnijcie guziczek, odczekamy 15 sekund, a pot
...................
...................
Pszemol
Guest
Guest
Sun Apr 06, 2014 11:05 pm
"Sylwester Łazar" <info@alpro.pl> wrote in message
news:lhsh2g$7u2$1@mx1.internetia.pl...
Quote:
Mój laptop ASUSa pracujący pod kontrolą MS Windows 7
wstaje z trybu uśpienia w 15-16 sekund...
Aaa... uśpienia!
Właściwie miałem na myśli hibernację...
Zagalopowałeś się... Inaczej startowałby może 45-55 sekund.
I startowałby z pustym pulpitem, a ja chce zachować stan pracy.
Nie ja.
Czyli podsumujmy fakty:
1) Ja uważam, że uśpienie/hibernacja to protezy, aby móc szybciej
korzystać
z kiepskiego oprogramowania po włączeniu urządzenia.
wstaje z trybu uśpienia w 15-16 sekund...
Aaa... uśpienia!
Właściwie miałem na myśli hibernację...
Zagalopowałeś się... Inaczej startowałby może 45-55 sekund.
I startowałby z pustym pulpitem, a ja chce zachować stan pracy.
Nie ja.
Czyli podsumujmy fakty:
1) Ja uważam, że uśpienie/hibernacja to protezy, aby móc szybciej
korzystać
z kiepskiego oprogramowania po włączeniu urządzenia.
Zgoda,
z tym że wspomnianym wyżej faktem jest że Ty tak uważasz
a nie jest faktem że hibernacja to proteza
To tylko Twoja *opinia*.
Quote:
2)bo producent oprogramowania po 20 latach doświadczeń,
po prostu nie umie tego zrobić, aby po naciśnięciu przycisku,
procesor z zegarem 1GHz= 1 000 000 000Hz,
zdążył wykonać swój program pokazujący obraz taki jak ostatnio
w czasie 16 sekund.
po prostu nie umie tego zrobić, aby po naciśnięciu przycisku,
procesor z zegarem 1GHz= 1 000 000 000Hz,
zdążył wykonać swój program pokazujący obraz taki jak ostatnio
w czasie 16 sekund.
No jak to nie umie, skoro umie - właśnie to robię.
Nazywa się to hibernacja. Polega na zatrzymaniu działania programów,
zamrożenie wszystkiego z pamięci DRAM do pliku na dysku i wyłączeniu
zasilania. Ponowne uruchomienie powoduje odczytanie zawartości DRAM
i "odmrożenie" zamrożonych wcześniej aplikacji w stanie w jakim
zostały zamrożone... Oczywiście upraszczam, bo jeszcze trzeba hardware
poinformować że idziemy spać ale z grubsza na tym to polega.
Quote:
2) "Ty" (a nie producent) uważasz, że to fajne, bo możesz zaoszczędzić 30
s
z tych powiedzmy 45 sekund.
s
z tych powiedzmy 45 sekund.
To jest punkt 3 czy może 2a?
Quote:
3) I uważasz, że 45 sekund to mało.
Nie wmawiaj mi czegoś, czego nie napisałem.
Napisałem, że 45 sekund to mniej niż te kilka minut jakie wcześniej
sugerowałeś.
Quote:
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.
napisany zwięźle, to mógłby się włączyć po 50ms od włączenia
urządzenia i być gotowy do pracy.
Naprawdę?
A te 50ms od włączenia to wyliczyłeś jakoś czy może to tylko
taka formuła retoryczna którą trzeba interpretować jako
bliżej nieokreślone "krótko od włączenia"? :-)
Bo obawiam się że przetestowanie DRAM, enumeracja magistrali USB,
zainicjowanie Ethernetu i komunikacja z serwerem DHCP aby uzyskać
aktualny adres IP z sieci zajmnie Ci dużo więcej niż te 50ms od włączenia.
I jest to podyktowane wyłącznie samą budową sprzętu i protokołów.
Quote:
5) Jeśli, aby zrealizować pkt. 4 potrzeba by było, aby napisać kod na
poziomie ASM, to bym tak zrobił. np. dlatego, że kompilatory C
były marne w latach 1995-2014.
poziomie ASM, to bym tak zrobił. np. dlatego, że kompilatory C
były marne w latach 1995-2014.
Co robiłeś Miszczu Złoty w latach gdy Gates robił kasę na MS-DOS
i MS Windows??? Czemu nie zbijałeś kasy na swoim osie?
Quote:
No to teraz mi powiedz:
a) dlaczego uważasz się, że hibernacja 15 sekundowa jest lepsza niż
uruchomienie urządzenia w 50 ms?
a) dlaczego uważasz się, że hibernacja 15 sekundowa jest lepsza niż
uruchomienie urządzenia w 50 ms?
Emocje Ci zalewają mózg i nie myślisz klarownie...
Gdzie ja napisałem że "uważam się" że hibernacja jest lepsza od 50ms startu?
Taki 50msekundowy start byłby świetny... mam podobny tylko nie od
power off tylko ze stanu "sleep", gdzie mój pecet gasi tylko LCD
i zatrzymuje dysk twardy :-)
Quote:
b) dlaczego nie wymienisz procka na 10x szybszy,
skoro tak bardzo chcesz zaoszczędzić 30 sekund?
skoro tak bardzo chcesz zaoszczędzić 30 sekund?
Skoro jak bardzo?
Hibernacja to ficzerek systemu operacyjnego od Gatesa.
Nic mnie nie kosztuje kasy włączenie go, w przeciwieństwie
do zakupu 10x szybszego procesora, jeśli taki produkują...
A mam laptop ASUSa A47U na procku i7 - byłoby mi ciężko
znaleźć 10x szybszy procesor do tego lapka.
Pszemol
Guest
Guest
Sun Apr 06, 2014 11:19 pm
"Sylwester Łazar" <info@alpro.pl> wrote in message
news:lhs95p$cup$1@mx1.internetia.pl...
Quote:
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?
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?
Dokładnie na tym właśnie polega hibernacja o której pisałem wcześniej.
elektroda NewsGroups Forum Index - Elektronika Polska - PIC czy AVR? Doświadczenia z kompilatorami HiTech i GCC w programowaniu uC