Popularność mikrokontrolerów

Dnia 07 Jul 2012 12:26:51 GMT, Jarosław Sokołowski napisał(a):

A nie odwrotnie ?

CP/M ma podobna zalete jak MS-DOS - nie przeszkadza :-) Tylko to po prostu kompletnie oplacalne wstawiac naped dyskietek zamiast (EP)ROM z programem.

Natomiast linux ... a po cholere on w sterowniku do windy ?

Na tyle popularny i o duzych mozliwosciach, zeby sie oplacilo sie system wymyslac i tworzyc.

Ale to z innych powodow IMHO - sterownik do windy, a jak ma miec USB na pokladzie do diagnostyki, i BT zeby serwis nie musial chodzic po drabinie, i ethernet zeby pracowac w sieci z innymi sterownikami, i podlaczony ma byc do systemu inteligentnego budynku, i miec webserver dla zarzadcy, i oczywiscie TCP/IP do tego potrzebne , i jeszcze gniazdo na karty SD - to niestety oprogramowanie tego wszystkiego kosztuje, a w systemie w cenie..

J.

Reply to
J.F.
Loading thread data ...

Na ARM tez jes asm :-)

Te army to tez sa, sa, tysiace, tylko kupic je trudno :-)

Zalezy od nacisku w edukacji. Tak to raczej mowi ktos z dluzszym stazem i dorobkiem, kto wie ze postawiony mu projekt moze rozwiazac szybko (z wykorzystaniem wczesniejszych programow), albo przyjdzie mu sie uzerac.

Na maszynie debugowac moze byc trudno. Moze wymagac odpowiednio szybkiej obslugi.

gcc sprzed 30 lat ? :-)

A to jakas istotna roznica ? Moze sie tylko wscieknie ze paru przydanych rozkazow brakuje.

Zdaje sie ze na poczatku zarzucales pisanie w asm - o co cie teraz architektura obchodzi ? Piszesz w C, i nie masz pojecia czy jest RISC czy CISC, czy rdzen jest dla programistow czy programatorow :-)

Czasem tylko bedziesz sie dziwil po co jakies dziwnie instrukcje, albo czemu nowoczesny kompilator taki niewydajny :-)

J.

Reply to
J.F.

tez sie nie rozpowszechnil w tej roli.

A byl jednak sporo gorszy.

bo czesto czysty 8-bitowy nie jest wystarczajacy. Zreszta i 8080 i Z80 wykraczaly poza "8 bit". Poza tym masz sprawdzona konstrukcje, masz biegle kadry, masz narzedzia - czemu niewykorzystac ?

Tylko cena 186/188 zawazyla, czy one jednak za malo uC przypominaly ?

J.

Reply to
J.F.

Pan J.F. napisał:

Praktyka pokazuje, że nie.

A teraz (wiele lat po pogrzebie CP/M) opłacalne jest wstawianie tylu zasobów, że korzysta się z jakichś 2%.

Można powiedzieć, że po nic -- tak jak CP/M i MS-DOS, Linux również nie przeszkadza. Ale jednak po coś -- zostało to opisane niżej.

Tak, to chyba dość rzadko. Nikomu się nie chce wymyślać i tworzyć systemu od podstaw. A tam gdzie się da, wstawia się gotowy, który jest za darmo. Czyli coś uniksowatego, przeważnie linux, czasem bsd.

Nie tyle "ma mieć", co "może mieć za śmieszne pieniądze". Jak może mieć, to się robi -- żeby było wygodniej. A z systemem zawsze jest wygodniej niż bez systemu. Nawet jeśli nie chcę mieć USB, BT itd.

Reply to
Jarosław Sokołowski

Po co inżynier potrafiący zaprojektować/zaimplementować system mikroprocesorowy ma znać "bebechy procesora"? To jest broszka projektanta procesorów - nauki mechanika samochodowego nie zaczynamy przecież od górnictwa i przetwórstwa stali i ropy.

Rozumiem jeszcze kogoś zaawansowanego[1], kto potrzebuje znać architekturę, sposób działania użytej magistrali, peryferia w procesorze, bo coś robi na FPGA z microblaze/openrisc/etc.

Nie rozumiem po co ktoś, kto się uczy podstaw uC ma wiedzieć jaki jest dokładnie pipeline w procesorze, skoro tego nie widzi a interesująca i potrzebna jest informacja np.:

- najszybszy na te architekturze typ zmiennej to (u)int16_t

- 2 cykle na rozkaz

- nie używać floating-point jeżeli nie jest to _konieczne_

- nie używać busy-wait jeżeli można to zrobić inaczej (automaty skończone + zegar)

- wykorzystywać przerwania gdzie się da

- dokumentować przebieg algorytmu

- przy częstotliwościach zegara powyżej xxx MHz krytyczne czasowo funkcje oznaczać yyy przy czym należy skontrolować czy to za bardzo nie uszczupla ramu.

[1] Raczej na studiach magisterskich, albo bardzo specyficznym kierunku inżynierskich.

