Fakty są takie, że nawigacja napisana w całości w asemblerze po pierwsze nie pracowałaby na tej samej baterii 24*7 razy dłużej a po drugie kosztowałaby tyle że mało kto byłby nią zainteresowany...
Już to widzę jak taki Garmin czy innny TomTom co dziś zleca pisanie softu w Indiach programistom C++ każe pisać ten sam kod w asemblerze aby mniej prądu pobierał... Ech... poza tym - w takich urządzeniach najwięcej prądu bierze wyświetlacz i jego podświetlenie - procesor idzie w uśpienie dosyć często i nie jest głównym konsumentem prądu z baterii.
Nic nie pisałem, że Kernighana czytałem w oryginale. Jest polski przekład. Jest sporo podręczników do c, tłumaczonych z angielskiego lub napisanych przez polskich autorów.
Ja tak właśnie nie podchodzę. Ale wydaje mi się że ci co się trzymają asemblera niestety są przez to często zmuszeni do pracy z prockami w których ledwo się mieszczą.
Zazwyczaj operując w ramach jednej rodziny. Przejście na coś całkiem innego boli. Sam przechodziłem z 51 na AVR i szybko stwierdziłem, ze wgryzanie się w pisanie w asm wymaga ode mnie dużo wysiłku. Po jednym małym projekcie wolałem się nauczyć c i kilka projektów zrobiłem w AVR-gcc. Przejście z c na AVR do c na ARM było już znacznie łatwiejsze. Podejrzewam, że ci co upierają się przy asm, z oporami sięgają po bardziej złożone architektury twierdząc, że to co mają w zupełności im wystarcza.
Twój wybór. Możesz korzystać z pracy społeczności na zdefiniowanych przez nią warunkach albo pisać wszystko sam. Naprawdę każdy musi sam wymyślać stos TCP, albo obsługę HD44780?
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?
Jakoś nie robią tego na Basicu. Widocznie c jest do tego lepszy.
Pewnie ARM jest lepszy od innych, może nawet najleszy.
Ale mnie to nie bardzo rusza; mi jest potrzebne coś co łyknie skompilowany kod w jęz C i będzie działało, może być 8,16 czy też 32 bitów; co mnie to interesuje, niech kompilator się tym martwi. Na chwilę obecną wystarcza mi coś co ma 2XUART, SPI, 64kB ROM i kilka KB. Prawdę mówiąc jeśli dzisiaj byłby popularny HD64180 (rozbudowany klon Z-80) to bym go użył.
Kiedyś się zabierałem za ARM ale nie było takiego prostego programatora jak do PIC czy też AVR (16zł na allegro) żeby można coś popróbować i szybko zaprojektować PCB do finalnego wyrobu.
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.
Bo muszą
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 :)
[..]
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.
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.
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, na który w życiu nie napisałem nawet linijki. A ja nie jestem nadczłowiekiem.
Tak samo jak dziurą w bucie. Przecież jakoś kuśtykasz.
To prawda. Faktem jest, że niemal jedyna w Twoich postach, ale ważna. Nie ma się co bać C. Nie musisz nic czytać, ani po polsku, ani po angielsku. Nauką jest Twój kompilator. Często darmowy lub w promocji czasowej po zalogowaniu. Przykłady w liczbie 3+ masz w katalogu EXAMPLES. Otwierasz projekt, kompilujesz i otwierasz plik *.lst Tam masz pięknie rozrysowane: instrukcja w C i 10-20 linijek kodu w czystym ASM, który znasz i rozumiesz. Jak widzisz, że za dużo, to zostaw sobie: void main() { ALMAKOTA =1; } i popatrz na Lambadę ;-)
Jak zaczniesz czytać książki, to może się okazać, że dowiesz się jakie są "dobre zwyczaje". Dobre zwyczaje są dobre, jeśli są dobre. Cały kod w C jest i tak zamieniany na kod maszynowy, gdzie BASICowy rozkaz GOTO jest najważniejszy.
Albo odwrotnie. Lecąc F16 (ASM) będziesz szybciej niż drezyną (C) u celu. Na dwoje babka wróżyła. Jeśli operujesz z rozdzielczością 20 ns, to rób sobie w C i szukaj procków, co spełnią Twoje założenia i tańczą Lambadę (R)Alex od wtorku do niedzieli.
Tak jak pisałem dla mnie wystarczającą motywacją było przejście z asm na
51 do asm na AVR.
No ale na błędy kompilacji narzekają chyba tylko ci co nie kompilują. Chyba to jest dla nich odpowiednik takich niedostępnych winogron które zapewne i tak są kwaśne.
Dostajesz kod np 1.6 wolniejszy niż byś go napisał sam w asm a uruchamiasz go na 10 razy szybszym procku. Nie opłaca się? W dodatku czas przesiadki programisty na ten 10 razy szybszy procek jest też wielokrotnie szybszy w przypadku c niż asm.
Tylko, że z błędami spowodowanymi przez siebie programista walczy co chwila, a błąd kompilatora masz szansę spotkać raz na dziesięć lat. No chyba, że używasz ne opartych na gcc, komercyjnych kompilatorów dla niezbyt popularnych architektur.
Możesz podać jakieś obliczenia? Nie możesz, bo musisz napisać w ASM i w C, a potem porównać, a Ty tego nie robisz.
1,6x wolniejszy kod w C vs, ASM dla TEGO samego procka, to kłamstwo, które próbujesz przeforsować. Nie uda Ci się. Z moich obliczeń częściej wynika dokładnie co napisałeś, ale bez kropki, czyli 16x. I dlatego musisz wybrać coś 10x szybszego. Dopóki nie udowodnisz - nie masz prawa pokazywać mnożników. Możesz podać jedynie link do RZETELNYCH analiz. S.
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.
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 :(
No i tak to mniej więcej działa. Z poprawką na to, że często nie musisz ustawiać bitu. Wystarczy, ze użyjesz bibliotekę wykorzystującą sterowniki CMSIS. Przy inicjalizacji (np portu UART czy SPI) podajesz który to numer portu, jaka prędkość bodowa i na którym pinie jest Tx a na którym Rx. 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.
To nie tak że ledwo się mieszczę, po prostu czasem trzeba zrezygnować z jakiejś extrasowej funkcji bo nie wejdzie, założona funkcjonalność musi się zmieścić albo procek za mały.
[..]
A może faktycznie im wystarcza?
[..]
Nie wiem w czym windows jest pisany ale daleko mu do bycia stabilnym. Linuxa ciężko ale też da się wywalić.
Nie znam powodów innych niż ten co podałem (kasa). Co stało na przeszkodzie zaadoptowania basic'a? A już wiem... kasa... nie byłoby jej za kursy, książki, poradniki i trzeba by było zabulić za licencje/prawa autorskie do basic'a.
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.
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.
2x droższy niż PIC12Fxxx. Tak to nie działa. Poza tym nie wiedziałem, że jest taki LPC810. Dzięki.
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.
W dniu 2014-04-06 17:34, Dariusz Dorochowicz 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 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!
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
formatting link
może inne też obsłuży). Ale i tak uważam, że obecnie SWD przebija zabawę z UARTem.
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.
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.
W którym miejscu bo jakoś nie zapamiętałem nic konkretnego.
Chyba jesteś tak wybredny jak identyfikator. Jemu też żadna książka nie pasuje.
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.
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)
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.