I co? Zaledwie 32 strony i już koniec tego wartościowego i pouczającego wątku?

pukury pisze:hej.
przecież żartowałem

No przecież wiem, że żartowałeś Po prostu rozwinąłem temat w oparciu o posty wątku.

W kwestii kultury technicznej i w ogóle świadomości różnych (czy może jakichkolwiek) zasad - można zauważyć pewną zależność oglądając "internetowe dzieła wybrane". Otóż od razu widać, jak bardzo róźnią się poziomem opracowania blogowate projekty radioamatorów anglosaskich tudzież niemieckojęzycznych, od wypocin naszych rodaków. I nie mam tu na myśli poziomu merytorycznego rozwiązań - ten jest zbliżony, tylko jakość i formę prezentacji.
Tamte projekty mają zazwyczaj ładny przemyślany opis, zazwyczaj czytelny i kompletny. Mają uporządkowana strukturę informacji, jasną i użyteczną dokumentację.
U nas - jakby krowa przelatywała i się ze..ła. Braki, błędy, bzdurne opisy. Niezrozumiałe informacje, przynajmniej dla tych dla których to w ogóle może być przydatne. Taka amatorszczyzna w amatorszczyźnie. Widać w tym głęboką niechęć do porządku, brak wyuczenia zasad i reguł. Takie wrodzone bałaganiarstwo i bylejakość. Mi się kojarzy z chłopem który przyjechał do miasta by zamieszkać w bloku, ale przywiózł ze sobą zwyczaje których nie umie się pozbyć. Np że po psie się sprząta albo że jest coś takiego jak ład domowy.
No a potem, jak się Jaś za młodu...

pukury pisze:hej!
a ja tam jestem " Nikiforem " elektroniki.
metoda inżynierska ( tzw. ) - łączę - jak się spali lub nie działa - to łączę inaczej.
elementy dość tanie są w końcu.
prędzej czy później musi się udać.
pzd.

Kiedy byłem mały (zupełnie mały) i z podziwem patrzyłem na żarzące się tudzież bzyczące bebechy urządzeń elektronicznych, byłem przekonany, bo inne rozwiązania uznawałem za niemożliwe, że takie rzeczy wymyśla się właśnie metodą przypadkowego łączenia przypadkowych części. Do skutku, aż coś wyjdzie. Niczym w radzieckim chemicznym instytucje badawczym,
Po kilku latach już wiedziałem, że takie rzeczy się projektuje i po kolejnych latach już nie dopuszczałem możliwości, żeby coś poprawnie zaprojektowanego nie działało OD RAZU. Ale pamiętam tamten "stan umysłu" do dziś. I ciągle widzę jego ślady-kopie w wielu wypowiedziach na różnych forach. Takie w rodzaju: "programuję bazy danych, więc jestem", "kupie sobie multimetr i będę elektronikiem" albo "umiem zaprogramować AVR, więc nie ma już dla mnie tajemnic"

antybeton pisze:AVR 8 bitowe oparte na MCS? Chyba coś ci się pomyliło. Łączy je tylko że niektóre pierwsze AVRki miały rozkład wyprowadzeń zgodnych z niektórymi MCS-51.

Nie pomyliło mi się. Struktura AVR wyrosła ze struktury MCS. Nie było to zupełnie nowe opracowanie, od podstaw. Stąd głębokie podobieństwa, rozbudowana po staremu lista rozkazów. Oczywiście nie mam na myśli, ze to unowocześniona wersja MCS.
Badziewie dlatego, że zarówno flash jak i eeprom były w nich niedodziałane i o RZĄD gorsze niż u konkurencji. Do ubiegłego roku zaprogramowanie AVR w porównaniu z zaprogramowaniem PICa to droga przez mękę i strata czasu w najczystszej postaci. Może teraz coś się zmieni, ale nie byłbym optymistą bo kupienie firmy nie oznacza poprawienia jej produktów.

Jednocześnie z rozwijaniem pierwszych AVR Atmel próbował bezpośrednio cywilizować MCS. Pojawiła się rodzina 89 z flash, co poprzedziła obecnie wstydliwie zapomniana rodzina z literką S w środku. Straszny złom z poważnymi błędami w rdzeniu.

AVR to badziewie oparte na zamierzchłej rodzinie MCS, tyle że popularne jak golonka w przydrożnych barach. Koncepcja starsza niż większość tutejszych forumowiczów. Z resztą firma nie wytrzymała nowoczesnej konkurencji i rok temu została wchłonięta.
Jeśli ktoś się chce spróbować pobawić w równoległe procesy na jednej kości, może użyć jakiegoś dsPIC. Albo lepiej dowolnego starszego prawdziwego procesora sygnałowego Texasa czy Motoroli. Jednak to już nie dla każdego zabawa.

