logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak wysterować TSA5511 z ATMega8 w projekcie nadajnika FM RDVV?

19 Cze 2016 09:42 2085 21
  • #1 15752776
    Konto nie istnieje
    Poziom 1  
  • #2 15752930
    Konto nie istnieje
    Poziom 1  
  • #3 15752979
    excray
    Poziom 41  
    PDF strony 7-8. Wysyłasz 4 bajty z konfiguracją bądź odbierasz jeden bajt statusu. Poszczególne bity konfiguracyjne masz rozpisane w nocie.
  • #4 15753006
    JacekCz
    Poziom 42  
    atom1477 napisał:
    A to C++ chcesz mieć na ATMega8?


    A dlaczego nie?
    Ja mam, i dobrze mi się to sprawdza. Porządkuje kodowanie, daje czysty design, więcej bezpieczeństwa kodu.
    Powielasz mity o nieprzydatności C++ na małych architekturach.


    Liczbowe możliwości architektury a CO ROBIMY w danych języku to inny temat.
  • #5 15753252
    Konto nie istnieje
    Poziom 1  
  • #6 15753286
    JacekCz
    Poziom 42  
    atom1477 napisał:
    Nie powielam żadnych mitów. Po prostu chodzi o to że zastosowanie C++ zmniejszy wydajność.


    Mit / bzdura / urban legend *)
    Nie zmniejszy ani na jeden takt Atmegi8, w obszarze jaki w ogóle jest możliwy na Atmega8.

    O ambitniejszych zastosowaniach mogę porozmawiać. Bardzo dobrze wiem gdzie są obszary delikatniejszej wydajności.

    PS. Może dać pojedyncze takty/bajty stosu zysku przy kodzie porównywalnym z C.

    *) pominę takie szeroko stosowane i "wysokowydajne" zastosowania C jak formatowanie liczby przez sprintf i podobne. Wszystko bierze się z bezrefleksyjnego przekazywania/kopiowania/nauki ze złych wzorów
  • #7 15753568
    grko
    Poziom 33  
    Cytat:

    pominę takie szeroko stosowane i "wysokowydajne" zastosowania C jak formatowanie liczby przez sprintf i podobne. Wszystko bierze się z bezrefleksyjnego przekazywania/kopiowania/nauki ze złych wzorów


    A co niby takiego złego jest w tej funkcji? Najlepiej jest formatować na piechotę wynajdując przy okazji koło na nowo. Mnie ręce opadają jak co najmniej raz w tygodniu ktoś pyta o rozwiązanie problemu, który można rozwiązać stosując bibliotekę standardową.

    Odnośnie C++ to różnica w wydajności/zajętości kodu będzie marginalna pod warunkiem, że program będzie napisany w stylu C + klasy. Jeżeli będziesz już korzystał choćby z VFT to zajętość ramu będzie większa (avr-gcc umieszcza VFT w ramie). Co na takim MCU jak Atmega8 ma kolosalne znaczenie.
  • #8 15753658
    JacekCz
    Poziom 42  
    GrzegorzKostka napisał:
    Cytat:

    pominę takie szeroko stosowane i "wysokowydajne" zastosowania C jak formatowanie liczby przez sprintf i podobne. Wszystko bierze się z bezrefleksyjnego przekazywania/kopiowania/nauki ze złych wzorów


    A co niby takiego złego jest w tej funkcji? Najlepiej jest formatować na piechotę wynajdując przy okazji koło na nowo.


    W 100% (a nawet 101%) się zgadzam, że trzeba używać biblioteki standardowej. Trzeba też używać optymalnie oraz ją znać. Sprintf jest szwajcarskich scyzorykiem, bardzo użytecznym, ale ogromnie ciężkim jak na np mikroprocesory (jeśli w danym programie nie robi niczego innego, niż formatowanie pojedynczych integerów). Zakochanie w sprintf i argumentacja minimalistyczna to jakaś schizofrenia. Jedno jest dla ludzi, i drugie, ale rozsądek a nie religia.


    Sprintf jest moim ukochanym sposobem na drażnienie programistów zakochanych w "wydajności C" wziętej z religijnej zasady, że C jest szybsze dlatego że jest C, zajmuje mniej pamięci itd...

    Aha, bym zapomniał, poddaję pod medytację cztery literki itoa
  • #9 15753833
    Konto nie istnieje
    Poziom 1  
  • #10 15754131
    grko
    Poziom 33  
    JacekCz napisał:

    W 100% (a nawet 101%) się zgadzam, że trzeba używać biblioteki standardowej. Trzeba też używać optymalnie oraz ją znać. Sprintf jest szwajcarskich scyzorykiem, bardzo użytecznym, ale ogromnie ciężkim jak na np mikroprocesory (jeśli w danym programie nie robi niczego innego, niż formatowanie pojedynczych integerów). Zakochanie w sprintf i argumentacja minimalistyczna to jakaś schizofrenia. Jedno jest dla ludzi, i drugie, ale rozsądek a nie religia.

    Aha, bym zapomniał, poddaję pod medytację cztery literki itoa


    Te literki, które poddałeś pod medytację nie są nawet częścią standardu. Odnośnie samej funkcji sprintf to istnieją różne implementacje. Najmniejsza zużywa mniej niż 1kB kodu na avr. Jeśli chodzi o wydajność to również jest całkiem nieźle i do 90% zastosowań (nawet ma MCU) ta funkcja jest wystarczająco wydajna. Naprawdę nie wiem o co Ci chodzi. Nikomu tej funkcji nie polecam jak pisze na ATiny albo Atmege8. Jeżeli już się ma do dyspozycji np 32kB FLASH to zawsze można rozważyć użycie tej funkcji.

    JacekCz napisał:

    Sprintf jest moim ukochanym sposobem na drażnienie programistów zakochanych w "wydajności C" wziętej z religijnej zasady, że C jest szybsze dlatego że jest C, zajmuje mniej pamięci itd...
    [/b]


    Zanim zaczniesz pisać tego typu bzdury to otwórz sobie przykładowo źródła avr-libc albo newlib i obejrzyj sobie implementację tej funkcji. Jeżeli umiesz to lepiej zrobić to wrzuć tutaj kod, który będzie lepszy i będzie miał co najmniej taką samą funkcjonalność.

    Jeżeli już chcesz się czepiać samego języka to proszę bardzo: oto co myślą programiści Kernela i Gita na temat C++ ;)
    http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
  • #11 15754256
    Konto nie istnieje
    Poziom 1  
  • #12 15754550
    Konto nie istnieje
    Poziom 1  
  • #13 15754645
    Konto nie istnieje
    Poziom 1  
  • #14 15754748
    Konto nie istnieje
    Konto nie istnieje  
  • #15 15755182
    Konto nie istnieje
    Poziom 1  
  • #16 15758325
    JacekCz
    Poziom 42  
    Żeby dopowiedziec i zakończyć odnogę wątku nt języków i standardów.

    albertb napisał:

    Doświadczony programista przy kodzie o wielkości mieszczącej się na Atmega8? Hmm.


    Coś sugerujesz, co można odczytywać na wiele sposobów.

    Że doświadczony programista nie będzie się zajmował A8? A dlaczego? Że uP nie warto oprogramować porządnie (izolacja kodu, moduły współużywalne, założenia prowadzenia kodu, tu sprzęt, tam logika, etc etc)? Zapewniam Cię, że można i warto. Do flasha się zmieści kilka tysięcy linii, zdecydowanie warto to dobrze zorganizować. Argument "milion much nie może się mylić"*), niestety mnie nie bierze.
    nawet jeśli to C z klasami, czemu nie

    GrzegorzKostka napisał:
    JacekCz napisał:

    poddaję pod medytację cztery literki itoa


    Te literki, które poddałeś pod medytację nie są nawet częścią standardu. Odnośnie samej funkcji sprintf to istnieją różne implementacje. Najmniejsza zużywa mniej niż 1kB kodu na avr. Jeśli chodzi o wydajność to również jest całkiem nieźle i do 90% zastosowań (nawet ma MCU) ta funkcja jest wystarczająco wydajna. Naprawdę nie wiem o co Ci chodzi. Nikomu tej funkcji nie polecam jak pisze na ATiny albo Atmege8. Jeżeli już się ma do dyspozycji np 32kB FLASH to zawsze można rozważyć użycie tej funkcji.



    Widzisz ... powołujesz się na (dla mnie nieco mityczne) standardy C, że nie przywołują itoa() po czym wspominasz o niestandardowych podmiankach funkcji standardowej, co w ogóle z filozofią programowania wg standardów nie ma wiele wspólnego (głęboka zmiana semantyki funkcji). Nie neguję, w realnym programowaniu jest to OK, sam to z rzadka robię, ale nie łączmy tego w jednym zdaniu z szacunkiem dla standardu. To jest jak z zasadami "trzeba je znać by czasem łamać"

    Nieliczni teoretycy programowania C emocjonują się kolejnymi standardami, podczas gdy cały tzw przemysł myśli "de facto standardami". Jeśli dwa kompilatory używane przez zespół (i trzeci który mógłby być używany) mają jakiś wspólny feature, to jest ważniejsze niż pińcet standardów.

    Takie są realia, C/C++ zawsze miało problem ze standaryzacją, genialnym (naprawdę) facetom w kraciastych koszulach nigdy nie udało się zrozumieć co i jak a propos standardów chce tzw przemysł. Dawno temu odpowiedział mi ktoś ważny "dlaczego standard C++ nie ma typu numerycznego do obliczeń biznesowych" - "bo nie chcieliśmy programiście zabierać wolności" . To jest właśnie ten tok myślenia. Zasadniczo świat C++ nie umie wypromować, wymusić standardu, historycznie i obecnie (typ String w arduino). "Nasz string" szybszy o ileś nanosekund (autentyczna wypowiedź członka zespołu znanego parsera C++) od std::string - a że na współpracy bibliotek trzeba to przepakować tracąc RAM i milisekundy? Chore, popełnione przez wykonawców, ale ja za to winię standaryzatorów C/C++

    Słabość standaryzacyjna C/C++ jest jednym z powodów zmniejszania się roli języka. Na mojej "liście chwały" najwyższe miejsce za standaryzację zajmuje Java, liczne w pełni kompatybilne, w pełni niezależne implementacje.

    Akurat itoa() jest wspaniałą funkcją "de facto standardu"
    dziwnym trafem dokumentują ją uniwersalne podręczniki C. Równoważniki mają Pascal, Arduino i wszystkie podobne środowiska

    GrzegorzKostka napisał:

    ...sprintf...
    Zanim zaczniesz pisać tego typu bzdury to otwórz sobie przykładowo źródła avr-libc albo newlib i obejrzyj sobie implementację tej funkcji. Jeżeli umiesz to lepiej zrobić to wrzuć tutaj kod, który będzie lepszy i będzie miał co najmniej taką samą funkcjonalność.



    Dziękuję za "bzdurę".
    Wiesz, funkcje z grupy va_args to ja modyfikowałem (kastrowałem) czy pisałem od zera, jak wielu z tu obecnych nie było na świecie, wyciskając z tego bajty. Mam o tym "lekkie pojęcie". Założenia choć na pececie (von Neumann) były w zasadzie podobne do Atmegi (harward): ostre limity RAM, absolutnie kontrolowane zużycie stosu, praca w przerwaniach itd

    Aha. Tak przy okazji, oprócz zużycia stosu poza świadomością programisty, które mi się przypomniało, sprintf & Co nie jest typesafe, dodatkowy argument aby tego nie promować. Zgodzę się, statystyka popełnionych błędów w aplikacjach nie jest tak tragiczna (defaultowe zachowania typów czasem bronią przed strzeleniem w stopę) jak w sscanf (fatalnie!!!) ale i tak są, można sobie conieco postrzelić. "Nieszczęsne" itoa() jest bezpieczne co do typów.


    *) złota czcionka z sąsiedniego wątku, rzecz pochodzi nie od elektrodowicza, a z noty kontrolera: #define uint unsigned int
  • #17 15758653
    Konto nie istnieje
    Konto nie istnieje  
  • #18 15758698
    JacekCz
    Poziom 42  
    albertb napisał:

    Równie dobrze w C.Chyba, że Tobie sprawi to trudność?

    Albert


    W takim C jak w cytowanej nocie, i dominującym w większości projektów uP? Tak, sprawi mi to trudność :)
  • #19 15758723
    Konto nie istnieje
    Konto nie istnieje  
  • #20 15758847
    Konto nie istnieje
    Poziom 1  
  • #21 15758885
    Konto nie istnieje
    Poziom 1  
  • #22 15759069
    grko
    Poziom 33  
    Cytat:

    Widzisz ... powołujesz się na (dla mnie nieco mityczne) standardy C, że nie przywołują itoa() po czym wspominasz o niestandardowych podmiankach funkcji standardowej, co w ogóle z filozofią programowania wg standardów nie ma wiele wspólnego (głęboka zmiana semantyki funkcji). Nie neguję, w realnym programowaniu jest to OK, sam to z rzadka robię, ale nie łączmy tego w jednym zdaniu z szacunkiem dla standardu. To jest jak z zasadami "trzeba je znać by czasem łamać"


    Te "niestandardowe" podmianki nie są w żaden sposób zabronione i niezgodne ze standardem. Absolutnie nikt nie obliguje Cie do linkowania jakiejkolwiek biblioteki standardowej. Możesz linkować glibc, newlib, uclibc albo jakąkowiek inną. Nawet napisaną przez siebie. Możesz nawet żadnej nie linkować. Wtedy program będzie super optymalny ;)

    Cytat:

    Nieliczni teoretycy programowania C emocjonują się kolejnymi standardami, podczas gdy cały tzw przemysł myśli "de facto standardami". Jeśli dwa kompilatory używane przez zespół (i trzeci który mógłby być używany) mają jakiś wspólny feature, to jest ważniejsze niż pińcet standardów.


    Nie emocjonuję się standardami. Jednak jeżeli mam do wyboru dwie funkcje i tylko jedną określa standard to wybór jest dla mnie oczywisty (pomijam w teraz kwestię wydajności).

    Cytat:

    Takie są realia, C/C++ zawsze miało problem ze standaryzacją, genialnym (naprawdę) facetom w kraciastych koszulach nigdy nie udało się zrozumieć co i jak a propos standardów chce tzw przemysł. Dawno temu odpowiedział mi ktoś ważny "dlaczego standard C++ nie ma typu numerycznego do obliczeń biznesowych" - "bo nie chcieliśmy programiście zabierać wolności" . To jest właśnie ten tok myślenia. Zasadniczo świat C++ nie umie wypromować, wymusić standardu, historycznie i obecnie (typ String w arduino). "Nasz string" szybszy o ileś nanosekund (autentyczna wypowiedź członka zespołu znanego parsera C++) od std::string - a że na współpracy bibliotek trzeba to przepakować tracąc RAM i milisekundy? Chore, popełnione przez wykonawców, ale ja za to winię standaryzatorów C/C++


    Nie będę się do tego jakoś odnosił. C++ to nie mój problem tylko Twój.

    Cytat:

    Akurat itoa() jest wspaniałą funkcją "de facto standardu"
    dziwnym trafem dokumentują ją uniwersalne podręczniki C. Równoważniki mają Pascal, Arduino i wszystkie podobne środowiska


    Nie, nie jest częścią standardu. Wszędzie w dokumentacji do tej funkcji jest to wyraźnie napisane. Naprawdę, nikomu nie zabraniam używania tej funkcji. Ja po prostu nie zakładam, że każda biblioteka standardowa takową implementację posiada. Do You see the difference?


    Cytat:

    Wiesz, funkcje z grupy va_args to ja modyfikowałem (kastrowałem) czy pisałem od zera, jak wielu z tu obecnych nie było na świecie, wyciskając z tego bajty. Mam o tym "lekkie pojęcie". Założenia choć na pececie (von Neumann) były w zasadzie podobne do Atmegi (harward): ostre limity RAM, absolutnie kontrolowane zużycie stosu, praca w przerwaniach itd


    Argument nie do obalenia: "ja coś tam robiłem jak wy jeszcze robiliście w pieluchy". Jeżeli posiadasz własną implementację biblioteki standardowej to proszę pochwal się kodem. W czym była lepsza niż standardowa biblioteka na daną architekturę? Czy aby to nie była to niecna "niestandardowa podmianka"?


    Cytat:

    Aha. Tak przy okazji, oprócz zużycia stosu poza świadomością programisty, które mi się przypomniało, sprintf & Co nie jest typesafe, dodatkowy argument aby tego nie promować. Zgodzę się, statystyka popełnionych błędów w aplikacjach nie jest tak tragiczna (defaultowe zachowania typów czasem bronią przed strzeleniem w stopę) jak w sscanf (fatalnie!!!) ale i tak są, można sobie conieco postrzelić.


    Tak, wszystkie funkcjie z va_args nie są typesafe. Podobnie jest z całym językiem C. Widzę, że Ci to nie odpowiada i piszesz w C++. Chciałbym zauważyć, że w Twoim ukochanym języku również da się strzelić w stopę na wiele innych sposobów, niedostępnych w C.

    Cytat:

    "Nieszczęsne" itoa() jest bezpieczne co do typów.


    A sprintf ma 10 razy większą funkcjonalność. Naprawdę nie widzisz miejsc gdzie można stosować jedną funkcję a gdzie drugą? Stosuję te funkcje od kilku lat (z va_args) w prawie wszystkich projektach. Nie wiem czy ilość błędów związanych z błędnymi parametrami mogę zliczyć na palcach jednej ręki. Oczywiście takie ryzyko istnieje. Ja je jednak akceptuje.
REKLAMA