Ale zaczynanie od kodu maszynowego prowadzi do "liczenia cykli" i przesadnego komplikowania programu. Optymalizację należy przeprowadzać gdy jest to potrzebne, a nie od początku tworzyć "unmaintainable code".

Reply to
Michoo

W dniu 2012-07-07 14:26, Jarosław Sokołowski pisze:

Ale nie wiem po co wprowadzać własną definicję gdy jest już powszechnie przyjęta. Poza tym twoja definicja jest nieprecyzyjna. Według niej to ARM w Raspberry Pi jest mikroprocesorem. A jeśli ten sam procek wlutuję w swoją płytkę i wszystkie potrzebne funkcje wrzucę w main to będzie to mikrokontroler. A co jak zastosuję Freertosa? Czy to nadal będzie mikrokontroler czy już mikroprocesor. Tak wiec stosując twoją definicję nie wiem czy kupując ten mikroukład w sklepie to kupuję mikrokontroler czy mikroprocesor.

Reply to
Mario

Pan Mario napisał:

Ponieważ nie wiedziałem jaka jest ogólnie przyjęta, podałem taką, która jest pomocna przy odpowiedzi na pytanie o wybór chipa w kontekscie jego popularności.

Ależ skąd! Niezwykle ostro dzieli dziedzinę na dwie klasy abstrakcji.

Prawda.

Święta prawda.

Łatwo się domyśleć, że mikroprocesor.

Jak kupuję mikroukład celem wlutowania jej samodzielnie zaprojektowaną płytkę i załadowanie kodu ze wszystkimi funkcjami wrzuconymi w main, to mikrokontroler. A jeśli kupuje płytkę Rapsberry Pi (z tym samym mikroukładem), to jest to mikrokomputer. W mikrokomputerach są mikroprocesory.

Reply to
Jarosław Sokołowski

Możesz rozwinąć tą myśl?

Pozdrawiam!

Reply to
Kernel Panic

W dniu 2012-07-08 00:11, Jarosław Sokołowski pisze:

Czyli aby określić czy ten kupowany element jest mikrokontrolerem czy mikroprocesorem, konieczna jest znajomość mojej intencji. Biedni producenci i sprzedawcy nie wiedzą jaki produkt oferują. To widać jest jakiś mikroukład Schroedingera, o którym do ostatniej chwili nie wiadomo w jakim jest stanie kwantowym. Wybacz, dla mnie to dosyć kretyńska definicja, nie dająca żadnych informacji o przedmiocie tylko o sposobie użycia go.

Według twojej kolejnej definicji.

Reply to
Mario

A przerysowując w drugą stronę można powiedzieć, że student mechaniki pojazdowej nie powinien znać budowy silnika tylko zestaw jego charakterystyk pozwalających na wyliczenie dynamiki pojazdu.

Tak samo można powiedzieć, że student elektroniki nie musie wiedzieć jak jest zbudowany tranzystor bipolarny a jak polowy, tylko znać ich modele zastępcze.

A to powinien znać moim zdaniem każdy student elektroniki o kierunkach cyfrowych.

Można pominąć poznawanie kodu maszynowego a także wszelkich rejestrów wewnętrznych. Można ukryć całą architekturę za warstwą sterowników, a student będzie tylko musiał dodać odpowiednie include w kodzie. Tylko po co wogóle programowania od tej strony (oderwanej od hardware) mają się uczyć studenci elektroniki skoro lepiej to wyjdzie studentom informatyki.

Reply to
Mario

Pan Mario napisał:

Nie tacy oni biedni. Na sprzedaży dobrych procesorów dobrze się zarabia.

Putina też nie interesuje, czy ktoś kupuje gaz jako paliwo, czy jako surowiec do syntezy chemicznej. Takie "kretyńskie definicje" dobrze się mają między rynkami surowcowymi. A umasowione rynki zaawansowanych technologii mają wiele wspólnego z tymi surowcowymi.

Nie kolejnej, a wciąż tej samej, konsekwentnie użytej.

Reply to
Jarosław Sokołowski

Tylko takie szczegóły jak to ilustopniowe jest dekodowanie instrukcji, czy jak szybkie jest połączenie rdzenia z daną pamięcią nie ma _żadnego_ znaczenia o ile nie projektujesz procesora. Dla "użytkownika" liczy się czas wykonania instrukcji i ewentualnie ilość wait-state (+ może konieczność dodania jakiejś odmiany lock w systemie równoległym).

Uczyłem się równań opisujących tranzystor, czy bramki, lustra prądowe, wzmacniacze, etc (i na egzamin mgr musiałem je sobie odświeżyć). Imo była to sztuka dla sztuki, bo nawet jak projektowaliśmy na którymś przedmiocie layout to dane tranzystorów szacowało się wzorami przybliżonymi.

No i ok - są sytuacje, gdzie jest to na miejscu, ale tak w ogólnym programie dla elektroniki?

Bo studenci informatyki nie kwapią się bawić ze sprzętem, po tym jak przeszli:

- programowanie na kartce w czystych opkodach a potem wklepywanie tego w sprzęt