I dlatego takich urządzeń nie oprogramowują specjaliści od okienek, aplikacji na smartfony albo baz danych
Dla programisty jednoukładowców takie problemy jak kolizje przerwań czy kontrola spójności zmiennych wielobajtowych to chleb powszedni. I nie będziesz w stanie zakręcić tak szybko żeby procesor zgubił położenie. Do momentu gdy enkoder sam przestanie rozróżniać impulsy Szacuję, że ze 64 bajty RAM do tego wystarczą i procesor z 8 nogami fizycznymi

P.S.
Asembler tym się różni od kodu maszynowego, że kod maszynowy o czysty kod a asembler daje do dyspozycji makroinstrukcje, instrukcje sterujące, dyrektywy itp. Oprócz czytelnych mnemoników oczywiście.

A można jeszcze dodać, że do bardzo dopasowanych i bardzo wydajnych rozwiązań, nawet C wysiada przy kodzie maszynowym. Bo jest to jedyny sposób, żeby uzyskać DOKŁADNIE zamierzony efekt sprzętowy w każdym momencie działania programu i specyficzne (nadzwyczaj wydajne) zarządzanie zasobami, w tym pamięcią. W takich przypadkach języki obiektowe są nie tyle niewydajne, co całkowicie bezużyteczne.
Podsumowując Wasz spór można powiedzieć, że rasowy inżynier programista posługuje się kodem maszynowym, językiem liniowym (np C) oraz językiem obiektowym, w zależności od potrzeb. Udowadnianie że język obiektowy jest super do wszystkiego, jest wręcz śmieszne.
To zupełnie tak samo jakby powiedzieć, że elektronik wystarczy jak umie zastosować układ scalony z aplikacją oraz wiedzieć jak działa wzmacniacz operacyjny i bramka cyfrowa.

Avalyah pisze:Sztuką jest napisać program, który działa sprawnie i optymalnie, a nie ukrywanie niedociągnięć mocą obliczeniową. To, o czym tutaj mówimy to jest przecież sprawa nieskomplikowana. Trzeba podpiąć enkodery pod przerwania, zliczać im impulsy i wyświetlać to na jakimś wyświetlaczu... gdzie tu filozofia? Pewnie na zwykłej atmedze taktowanej 2MHz by się to dało zrobić, a Wy tutaj piszecie o czterordzeniowych prockach i armach No chyba, że wynik ma być na wyświetlaczu full HD podpiętym przez hdmi, to wtedy atmega nie wystarczy.

Święte słowa

strikexp pisze:To był taki przykład przerwanie procesu. Czy programując mikrokontrolery nie doszliście do takiego pojęcia jak proces ( nie, nie chodzi o te z Linuxa)?
To są problemy programów wielozadaniowych, wielowątkowych i ogólnie programów serwerowych z których korzysta więcej niż jeden klient jednocześnie.
Może tego nie pojmujecie bo mikrokontrolery są jednowątkowe i rzadko działają jak serwery.

KAŻDY układ mikroprogramowany jest jednowątkowy. Żeby procesor był wielowątkowy, musi mieć w sobie więcej niż jeden FIZYCZNY kompletny rdzeń złożony z ALU, adresowania i rejestrów pomocniczych. Tyle że jest to faktycznie kilka mikroprocesorów na jednej płytce półprzewodnika i w zasadzie jest to równoważne płytce na której te elementy są widoczne osobno. Zanim powstały wielordzeniowe (wielowątkowe) procesory tak się to właśnie robiło. Nic nowego tu nie wymyślono, tylko dokonano miniaturyzacji.

W dużych programach jak np aplikacje internetowe. Stosuje się bardzo skomplikowane struktury aby temu zaradzić. Więc radzę ostrożnie z teoriami że C to jest taki wspaniały język, ponieważ ktoś doświadczony może was wyśmiać. Owszem jest to szybki język, dla prostych programów. Ale w bardziej wymagających zastosowaniach wyparty niemal całkowicie przez obiektowe C++.

To nie jest kwestia konieczności tylko wyłącznie wygody. Języki wyższego poziomu są oparte na językach niższego poziomu i tej zależności nie da się przeskoczyć. Język wyższego poziomu to po prostu język na wyższym poziomie abstrakcji, w którym istnieją (gotowe) mechanizmy których programista nawet nie musi wiedzieć, skąd się wzięły i jak działają. Po prostu chodzi o szybsze tworzenie dużych aplikacji i oszczędność na wynagrodzeniu programistów. Tylko i wyłącznie. I o oczywiście o to, żeby ci programiści nie musieli być zanadto dobrzy, żeby wystarczyli przeciętni. Wtedy za te same pieniądze można mieć ich więcej i taniej i tez zrobią co trzeba.
Programowanie użytkowe opiera się na takich właśnie zasadach, bo to od dłuższego czasu jest rynek przypominający tanie supermarkety, gdzie jest potrzeba na zapełnienie półek dużą ilości towaru przeciętnej jakości. Ale tam gdzie robi się rzeczy trudne i technologicznie zaawansowane oraz na szczycie technologii, nadal pisze się programy w językach bardziej "archaicznych".