Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[STM32] Czy używać bibliotek ST?

pikoc 12 Sty 2016 23:20 30481 152
  • #121 12 Sty 2016 23:20
    grko
    Poziom 33  

    @PDT Moim nie są dobrym przykładem dobrze napisanego softu. I nie chodzi tutaj o rozmiar tego kodu czy o błędy w sofcie (bo każdy soft jest zabugowany mniej lub bardziej). Nawet nie chodzi mi o poziom abstrakcji tego kodu bo sam stosuje większą abstrakcję (np uniwersalny interfejs do IO, interfejs urządzenia blokowego etc). Po prostu sam styl w jakim to jest napisane jest... niesmaczny :)

  • #122 12 Sty 2016 23:29
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tadzik85 napisał:
    To akurat twoje założenia projektowe, twoje szczęście, że miałeś możliwość coś takiego stworzyć. Ale patrząc na popularność IoT oraz trendu z tym związanego low power......

    Abstrahując już od tego czy faktycznie to takie popularne i czy aby na pewno większość tutaj dyskutujących się tym zajmuje - IoT to nie tylko sprzęt na baterie. Lodówka też może być "IoT", podobnie jak domowa automatyka. Jedno i drugie z zasilaniem sieciowym.

    tadzik85 napisał:
    Tu to się w zupełności nie zgodzę.
    Bo jak ja to każdy grosik mam uszczknąć gdzie się da, jeśli jest to opłacalne. A często okazuje się, że poświecenie 3 miesięcy dla 1zł/ sztukę jest.
    Albo konstruktor siedzi nad jednym projektem naście lat rozwijając zapotrzebowanie na rosnące zapotrzebowanie. Taka praca.
    I oczywiście są przypadki jak opisałeś, stworzenie czegoś w ilościach pojedynczych sztuk na specjalne zamówienie.

    Poza tym wielu z nas o ile pracuje w zawodzie zajmuje się znacznie większą ilością obowiązków niż pisane oprogramowania na MCU.

    Nie zgadzaj się jeśli nie chcesz. Nie rób tylko ze swojego przypadku ogólnej normy.

  • #123 12 Sty 2016 23:30
    tadzik85
    Poziom 38  

    Freddie Chopin napisał:
    tadzik85 napisał:
    To akurat twoje założenia projektowe, twoje szczęście, że miałeś możliwość coś takiego stworzyć. Ale patrząc na popularność IoT oraz trendu z tym związanego low power......

    Abstrahując już od tego czy faktycznie to takie popularne i czy aby na pewno większość tutaj dyskutujących się tym zajmuje - IoT to nie tylko sprzęt na baterie. Lodówka też może być "IoT", podobnie jak domowa automatyka. Jedno i drugie z zasilaniem sieciowym.

    tadzik85 napisał:
    Tu to się w zupełności nie zgodzę.
    Bo jak ja to każdy grosik mam uszczknąć gdzie się da, jeśli jest to opłacalne. A często okazuje się, że poświecenie 3 miesięcy dla 1zł/ sztukę jest.
    Albo konstruktor siedzi nad jednym projektem naście lat rozwijając zapotrzebowanie na rosnące zapotrzebowanie. Taka praca.
    I oczywiście są przypadki jak opisałeś, stworzenie czegoś w ilościach pojedynczych sztuk na specjalne zamówienie.

    Poza tym wielu z nas o ile pracuje w zawodzie zajmuje się znacznie większą ilością obowiązków niż pisane oprogramowania na MCU.

    Nie zgadzaj się jeśli nie chcesz. Nie rób tylko ze swojego przypadku ogólnej normy.


    Ja? wypraszam sobie. Ty podałeś liczby rzędu 99%

  • #124 12 Sty 2016 23:47
    PDT
    Poziom 24  

    Spoko Freddie Chopin ja jestem też od numerologii stosowanej, równania różniczkowe cząstkowe itp.

    Dodano po 10 [minuty]:

    No proszę odezwał się Gregorz Kostka i napisał, że źle napisał.. czy to spowiedź jest? Wiem, że źle ale ileś postów wyżej i tak podziękowałem, że coś w sprawie stm32f429 napisał

    PS Zamieścił skrypt loadera z 15 marca 2012 Freddiego Chopina

  • #125 12 Sty 2016 23:47
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tadzik85 napisał:
    Ja? wypraszam sobie. Ty podałeś liczby rzędu 99%

    Zrób ankietę, zobaczymy kto był bliżej.

  • #126 12 Sty 2016 23:58
    tadzik85
    Poziom 38  

    Freddie Chopin napisał:
    tadzik85 napisał:
    Ja? wypraszam sobie. Ty podałeś liczby rzędu 99%

    Zrób ankietę, zobaczymy kto był bliżej.


    Czekaj czekaj, tylko kto tu liczbami rzucił?

  • #127 13 Sty 2016 00:00
    PDT
    Poziom 24  

    Co ta komercja robi z ludzi, lodówka ma chłodzić a nie się upgrade-ować i przy okazji zżerać mi transfer :)
    PS W urządzeniach zasilanych z baterii, gdzie oszczędzanie energii jest priorytetowe to BlueDraco miał rację, to programowanie GPIO nie jest jednokrotne jak napisałem, zdarza się po każdym wybudzeniu, ale nie tak częste znowu by to było problemem do optymalizowania

  • #128 13 Sty 2016 00:18
    grko
    Poziom 33  

    Cytat:

    No proszę odezwał się Gregorz Kostka i napisał, że źle napisał.. czy to spowiedź jest? Wiem, że źle ale ileś postów wyżej i tak podziękowałem, że coś w sprawie stm32f429 napisał

    PS Zamieścił skrypt loadera z 15 marca 2012 Freddiego Chopina


    O co kaman w tej wypowiedzi? :)

  • #129 13 Sty 2016 08:11
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tadzik85 napisał:
    Czekaj czekaj, tylko kto tu liczbami rzucił?

    Nie chodzi o to, kto rzuca liczbami, tylko o to kto rzuca tekstami typu:

    tadzik85 napisał:
    Pogadamy jak zaczniesz konstruować coś co ma być produkowane w setkach tysięcy sztuk rocznie. Gdzie wybranie MCU z choćby 2x większa pamięcią flash to strata ok. 10000 zł. przy małych prockach.

    Pogadamy dodatkowo jak twój układ będzie musiał brać jak najmniej prądu. Tu bez problemu można zyskać 5-10% oszczędności w poborze energii.

    Pogadamy 3 raz gdy jedną z tych aplikacji będziesz musiał przenieść na inną rodzinę, dla której owego SPLa czy Hala nie będzie.

  • #130 13 Sty 2016 08:20
    tadzik85
    Poziom 38  

    Freddie Chopin napisał:
    tadzik85 napisał:
    Czekaj czekaj, tylko kto tu liczbami rzucił?

    Nie chodzi o to, kto rzuca liczbami, tylko o to kto rzuca tekstami typu:

    tadzik85 napisał:
    Pogadamy jak zaczniesz konstruować coś co ma być produkowane w setkach tysięcy sztuk rocznie. Gdzie wybranie MCU z choćby 2x większa pamięcią flash to strata ok. 10000 zł. przy małych prockach.

    Pogadamy dodatkowo jak twój układ będzie musiał brać jak najmniej prądu. Tu bez problemu można zyskać 5-10% oszczędności w poborze energii.

    Pogadamy 3 raz gdy jedną z tych aplikacji będziesz musiał przenieść na inną rodzinę, dla której owego SPLa czy Hala nie będzie.

    Fakt, a że akurat Ciebie nie dotyczy to .......

    Ale rozumiem, że twierdzisz, że nastały czasu w których większość woli wydać więcej i mniej zarobić? Ciekawe spostrzeżenie.

  • #132 13 Sty 2016 09:14
    BlueDraco
    Specjalista - Mikrokontrolery

    Freddie Chopin napisał:

    Abstrahując już od tego czy faktycznie to takie popularne i czy aby na pewno większość tutaj dyskutujących się tym zajmuje - IoT to nie tylko sprzęt na baterie. Lodówka też może być "IoT", podobnie jak domowa automatyka. Jedno i drugie z zasilaniem sieciowym.


    Poczekaj, Kolego, ze trzy lata, kiedy wg. norm UE każda lodówka będzie musiała być w klasie energetycznej AAAAAAA+++++++ z odzyskiem energii ruchu powietrza od skrzydeł much, wtedy pogadamy o braku potrzeby oszczędzania energii... ;)

  • #133 13 Sty 2016 10:04
    PDT
    Poziom 24  

    GrzegorzKostka napisał:
    O co kaman w tej wypowiedzi?

    W 2013 roku zaczynałem poznawać procesory STM32F4. W Twoim przykładzie zwrócił moją uwagę początek programu:
    pll_init();
    bsp_init();
    A gdyby tak jeszcze to ukryć przed main? Tak wtedy pomyślałem i przeniosłem powyższe do startup-a.

    O skrypcie loadera od Freddiego Chopina to wspomniałem ponieważ była w nim konfiguracja umieszczająca całość programu w RAM. To bardzo wygodne jak się testuje małe programiki.
    Cykl edit->compile->load->run/debug znacznie się skraca.

    A tak ogólnie co do zasadniczego tematu dyskusji, podzieliliśmy się swoimi opiniami, każdy ma swoje racje które należy uszanować.
    Pzdr

  • #134 13 Sty 2016 10:14
    BlueDraco
    Specjalista - Mikrokontrolery

    Tak z teoriii programowania:

    Procedura - to fragment kodu przeznaczony do WIELOKROTNEGO użycia w programie.

    Ile razy i z ilu różnych miejsc programu wołamy inicjowanie pll, sterownika pamięci albo peryferiów?

    Ok, wiem, znów wbiłem kij w mrowisko...

  • #135 13 Sty 2016 10:27
    alagner
    Poziom 25  

    @up ale od tego chyba jest inline. Poza tym chodzi jeszcze o podział kodu na pewne czytelne bloki.

  • #136 13 Sty 2016 11:20
    BlueDraco
    Specjalista - Mikrokontrolery

    No więc właśnie ten podział - jest kwestią estetyki/przejrzystości, ale zupełnie nie broni się poza tym. inline - ok, ale bez inline mamy tylko narzut na wywołanie i powrót po stronie wołającego i wołanego, czyli dla wygody i estetyki marnujemy pamięć i czas procesora. Oczywiście można zaraz zapisać wzór matematyczny współczynnika wygody i estetyki oraz współczynnika marnowania czasu i pamięci i snuć dalsze wywody... ;)

  • #137 13 Sty 2016 12:37
    alagner
    Poziom 25  

    Draco, bez urazy ale

    Harold Abelson napisał:

    Programs must be written for people to read, and only incidentally for machines to execute.


    oraz:
    http://c2.com/cgi/wiki?RulesOfOptimization

    Zwłaszcza pkt. 3. Profile before optimizing

    Walczyłem parę razy o pojedyncze bajty w Attiny13 bo urządzenie już pracowało a potrzebny był upgrade; zdarzyło mi się odchodzić od ładnej abstrakcji na MSP430 bo stosu brakowało. Ale tam są bajty pamięci. W STM/LPC/ogólnie ARM (zwłaszcza dużych) są ich setki tysięcy czy miliony i spokojnie można lecieć w C++, często bez przejmowania się takimi rzeczami jak threadsafe static initialization.

    A teraz mam to w... głębokim poważaniu bo piszę pod linuxy i mam wrażenie, że to wszystko w tym kierunku pójdzie, coraz rzadziej widzę baremetal embedded, za to linuxa coraz więcej. Ew. mój zawód trochę mnie profiluje na patrzenie na taką robotę.

  • #138 14 Sty 2016 23:26
    PDT
    Poziom 24  

    Miło przeczytać rozsądną opinię. Przytoczony Harold Abelson zapewne nie jest zwolennikiem takich programów, napisałem to gdzieś około 1997 roku:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Powyższy przykład polecam do refleksji programistom/koderom i jeśli chcą się doskonalić w branży zaciemniania kodu, niech staną w szranki z mistrzami gatunku:
    http://www.ioccc.org
    Pzdr

  • #139 14 Sty 2016 23:37
    BlueDraco
    Specjalista - Mikrokontrolery

    Cytowane powiedzonko jest równie zabawne i efektowne, co w oczywisty sposób nieprawdziwe: typowy program jest częściej wykonywany przez komputer, niż czytany przez człowieka. Nie wiem, ile razy dziennie czytasz procedurę obsługi wciśnięcia klawisza na klawiaturze PC - ja nie robię tego wcale, a klawisze naciskam dość regularnie.

    Ponieważ osobiście jestem przeciwnikiem zaciemniania kodu, nie używam SPL.. ;)

  • #140 14 Sty 2016 23:53
    PDT
    Poziom 24  

    Zrób mi tę przyjemność i rozpracuj przytoczony program :)

  • #141 15 Sty 2016 00:10
    alagner
    Poziom 25  

    @BlueDraco idąc tymi kategoriami to wróćmy do asemblera. Poza tym jeżeli kod jest pisany zgodnie ze sztuką to mikrooptymalizacje na starcie mają sens? Imho nie.

    A kod czytam często bo pracuję bardziej przy utrzymaniu starego kodu i błogosławię naszych devów, że pisali czytelnie. Co nie znaczy, że uważam SPL za coś dobrego, można pisać źle i rozwlekle przecież... ;)

  • #142 15 Sty 2016 08:30
    tadzik85
    Poziom 38  

    alagner napisał:
    @BlueDraco idąc tymi kategoriami to wróćmy do asemblera. Poza tym jeżeli kod jest pisany zgodnie ze sztuką to mikrooptymalizacje na starcie mają sens? Imho nie.

    A kod czytam często bo pracuję bardziej przy utrzymaniu starego kodu i błogosławię naszych devów, że pisali czytelnie. Co nie znaczy, że uważam SPL za coś dobrego, można pisać źle i rozwlekle przecież... ;)


    Zawsze uwielbiam, gdy porusza się te kwestie. To jak badanie ile cukru jest w cukrze.

    Po 1. Do każdego zagadnienia podchodzimy, indywidualnie oznacza to zdefiniowanie odpowiednich założeń. I w tym miejscu należy również uwzględnić optymalność i przyszłość naszego kodu, jego rozwijalność w tym czytelność. Kwiatki to każdy napisze, ale dobrze wiemy, że nawet na siebie musimy uważać, bo po dłuższym czasie nad własna twórczością idzie się zastanowić.

    Po 2. Każda aplikacja jest inna, w jednej rozbudowanej, jakiś rozbudowany sterownik, czy centralka, tu czytelność, abstrakcja są mile widziane, optymalizację czy pobór prądu, ma znaczenie drugorzędne. A są aplikacje gdzie te priorytety się odwracają.

    Rozmawianie na te tematy bez kontekstu, całkowicie mija się z celem.

    I tu przykład bo w dobrze znanym nam OpenOCD zdarzyła się optymalizacja na bardzo niskim poziomie. Nie przypomnę sobie o co dokładnie w niej chodziło, ale byłem zdziwiony, ze w programie na PC-ta uznają to za istotne.

  • #143 15 Sty 2016 09:02
    BlueDraco
    Specjalista - Mikrokontrolery

    Nie namawiam nikogo na asembler. Ja tylko powtarzam, że - dla mnie przynajmniej - inicjowanie peryferiów przy użyciu SPL jest NIECZYTELNE (a potem dopiero wysoce nieoptymalne). Dla mnie bardziej czytelny jest fragment programu, który ma 40 instrukcji, niż robiący dokładnie to samo fragment z ponad 200 instrukcjami, choćby z tego powodu, że ten pierwszy mieści się na jednym ekranie edytora bez przewijania.
    Mnie nie bawi "szyfrowanie" programów. Bawi mnie prosty, czytelny i zwięzły ich zapis (w sensie liczby instrukcji,a nie gęstości ich upakowania w tekście). I w tej konkurencji SPL i HAL odpadają (SPL odpada bardziej).

    PDT: ten program to naprawdę całkiem czytelna prościzna ;), a nazwy z podkreśleń zupełnie mnie nie przerażają - sam czasem używam dla zabawy.

  • #144 15 Sty 2016 09:42
    alagner
    Poziom 25  

    @tadzik85 od unikania kwiatków są przyjęte normy pisania kodu (coding standards), code review, testy developerskie, analizatory kodu (lint i inne wariacje na jego temat) i pewnie jeszcze kilka innych mechanizów, których nie wymieniłem.

    Natomiast planowanie optymalności i czytelności kodu na etapie założeń jest jak dla mnie, przepraszam, ale niezgodne ze sztuką inżynierską.
    Nie wiesz, kiedy zmienią się wymagania, nie wiesz kiedy przyjdzie Ci buga szukać, ale wywalmy wygodną i czytelną w danym zastosowaniu obiektowość na rzecz low powera (przykładowo). Sorry, nie. Pobór energii bada się chyba jak urzędzenie już działa. To też jest szukanie bottlenecków i profilowanie w pewien sposób.

    Pracowałem przy lowpowerach i jestem zdania, że tam bezproblemowo można napisać kod dobrze i czytelnie. A jak już trzeba robić h4x0r5ką magię bo "coś tam", to napisanie komentarza nie boli.

    Co nie znaczy, że popieram SPL, sam go nigdy nie używałem, imho napisany jest kiepsko.
    Co do OpenOCD - ależ wierzę, aczkolwiek chętnie ten kod zobaczę, z czystej ciekawości.

    Nie jest to zarzut pod adresem kogokolwiek tutaj, raczej takie ogólne przeświadczenie i przemyślenie zarazem: najpiew trzeba po prostu umieć programować i to dobrze, a potem brać się za mikroptymalizacje.

    Cytat:

    Poza tym wielu z nas o ile pracuje w zawodzie zajmuje się znacznie większą ilością obowiązków niż pisane oprogramowania na MCU.

    I może tu jest clue... niech to programują programiści, elektronicy robią projekt PCB itd. itd. Ja wiem, że fajnie się gada ;)

  • #145 15 Sty 2016 10:14
    tadzik85
    Poziom 38  

    alagner napisał:
    @tadzik85 od unikania kwiatków są przyjęte normy pisania kodu (coding standards), code review, testy developerskie, analizatory kodu (lint i inne wariacje na jego temat) i pewnie jeszcze kilka innych mechanizów, których nie wymieniłem.

    Alagner nie zawsze jest wymagane MISRA czy zastosowanie ogólnie przyjętych czy choćby wewnętrznych standardów kodowania.
    Kwiatki to nie koniecznie błędy.

    A założenia, cóż tylko w części masz rację. w końcu to migania diodą nie użyję RTOS.
    A propos planowania, przecież nie podchodzimy do tematu z założeniem będzie nieczytelny.

    Programować dobrze? Dobrze wiemy ze każdy programista ciągle się uczy. Co wczoraj zrobiłeś tak dziś zrobisz inaczej. X zrobi tak Y zrobi siak.

    A co to coding standards, zawsze mówię, że najpierw to trzeba wprowadzić pewną konsekwencję, by nie było tak, że pewne fragmenty szczególnie tego samego autora różniły się znacząco. Potem można wprowadzać pewne standardy. Oczywiście w projektach zespołowych, czy w miejscach gdzie takie rzeczy robi się na poważnie to inna bajka.

    A pisząc na low power na pewno trzeba podejść inaczej niż do zwykłej aplikacji. Bo nie powiesz mi, że gdyby usunąć wymóg low power napisałbyś to tak samo.
    A przecież nie twierdzę, ze to blokuje zastosowanie czytelności czy abstrakcji.

    Panowie jesteśmy w większości inżynierami, a przynajmniej osobami które się nią zajmują.
    Tu robić cokolwiek uważam z pełną świadomością trzeba. A jednak jak w matematyce nie ma u nas dróg królewskich. To samo można osiągnąć na wiele sposobów.
    Więc ja nie będę posuwał się do wniosków która jest lepsza.

    Poza tym, nie wiem dlaczego się tak odniosłeś, ale jasno napisałem, że tworząc oprogramowanie trzeba pamiętać, że nie tylko ty za jakiś czas będziesz z niego korzystał i o możliwości ewentualnego rozwoju.

    alagner napisał:
    Sorry, nie. Pobór energii bada się chyba jak urzędzenie już działa.
    Ale po co badać skoro z miejsca wiadomo, że podejście sprawiło 3 razy większy pobór energii? Przecież samo low power jest założeniem.

  • #146 15 Sty 2016 10:44
    alagner
    Poziom 25  

    MISRA chyba, o MASRA nie słyszałem? To, że nie jest wymagane nie znaczy, że nie należy np. w obrębie teamu jakichś ustalić/wypracować.

    Cytat:
    A założenia, cóż tylko w części masz rację. w końcu to migania diodą nie użyję RTOS.
    Chyba, że akurat wiesz, że projekt może się rozrosnąć/priorytetem jest czas a Ty akurat znasz danego RTOSa/RTOS ma HAL, które dużo ułatwi... nigdy nie mów nigdy :)

    Cytat:
    Programować dobrze? Dobrze wiemy ze każdy programista ciągle się uczy. Co wczoraj zrobiłeś tak dziś zrobisz inaczej. X zrobi tak Y zrobi siak.

    Design patterns, std::algorithm, RAII... nie ma znaczenia czy będzie vector<Observer*>, observers czy list<subscriber_t&> subscribers, nadal widać, że to implementacja observer pattern (pytanie czemu list a nie vector czy array, ale mniejsza z tym, nadal jest czytelnie).
    Cytat:

    A pisząc na low power na pewno trzeba podejść inaczej niż do zwykłej aplikacji. Bo nie powiesz mi, że gdyby usunąć wymóg low power napisałbyś to tak samo.
    A przecież nie twierdzę, ze to blokuje zastosowanie czytelności czy abstrakcji.
    (...)
    Ale po co badać skoro z miejsca wiadomo, że podejście sprawiło 3 razy większy pobór energii? Przecież samo low power jest założeniem.

    Pytanie czy 3x czy o 5-10%. O ile możemy sobie tak poteoretyzować ;)

  • #147 15 Sty 2016 11:03
    tadzik85
    Poziom 38  

    alagner napisał:
    Cytat:
    Programować dobrze? Dobrze wiemy ze każdy programista ciągle się uczy. Co wczoraj zrobiłeś tak dziś zrobisz inaczej. X zrobi tak Y zrobi siak.

    Design patterns, std::algorithm, RAII... nie ma znaczenia czy będzie vector<Observer*>, observers czy list<subscriber_t&> subscribers, nadal widać, że to implementacja observer pattern (pytanie czemu list a nie vector czy array, ale mniejsza z tym, nadal jest czytelnie).


    A przed chwilą coś tam pisałeś o
    alagner napisał:
    h4x0r5ką magię


    To spora przepaść.
    alagner napisał:
    Ale czy 3x czy o 5-10%. O ile możemy sobie tak poteoretyzować ;)
    U mnie to było by co najmniej 100%. A jak wcześniej mówiłem Zastosowanie SPLa dało wzrost 15%. Co ma znaczenie. A skoro się tego spodziewałem, to go nie zastosowałem, mimo odgórnych preferencji.

    alagner napisał:
    MISRA chyba, o MASRA nie słyszałem? To, że nie jest wymagane nie znaczy, że nie należy np. w obrębie teamu jakichś ustalić/wypracować.
    A czasem wystarcza poznanie czyjegoś stylu, o ile ktoś stosuje go konsekwentnie.

    Tu możemy dywagować bez końca. Szczególnie, że widać ze mamy do czynienia z zupełnie innym środowiskiem w tej kwestii.

  • #148 15 Sty 2016 11:24
    alagner
    Poziom 25  

    To inaczej: nie wiem jak to się ma do lowpower, ale widziaiłem porównania gdzie taki C++ i zastosowanie algorithm dawało mniejszy kod niż C i for. Sam robiłem nawet na AVR takie porównania i napisanie takiego automatu skończonego w C++ (polimorficznie, używając state machine pattern) dawało w sumie 4 bajty narzutu w zamian za ogrom czytelności. Czy warto? Dla mnie w danym projekcie było. Ale zachęcam do stosowania dobrych praktyk zamiast stwierdzeń "float jest duży i wolny, template długo się kompiluje, a memcpy to fukcja biblioteczna z forem i lepiej użyć fora bo odpada narzut na wywołanie".

    Jak ktoś tego floata używa w takiej Atmedze32 raz na 10 sekund i ma jeszcze mnóstwo pamięci a potrzebuje np. wielu wyprowadzeń tego mikrokontrolera, to imho nie jest to błąd. Optymalizować to będzie jak mu się pamięć skurczy/z 10 sek. zrobi się 1ms itd.

    Inna rzecz, kiedy wiesz, że ten proc ma spać a nie liczyć miejsca po przecinku; ale w tym wypadku lepiej napisać sobie ładną klasę do obsługi fixed pointa/użyć jakiejś gotowej biblioteki zamiast np. wszędzie to przeliczać ręcznie przesuwając w stringu przecinek, choćby z tego względu że będzie można użyć tego w kolejnym projekcie...

  • #149 15 Sty 2016 11:41
    tadzik85
    Poziom 38  

    Ale przecież który raz mam powtórzyć? Nie warto walczyć o bajty czy pojedyncze instrukcje, czy kilku procentowy dłuższy czas wykonania. A już zdecydowanie odradzam, gdy taki ruch wykonujemy kosztem innych parametrów oprogramowania.

    Ale jeśli z miejsca można coś osiągnąć innym podejściem bez strat na innych parametrach oprogramowania, to dlaczego nie??

  • #150 15 Sty 2016 11:44
    grko
    Poziom 33  

    Cytat:

    Ale jeśli z miejsca można coś osiągnąć innym podejściem bez strat na innych parametrach oprogramowania, to dlaczego nie??


    Mógłbyś przybliżyć te parametry oprogramowania? Chętnie dowiem się jak ograniczyć 3x pobór prądu.