tuxcnc pisze:optymalizacja kodu jest dla programisty bajką o żelaznym wilku

Oczywiście, tylko trzeba wiedzieć kiedy optymalizować - zapytaj o to jakiegokolwiek dobrego programisty. Optymalizowanie na siłę tam, gdzie nie trzeba jest równie błędne jak pisanie złego kodu, bo marnuje cenny czas, który można spędzić inaczej. Mówimy w tym temacie ciągle o programiku, który nie wykorzystuje nawet 1% możliwości procesora. Czy się go zoptymalizuje, czy nie i tak można zawsze coś dopisać i spowolnić.

tuxcnc pisze:program komputerowy powinien być najkrótszy i najszybszy jak to tylko możliwe?

To nie jest program komputerowy. Pisanie kodu na mcu i komputer trochę się różni. Zgaduję, że to wiesz. Więc jaki to ma związek? Ty nie mówisz zresztą tylko o treści programu, a doborze sprzętu.

tuxcnc pisze:Ale tym trollom wcale nie chodzi o merytoryczną dyskusję,

Dalej czekam, aż mi powiesz dlaczego lepiej zużyć mniej pamięci w mikrokontrolerze, niż więcej. Co zyskujesz z tego, że po napisaniu programu masz wolne 24kb flash zamiast 20kb. Albo co daje nie skorzystanie z gotowych bibliotek, które może zajmują od strzału 20% pamięci procka, ale w końcowym projekcie wykorzystasz jej w sumie 22%, więc i tak nie braknie, a kod będzie znacznie prostszy.

tuxcnc pisze: żeby mi dokopać

Sam to robisz kompromitując się w tego typu tematach. Nie znasz w ogóle rzeczywistości i żyjesz w wyimaginowanym, idealnym świecie drobnych projekcików, które sobie piszesz dla rozrywki raz na jakiś czas. Gdybyś kiedyś musiał zrobić coś bardziej skomplikowanego, co jest Ci do czegoś potrzebne, więc czas projektu miałby duże znaczenie, to byś przestał opowiadać takie dyrdymały.

Nie mam Ci nic więcej do powiedzenia, bo z Tobą można gadać w kółko, merytorycznie nic nie jesteś w stanie wnieść (a może raczej nie chcesz), a na przepychanki słowne nie mam ochoty.

tuxcnc pisze:Takich bzdur dawno nie słyszałem...

Jeżeli to uważasz za bzdury, no to już nic na to nie poradzę. Możesz żyć dalej w swoim świecie, tylko nie ściągaj do niego innych. Zresztą skoro to bzdury to możesz mi napisać dlaczego się mylę. Ale wątpię, że to zrobisz, bo sam wiesz, że gadasz głupoty, więc nie możesz się w merytoryczną dyskusję tutaj wdać.

Ja Ci mówię z doświadczenia teoretycznego, praktycznego (zarówno na użytek własny jak i komercyjny), więc zwyczajnie wiem, że racja jest po mojej stronie

tuxcnc pisze:na argument że rowerem nie przewieziesz tony ziemniaków odpowiadacie "ale da się sto razy po dziesięć kilogramów...

Twoja analogia powinna brzmieć tak - po co wozić tonę ziemniaków samochodem, jak można rowerem na dziesięć razy, ale za to przy okazji trochę się potrenuje. Bo Ty sugerujesz robienie wszystkiego naokoło, w sposób pochłaniający więcej czasu i nie dający żadnego zysku. No może oprócz dodatkowej nauki, ale czasem trzeba coś potrzebnego zrobić na już i korzystać, a nie budować browar, żeby napić się piwa.

Nie rozumiesz, że pamięć czy możliwości procesora, których nie zużyjesz są zwyczajnie zmarnowane. Nie masz w tym żadnego zysku, jeśli zamiast 50% ramu wykorzystasz 30%. Nie masz żadnego zysku w napisaniu programu C czy w Bascomie, jeśli działają tak samo.

Ale co ja Ci będę tłumaczył, wymyśliłeś coś sobie i będziesz się tego trzymał, zamiast pomyśleć. Gdybyś trochę odbetonował myślenie na pewno by to nie zaszkodziło i przestałbyś naskakiwać na każdego, kto pokazuje jakieś swoje rozwiązania tutaj.

tuxcnc pisze:Jak widać, program który nic nie robi zeżarł 19% pamięci programu i 44% pamięci danych, a od czego są te biblioteki to powinieneś wiedzieć...

I co z tego? Póki pamięci nie braknie to nie ma znaczenia, czy procesor zużyjesz w 99% czy w 3%. A żeby tej pamięci brakło to trzeba się bardzo postarać. A przez czas zaoszczędzony na implementowanie wszystkiego samemu można robić rzeczy bardziej pożyteczne, jak np. zająć się logiką swojego programu.

Optymalizacja, zwłaszcza sprzętowa ma sens tylko przy produkcji (a i to nie zawsze, czasami nie robi różnicy czy procek kosztuje 8 czy 12zł). Przy tego typu jednorazowych projektach to zwyczajna głupota. Trochę tak, jak jeździć godzinę po sklepach, żeby znaleźć tańszą bułkę. Czasu ani paliwa nikt nie liczy, bo liczy się to, że zaoszczędził w te pół godziny 2 złote na bułkach.

Malujesz się tux takim specjalistą, więc dziwi mnie, że tego nie wiesz. Może dlatego, że swoje projekty robisz w ramach ćwiczeń, a nie praktycznej potrzeby. Gdybyś potrzebował coś, co ma działać, a dodatkowo nie miał doświadczenia, to byś nigdy nawet nie spojrzał na goły procek, choćby i 50gr kosztował, jeśli ten sam projekt możesz w 15 minut zacząć programować na podróbie arduino mega za 20zł i zająć się tym, co istotne a nie składaniem płytek prototypowych, czytaniem datasheetów, ogarniania programatorów itd. Te umiejętności mogą się przydać później, jeśli projekt przerodzi się w coś komercyjnego, ale dla jednorazowych wynalazków nie ma żadnego sensu.

tuxcnc pisze:Jakieś merytoryczne argumenty?

Żartujesz sobie ze mnie? A w Twoim poście coś merytorycznego było?

Chłop na arduino zrobił, co chciał, a Ty mu mówisz, że tego się nie robi na Arduino tylko na stmie. Co z tego, że ma sprzętową obsługę enkodera kwadraturowego? Ten jego AVR w Arduino i tak się nudzi nie mając nic do roboty, więc nie byłoby żadnego zysku z robienia tego na innym procesorze tylko dlatego, że jest tańszy. Oczywiście pomijając finansowy, ale jeśli bawi się na codzień arduino, a prawdopodobieństwo jest spore, skoro mu leżało pod ręką, to nie ma żadnego powodu przesiadać się na stm z tak błachego powodu i w ogóle zmieniać środowisko.

A co do tego Bascoma to może sam wyjaśnij najpierw, czemu się na nim nie pisze poważnych programów? I co ten programik do kontroli rozstawu ma wspólnego z poważnym programem? Też wolę C, bo jest lepszy, ale co to ma do rzeczy w tym przykładzie?

Brawo tux, napisałeś właśnie chyba najgłupszy post w Twojej karierze a było z czego wybierać.