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

Jaki mikrokontroler po AVR? -

kamill_94 06 Sty 2017 20:58 7920 165
  • #91
    Freddie Chopin
    Specjalista - Mikrokontrolery
    tmf napisał:
    Praktycznie każdy Cortex M0, M0+ nie ma 10-krotnie wyższej wydajności niż taki 20 MHz tinek, pomijając nieżyciowe przypadki, w których ktoś robi pętlę od 1 do 10 przy pomocy 64 bitowej zmiennej. O takich jak sądzę z kol. BlueDraco pisaliśmy, bo niesądzę aby jakieś mega wypaśne ARMy były w SSOP20.

    Wchodzimy więc na http://www.eembc.org/coremark/index.php i widzimy tam, że "Atmel ATmega644" osiąga zawrotną wydajność 0.54 "CoreMark/MHz", co przy 20MHz daje szokującą ocenę całkowitą 10.81. Kilka stron dalej znajdujemy "STMicroelectronics STM32F051C8" taktowany na 24MHz, który przy tym zegarze osiąga 2.33 "CoreMark/MHz", a w sumie ocenę 56.05. Zgadza się, 10x nie ma. "tylko" ponad 5x. Teraz gdy weźmiemy pod uwagę fakt, że owe STM32F0 potrafi działać jednak na 48MHz, to nawet przy lekkim zmniejszeniu wydajności na MHz (cache) - wynoszącej wtedy 2.2 - będzie 10x większa wydajność ogólna, wynosząca 105.61. No chyba że się przyczepisz, że to nie 10x a 9,769657724x... (;

    Ciekawostka - jest też nowoczesna Atxmega, z wynikami niższymi niż zwykła atmega.

    Ciekawostka nr 2 - STM32F4 przy pełnym zegarze to rejony 500-600 (~3.3 CoreMark / MHz). STM32F7 - ~1000 (koło 5 na MHz). STM32H7 - koło 2000.
  • PCBway
  • #92
    piotr_go
    Poziom 28  
    tmf napisał:
    To podasz dokładny typ i gdzie go kupię? Jakiś darmowy toolchain do tego jest? W ogóle jako prosty człek z Polski to kupię, czy to raczej oferta dla gościa od zakupów w Apple?

    PSOC3/4/5
    Tu jakiś stary opis (z przed 4 lat):
    http://www.forbot.pl/forum/topics20/inne-psoc-czyli-gumowy-procesor-vt7779.htm
    Czy kupisz w PL? Nie wiem, nie szukałem, startery widziałem, za 15zł były.
  • PCBway
  • #93
    tmf
    Moderator Mikrokontrolery Projektowanie
    Freddie Chopin napisał:
    tmf napisał:
    Praktycznie każdy Cortex M0, M0+ nie ma 10-krotnie wyższej wydajności niż taki 20 MHz tinek, pomijając nieżyciowe przypadki, w których ktoś robi pętlę od 1 do 10 przy pomocy 64 bitowej zmiennej. O takich jak sądzę z kol. BlueDraco pisaliśmy, bo niesądzę aby jakieś mega wypaśne ARMy były w SSOP20.

    Wchodzimy więc na http://www.eembc.org/coremark/index.php i widzimy tam, że "Atmel ATmega644" osiąga zawrotną wydajność 0.54 "CoreMark/MHz", co przy 20MHz daje szokującą ocenę całkowitą 10.81. Kilka stron dalej znajdujemy "STMicroelectronics STM32F051C8" taktowany na 24MHz, który przy tym zegarze osiąga 2.33 "CoreMark/MHz", a w sumie ocenę 56.05. Zgadza się, 10x nie ma. "tylko" ponad 5x. Teraz gdy weźmiemy pod uwagę fakt, że owe STM32F0 potrafi działać jednak na 48MHz, to nawet przy lekkim zmniejszeniu wydajności na MHz (cache) - wynoszącej wtedy 2.2 - będzie 10x większa wydajność ogólna, wynosząca 105.61. No chyba że się przyczepisz, że to nie 10x a 9,769657724x... (;

    Ciekawostka - jest też nowoczesna Atxmega, z wynikami niższymi niż zwykła atmega.

    Ciekawostka nr 2 - STM32F4 przy pełnym zegarze to rejony 500-600 (~3.3 CoreMark / MHz). STM32F7 - ~1000 (koło 5 na MHz). STM32H7 - koło 2000.


    No to chociażby ta ciekawostka podana przez ciebie podważa wiadygodność benchmarka. Ale są też inne. Zobaczmy co ten test mierzy:
    Cytat:
    The code is written in C and contains implementations of the following algorithms: list processing (find and sort), matrix manipulation (common matrix operations), state machine (determine if an input stream contains valid numbers), and CRC.


    Jak widać dosyć wąski wycinek zastosowań. I teraz kolejna ciekawostka. Jednym z pomiarów jest obliczanie CRC. Problem w tym, że wymienione MCU liczą CRC sprzętowo. Oczywiście do benchmarka zapewne nie jest ta opcja wykorzystywana. Lecz... w realnej aplikacji by była (a skoro CRC umieszono w benchmarku to najwyraźniej twórcy uznali, że jest to miarodajne, z czym można dyskutować), a korzystając ze sprzętu mielibyśmy ponad 100-krotne (dla XMEGA) przyśpieszenie tej operacji, podobnie na ARM. Inna sprawa, że obliczenia na macierzach, czy sortowanie danych to nie są aplikacje na małe układy embedded, stąd pewnie nieporównywalnie dobre wyniki "dużych" procków.
    O benchmarkach można sobie dużo gadać. To weźmy to na logikę - i na AVR i na ARM większość operacji trwa jeden takt. Różnica taka, że ARM wykonuje operacje na 32-bitach, AVR głównie na 8. Dopóki więc nie zajdzie potrzeba przeprowadzania operacji na typie większym niż 8-bitów to oba rdzenie idą 1:1 (poza drobnymi wyjątkami). Ale już dodawanie 32-bitowe, to dla ARM 1 takt, dla AVR - 4 takty. Ok, dodajmy pobranie i zapisanie rejestrów, żeby AVR pognębić to mamy ARM 3-4 takty, AVR - 20 taktów. Ale już dla obliczeń na 8-bitach przewagę uzyskuje AVR, bo operacje 8-bitowe są na ARM kosztowne. Pytanie po co je stosować, skoro możemy bezkarnie wydłużyć typ. Pierwszy lepszy przykład - alfablending. Mamy upakowany kolor RGB na 32-bitach, trzeba teraz przemnożyć składowe przez alfa. Na ARM - dekompresja RGB na 3*32bity, mnożenie i składanie tego spowrotem. Pomijam ARMy, które mają sprzetowe wspomaganie dla tego typu operacji, bo to rzadkość. Na AVR - po prostu 3 mnożenia ((też sprzętowe). Nie piszę tego, żeby wykazać, że coś jest lepsze, czy gorsze. Niestety mało kto sobie uświadamia, że wszystko zależy od zastosowania i tego do czego procka planuje się użyć. Żaden benchmark nie odda złożoności problemu.
    Tak sobie możemy dyskutować. To, żeby mówić o konkretach - podaj kilka typowych aplikacji, elektrodowiczów, lub hobbystów i zobaczmy jak to porównanie wypadnie.
  • #94
    JarekC
    Poziom 28  
    I niestety znowu dyskusja zeszła na temat AVR kontra ARM i licytowanie się który scalak jest tańszy.

    Dla hobbysty koszt pojedynczego scalaka i tak najczęściej nie ma znaczenia, ważniejszy jest dostęp do darmowego środowiska programistycznego i tanich zestawów startowych

    Dla projektów komercyjnych jest dużo więcej warunków które należy uwzględnić:
    - skala produkcji
    - udział kosztu uP w stosunku do kosztu całego urządzenia
    - koszt profesjonalnych narzędzi (np oryginalny JTAG SEGGER)
    - koszt komercyjnych środowisk programistycznych (KEIL, IAR)
    - jakość obsługi technicznej producenta
    - dostępność długoterminowa
    - ilość wcześniejszych opracowań na daną rodzinę procesorów (biblioteki)
    - itd

    Często pozostanie przy danym typie uP wynika po prostu z czystego rachunku ekonomicznego.
    Załóżmy że mamy produkt zrealizowany na ATMEGA sprzedawany rocznie w ilości 1000 sztuk oraz że układ podrożał z 4zł na 8zł.
    Czy jest sens ekonomiczny przeprojektowania urządzenia na ARM za 2zł?
    Roczne zaoszczędzimy 6tys.zł a ile będzie kosztowało przeprojektowanie i np ponowna certyfikacja urządzenia?
    Nie mówiąc już o ryzyku związanym z błędami i ewentualnymi kosztami obsługi serwisowej.
    Koszt pracy programisty to kwoty od kilku do kilkunastu tysięcy złotych miesięcznie.
    Nie ma. Zazgrzytamy zębami i kupimy następną partię AVRów.

    Ilu z was projektuje urządzenia produkowane w ilościach większych niż 1-10tys. rocznie?

    Również przy projektowaniu nowego urządzenia nie zawsze koszt samego uP będzie miał znaczenie.

    A wracając do meritum tematu czyli co po AVR.
    Jeżeli celem jest rozwinięcie swoich umiejętności w celach hobbistycznych to należy się kierować popularnością tego typu układów na lokalnym rynku (dostęp do samych układów jak i pomocy technicznej na forach).
    I tutaj dobrym wyborem mogą być układy ARM od ST

    Jeżeli celujesz w rynek komercyjny to dobrze znać wiele architektur i środowisk programistycznych bo często trafisz na sytuacje gdy wybór uP i środowiska będzie narzucony przez klienta.
    Sam tego ostatnio doświadczyłem gdy dostałem do realizacji projekt na PIC32 i PIC16 chociaż nigdy nie przepadałem za Microchipem i moje wybory padały raczej na AVR, C51 i ARM.

    Hasło ARM często jest traktowane zbyt ogólnikowo, przesiadając się np z ARM od ST na ARM od NXP okaże się ze znajomość samego jądra uP (np Cortex M0,czy M3) pomimo że takie samo to dla obydwu to za mało i musimy poznać od nowa całe otoczenie.

    Rynek półprzewodników pokazuje że jest miejsce dla wielu rozwiązań opartych o różne architektury np:
    - nowe serie C51 od Silicon Labs (EFM8 Universal/Sleepy/Busy Bee)
    - POSC od Cypressa
    - PIC32MX i MZ od Microchipa
    - FT90x i FT5A1 od FTDI
    ...

    Sam uP to prawie zawsze tylko cząstka całości układu i ważniejsza może być znajomość chociażby tematów związanych z USB, Bluetooth, GSM, LORA.


    Pozdrawiam
    JarekC

    PS
    Dla miłośników ARM, pooszukuję ARMa (Cortex M0, M0+ lub M3) z następującymi wymaganiami:
    - interfejs USB (wystarczy nawet Low Speed)
    - zasilenie z USB bez dodatkowego stabilizatora
    - praca bez zewnętrznego rezonatora kwarcowego
    - możliwość programowania przez USB (wbudowany fabrycznie bootloader)
    - wymiary obudowy nie większe niż 4x4mm
    - cena < 1$
  • #95
    Pituś Bajtuś
    Poziom 28  
    Panowie, ta dyskusja nie ma najmniejszego sensu. Wystarczy popatrzeć w stopki aby zobaczyć że nie jest obiektywna. Strony dyskusji (a przynajmniej jedna, ta najgłośniesza) mają czysty komercyjny interes w promowaniu swojej opcji.
  • #96
    piotr_go
    Poziom 28  
    tmf napisał:
    bo operacje 8-bitowe są na ARM kosztowne

    eeeeee? Od kiedy? Przecież można czytać/zapisywać na ARM także pojedyncze bajty. Przejrzyj zestaw instrukcji bo bzdury gadasz.
  • #97
    michalko12
    Specjalista - Mikrokontrolery
    tmf napisał:
    Ale już dodawanie 32-bitowe, to dla ARM 1 takt, dla AVR - 4 takty. Ok, dodajmy pobranie i zapisanie rejestrów, żeby AVR pognębić to mamy ARM 3-4 takty, AVR - 20 taktów. Ale już dla obliczeń na 8-bitach przewagę uzyskuje AVR, bo operacje 8-bitowe są na ARM kosztowne. Pytanie po co je stosować, skoro możemy bezkarnie wydłużyć typ.

    Są dziesiątki innych instrukcji które, na ARM będą trwały jeden cykl, a na AVR dziesiątki cykli. A są instrukcje które robią więcej niż jedna operacja w jednym cyklu.
    tmf napisał:
    Mamy upakowany kolor RGB na 32-bitach, trzeba teraz przemnożyć składowe przez alfa. Na ARM - dekompresja RGB na 3*32bity, mnożenie i składanie tego spowrotem.

    Trzeba byłoby zobaczyć jak sobie z tym kompilatory poradzą. Bo nie wydaje mi się żeby była jakaś wielka różnica.
  • #98
    tmf
    Moderator Mikrokontrolery Projektowanie
    piotr_go napisał:
    tmf napisał:
    bo operacje 8-bitowe są na ARM kosztowne

    eeeeee? Od kiedy? Przecież można czytać/zapisywać na ARM także pojedyncze bajty. Przejrzyj zestaw instrukcji bo bzdury gadasz.


    Czytać i zapisywać możesz. Ale jak wygląda mnożenie dwóch 8-bitowych zmiennych? Raczje trzeba najpierw znormalizować wartość w rejestrze. Nie wiem, czy jest w asemblerze instrukcja typu pobierz 8-bitową wartość z rozszerzeniem na 32-bity dla wartości signed lub unsigned.

    Dodano po 12 [minuty]:

    michalko12 napisał:
    tmf napisał:
    Ale już dodawanie 32-bitowe, to dla ARM 1 takt, dla AVR - 4 takty. Ok, dodajmy pobranie i zapisanie rejestrów, żeby AVR pognębić to mamy ARM 3-4 takty, AVR - 20 taktów. Ale już dla obliczeń na 8-bitach przewagę uzyskuje AVR, bo operacje 8-bitowe są na ARM kosztowne. Pytanie po co je stosować, skoro możemy bezkarnie wydłużyć typ.

    Są dziesiątki innych instrukcji które, na ARM będą trwały jeden cykl, a na AVR dziesiątki cykli. A są instrukcje które robią więcej niż jedna operacja w jednym cyklu.
    tmf napisał:
    Mamy upakowany kolor RGB na 32-bitach, trzeba teraz przemnożyć składowe przez alfa. Na ARM - dekompresja RGB na 3*32bity, mnożenie i składanie tego spowrotem.

    Trzeba byłoby zobaczyć jak sobie z tym kompilatory poradzą. Bo nie wydaje mi się żeby była jakaś wielka różnica.


    Z tymi dziesiątkami instrukcji to pojechałeś. Załóżmy, że mówimy o CM0+, bo jeśli myślisz o o instrukcjach DSP to jasne, masz rację. Też kwestia czy mówisz o pełnym zestawie, czy Thumb. Te instrukcje, które wykonują więcej niż jedną operację to najczęściej zrób coś i umieść wynik we wskazanym rejestrze. Znaczy to dwie operacje. Jedyna kosztowna rzecz na AVR to przesunięcia bitowe. W najgorszym przypadku 4 takty, na ARM 1. Oczywiście dla 8-bitowych, dla szerszych typów różnice będą odpowiednio większe.
    Przykład z alfablendingiem właśnie pokazuje, że jakiś dramatycznych różnic nie ma, chociaż na ARM dla RGB888 zysk jest po stronie AVR. Ale już dla RGB565 ze względu na koszty przesunięć zyskuje ARM.
    Niemniej ciągle kręcimy się wokół rzeczy zupełnie nieistotnej, jaką jest rdzeń. Mam nadzieję, że dyskusją o asemblerze nie zwabimy tutaj naszych asm guru :) Piszemy w C/C++ i raczej nam to dokładnie zwisa, jak kompilator sobie poradzi z kodem. W tym sensie, cała dyskusja jest zbędna, bo procek albo ma wystarczające możliwości obliczeniowe do realizacji zadania albo nie ma. Jak zacznę na elce.czy w ogóle wśród amatorów, oglądać projekty, w których te możliwości obliczeniowe ARMów są wykorzystywane to zmienię zdanie. Tym bardziej, że to co często mozolnie kodujemy bez problemu rozwiązuje układ peryferyjny. Więc raczej warto się nad tym zastanowić. I tu można wrócić do wymienionych nowych ATTiny, żeby zastanowić się czy oferują coś przydatnego.
  • #99
    piotr_go
    Poziom 28  
    tmf napisał:
    Czytać i zapisywać możesz. Ale jak wygląda mnożenie dwóch 8-bitowych zmiennych? Raczje trzeba najpierw znormalizować wartość w rejestrze. Nie wiem, czy jest w asemblerze instrukcja typu pobierz 8-bitową wartość z rozszerzeniem na 32-bity dla wartości signed lub unsigned.

    A od kiedy dane RGB są signed?
    LDRSB, STRSB czyta i zapisuje bajty ze znakiem.
    LDRB, STRB czyta i zapisuje bajty bez znaku.
  • #100
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #101
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Mnożenie, dodawanie, przesuwanie... Czemu nie pogadamy o dzieleniu? Czemu nie pogadamy o tym, jaką wielką różnicą jest fakt, że operacje 32-bitowe dla architektury 32-bitowej są "atomowe", więc w wielu sytuacjach nie trzeba się bawić w żadne sekcje krytyczne i wyłączanie przerwań? Czemu zakładasz, że w projekcie operacje na macierzach czy liczenie CRC nie mogą być robione programowo? Na 8-bitowych układach może nie, ale czemu miałbym sobie odmawiać mnożenia macierzy przez wektor w 32-bitowym układzie? Akurat tak się składa, że całkiem niedawno miałem taki projekt - było tam całkiem sporo matematyki na liczbach zmiennoprzecinkowych, włącznie z mnożeniem macierzy przez wektor (chodziło o rotację punktu w trójwymiarowej przestrzeni). Na 8-bitowym układzie nawet by nikt tego nie rozważał, a tu? Żaden problem. Kiedyś - w pierwszej wersji tego projektu - nawet sprawdzałem ile trwa cały cykl obliczeń i wyszło mi, że do 30 tysięcy cykli zegara (to było na STM32F1, więc bez FPU). Ciekawe ile by trwało na AVR... Myślę że nie 10x dłużej, tylko z 1000x dłużej. I właśnie taki jest sens benchmarków. Tak jak przy pewnej dyskusji jakiś czas temu tez nie udało się pewnego forumowicza przekonać do tego, że mikrokontrolerów używa się do czegoś innego niż sterowanie przez PWM jednej grzałki na podstawie jednego czujnika temperatury, tak teraz chyba Ciebie nie uda się przekonać o tym, że mikrokontrolerów można używać też do zadań w których potrzebne są szybkie obliczenia polegające na czymś więcej niż dodawanie 8-bitowych wartości.

    Czy np. implementacja RTOSa na 8-bitowym układzie też będzie taka dobra jak na 32-bitowym, skoro overhead jest spowodowany głównie tym ile trzeba zachować rejestrów i chodzi tutaj akurat o ich ILOŚĆ? No i oczywiście sekcja krytyczna przy najbardziej durnej operacji na typie większym niż 8-bitów (czyli praktycznie każda).

    Czy dowolne operacje na wskaźnikach (z oczywistych względów większych niż 8-bitów) też są tylko "troszkę" wolniejsze niż na 32-bitowym układzie?
  • #102
    piotr_go
    Poziom 28  
    Piotrus_999 napisał:
    Troszkę szacunku dla kol. tmf, którego wiedzy i doświadczenia nikt rozsądny na tym forum nie będzie kwestionować. Można dyskutować, spierać się, mylić ale kol @piotr_go zachowuj się jakoś.

    Doświadczenia tylko i wyłącznie w AVRach, o ARMach nie ma pojęcia co udowodniłem post wyżej.
    Żeby moderator rozsiewał takie bajki?
    Projektów nie kojarzę (elektrodowa szukajka nie wyszukuje tematów autora :( ).
  • #103
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #104
    piotr_go
    Poziom 28  
    Piotrus_999 napisał:
    Co nie oznacza że można pisać co Ci skapnie na klawiaturę. Pewnie rozmawiając twarz w twarz byś tak nie rozmawiał.

    A to niby czemu? Obraziłem go czy coś? Używałem niecenzuralnych słów?
    Czy skłamałem? Nie.
    Czy tmf minął się z prawdą? Tak.
    Ja w XMEGAch nie doradzam jak ich nie znam.
  • #105
    Użytkownik usunął konto
    Poziom 1  
  • #106
    piotr_go
    Poziom 28  
    Odnośnie tematu to polecam taki zestawik ARM Cortex M0/M3:

    1. Programator ST-LINK V2
    Jaki mikrokontroler po AVR? -

    2. stm32f103c8t6 board
    Jaki mikrokontroler po AVR? -

    3. stm32f030f4p6 board
    Jaki mikrokontroler po AVR? -

    Źródło: Aliexpress.
    Koszt około 20zł za komplet.
  • #107
    tmf
    Moderator Mikrokontrolery Projektowanie
    piotr_go napisał:
    tmf napisał:
    Czytać i zapisywać możesz. Ale jak wygląda mnożenie dwóch 8-bitowych zmiennych? Raczje trzeba najpierw znormalizować wartość w rejestrze. Nie wiem, czy jest w asemblerze instrukcja typu pobierz 8-bitową wartość z rozszerzeniem na 32-bity dla wartości signed lub unsigned.

    A od kiedy dane RGB są signed?
    LDRSB, STRSB czyta i zapisuje bajty ze znakiem.
    LDRB, STRB czyta i zapisuje bajty bez znaku.


    Po pierwsze czytaj uważniej, już o to prosiłem. Nigdzie nie pisałem, że RGB jest signed. No nic, postaram się pisać prościej, żeby inni nadążali :)
    Dwa, ok, można odczytując rejestr rozszerzyć go do 32-bitów, a co jeśli dane są już w rejestrze? Trzeba wykonać dodatkową instrukcję, bo MUL działa tylko na typie 32-bitowym. Poza tym te zagadnienia mnie miernie interesują, bo używam C, a do asemblera zaglądam rzadko, jako że nie jestem paranoikiem i nie doszukuję się błędów w kompilatorze. Prawdę mówiąc widzę asembler tylko jak mnie tam debugger z jakiegoś magicznego powodu wrzuci. Żeby nie było, tak wygląda sekencja mieszania kolorów:
    Kod: armasm
    Zaloguj się, aby zobaczyć kod
  • #109
    tmf
    Moderator Mikrokontrolery Projektowanie
    @Marek_Skalski Owszem, FT8xx są świetne i ich używam. Ale do prostych projektów można czasami zabawić się czymś innym. Używam też modułów HMI, bo nie zawsze mnie bawi pisanie GUI, szczególnie jeśli to samo mogę wyklikać w 5 minut. Staram się dobierać rozwiązania aby było mi wygodniej (jako hobysta mogę sobie na to pozwolić). Piszesz o ARMach z magistralą do LCD - to dodaj tylko, że to zupełnie poza zasięgiem hobbystów. Raz, że one są w obudowach >160 pinów, dwa, że będą wymagać zewnętrznej pamięci, bo nie mają na pokładzie kilkuset kB do sterowania matrycą, trzy, że to wszystko połączyć na dwóch warstwach zakrawa o magię. Cztery, że cena takiego rozwiązania będzie wyższa niż dowolny MCU + kontroler z LCD. Przynajmniej w warunkach domowych. A jak mam mieć wydajną grafę to mogę to zrobić na FT8xx + dowolny procek. A jak ma być tanio, to jakiś budżetowy moduł LCD, przy czym w wielu przypadkach wąskim gardłem jest i tak interfejs MCU-LCD i wydajność MCU nie ma większego wpływu. No o ile ktoś nie robi na tym grafiki 3D.
    A na koniec - trudno się nie zgodzić, że to co wymieniłeś to fajne zabawki. Tylko pokaż mi projekty hobbystów, które z tych peryferii korzystają. Na elce nie widziałem żadnego, w necie też niewiele. Zresztą jak niewiele osób z tych bajerów korzysta to widać, gdy ktoś zada pytanie na forum - zwykle w temacie cisza. Ty się tym zajmujesz profesjonalnie, to masz inne spojrzenie. Hobbyści jak pokazuje rzeczywistość siedzą na Arduino i ich nasze dywagacje niezbyt interesują. Albo kupią sobie devboardy z STM, bo są tanie i modne, odpalą kilka przykładów i są szczęśliwi bo "programują ARMy". Swoją drogą nie ja zacząłem te porównania, jeśli zaglądniesz do pierwszych postów, które ten wątek wyczerpują to poznasz moją opinię, dalece odmienną, od tego co tu niektórzy insynuują.
  • #110
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #111
    piotr_go
    Poziom 28  
    tmf napisał:
    Po pierwsze czytaj uważniej, już o to prosiłem. Nigdzie nie pisałem, że RGB jest signed. No nic, postaram się pisać prościej, żeby inni nadążali

    Post #98 zasugerowałeś problem z signed.

    tmf napisał:
    ok, można odczytując rejestr rozszerzyć go do 32-bitów, a co jeśli dane są już w rejestrze? Trzeba wykonać dodatkową instrukcję, bo MUL działa tylko na typie 32-bitowym

    eeeeee? Nic? Zostanie zastąpiony w całości wartością 8mio bitową.

    tmf napisał:
    Żeby nie było, tak wygląda sekencja mieszania kolorów

    Dobra, dobra, jeszcze poprosimy odpowiednik w c i ustawiony stopień optymalizacji.
  • #112
    tmf
    Moderator Mikrokontrolery Projektowanie
    @piotr_go Przeczytaj jeszcze raz post #98 - tam nawet nigdzie RGB nie pada. Pokazany kod jest dla -Os, w gcc.
  • #113
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #114
    Użytkownik usunął konto
    Poziom 1  
  • #115
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #116
    piotr_go
    Poziom 28  
    tmf napisał:
    Przeczytaj jeszcze raz post #98 - tam nawet nigdzie RGB nie pada

    Ja to mam chyba jakiś inny internet:
    tmf napisał:
    ...chociaż na ARM dla RGB888 zysk jest po stronie AVR...

    i poprzedni:
    tmf napisał:
    ...Mamy upakowany kolor RGB na 32-bitach, trzeba teraz przemnożyć składowe przez alfa...

    Więc czego to dotyczyło jak nie RGB?


    Aaaaaa, gdzie kod w C?
  • #117
    Użytkownik usunął konto
    Użytkownik usunął konto  
  • #118
    piotrek0207
    Poziom 14  
    tmf napisał:
    Albo kupią sobie devboardy z STM, bo są tanie i modne, odpalą kilka przykładów i są szczęśliwi bo "programują ARMy".


    Ale to chyba nic złego kupić devboarda od ST dla amatora i zacząć od ARMów zamiast AVRów?
    Zwłaszcza, że są bogate w peryferia. Mają na pokładzie np. i ADC i DACa. Można zrobić proste DSP bez konieczności dokupywania dodatkowych elementów. Kilka USARTów, SPI, I2C i timerów. Mnie zaciekawił i zachęcił do zakupu Discovery wspomniany już sprzętowy generator liczb losowych. Amator czuje satysfakcję, że nie "spuchł"na widok RM na 1700 stron i umie kilka rzeczy uruchomić na rejestrach bez użycia nieszczęsnych bibliotek od ST :)
  • #119
    dondu
    Moderator Mikrokontrolery Projektowanie
    piotrek0207 napisał:
    Ale to chyba nic złego kupić devboarda od ST dla amatora i zacząć od ARMów zamiast AVRów?
    ...
    Amator czuje satysfakcję, że nie "spuchł"na widok RM na 1700 stron i umie kilka rzeczy uruchomić na rejestrach bez użycia nieszczęsnych bibliotek od ST :)

    Jeśli sobie poradził, to jak najbardziej. Tylko bić brawo należy.

    Ale problem polega na tym, że niewielu daje radę ... dlatego mamy przedszkola, szkoły i uczelnie wyższe, bo prawie żaden przedszkolak nie radzi sobie z trygonometrią, całkowaniem, liczbami zespolonymi, ... o technicznym języku angielskim już tylko wspomnę :)
  • #120
    Użytkownik usunął konto
    Użytkownik usunął konto