W dniu 2014-04-06 00:42, AlexY pisze:
A tego to nie rozumiem. Może chciałeś napisać "tylko to znam"? Jaka jest korzyść z pisania w asemblerze? Tylko nie pisz o tym, że w asemblerze łatwiej ci się uda napisać program, który będzie wystarczająco szybki i zwarty żeby sobie poradzić z ograniczeniami sprzętowymi 8-bitowca.
W dniu 2014-04-06 13:56, janusz_k pisze:
To tak jak w ARMach :)
Użytkownik Pszemol napisał:
Użytkownik Mario napisał:
[..]Nie, nie tylko, ASM, pascal, basic. Tych potrzebowałem to się nauczyłem, zrobiłem podejście do C i C++ ale chyba już za stary jestem bo mi się odechciało, może to kwestia braku odpowiedniej literatury napisanej w sposób dla mnie zrozumiały.
Nikt nigdy nie wmówi mi że asm jest łatwy, jego podstawowa zaleta to wiedza co w danym momencie się dzieje z każdym bitem, całkowita kontrola sprzętu, zawsze, wszystkie procedury bez skrępowania mogę okroić z funkcji których nie użyję, nie wiem czy tak samo można grzebać w bibliotekach C. np obsługa LCD HD44780 wyciąć obsługę 8bitowej transmisji i odczyt stanu wyświetlacza.
Nikogo nie zamierzam przekonać do swoich racji wiem że rynek wymusił pisanie szybko bo na chlebek nie zarobisz, ale czy to jest rzeczywiście dobre?
W dniu 2014-04-06 14:28, AlexY pisze:
O jakich błędach mówisz? Używam gcc od bodajże 2009 roku i nie musiałem poprawiać żadnych błędów kompilacji. No chyba, że za błąd uważasz to co Sylwek opisał w swojej analizie kodu w sąsiednim wątku. Czyli, że kompilator zastosował w kodzie wynikowym operacje na bajtach zamiast na słowach. No i jak taki błąd wpływa na prawidłowe działanie kodu?
Uważasz, że żeby nauczyć się c to trzeba się odpłatnie szkolić u specjalistów? No to może w tym jest twój problem. Ja po nastu latach rzeźbienia w asm wziąłem się ze sporą niechęcią za c - przymuszony koniecznością przejścia na coś mocniejszego od 51. Po zrobieniu kilku projektów na AVRach w AVR-gcc, uznałem, że to nie tędy droga i przeszedłem na ARMy. I nie żałuję. Nie muszę wiedzieć co program robi na poziomie pojedynczych komend kodu maszynowego. Ważne czy robi to co zapiszę w c i jakby co mogę to podejrzeć w debuggerze. Rozumiem też twój sentyment do BASICa. Przy przesiadce tez żałowałem, że nie mogę się przestawić na BASIC, czy Fortran lub Algol. C w porównaniu do nich wydawał mi się jakiś zawiły. Ale uwierz nawet pięćdziesięciolatek jest w stanie się go nauczyć bez pomocy specjalistów.
To oczywiście jest jakaś opcja. Ale raczej dla programisty linuksowego, który chce sobie zrobić sterownik do domu czy drona. Nie wyobrażam sobie dawanie Raspberry czy innych gotowych modułów do moich komercyjnych produktów.
Napisz coś konkretnego o tych błędach kompilatora. I w czym są gorsze od błędów własnych?
I wrzuca się go na 10 razy szybki procek. W efekcie czas realizacji zadania jest mniejszy, koszt zarazem też niższe, a wydajność procka wraz z oprogramowania wyższa.
Z błędami kompilatora jest tak jak z błędami w architekturze procka. Są znane i nieznane. Jak masz pecha to możesz na nie trafić. Jak siedzisz w temacie i korzystasz z wiedzy zawartej w dużej społeczności masz duże szanse dowiedzieć się o tych błędach i ich unikać. A największe społeczności są teraz zgromadzone wokół ARMów i gcc.
W dniu 2014-04-06 14:39, AlexY pisze:
No to chyba młodszy jesteś ode mnie bo ja uczyłem się Algolu i Fortranu. DO nauki c wystarczył mi Kernighan Ritchie oraz kieszonkowy leksykon c z serii O'Reilly.
Nie piszę, że łatwy tylko, że większe ma się szanse na to, że program będzie wystarczająco mały i wystarczająco szybki aby zmieścić się w osmiobitowcu i maksymalnie wykorzystać jego słabą wydajność. Czyli ciężką pracą kodera, bohatersko zwalcza się problemy wynikające ze słabej architektury.
Dopóki ten sprzęt jest wystarczająco prosty aby go ogarnąć.
Możesz to zrobić. Jeśli biblioteka ma dużo kodu, a wykorzystujesz tylko małą część to możesz wyciąć te funkcje, wkleić wprost do swojego kodu albo zapisać jako inną bibliotekę. Tu ograniczeniem może być licencja. Często się korzysta z dorobku innych zawartego w domenie publicznej. Dołączenie czyjegoś kodu np. na GPL wprost do twojego kodu powodowałoby wymóg opublikowania twojego kodu. Często jest jednak tak, że licencja zezwala na używanie zamkniętego kodu twojego własnego programu, a publikować trzeba jedynie zmiany w środowisku jak funkcje biblioteczne czy sterowniki. Wtedy lepiej zmianę jakiejś biblioteki zapisać jako nową bibliotekę i ewentualnie opublikować w razie potrzeby.
Czy pisanie w c pod linuksa czy systemy BSD jest twoim zdaniem niewłaściwe, bo nie panuje się nad efektem kompilacji? Superkomputery, routery, duża część serwerów internetowych, systemy dowodzenia i prowadzenia ognia. Lepiej i bezpieczniej byłoby gdyby to wszystko pisać w asemblerze?
Myślę że Gates udowodnił swoim portfelem który model biznesu się sprawdza. Ty masz satysfakcję że Twoja pętla ma tylko 40 instrukcji a on ma miliardy dolarów i nie wie co z nimi zrobić...
Jakie błędy kompilatora chcesz poprawiać?? To jakieś mity.
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".
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 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.
Każdy ma inne oczekiwania - gotowiec to jakiś tam start i dobrze służy do poznania rodziny procesorów, zrobienia pierwszych kroków, ale potem warto pójść dalej - implementacja ARMa na własnej płytce nie jest jakimś wyczynem do którego wymagana jest znajomość prowadzenia wysokomegaherzowych magistral pamięci DDR3... Tu też masz do czynienia z mikrokontrolerami gdzie wszystko masz zamknięte wewnątrz kostki, jak w AVR czy 8051 czy PICu... Nie bardzo więc widzę gdzie Ty widzisz trudność że w AVR zrobisz płytkę samemu a do ARMa musisz mieć jakiegoś gotowca...
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.
Nie każdy ARM ma wszystko... zgoda. 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.
Zrozum, ceny procesorów 8-bitowych dzisiaj są nadmuchane. Dlaczego są nadmuchane? Bo producenci trzymają Cię w garści. Płacisz jak za zboże bo musisz. Musisz, bo tylko te znasz... Tylko tego proca zastosujesz jak mniejszy Ci okaże się za mały. Producent wie, że przesiadka na inną rodzinę to koszty zaporowe 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 lub niższe jak wolniejszych, starszych procków LGA775 dlaczego? Bo DDR2 czy procek LGA775 wstawia się jako retrofity do starszych maszyn, aby robić upgrade... Rynek zdyskontował fakt, że aby przesiąść się na inna platformę trzeba wydać więcej: nowa płyta, nowy ram, nowy proc, często nowy zasilacz itp, itd... Więc Cię rypią bez mydła za stary procek czy pamięć więcej niż za nowe...
To samo jest z prockami 8-bitowymi w stosunku do procków ARM.
No to samo masz w ARMach... nie widze tu żadnej rewelacji.
Co ma swoje? Ja mówię o standardowej bibliotece CMSIS:
Dla początkujących... i potem co? Zainwestujesz czas w naukę a potem zmiana i od nowa będziesz się uczył od początku? 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.
To coś tak jak byś powiedział że docelowo chcesz się nauczyć języka niemieckiego i wyemigrować do Berlina... Ale ponieważ jesteś początkujący to na początek nauczysz się języka ruskiego, bo jest dla Ciebie, Polaka, łatwiejszy niż niemiecki, "na początek"... Widzisz bezsens w tej logice? :-)
Naprawdę nie ma się czego bać ARMów. To jest dzisiaj procesor do nauki dla początkującego. Masz całą rodzinę Cortexów do poznania: M0, M1, M3 a nawet M4 z koprocesorem zmiennoprzecinkowym... Do wyboru do koloru. Najmniejsze, najtańsze M0 w małych obudowach kosztować Cię będą DUŻO, DUŻO MNIEJ niż 8-bitowce dzisiaj...
W dniu 2014-04-06 13:17, Pszemol pisze:
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ć.
Bo o to chodzi, żeby było coś, czego inni nie mają itd - trzeba dobrze nazwać. Ale to jest jednak więcej niż system przerwań. Raczej coś w stylu prostego FPGA nałożonego okrakiem "na procek".
Ale z tym nie dyskutuję - też tak uważam, chociaż na koniec 8-bitowców jeszcze trochę trzeba poczekać.
:) 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.
Pozdrawiam
DD
W dniu 2014-04-06 13:38, Mario pisze:
Dzięki :) Przyjrzę się dokładniej. Czym się toto programuje (software i hardware)? I dokumentacja - jak można tak zagmatwać proste sprawy? Tu już chyba nawet dwa monitory to za mało do robienia projektu...
Pozdrawiam
DD
Jeżeli się coś sprawdza, to warto jeszcze zaznaczyć dla kogo. Gatesowi się sprawdził, a miliony ludzi na świecie włącza komputer, aby po kilku już minutach móc się zalogować do banku i sprawdzić, czy ma kasę na kolejną ratę. Jakoś nie widzę, że ludzie którzy próbują naśladować tych co wpuszczają w maliny innych, stawali się miliarderami. Nawet po 20 latach wpuszczania w maliny. No może czasem sami dają się wpuścić w Raspberry Pi. S.
Użytkownik Mario napisał:
[..]Nie będę się licytował, angielski mam słaby, nie programuję zawodowo i nawet bym nie chciał bo to wypala mózg :)
[..]Źle do tego podchodzisz, rozpoczynając projekt sprawdzasz który sprzęt spełni wymagania i na nim dłubiesz, dłubanie na siłę w zbyt słabym sprzęcie jest skazane na porażkę.
Ogarniasz go na bieżąco podczas pisania, do tej pory nie miałem z tym problemu.
Licencja... no właśnie...
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ć, systemy operacyjne co rusz się aktualizuje, co w przypadku asm jest szczególnie ciężkie. To wymusza użycie języka wysokiego poziomu, moje "ale" jest co do jego wyboru.
Użytkownik Mario napisał:
[..]Wszystkiego idzie się samemu nauczyć, ja na razie jakoś nie mam motywacji, a jest ona mi niezbędna po pierwszych podejściach do C
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ł.
Właśnie, i ten procek zamiast zrobić co trzeba to tańczy lambadę nagraną przez kompilator, dlatego musi być 10x szybszy.
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.
Przypomniało mi się coś:
I tak to wygląda. Ceny 32-bitowców są na poziomie 3$. Wszystkie inne 8 i 16 bitowe, które mają jakąś sensowną pamięć, kosztują już
2x więcej. Wygląda na to, że nie ma popytu na 32-bitowe uC. Pytanie dlaczego? Ja je lubię, ale większość ludzi zobaczy kartę katalogową i ucieka na drzewo. Gdyby taki 32-bitowiec miał tylko jeden prosty UART, 2 przerwania, 1 timer i kartę katalogową 50 stron, to ludzie by się nie bali. A tak, same zalety wymienione na początku, zamiast zachęcać, to odstraszają wydumanymi nazwami. Przyszły użytkownik zadaje sobie pytanie: Po co właściwie to jest?A tak jak powiedział Alex, nie przejmować się, że ma tyle bloków dodatkowych. Jak będę jakiś potrzebował, to sobie poszukam rejestru konfiguracyjnego o nazwie: bardzo_fajny_blok_CON i ustawię sobię w nim bit bardzo_fajny_blok_ON. Do tego czasu udajemy, że się nie znamy :-) S.
Nie wiem o czym mówisz... Mój laptop ASUSa pracujący pod kontrolą MS Windows 7 wstaje z trybu uśpienia w 15-16 sekund... A kasę w banku to można dziś sprawdzić byle apkiem na smartfona, pracującego zwykle pod kontrolą procesora ARM nawiasem mówiąc :-)
Sylwester - jako biznes model Gatesowi sprawdził się model oparty o pisanie kodu w C, C++, C# czy inne .NETy i nie certolenie się z dopieszczaniem kodu do ostatniej usuniętej niepotrzebnej instrukcji w asemblerze. To wymaga cholernie dużo trudu i niestety nie jest odporne na błędy w programach. Co innego gdy piszesz sobie kod mający 100-200 instrukcji na konkretny hardware który kontrolujesz jako projektant w 100% a co innego gdy piszesz przenośny kod MS Windows który ma pracować na setkach tysięcy różnych komputerów wyprodukowanych na przestrzeni ostatnich 25 lat i współpracować z pierdylionem różnych urządzeń i sterowników od osób trzecich, czego nie jesteś w stanie kontrolować w 100%. Gdybyś miał za zadanie napisać takie MS Windows w asm to szybko pogubiłbyś się bo zostałbyś w tyle - życia by Ci brakło na pisanie kodu...
:-) Po prostu pięknie! Dokładnie tak jest. Jest tylko jeden problem. Ludziom, coraz częściej nie przeszkadza, że procesor tańczy lambadę, skoro w przerwie podejdzie do stołu i poleje drinka.
Jeżeli będzie taka potrzeba, to zadowolą się tym, że tańczyć będzie od wtorku do niedzieli, a w Poniedziałek wykona całą robotę.
Ale po co się ograniczać! Niech tańczy cały miech, 30-go każdego miesiąca przyjdzie i wykona plan, a luty pal licho! Co z tego!
6 rdzeni, 1GHz każdy, bateria malutka a gość e-maila odczytuje. I tak już 18 lat trzeba komórkę przynajmniej raz w tygodniu doładować.... prądem ma się rozumieć. Nawigacja w samochodzie - bez ładowania zacznie migać na czerwono już po godzinie jazdy. Ma ktoś taką, co po naładowaniu działa przez tydzień? I to są fakty, a reszta to banialuki. S.
Aaa... uśpienia! A po co to uśpienie? Bo inaczej ładowałby się ile czasu? Zwykła proteza. Dzięki że podałeś ten przykład. To was czeka. Ze względu na GIGABAJTOWĄ nadbudowę już powoli strach przeładować system.
Gates miał na to 20 lat. Nie udało mu się. Świadczy to o jego geniuszu czy głupocie? S.
W dniu 2014-04-06 17:41, Dariusz Dorochowicz pisze:
Przydałby się jakiś toolchain. Można sobie skomponować na bazie Eclipse. Opis jak to zrobić jest na stronie freddiego
Mi dwa wystarczają.
Długo na samym asemblerze nie pociągniesz... Kiedyś znudzi Ci się miganie LEDem z pinu procesora i będziesz chciał napisać coś bardziej ambitnego - coś, co napisane w asemblerze będziesz poprawiał aż do emerytury a napisane w C/C++ zajmie Ci dwa dni :-)
Są dwie możliwości błędów kompilatora: błąd ujawnia się w postaci błędnie działającego kodu wynikowego (takie wyłapiesz) lub nie ujawnia się w postaci błędnie działającego kodu wynikowego... Tych drugich nie ma potrzeby wyłapywać ani się nimi przejmować.
Obawiam się, że sztucznie demonizujesz coś, czego nie znasz.. Uważaj, bo strach przed nieznanym ma wielkie oczy ! :-)
Podchodząc do życia w taki sposób chyba nie wychodzisz z domu... ??? Nie dasz rady nad wszystkim panować, nad wszystkim mieć 100% kontroli. Nawet jak autobusem jedziesz to polegasz na kierowcy i na innych użytkownikach drogi. Owszem, jadąc rowerem (asembler) pojedziesz najkrótszą drogą do celu, krótszą niż autobusem (C/C++) ale niekoniecznie najszybszą... A wypadki zdarzają się i busom i rowerom.
Nie przypomniało Ci się tylko na szybko coś wygooglałeś... I powiem Ci, że pudło - to raczej właśnie był komentarz o błędach jakie popełniają programiści piszący w C++ lub PHP. I to była pochwała właśnie kompilatora C++ który zgłosi programiście błąd w tym co napisał i nie utworzy błędnego kodu wynikowego a piszący w php dowie się o swoich błędach dopiero od klienta.
Podsumowując - nie bój się C, poczytaj książki (są po polsku!) i powodzenia!
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.