- użeranie się z centronixem pod DOSem

- uczenie assemblera 16 bit na x86

U mnie z ~150 osób z informatyki na Inżynierię Komputerową poszło nas sześciu, po doliczeniu osób z innych uczelni i innego kierunku inż wyszło całe dziesięcioro. Końcowo będzie 5-6 magistrów po informatyce znających się na programowaniu I znających sprzęt.

A elektronicy jak na razie robią koszmarny kod, więc gdzieś się muszą nauczyć.

Reply to
Michoo

Dnia Sun, 08 Jul 2012 00:53:21 +0200, Mario napisał(a):

No, ale sa jeszcze studenci transportu samochodowego, gdzie w zasadzie to nie potrzebne. I sa jeszcze termodynamiczne podstawy dzialania silnika.

Jak jest zbudowany to mozna w ksiazkach wyczytac. Ale na studiach sie dowiedzialem jak to naprawde dziala, no powiedzmy - przeszedlem na kolejny etap wtajemniczenia, w ktorym sporo machania rekami bylo. Wiedza w zasadzie nieprzydatna, ale zawsze mnie to intrygowalo :-)

Jak sa zbudowane nowoczesne tranzystory mosfet nie mam pojecia, co nie przeszkadza uzywac :-) Podobnie jak nie wiem jak sa zrobione pamieci eeprom, flash, nowoczesne dram - i tez mi to nie przeszkadza.

J.

Reply to
J.F.

Ale nie można ograniczyć studiów tylko do nauki jak "używać" procka bez znajomości jak jest zbudowany. Przydałoby się żeby student znał architekturę procka trochę dokładniej niż jest w artykułach w PCWorld. A co do znajomości assemblera (i świadomości ze istnieje kod maszynowy), to przydaje się ona choćby przy analizie wyników kompilacji jeśli coś jest nie tak.

Mówimy o kierunkach cyfrowych, to moim zdaniem w ogólnym programie jest miejsce i na mikrokontrolery/mikrprocesory i na układy programowalne.

Bezsprzecznie powinni mieć więcej informatyki, ale nie oznacza to, że nie powinni poznawać budowy procka na jakimś elementarnym poziomie.

Reply to
Mario

Jasne. Zdecydowana wiekszosc idacych na kierunki informatyczne (nawet te powiazana z elektronika) nie lubi sprzetu. Po drugie nawej jesli lubi to bez tzw. doswiadczenia zdecydowanie szybciej znajda prace jako programista Java dla businessu.

Pozdrawiam

Marek

Reply to
Marek Borowski

To akurat dla przyszłego profesjonalisty w tej branży nie powinno być żadną przeszkodą a wręcz zaletą: uczy się od razu poprawnych, na codzień używanych w branży pojęć. Bez jakichś koślawo przetłumaczonych polskich potworków :-)

Reply to
Pszemol

:-))))

Jest w tym trochę prawdy, ale sam wiesz że nowy producent procków potrafi zaskoczyć czasem taką niespodzianką że projekt leży i kwiczy parę tygodni zanim znajdziesz rozwiązanie. Tym bardziej zupełnie nowa dla kogoś architektura procesorów z całym lokalnym folklorem :-)

W naszej firmie wreszcie w tym roku odbiliśmy się od rodziny klonów

8051 i pierwszy projekt robimy na ARMie Cortex M3. Mam nadzieję że do 8051 już nie wrócimy, mimo iż były to fajne procki firmy SiLabs, i nawet do najprostszych rzeczy znajdziemy coś małego/taniego z ARM.
Reply to
Pszemol

I niewielu w nim pisze. Bo i po co skoro są normalne kompiltory.

Army akurat łatwo kupić prawie dowolne.

Debugowanie w systemie ma kilka ograniczeń, ale lepsze to niż debugowanie poprzez "tu k.... musi gdzieś być jakiś bład" popularne na '51 i okolicznych trupach.

gcc "z przed 30 lat" supportuje C++11 z zeszłego roku. Pewno piszesz o jakimś innym gcc.

Jesli do tego sprawdzasz, to faktycznie. Programator '51 będzie klnął.

Kompilator obchodzi czy jest CISC czy RISC. Kompilator w ogóle obchodzi architektura. Zgadnij czemu do dzisiaj nie ma gcc na stare PICe.

Może zły kompilator albo zły programista.

Reply to
Sebastian Biały

Prawda. Co więcej, według moich obserwacji, jako programiści będą więcej zarabiać.

Pozdrawiam!

Reply to
Kernel Panic

On 2012-07-06 18:51, Sebastian Biały wrote: [.....]

No chyba nadal jest ponieważ Renesas nadal produkuje kości z rodziny H8 które mają wspólnego przodka z M68k - PDP11. :-D Ale patrząc na politykę Renesasa to H8 chyba rzeczywiście zaczyna dogorywać.

BTW. Szkoda, że rodzinka H8 nie zeszła pod strzechy tak jak MCS51, AVR czy "ostatnio" ARM.

Reply to
JDX

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.