Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[Solved] 8051 - Czy ktoś jeszcze w dzisiejszych czasach tworzy coś na 8051 ?

sibislaw 25 Aug 2017 22:49 11868 143
Altium Designer Computer Controls
  • #121
    User removed account
    User removed account  
  • Altium Designer Computer Controls
  • #122
    Freddie Chopin
    MCUs specialist
    kamyczek wrote:
    Kogo interesuje czy w pralce jest 51,arm czy programator mechaniczny ma prać i tyle . co za różnica dla użytkownika 51,arm programator mechaniczny pierze wiruje i wylewa wodę kogo interesuje coś więcej ?

    No i tu pokazałeś w jaki "target" celujesz. Obawiam się jednak, że do tak przyziemnego zadania mogą nie chcieć zatrudnić nadczłowieka <:

    Dodano po 1 [minuty]:

    Piotrus_999 wrote:
    Napisanie tego w C# zajeło mi dobre 3-4 dni z testowaniem i porawianiem błedów, których narobiłem co niemiara.

    Trzeba było pisać w Pythonie (;
  • #123
    User removed account
    User removed account  
  • Altium Designer Computer Controls
  • #124
    User removed account
    Level 1  
  • #125
    User removed account
    User removed account  
  • #126
    tronics
    Level 38  
    @Piotrus_999 AVR nie mają dzielenia tak jak i CM0 i CM0+ , a brakujące w tiny48/88 instrukcje to
    Quote:
    Table 4-1. Instructions not implemented in ATtiny48/88.
    Instruction Operands Meaning
    MUL Rd, Rr Multiply Unsigned
    MULS Rd, Rr Multiply Signed
    MULSU Rd, Rr Multiply Signed with Unsigned
    FMUL Rd, Rr Fractional Multiply Unsigned
    FMULS Rd, Rr Fractional Multiply Signed
    FMULSU Rd, Rr Fractional Multiply Signed with Unsigned
    JMP k Direct Jump
    CALL k Direct Subroutine Call

    Nie pamiętałem tej tabelki, wiedziałem że coś raczej istotnego w obliczeniach, dlatego bardzo wyraźnie zaznaczyłem "z tego co pamiętam". Nie zmienia to sensu wypowiedzi w żadnym stopniu gdyż nadal udowadnia, że kod napisany w asm na wybrany mikrokontroler będzie przenośny w części i całości wyłącznie na kompatybilne modele.
  • #127
    atom1477
    Level 43  
    To trzeba wyjaśnić na czym polega dobra praca techniczna/konstruktorska/inżynierska.
    Nie polega ona na robieniu tego co można zrobić osobiście najlepiej jak się tylko to da zrobić najlepiej. Lecz o robieniu najlepiej w ogóle ale niekoniecznie osobiście.
    Oraz o wykorzystywaniu znanych sobie metod na rozwiązanie różnych problemów. Różnych metod, często bardzo zaawansowanych.
    Sztuka zrobić to co się ma zrobić a się nie narobić. A nie narobić się jak głupi.
    Sam znam wiele różnych metod na robienie czegoś tam, ale to nie powód żeby korzystać z tych metod. Czasami lepiej czegoś nie robić w ogóle niż się męczyć.
    I sztuka zrobić coś zaawansowanego przy użyciu prostych narzędzi a nie robić proste rzeczy przy użyciu zaawansowanych narzędzi.
    I tu niespodzianka, bo nie mam tu na myśli pisania programów za pomocą kompilatorów wysokiego poziomu.
    Dokładnie odwrotnie.
    To właśnie pisanie programów przy użyciu kompilatorów wysokiego poziomu jest robieniem skomplikowanych rzeczy przy użyciu prostych narzędzi. Bo kompilatory z punktu widzenia programisty aż takie skomplikowane nie są. Programista dostaje kompilator jako gotowy produkt. I nie zauważa jego skomplikowania. Może więc pisząc prosty (tekstowo) kod robić zaawansowane rzeczy.
    Z kolei przy assemblerze jest odwrotnie. Wydawało by się (i niektórym się wydaje) że assembler jest prosty a można by za jego pomocą zrobić zaawansowane rzeczy.
    No i owszem, dało by się.
    Ale w akceptowalnym czasie rzeczywistość wygląda inaczej. Pisząc w assemblerze programista musi sięgać po zaawansowane narzędzia jak tablice przeliczeniowe funkcji trygonometrycznych czy inne rzeczy. Debugować na różne sposoby kod który ma robić całkiem podstawowe rzeczy. Dajmy na to FFT.
    I koniec końców wychodzi na to że użyliśmy zaawansowanych narzędzi, a wyszedł całkiem przyziemny kod.
    Niestety niektórzy tego nie rozumieją bo dla nich najważniejsze jest zaoszczędzenie każdego bajta pamięci programu. Dla czystego programisty można to jeszcze zrozumieć.
    Ale dla elektronika-programisty już nie, bo poza programem w projekcie urządzenia są też przetwornice, bloki kondycjonowania sygnałów analogowych dla przetworników ADC, bloki interfejsów (sprzętowe, czyli terminatory, izolacje galwaniczne, itp.). A to wszystko wymaga czasu i testów aby uzyskać dobre działanie. Nie ma tam czasu na dłubanie nad każdym bajtem kodu. Bo to nie przekłada się na żadne pozytywne cechy projektu.
    Owszem miej zajmie kod ale tego w ogóle nie widać a co ważniejsze nie ma to żadnego ale to żadnego wpływu na działanie urządzenia. Natomiast każda zmiana w torach analogowych ma bezpośredni wpływ na działanie urządzenia.
    Więc tym sposobem dochodzimy do ważnego wniosku: trzeba optymalizować wszystko ale nie kod. A w każdym razie jeżeli już optymalizować kod, to na końcu.
    Ostatnio robiłem projekt w którym zmiana procka na lepszy i dodatkowo droższy pozwoliła oszczędzić kilkadziesiąt zł na sztuce urządzenia. Jakim cudem? Niektórzy (ci którzy chcą zaoszczędzić tylko na ilości zajętego FLASHa z mikrokontrolerze) nie zrozumieją. Bo dla nich oszczędność jest tylko przy zmianie procka na gorszy i tańszy. Al tak to jest jak się zapomina że nie sam mikrokontroler tworzy projekt. I jak się zapomina że nie cała praca projektowa to pisanie kodu.

    A na koniec żeby nie było że potępiam assembler. Sam wykonałem ostatnio prosty projekt na ATTINY4. Tak mały że nie wymagał w ogóle używania RAMu (i dlatego można było użyć procka takiego jak ATTIny4, który RAMu nie ma). I w tym przypadku używanie do programowania C nie miało sensu. Choćby z tego powodu że kompilator nie wspierał kompilacji dla tak małego procka. Trzeba by się nakombinować żeby kompilator cokolwiek skompilował.
    A pisząc w assemblerze poszło całkiem szybko, bo i kod algorytmicznie był prosty.
    Program ma realizować proste timingi, oraz pobierać jak najmniej prądu. I tu assembler się sprawdzić bardzo dobrze.
    Ale nie można tego przekładać na każdy inny projekt. Assembler się sprawdził tu, w tych szczególnych warunkach. I kropka.
  • #128
    User removed account
    User removed account  
  • #129
    atom1477
    Level 43  
    Błędnę jest też przekonanie że kiedyś mikrokontrolery 8051 czy podobne (CISC) były dobre do tamtejszych zastosowań, a teraz zmieniły się czasy i lepsze są inne mikrokontrolery (RISC).
    Wystarczy poczytać historię rozwoju mikrokontrolerów czy ogólnie procesorów.
    W skrócie: Procesory się rozwijały (wtedy CISC) aż ktoś policzył jaki jest narzut na operacje transferu danych. I wtedy się okazało że jest on bardzo duży. Większy niż ewentualny narzut na wykonywanie mnożeń, dzieleń, adresowania, gdyby uprościć procesor pozbawiając go tych funkcji. Więc wtedy pomyślano o przejściu na procesory RISC.
    Ale jak mówię: ten fakt nieoptymalności zauważono na starszych mikrokontrolerach. A więc już wtedy były one nieoptymalne. Już wtedy wszystko by lepiej pracowało na mikrokontrolerach RISC.
    CISC się utrzymały i pozwoliły robić całkiem zaawansowane projekty tylko dlatego że po prostu na początku tylko takie były, a potem gdy były już znane i rozpracowane to nie chciano z nich rezygnować bo to oznaczało by brak kompatybilności starszych projektów/kodów z nowszymi.
    Jedyny podział różnego rodzaju zastosowań jaki ma sens to podział na mniejsze i większe. A więc na mikrokontrolery 8 i 32 bitowe (i może i pośrednie). Ale ciągle nie ma powodów żeby któreś z nich były CISC. Raczej lepiej jak wszystkie ciągle są RISC.
    Żeby nie być gołosłownym: sam zaczynałem od 8051 i pisałem zarówno w wysokim poziomie (w BASCOMIe, ale jednak trzeba to uznać za wysoki poziom) jak i w assemblerze. I faktycznie cuda się robiło.
    Nawet pisałem na elektrodzie że nigdy nie zrezygnuję z 8051 bo mogę zrobić na nich wszystko.
    Ale jak przeszedłem na AVR to się mocno zdziwiłem. Nagle zniknęło wąskie gardło którego w przypadku 8051 się nawet nie zauważało bo się ono wydawało oczywiste. A mianowicie zniknął akumulator. Na początku było zdziwienie, no jak to? To jak teraz robić obliczenia? Ale szybko się wyjaśniło że obliczenia można robić na prawie każdym rejestrze roboczym których jest 32. Czyli tak jakby było 32 akumulatorów. A piszę tu o programowaniu w assemblerze.
    W przypadku kompilatorów jest jeszcze większa różnica bo kompilatory są zdecydowanie lepiej przygotowane do kompilowania pod wiele rejestrów roboczych niż pod przepychanie wszystkiego przez jeden akumulator. Bo po prostu przy akumulatorze nie można zrobić praktycznie żadnej optymalizacji. A przy rejestrach można bo prawie każdy z nich jest pełnosprytny a więc można w nich porostwiać różne wartości czy cząstkowe wyniki obliczeń i dokonywać obliczeń bez konieczności ciągłego transferowania danych w tą i z powrotem.
  • #130
    User removed account
    User removed account  
  • #131
    User removed account
    Level 1  
  • #132
    User removed account
    User removed account  
  • #133
    kamyczek
    Level 38  
    Każdy ma prawo mieć swoje zdanie i receptę na realizację projektu , różne są też potrzeby nas samych jak i użytkowników urządzeń ,które budujemy . Zauważam tylko jeden problem w tym całym zagadnieniu który ciągle nas dzieli i psuje nasz wizerunek na forum . Każdy uważa się za najlepszego programistę i język w którym pisze za najlepszy . Tak na prawdę w każdym języku którego używamy są lepsze i gorsze strony a na realizację projektów możemy mieć różne wizje .
    jednak przy podejściu Piotra i kilku innych "kolegów z branży" czuję się jak idiota bo piszę na AVR i w asemblerze . Co lepsze było tu jeszcze kilku ,którzy tak realizowali grube projekty i żyli . Ja nie czuję się dobrze w c i jakoś lepiej leży mi asembler ale nie neguję tego że pewne rzeczy w c pisze się łatwiej i wygodniej . dlaczego nie przesiadłem się na C to proste bo w realizowanych projektach nie miałem takiej potrzeby a zagadnienia ,które realizowałem nie sprawiły mi problemu w asemblerze . Ceniąc swój czas wolałem posiedzieć godzinę dłużej i napisać kilka stron kodu w asemblerze więcej niż uczyć się c dla realizacji jednego bardziej złożonego zagadnienia . Poza tym staram się pisać cały kod własnoręcznie a trudno o tym mówić wkładając "biblioteki z sieci " Dodatkowo nie chcę wiedzieć jak by się skończyło dowolne pytanie o zagadnienia z c do kolegów salwą śmiechu i nabijaniem że piszę coś w C . My sobie koledzy nie pomagamy tylko podkładamy sobie wzajemnie nogi i zamiast pomagać gnoimy się za błędy bez wyjątku . Fora są po to żeby się wymieniać wiedzą konsultować i pomagać ale dla was to miejsce żeby naśmiewać się z tych którzy potrafią coś zrobić w inny sposób i mieć z tego przyjemność i satysfakcję . Mi nie przeszkadza że ktoś pisze na 51 w dowolnym języku jak osiągnie zamierzony cel to super cieszę się razem z nim .
  • #134
    Freddie Chopin
    MCUs specialist
    kamyczek wrote:
    Co lepsze było tu jeszcze kilku ,którzy tak realizowali grube projekty i żyli .

    No pokaż te "grube" projekty. Choć jeden.

    kamyczek wrote:
    Poza tym staram się pisać cały kod własnoręcznie a trudno o tym mówić wkładając "biblioteki z sieci "

    Ciekawe jak "gruby" projekt można zrobić z takim podejściem. Ile czasu będziesz potrzebował żeby zrobić własnoręcznie w assemblerze stos TCP/IP? Czy może "nadludzie" nie zajmują się takimi głupotami jak Ethernet, bo to nie potrzebne w "grubych" projektach?

    kamyczek wrote:
    My sobie koledzy nie pomagamy tylko podkładamy sobie wzajemnie nogi i zamiast pomagać gnoimy się za błędy bez wyjątku .

    Pomagamy. Chyba że ktoś kreuje się na "nadczłowieka" i "ponadprzeciętnej" inteligencji pozwalającej mu wyrwać się z ograniczeń języków wysokiego poziomu i używać tylko assemblera, to wtedy możemy się tylko naśmiewać (; Innym wyjątkiem są sytuacje gdy ktoś na "normalną" poradę bardzo się upiera żeby coś zrobić w bezsensowny sposób - wtedy można tylko życzyć powodzenia i oddalić się w przeciwnym kierunku. Jakby ktoś na forum fotograficznym upierał się przy naprawianiu lustrzanki młotkiem i dłutkiem to mniej-więcej sytuacja byłaby podobna. Używaj sobie więc assemblera i AVRów, tylko skończ dorabiać sobie do tego mesjanistyczną filozofię superbohatera.
  • #135
    User removed account
    User removed account  
  • #136
    dondu
    Moderator on vacation ...
    Piotrus_999 wrote:
    Kiedyś po prostu nie było innego wyjścia niż tylko zakasać rękawy i rzeźbić w asemblerze, stosując mająć na podorędziu masę trików oraz metod tajemnych. Teraz można się skupić na problemie, zapomnieć o ograniczeniach.

    I to jest podstawą decyzji ekonomicznych, bowiem skraca czas projektowania, a to bezpośrednio przekłada się na mniejsze koszty. Dlatego opłaca się poświęcić czas, by C/C++ biegle opanować, gdyż zwróci się to po tysiąckroć.

    Problem polega tylko na tym, że Ci co się samoograniczają, nie mają świadomości lub nie dopuszczają do siebie faktu, że koparką jest szybciej i taniej niż łopatą rowy kopać. Z drugiej strony to dobrze, bo są mniej konkurencyjni na rynku :)
  • #137
    User removed account
    Level 1  
  • #138
    linuxtorpeda
    Level 25  
    Wracając do tematu, 8051 wykorzystuje się nadal nawet w nowych projektach i dużych firmach, gdyż IP cores na tą architekturę są otwarte. Dla przykładu, w niektórych SoCach znajdujących się w dekoderach znajduje się duet - jakiś uC 32-bitowy (podstawowa funkcjonalność dekodera, wyświetlanie menu, wyświetlanie obrazu, itp.) + jakiś 8051 jako układ standby, czyli monitorujący wciśnięcia klawiszy pilota IR lub przycisków na obudowie dekodera w celu podniesienia platformy.

    Co do wyższości C nad assemblerem (lub odwrotnie), nawet na 51 można pisać i często pisze się w C. W najbardziej pospolitych zastosowaniach nowoczesne kompilatory lepiej zoptymalizują kod niż przeciętny człowiek, który do tego celu musiałby znać zarówno szczegóły architektury, jak i pewne sztuczki matematyczne (na początek polecam Hacker's Delight). Assembler stosuje się przeważnie tam, gdzie zidentyfikowano wąskie gardła w wydajności i jest możliwość jej poprawy. Poza tym assembler nadal jest niezastąpiony w pisaniu bootloaderów czy innego kodu odpowiedzialnego za start platformy (m.in. ze względu na pewne ograniczenia techniczne samego kodu wykonywanego bezpośrednio po zasileniu układu).
  • #139
    User removed account
    User removed account  
  • #140
    tronics
    Level 38  
    Quote:
    Assembler stosuje się przeważnie tam, gdzie zidentyfikowano wąskie gardła w wydajności i jest możliwość jej poprawy

    Czyli innymi słowy size critical (np. bootloader) bądź time critical.
    Quote:
    nawet na 51 można pisać i często pisze się w C

    Tylko jak się ma XRAM to trzeba odpowiednio skonfigurować, a jak się nie ma to trzeba ciągle pamiętać o nikłej ilości RAM czyli nie przepełnić stosu, bo to akurat w C na 51 można nieopacznie zrobić bardzo łatwo. A w takim "ograniczonym" C wcale się przyjemnie nie pisze szczególnie, że nie ma wcale takiej potrzeby skoro są architektury lepiej dostosowane. I to takie gdzie kod nie puchnie przy częstych obliczeniach na 16 i 32bit.
  • #141
    linuxtorpeda
    Level 25  
    Mówiąc o wąskich gardłach, bardziej chodziło mi o sytuacje, gdzie np. kompilator nie wspiera pewnych instrukcji lub nie uwzględnia pewnych zależności, bo platforma jest egzotyczna. Poza tym trudno mi sobie wyobrazić sytuację, by bootloader się wykonywał zauważalnie wolniej, bo ktoś go pisał w C - wydaje się to nieprawdopodobne. Fragmenty bootloadera pisze się w assemblerze na przykład dlatego, że podczas boot-upu platformy trzeba m.in. skonfigurować kontroler RAM, więc wykonywany kod nie może wykorzystywać RAMu na czas podnoszenia platformy.
  • #142
    kamyczek
    Level 38  
    Koledzy na temat proszę 51 nie wyższość c nad wszystkim ... Sam chętnie zapoznał bym się z obecną ofertą 51 i narzędzi do nich . Tyle że koledzy każdy temat sprowadzą do arma i C a resztę z nas potraktują jak gorszą część środowiska bo w końcu to nie arm i nie zawsze c a dla was każdy inny sposób realizacji projektów jest zły i niedopuszczalny . Tylko chętnie zobaczę takiego kto nigdy w życiu nie użył wstawki asemblerowej i mikrokontrolera innego niż arm .
  • #143
    tronics
    Level 38  
    Cypress miał PSoC 3 na 8051. Raczej się to nie rozwija biorąc pod uwagę, że większość ich produktów to obecnie CM0/CM0+, CM3 i CM4. Niemniej jeśli programowało się w ich IDE to i tak nie miało to większego znaczenia bo ogromna część konfiguracji i połączeń realizowana była z użyciem GUI, a nie kodu.
  • #144
    sibislaw
    Level 12  
    Myślę że dyskusja wyczerpuje temat w zupełności - w dzisiejszych czasach tworzy się dalej programy na 8051 i jego wypieranie będzie bardzo powolne - był on standardem a jego znajomość jest szeroko rozpowszechniona. Dodatkowo mikrokontrolery z rdzeniem 8051 i bardzo bogatymi peryferiami są produkowane przez wielu producentów i są to często układy sprawdzone i dojrzałe. Nawet jeśli 8051 zostanie wyparty sama jego architektura jako część większych systemów / implementacja w programowalnych matrycach bramek pozostanie z nami jeszcze na długo.