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

8-bit vs. 32-bit - kolejna dyskusja

BlueDraco 23 Gru 2019 22:27 13221 368
  • #241
    atom1477
    Poziom 43  
    A użyłeś tam jakiegoś STD_LOGIC_VECTOR o długości 32 bity?
    Bo jak tak to możesz spać spokojnie :D
  • Computer ControlsComputer Controls
  • #242
    LChucki
    Poziom 31  
    RitterX napisał:
    Najbardziej mnie gniecie, że jak przepłacę poniżej 1. euro za uC 32bit.

    Nie przepłacisz przynajmniej jeśli chodzi o STM32 vs AVR. Nawet w przypadku 8-pin STM32 jest tańszy a im większe zasoby tym różnica coraz większa na korzyść STM32. Najnowszy przykład https://www.elektroda.pl/rtvforum/topic3642727.html gdzie za dwa razy niższą cenę kupisz wypasionego STM32L412R8. Naturalnie mowa o cenach hurtowych.

    Co do wypowiedzi
    Urgon napisał:
    Zresztą jak ktoś musi do prostego projektu pchać coś 32-bitowego, gdy zwyczajowo i ośmiobitowiec da radę, to to raczej negatywnie świadczy o umiejętnościach takiej osoby...

    Jaki sens pchać drogiego 8-bit nad którym trzeba się napracować aby osiągnąć zamierzony efekt, jak można użyć tańszego 32-bit, który ma 10 razy za dużo zasobów? Jak Z-8 podoła to mam go użyć? Albo 8035?
    Sztuka dla sztuki?

    Czasy C-64, Atari i ZX-Specrtum minęły. Nie trzeba kilka dni pisać prostej funkcji bo brakuje kilku cykli zegara czy kilku bajtów pamięci.
  • #243
    bart-projects
    Poziom 16  
    Pisząc dla zleceniodawców apki niektóre rzeczy przerzucam na moc obliczeniową telefonów. To proste, a uC jest dalej uC i tylko zbiera dane.
    Chyba kilka rzeczy zalezy od zadania.. cos uogulniasz, jak zwykle , nic sie nie uczysz. Ciekawe czy umiałbys napisać program na pralkę na 8 bit ahahahaha bo one nie mają korteksów wiesz? w ogóle?
  • Computer ControlsComputer Controls
  • #244
    _lazor_
    Moderator Projektowanie
    Sprzęt AGD ma najczęściej renesas'a na pokładzie. Jak się dopytałem znajomych co robili w AGD to są najczęściej 16 bitowe mikrokontrolery.
    AGD rządzi się też jednym prawem - jeśli coś wygląda głupio, ale działa i jest o cent za sztukę tańszę to używamy.
    Dla przykładu używali mosków prostowniczych w roli diody... bo ludziom od zakupów wychodziło to taniej.
  • #245
    bart-projects
    Poziom 16  
    No i ten typ rozumowania przyjmuję bo się z nim spotykam :D
    Projektuje układy jak najlepiej umiem.. a czasem jak patrze na spalony układ pralki to myślę...wymiana.. a dopiero potem ktoś nad tym chyba myślał żeby się to wszystko tak spaprać
    I teraz nie wiem kto mądrzejszy....

    Dodano po 2 [minuty]:

    rzadko naprawiam pralki - gwoli scisłości - ale swoje widziałem
  • #246
    LChucki
    Poziom 31  
    bart-projects napisał:
    Ciekawe czy umiałbys napisać program na pralkę na 8 bit ahahahaha bo one nie mają korteksów wiesz? w ogóle?

    Nie wiem do kogo kierujesz pytanie bo nie masz w zwyczaju używać cytatów ale biorąc pod uwagę, ze wypowiadasz się zaraz po mnie to pewnie masz mnie na myśli. Na forach już tak jest, ze trzeba się domyślać, co pytający ma na myśli, taki urok współczesnej młodzieży.

    Czy napisze soft dla pralki na 8-bit? Bez problemu a nawet na 4-bit to zrobię, bo, według @urgon jestem ekspertem nad ekspertami bo nie tylko na bramkach logicznych czy tranzystorach/diodach ale i na przekaźnikach taki sterownik potrafię zrobić. To, ze prace będą trwać długo, urządzenie będzie kosztowne to już inna para kaloszy bo podłączenie do przekaźników jakiegoś drogiego PLC z jeszcze droższym wyświetlaczem aby wyświetlać menu będzie kosztować.
  • #247
    atom1477
    Poziom 43  
    LChucki napisał:
    Jaki sens pchać drogiego 8-bit nad którym trzeba się napracować aby osiągnąć zamierzony efekt, jak można użyć tańszego 32-bit, który ma 10 razy za dużo zasobów? Jak Z-8 podoła to mam go użyć? Albo 8035?
    Sztuka dla sztuki?

    Jaki sens pchać nawet tańszego 32-bit, jak 8-bit ma analogowe piny 5V.
    32-bitowy działający na 5V był by jakimś dziwolągiem. Na pewno takie są ale to znowu pewnie by więcej kosztował.
    Taki na 3.3V wymagał by dodania przetwornika ADC na 5V, i stosowania dwóch stabilizatorów napięcia do nich.
  • #248
    LChucki
    Poziom 31  
    atom1477 napisał:
    LChucki napisał:
    Jaki sens pchać drogiego 8-bit nad którym trzeba się napracować aby osiągnąć zamierzony efekt, jak można użyć tańszego 32-bit, który ma 10 razy za dużo zasobów? Jak Z-8 podoła to mam go użyć? Albo 8035?
    Sztuka dla sztuki?

    Jaki sens pchać nawet tańszego 32-bit, jak 8-bit ma analogowe piny 5V.
    (...)
    Taki na 3.3V wymagał by dodania przetwornika ADC na 5V

    No fakt, dodanie dzielnika złożonego z dwóch rezystorów to ogromny koszt. Jeśli nawet nie to pewnie obliczenie ich wartości jest trudne i trzeba sięgać po zewnętrzny ADC.
  • #249
    _lazor_
    Moderator Projektowanie
    jeśli potrzebny jest output 5V to może być problem, jeśli tylko input z czujnika jest 5V to piny 5V tolerant jak najbardziej wystarczają.
    Często i tak się jeszcze stosuje bufory na wzmacniaczach czy filtry dolnoprzepustowe więc tam można przy okazji wprowadzić dzielnik napięcia. Jako że to jest dość standardowa praktyka w projektowaniu to wzmacniacze są dorzucane bardzo często do układu, aby nie generować dodatkowych kosztów oraz nie zabierać miejsca dla wyjściowego produktu.
  • #250
    atom1477
    Poziom 43  
    LChucki napisał:
    No fakt, dodanie dzielnika złożonego z dwóch rezystorów to ogromny koszt. Jeśli nawet nie to pewnie obliczenie ich wartości jest trudne i trzeba sięgać po zewnętrzny ADC.

    Czekałem na ten argument.
    Czyli mamy zastosować dzielniki, byle tylko nie użyć mikrokontrolera 8-bit*.
    No przecież dzielnik taki prosty.
    Do zasilania LEDa też stosujesz dzielnik, czy może sam rezystor?

    *Czy nie taki argument jest stosowany przeciwko 8-bitowcom? Że coś tam trzeba do nich dodać żeby uzyskać funkcjonalność 32-bitowca? Oczywiście nie mówię o wydajności, tylko o jakichś peryferiach który 8-bitowiec nie ma.
  • #251
    LChucki
    Poziom 31  
    _lazor_ napisał:
    jeśli potrzebny jest output 5V to może być problem

    Jeśli wyjście cyfrowe to przeważnie nie problem. Wystarczy wyjście ustawić w tryb OD i podciągnąć rezystorem do 5V (wyjście to, w trybie wejścia musi akceptować 5V ale problem może być tylko w starszych rodzinach jak F1, nowsze jak F4 mają wszystkie 5V tolerant).
    Jeśli analogowe, to w większości wypadków i tak jest jakiś oamp i zmiana wzmocnienie nie jest problemem.

    @atom1477 sztucznie wynajduje problem w ARM aby wykazać wyższość AVR tylko ardumenty ma chybione.

    Dodano po 4 [minuty]:

    atom1477 napisał:
    *Czy nie taki argument jest stosowany przeciwko 8-bitowcom? Że coś tam trzeba do nich dodać żeby uzyskać funkcjonalność 32-bitowca? Oczywiście nie mówię o wydajności, tylko o jakichś peryferiach który 8-bitowiec nie ma.

    Wygrywa zwykła matematyka. Drogi uC bez rezystorów a często zmiana ich wartości czy tani uC + dwa rezystory?
    Jak się upre to wykażę, że w wybranym projekcie 4004 byłby lepszy od AVR ale będzie to się miało nijak do rzeczywistości jak wiele sond, według których wszyscy operatorzy GSM mają najwięcej klientów.
  • #252
    atom1477
    Poziom 43  
    A w mniejszości przypadków nie ma oampa. I to jest przypadek jaki wymieniłem.
    Zresztą tam było 10 wejść, więc to by było 10 dzielników. A wyjścia ratiometric więc trzeba by też przenosić poziom napięcia zasilania 5V.
    I czy ja gdzieś pisałem o wyższości AVRa nad ARMem?
    Jeżeli już to w tym konkretnym specyficznym przypadku. Argument nie jest więc chybiony, tylko po prostu jest jednym małym argumentem, w gąszczu innych argumentów w przeciwną stronę. Nie świadczy więc ogólnie o wyższości AVRa nad ARMem.
    Nie zrozumiałeś tego co napisałem, jeżeli tak to odebrałeś.
    To co napisałem bo był tylko kontrargument na to że nigdy 8-bitowiec nie nadaje się lepiej do projektu. Mój argument pokazuje że nie zawsze się nie nadaje. Czasami się nadaje lepiej. Podkreślam słowo czasami.

    Kompletnie nie zrozumiałeś mojego przykładu, zakładając że upycham projekt w 8-bitów na siłę. Jak kamyczek. Byle tylko nie użyć procesora co ma za dużo FLASHA i za dużo RAMu.
    A to zupełnie nieprawda.
    Sam przeszedłem na 32-bity, i stosuję je wszędzie gdzie się da nawet jak wymagana moc obliczeniowa jest mała i projekt by działa na 8-bitowcu.
    Ale używam tu argumentu logicznego, a nie siłowego. Czyli logika mnie kieruje do zastosowania 32-bitowca. Mniejszy koszt, łatwość zaprogramowania (i programowo w kompilatorze, i sprzętowo przez SWD), dostępne peryferia (ADC 12-bitowe, wiele UARTów), itp.
    A nie siła, że ma być 32-bity i koniec.
    W przypadku projektu jaki opisałem, też zadziałała logika. 32-bitowiec nie przedstawiał żadnych zalet (nie trzeba wielu UARTów, dużej mocy obliczeniowej, koszt jest podobny), a wprowadzał jedną, może małą, ale jednak wadę. Konieczność przenoszenia napięcia z 5V na 3.3V.
    Czy są logiczne argumenty za 32-bitowcem 3.3V? Bo sama łatwość zastosowania dzielników jest niczym wobec całkowitego braku stosowania dzielników.
    Pisząc o łatwości zastosowania dzielnika nie dowodzisz że to jest zaleta, a jedynie dowodzisz że to jest mała wada.
  • #253
    RitterX
    Poziom 38  
    atom1477 napisał:
    A użyłeś tam jakiegoś STD_LOGIC_VECTOR o długości 32 bity?
    Bo jak tak to możesz spać spokojnie :D

    No to mnie zdruzgotałeś, nie pamiętam czy użyłem! Teraz już na pewno nie będę spał spokojnie, tylko leżał i myślał.

    #
    Opowieść Wigilijna :) .
    Możecie to potraktować jako kolejny żart, tym nie mniej rzecz wydarzyła się naprawdę. Jest tak pokręcona jak kraj w dobie przemian.
    Spotkałem taki projekt robiony etapami, magistrala ModBus RTU. W czujnikach siedziały AVR-y w czymś na kształt centralki zbiorczej i komunikacyjnej PIC. Dalej był 16bit. Renesans jako moduł sterujący, z drukarką odpowiadał dodatkowo za dokumentację procesu plus jeszcze jeden Renesans 16bit. do wyświetlacza TFT i klawiatury. To wszystko i tak było na łasce MC68HC11 :) . Urządzenie, nazwijmy je "mieszalnikiem" produkowało coś bardzo biologicznego.
    Cały system rósł tak jak wiele firm gdzie najpierw kupuje się Mercedesy a później pyta jak długo wytrzymają urządzenia produkcyjne. Na początku był jeden mieszalnik i pomysł na produkcję. Właściciele zatrudnili "dawcę zero" :) , który przełożył to na kod maszynowy do MC68HC11 z zewnętrznym EPROM+RAM. Taka była wtedy mądrość etapu. Interes na tyle dobrze się kręcił, że dostawiano kolejne Mercedesy na parkingu a mieszalniki w hali poprzez ich klonowanie. Gdy tego zrobiło się już całkiem sporo a wspomniany "dawca zero" wybył na zachód od Odry właściciele podrapali się w głowę bo zrobiło się jakoś nieciekawie. Chcąc sklonować magiczny wsad postanowili, że wypadałoby to oczujnikować i zrobić inżynierię wsteczną gdyż jakoś słabo szło im znalezienie kogoś do rozpracowania kodu z MC68HC11.
    Na skutek procesu poszukiwań pojawił się spec od PIC-y i stworzył centralkę pod czujniki z ModBus-em RTU. Etap bliżej inżynierii wstecznej zakończył się sukcesem ale jedynie połowicznym. Pojawił się problem gdyż albo spec od PIC-ów podniósł cenę za całość, łącznie z przeniesieniem kodu z MC68HC11 albo też właściciele - sknery czytając ogłoszenia i rozmawiając z potencjalnymi nowymi wykonawcami stwierdzili "dobra nasza ModBus hula, czujniki to prosta sprawa, co może się nie udać?" Koleś od PIC-owania wyleciał i w jego miejsce pojawił się koleś od czujników na AVR-ach. Zrobił czujniki, pożenił z centralką i nawet się zarzekał, że zrobi transkrypcję kodu z Motoroli a nawet dokończy dzieło czyli dokumentator i moduł nadzorujący sterowanie wieloma mieszalnikami.
    Znowu nie wiadomo co się stało ale się stało. Nie łudźmy się AVR jest trochę za słaby na 5" TFT . Tu pojawia się prawdziwy heros, 16bit. od Renesansa w repertuarze to nie w kij dmuchał :) . Ciachnął dokumentator, grafikę i drukarkę a na koniec pożegnał zleceniodawców.
    Akurat w tym momencie na scenę wchodzi UE :) . No nie ma przebacz, w UE nie patrzy się na taką partyzantkę przychylnie, HACCP-y i inne wynalazki potrafią być bardzo dokuczliwe. Doszło do tego, że system musiał mieć bazę danych by zbierać i dokumentować procesy produkcji. Nie pytajcie mnie dlaczego etap centralka-system dokumentująco-sterujący nie był na PC z dodaniem wewnętrznej karty komunikacyjnej albo mostka pod USB?! Nie każda decyzja jest logiczna. Mogę jedynie podejrzewać, że 16bit. specjalista wolał wpakować swoją technologię, którą dokładnie znał jak babrać się w RtLinux-a albo w coś płatnego np. QNX-a . Zleceniodawcy zapewne po tylu zmianach w projekcie mieli już taki mętlik w głowach, że jedyne na co mogli się zdobyć to dryfować z prądem. Nawet nowe Mercedesy przestały ich cieszyć jak poprzednio.
    No dobra, jesteśmy na etapie UE i jej paranoi poziom ekspert, HACCP i całej reszcie. Właściciele radzi nie radzi, po różnych konsultacjach, może nawet tutaj na elektrodzie, postanowili wejść w coś uniwersalnego na trzy litery czyli... PLC. Pojawili się kolesie od PLC i ponoć jak to zobaczyli to zapłakali a chwilę później właściciele jak usłyszeli cenę za wyprostowanie tego. Przypomnę tylko, że mieszalniki na tym etapie były nadal nadzorowane na najniższym poziomie na HC11 a reszta była przybudówką. Tym samym pozostał nierozwiązanym problem sterowania mieszalnikami, który zapisany w .bin 32kB EPROM-owej pamięci robił robotę, której nikt specjalnie nie mógł rozszyfrować! No tak to się dzieje jak ktoś do 8. bitowca pakuje zbiory rozmyte i takie tam, czego nikt zdrowo myślący by się nie spodziewał :) .
    Opowieść skończyła się szczęśliwie i to pomimo jeszcze dwóch zwrotów akcji :) . Okazało się, że nie jest wcale tak prosto pozbyć się HC11 ale po przebrnięciu przez ten etap reszta była już jedynie rzemiosłem.
  • #255
    tronics
    Poziom 37  
    Urzekła mnie ta historia :) Ale rzeczywiście, jest drobny rynek, ale jest dość bogaty dot. przenoszenia projektu ze starych sterowników (PLC) na nowe ... bo za serwisowanie starego sprzętu się płaci więcej niż raz a dobrze zainwestować w nowe i łebskiego kolesia co to ogarnie. I obnażona cecha narodowa, przesadne kombinowanie na dłuższą metę jest nieopłacalne.
  • #256
    tzok
    Moderator Samochody
    LChucki napisał:
    Czasy C-64, Atari i ZX-Specrtum minęły. Nie trzeba kilka dni pisać prostej funkcji bo brakuje kilku cykli zegara czy kilku bajtów pamięci.
    Wręcz przeciwnie, coraz więcej ludzi wraca do tych komputerków i zwyczajnie bawi ich pisanie na nie dem i nowych gier.

    Jeśli chodzi o Arduino to zazwyczaj jest to przerabianie gotowego kodu, ale ludzi to bawi i sprawia im to przyjemność.

    Masz zbyt zawodowe podejście do tematu, nie możesz zrozumieć, że ludzie się tym bawią hobbystycznie dla przyjemności, czasem właśnie po to aby udowodnić, że się da.
  • #257
    Urgon
    Poziom 36  
    AVE...

    LChucki ma ten problem, że on zna się na tych swoich ARMach i jest zaślepiony swoją miłością do nich. Wsadzałby je wszędzie, nawet tam, gdzie byle ATTiny czy PIC10/12F da radę. Dzielnikami i buforami rozwiązuje problemy, których by nie miał używając ośmiobitowca.

    A co do pisania prostych funkcji, to pozwolę sobie posłużyć się przykładem programu, który na wciśnięcie przycisku zapala diodę LED.
    Najpierw PIC16F1827 - ośmiobitowiec.

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Ten sam przykład, tym razem z tutoriala gdzieś w internetach, dla STM32F103:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Nic więcej nie trzeba dodawać...
  • #258
    _lazor_
    Moderator Projektowanie
    Myślę że jednak dyskusja przypomina taki o to fragment:

    https://youtu.be/e1IfOzZH1TQ?t=110


    @Urgon

    Jak ktoś nie potrafi programować to każde trywialne zadanie rozwinie do bardzo dużego kodu.

    https://www.elektroda.pl/rtvforum/topic3520355.html

    Masz przykład jak minimalnie obsłużyć cortex-m. To co pokazałeś to jest jakiś ponury żart.
  • #260
    atom1477
    Poziom 43  
    Akurat na ARMie można pomigać LEDem w kilku linijkach assemblera, więc Twój przykład niczego nie dowodzi.
  • #261
    _lazor_
    Moderator Projektowanie
  • #262
    tzok
    Moderator Samochody
    Problem w tym, że początkujący też się nie zna i prawdopodobnie znajdzie ten sam tutorial... na pewno będzie też chciał pisać w C++ ew. w C, a na pewno nie w ASM.
  • #263
    atom1477
    Poziom 43  
    Ja natomiast nie kultywuję mitów :D
    Przypominam że mój przykład z enkoderem na AVR to nie był przykład mający porównać całą rodzinę AVR do ARM (że niby AVR jest lepszy), a jedynie pokazać że istnieją przypadki (rzadkie, ale jednak) gdzie prostszy procesor ma zalety nad nowszym, mocniejszym i tańszym ARMem.
    Co nie przekłada się oczywiście na pozostałe przypadki. Gdzie nawet gdy wystarczył by mniejszy procesor, to wstawia się ( i ja też wstawiam) ARMa. Bo po prostu tak się bardziej opłaca z każdej strony (ze względu na koszt pisania kodu również).
    To po prosu taki etap rozwoju. Kołodzieje i kowale też odeszli w zapomnienie.

    Każdy zresztą korzysta z pewnego przedmiotu i nawet sobie nie zdaje sprawy jak zaawansowany technologicznie i jak nadmiarowy on jest. Tym czymś jest nakrętka (albo i śruba).
    Jak ktoś wie jak wyglądał proces produkcji śrub i nakrętek w XIX wieku ten się domyśla o czym mówię.
    Dzisiaj się to robi z odkuwek, za pomocą nagniatania. Co daje dobrą jakość powierzchni zewnętrznej jak i gwintu, oraz dużą wytrzymałość gwintu. A na koniec się to cynkuje.
    A do wielu zastosowań nie jest to przecież potrzebne. Wystarczyła by nakrętka nacinana i niecynkowana.
    Ale nikt nie szuka innych nakrętek tylko daje tą dobrej jakości nakrętkę cynkowaną.
    Zdarza się jednak że potrzeba konkretnie niecynkowaną. Gdy trzeba spawać. Ocynk nie daje się spawać i wydziela trujące gazy (są przypadki śmierci spawaczy po próbach spawania ocynku).
    Tak samo tutaj. Stosuje się 32-bity nawet jak jest to mocno nadmiarowe.
    Ale są przecież i przypadki, jak jakaś cecha nowych procesorów jest na tyle uciążliwa że trzeba sięgnąć po jakiś starszy procesor. Są to oczywiście rzadkie przypadki. Ale są.
  • #264
    _lazor_
    Moderator Projektowanie
    tzok napisał:
    Problem w tym, że początkujący też się nie zna i prawdopodobnie znajdzie ten sam tutorial... na pewno będzie też chciał pisać w C++ ew. w C, a na pewno nie w ASM.


    Tylko po co w assemblerze? To co ja zawarłem w artykule to taka śmieszna rzecz, gdyż to są podstawy (startup, linker script, makefile, cruntime), które i tak są schowane przez IDE, są realizowane "automagicznie", więc można sobie od razu pójść do funkcji main, gdzie jest kilka linijek w C... i to zagmatwanych, gdyż chciałem pokazać po co jest c runtime i jak to koresponduje z linkerem.

    Ale to były tylko oczekiwania, ludzie są ludźmi i doba internetu tego nie zmieniła.
  • #265
    tronics
    Poziom 37  
    No tak, ale dla ARM się dodaje startup.s ;) Czasem trzeba w skrypcie linkera pogrzebać. Dla osoby postronnej jest to niewątpliwie więcej rzeczy, które trzeba zrobić wokół ARM niż się robi w AVR. Czy to cokolwiek zmienia? No w zasadzie to nie, bo przykład Urgona to taki trochę z pupy jednak był, to tak jakby budować dwa bloki, pokazać że w pierwszym przyszedł majster, wyciągnął pacę, wiadro, zaprawę, mieszadło i po 10 minutach tynkował, a w drugim dopiero rozciągało się przewody z agregatu ;) I na tym etapie by ktoś powiedział "nooo, to majster lecący ręcznie lepszy". Tak, ale jak problemem nie będzie kawałek tynku 2x2m to agregat będzie lepszy. Dla hobbysty co jest przeszkodą w ogarnięciu ARM? No żadnej rzeczywistej przeszkody nie ma.
    Arduinowate można zrobić idealnie na STM32F1 (na innych trochę gorzej, ale ujdzie). Displaye i czujniki w dużej mierze działają na 3V3 (a wiele nawet nie działa na 5V już!) Płytki są tanie jak barszcz. Wyprowadzeń jest więcej (mowa o bluepill). Dodatkowo jest zdecydowanie więcej pamięci. Ok... to załatwiliśmy sprawę hobbystów, którzy racjonalnie awersji do ARM nie są w stanie wytłumaczyć.
    Profesjonaliści - tak, śledzę rynek pracy, nie ma w zasadzie ofert w których plusem jest znajomość AVR. Zdarzają się okazjonalnie, ale w mniejszych firmach i nastawionych na specyficzne produkty (np. ZaMeL), poza takimi firmami jednak w znaczącej większości oczekuje się znajomości architektur 32bitowych (niekoniecznie STM32, ale prawie zawsze jakiś ARM).
    8bit ma swoje nisze i się tam broni, dobrze że się broni, nie neguję że tak jest i że tak będzie. Ale już nie wymyślajmy na siłę zalet 8bit gdy ich tak zbyt wiele to wcale nie ma.
  • #266
    Urgon
    Poziom 36  
    AVE...

    @_lazor_
    Możesz mi napisać konkretnie, co jest złego w przykładzie dla STM32, który zapodałem? Bo poszukałem paru innych przykładów i mają one podobne elementy, co ten: jest funkcja main(), która w praktyce nie różni się niczym od wersji 8-bit, i są typowe dla STM32 bloki konfiguracji zegarów i GPIO, oba dość rozbudowane, ale w końcu jest 4 razy więcej bitów, więc trza to wykorzystać. Plus jakieś funkcje do obsługi błędów tak dla ozdoby. Ja to rozumiem bo jako-takie doświadczenie z mikrokontrolerami mam. Ktoś, kto wcześniej programował Arduino, albo w ogóle jest "zielony" raczej się zniechęci po takim przykładzie.

    Ponadto moim celem było odniesienie się do argumentu LChucki nt. tego, że przy 8-bitowcach kod jest bardziej skomplikowany niż przy 32-bitowcach. Jest to prawdą tylko wtedy, gdy chcemy zrobić coś skomplikowanego. W przypadku prostej funkcji kod dla 32-bit ARM jest bardziej skomplikowany. Aha, jeszcze mi się nie zdarzyło, by wymaksować ośmiobitowca z wyjątkiem jednej sytuacji, gdy zaczynałem i napisałem straszliwie nieoptymalny kod, który powtarzał się 64 razy...

    Cała dyskusja jest cokolwiek idiotyczna, bo każdy mikrokontroler ma swoje miejsce i swoje zastosowania. Upieranie się przy stosowaniu "jedynej słusznej architektury" niezależnie od tego, czy będzie to miganie LEDem w 32 bitach przy 200MIPS, czy zabawa w zaawansowane DSP gdzie obliczenia zajmują więcej czasu niż potrzeba na ugotowanie jajka, bo sercem projektu jest 8-bitowy układ z wydajnością 8MIPS przy 32MHz jest wręcz dziecinne. A firmy produkujące towary liczone w milionach sztuk nie będą się cackać i każą umieścić najtańszy zestaw układów, który spełni swoje zadanie. Zestaw, bo jeśli niższa cena ARMa względem układu 8-/16-bitowego jest okupiona dokładaniem dodatkowych buforów i translatorów napięć, nie licząc wielkości PCB, to ARM przegra z mniejszym bitowo układem...

    Jak ktoś umie dobrze programować w ARM, to taki AVR/PIC/STM8 czy inny maluch to pikuś na jedno popołudnie...
  • #267
    khoam
    Specjalista - ESP32, ESP8266
    Urgon napisał:
    Jak ktoś umie dobrze programować w ARM, to taki AVR/PIC/STM8 czy inny maluch to pikuś na jedno popołudnie...

    A świstak siedzi w kącie i zawija w sreberka ... to tak w świątecznym nastroju :)
  • #268
    Miziolek
    Poziom 9  
    Jak dobrze zapłacą - można i 8 bitowce programować i MISRĘ przeżyć. Czym tu się stresować?
  • #269
    _lazor_
    Moderator Projektowanie
  • #270
    RitterX
    Poziom 38  
    _lazor_ napisał:
    Patrzę na odpowiedzi i uznaje że nie będę dyskutował na temat mocznika i saletry. Wypisuje się z tego tematu.

    Jeszcze nie ma Sylwestra a już się wymiksowywujesz :) .

    Ja to lubię sobie poczytać o fetyszach sado-maso :D . No i czytam, co lepsze? "Większy = lepszy...." , "Sprzęt o głupstwo! Liczy się technika...", "Co ty pleciesz, najważniejsza jest gra wstępna na poziomie linkera..." , ... . Serio, porównujecie kto czym dysponuje?
    Jestem w o tyle dobrej sytuacji, że w sumie nie lubię programować a nawet nie potrafię tak dobrze jak szacowne grono. Dla mnie powyższe przykłady zlewają się w całość, gdzie różnica?
    Wychodzę z założenia, że najważniejszy by "klientka" była zadowolona :) . Dajemy coś od siebie, otrzymujemy coś w zamian i tak to się kręci. Jakie to ma znaczenie czy jest tego teoretycznie za dużo albo za mało i kto to ma oceniać? Grunt, że działa i wszystkim zainteresowanym pasuje.
    W dawnych dobrych czasach gdy konstruktor systemów wbudowanych był jak jednorożec trzeba było do pokaźnej wielkości mikrokontrolera zwykle dodać jeszcze zatrzaski adresu, pamięć EPROM/EEPROM a w środku do dyspozycji było zaledwie kilka kB RAM. Jeżeli ktoś przechodził przez taką traumę niedostatku to dzisiaj bez większych oporów projektuje na nadmiarowych mikrokontrolerach. Nie dlatego, że zakłada jakąkolwiek modyfikację albo unowocześnienie softu bo to się nie zdarzy z powodu długości cyklu życia współczesnej elektroniki, ale dlatego, że ma dość "chodzenia w za ciasnych butach".

    Wykończenie zasobów 8bit. ależ proszę bardzo. Wystarczy, że będzie musiał liczyć z określoną dokładnością trygonometrię. To popularny przypadek z życia wzięty np. układ pozycjonujący robota albo manipulatora, Transformacja Clarka i Parka stosowana w sterowaniu silnikami.