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

kamyczek wrote:

który stworzył mechanizmy optymalizacji dla tego co napiszecie w c daje efekt zbliżony do kodu napisanego w assemblerze choć zawsze o te kilka procent gorszy ..

Nie wiem bo jeszcze nie widziałem kodu równolegle napisanego w asemblerze.

Mam dla kolegi @kamyczek propozycję. W moim dawnym projekcie oscyloskopu jest taka funkcja:

Podaje się tam dowolne działanie arytmetyczne (z nawiasami, funkcjami itd itd) a to sobie liczy wynik w podanym przedziale dla podanej ilości punktów. Napisanie tego w C# zajeło mi dobre 3-4 dni z testowaniem i porawianiem błedów, których narobiłem co niemiara. Proponuję abyś tylko napisał tę część funkcjonalności w asemblerze jako test swoich umiejętności.

Dodano po 2 [minuty]:

@tronics A atmegi to dzielenie mają wg kolegi?

@Freddie Chopin Myślę że do przyszłej soboty kolega @kamyczek nam napisze w asemblerze.

A to z tym masz problem...
@kamyczek, minęły czasy genialnych jednostek. Teraz pracuje się w zespołach. Jeżeli każdy mówi innym językiem, to nigdy się nie dogadamy i nigdy nie zrobimy ani pralki, ani falownika, ani sterownika silnika trakcyjnego, ani kontrolera pokładowego do samolotu, ani... w sumie to nic sensownego nie zrobimy. Pewnie dlatego, że jesteśmy mocno ograniczonymi programistami.
Opracowanie urządzenia, to nie tylko napisanie kodu, w którym każdy jeden rozkaz jest na wagę złota i absolutnie niezbędny. Opracowanie urządzenia to dość żmudny proces, który ma wiele faz, w każdej z nich inni ludzie są zaangażowani. Jedną z trudniejszych faz jest tworzenie kolejnej generacji produktu. Jeżeli kod jest dobrze napisany, to wymaga "tylko" dołączenia kilku modułów, skompilowania i testowania. Jeżeli jest w języku niskiego poziomu, to rozpoznanie/analiza dokumentacji i jej późniejsze przygotowanie dla celów konserwacji lub dalszego rozwoju zajmie kilka razy więcej czasu niż napisanie tego od początku w języku wyższego poziomu. Czas to pieniądz. Dobry programista to nie ten, który spędzi 2 lata na pisaniu w asm, aby zaoszczędzić parę groszy na finalnym produkcie. Dobry jest ten, który potrafi zrealizować pełną funkcjonalność w krótkim czasie i wyprzedzić oczekiwania klienta lub osiągnięcia konkurencji. Możesz się obrażać, że woda zamarza w 0°C, albo że słońce zachodzi na zachodzie, ale tak już jest. A jak ktoś dla sportu chce się bawić i dłubać coś w domu, ponieważ może, to nie należy tego rozciągać na zawodowców i biznes, jako regułę. Nie. To jest pomyłka.

@Marek_Skalski Niestety nie rozumiesz. On naprawdę uważa nas za półgłówków

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.

Marek_Skalski wrote:

R-MIK wrote:

Były 8051 (jeden mam 80154 umożliwiające prace krokową. Nie znam szczegółów, podobno były niepublikowane instrukcje (coś jak BREAK dla AVR). Aby otrzymać ich opis, trzeba było podpisać umowę z Intelem. Procek, który posiadam pochodzi z z emulatora z praca krokową.

Powiedz proszę, co chciałeś osiągnąć cytując moją wypowiedź w odniesieniu do tego cudu techniki, który chcesz sprzedać?
- Ten uC nie posiada żadnego wsparcia w kierunku pracy krokowej w swojej strukturze; żadnych jednostek kontroli rdzenia, interfejsu debugera, breakpointów, komparatorów danych, etc. Zaleca się taktowanie go zegarem min. 16MHz, chociaż może pracować od 1MHz. To wyklucza możliwość pracy krokowej.
- Skoro o zegarach, to sprawdźmy wydajność. Z zegarem 22MHz, minimalny cykl maszynowy to 545ns; efektywnie 1,83 MIPS, albo 0,083 DMIPS/MHz. Dla porównania Cortex M0+ oferuje 0,95DMIPS/MHz. Tylko 11x więcej.

Widzę, ze kolega nie wie po co były produkowanie procesory "piggyback".

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.

Pierwszym prockiem z wieloma akumulatorami był 68000. 16 (15) rejestrów danych, 8 (7) rejestrów adresowych. Rozkaz mov miał "tylko" 4096 kombinacji! Procek już w 1981 roku miał rejestry 32bit, choć magistralę zewnętrzna 16-bit (był 68008 z 8-bit magistralą). 68020 był już w pełni 32-bit (Amiga 1200, Atari Falcon). Na tym procku optymalizacja w C mogła rozwinąć skrzydła. No i tryb nadzorcy i użytkownika, jak w późniejszych ARNM-ach. Na 68000 bardzo wygodnie pisało się w assemblerze. Na systemy z tym prockiem pisałem właśnie w ASM, na Amigę w E.

PS
Jak pamiętam 6800 miał dwa akumulatory. A był to procek zrobiony w czasach 8080, Z-80, 6502.

Napisałem kiedyś, że układy z rodziny C51 nie posiadają interfejsów pozwalających na programowanie i debugowanie, typu JTAG, Trace, itp. Dwa lata później, cytujesz moje słowa, rozpoczynając na nowo dyskusję i przeciwstawiasz mojej wypowiedzi układ, któremu zmieniasz oznaczenie, dokładając swoje teorie niezgodne z prawdą. Kiedy pytam o cel tej wypowiedzi, Ty piszesz coś takiego:

R-MIK wrote:

Widzę, ze kolega nie wie po co były produkowanie procesory "piggyback".

Wiem po co były układy w obudowie piggy-back, ale nie wiem jaki to ma związek z moją wypowiedzią ne temat JTAG i Trace. Dlatego proszę o odpowiedź na moje pytanie. Konkretnie, bez gdybania, zgadywania, teoretyzowania i podawania informacji niezgodnych z prawdą.

R-MIK wrote:

Były 8051 (jeden mam 80154 umożliwiające prace krokową. Nie znam szczegółów, podobno były niepublikowane instrukcje (coś jak BREAK dla AVR). Aby otrzymać ich opis, trzeba było podpisać umowę z Intelem. Procek, który posiadam pochodzi z z emulatora z praca krokową.

80154 - nie ma i nie było takiego mikrokontrolera. Był produkowany M85C154.
M85C154, w swojej konstrukcji posiadał możliwość pracy krokowej tak samo jak każdy inny uC, czy układ synchroniczny. Problem polega na tym, że przy minimalnej prędkości zegara 1MHz, nie można wstrzymać programu, nie można dostać się do rejestrów CPU ani peryferiów, a percepcja człowieka nie nadąża ze śledzeniem wykonania programu w takim tempie. Nie ma to nic wspólnego z debugowaniem, o którym pisałem.
Podobno były niepublikowane instrukcje? Albo były, albo nie. Jeżeli nie znasz szczegółów, to po co zmyślasz? To jest forum techniczne, nie wróżbiarskie.
Emulator z pracą krokową to urządzenie, które jest trochę bardziej skomplikowane niż goły uC. Przywoływanie go w celu wykazania możliwości debugowania rdzenia, który nie posiada takiego mechanizmu jest pozbawione logiki.
Odpowiesz czy się obrazisz jak w innych tematach?

Marek_Skalski wrote:

M85C154, w swojej konstrukcji posiadał możliwość pracy krokowej tak samo jak każdy inny uC, czy układ synchroniczny. Problem polega na tym, że przy minimalnej prędkości zegara 1MHz, nie można wstrzymać programu, nie można dostać się do rejestrów CPU ani peryferiów

W jaki więc sposób Czesi rozwiązali ten problem? Procesor pochodzi ze sprzętowego emulatora. Fotografia przedstawia płytę emulatora, która była łączona taśma z interfejsem z ISA w komputerze.

Skoro jesteś ekspertem od 8051 to na pewno widziałeś ten emulator:

Jeśli nie widziałeś, to daleko ci do eksperta w dziedzinie tych mikrokontrolerów.

Moderated By dondu:

Kolego R-MIK. Kolegi działania na forum są ostatnio bardzo nieetyczne, ironiczne i złośliwe.

Jeśli kolega nie zmieni swojego postępowania, to następnym razem nie będę miał innego wyjścia jak za tego typu personalne uwagi wręczać koledze bezterminowe ostrzeżenia, co w krótkiej perspektywie doprowadzi do zablokowania kolegi konta, ze względu na posiadane już 3 ostrzeżenia.

Proszę więc o zmianę podejścia do dyskusji na forum oraz innych jego użytkowników, i wyłącznie merytorycznego odnoszenia się do poruszanych tematów.

3.1.9. Nie ironizuj i nie bądź złośliwy w stosunku do drugiej strony dyskusji. Uszanuj odmienne zdanie oraz inne opinie na forum.

Teraz nie pamiętam czy ten emulator czy Z-80, miał możliwość cofnięcia o 10 rozkazów od miejsca, w którym sie zatrzymał.

Marek_Skalski wrote:

R-MIK wrote:

Widzę, ze kolega nie wie po co były produkowanie procesory "piggyback".

Wiem po co były układy w obudowie piggy-back,

Skoro tak to jaki sens ma ta wypowiedz:

Marek_Skalski wrote:

- To może zaoszczędzimy energię karmiąc tylko 8 bitów zamiast 32. Promowany wynalazek potrzebuje 27mA @22MHz. Ponieważ jest zasilany z 5V, to zużywa 135mW. Bez pamięci programu (EPROM), która pożera dodatkowe mA. Wspomniany już Cortex M0+ potrzebuje 5,1mA @32MHz. Ponieważ jest zasilany z 3,3V, to zużywa 16,9mW, wykonując 32MHz*0,95/(22MHz*0,083) = 16,58x więcej operacji. Efektywność energetyczna 133x większa.

Porównywać pobór prądu mikrokontrolera przeznaczonego do emulatorów/prototypów z układami przeznaczonymi do produkcji seryjnej?
Gdzie sens, gdzie logika?
Do tego 51 trzeba było jeszcze dodać pobór prądu komputera sterującego emulatorem. Wynik byłby jeszcze bardziej imponujący, ne 133 tylko 13333 razy.

kamyczek wrote:

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 .

Problem w świecie uC jest taki że rozwój sprzętu następuje w postępie geometrycznym. Trzeba ciągle byc na bieżąco - powstają nowe idee programowania, języki itd.

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. Z 10 lat temu mało kto by uwierzył że uC za 25zł będzie miał FPU podwójnej precyzji, pamięci ile tylko programista sobie zażyczy i taką ilość peryferiów, że sama ich lista zajmuje kilka stron w DS-ie

R-MIK wrote:

Teraz nie pamiętam czy ten emulator czy Z-80, miał możliwość cofnięcia o 10 rozkazów od miejsca, w którym sie zatrzymał.

Nadal nie odpowiedziałeś na moje pytanie.
Temat dotyczy 8051 i pochodnych. Wstawiłeś zdjęcie archaicznego uC używanego podczas prac rozwojowych jako przykład 8051 posiadającego możliwość debugowania, a kiedy podaję fakty z dokumentacji, to zasłaniasz się lukami w pamięci i wskazujesz na Z-80.
W takiej sytuacji dalsza dyskusja nie ma najmniejszego sensu. Twoja obecność na Forum jest szkodliwa, ponieważ w swoich wypowiedziach prezentujesz informacje nieprawdziwe, nieprawdopodobne, z gruntu błędne i niezgodne z praktyką inżynierską, kreując się przy tym na autorytet. Cierpi na tym Elektroda i początkujący. EOT.

linuxtorpeda wrote:

Assembler stosuje się przeważnie tam, gdzie zidentyfikowano wąskie gardła w wydajności i jest możliwość jej poprawy.

Też coraż rzadziej kolego @linuxtorpeda. Ostatnio musiałem na PC-ie wyrzeźbić bardzo sprawne operacje na dużych tablicach i potrzebowałem użyć instrukcje temporal czy non temporal - jedyne co użyłem to intrinsics-y w C i nie uznaję tego za pisanie w asemblerze. tak samo jak użycie __dsb() nie jest pisaniem w asemblerze.