Microchip - procesor w mini obudowie 6-pinowej SOT-23

Loading thread data ...
Reply to
Andrzej Kamieniecki

Użytkownik Pszemol napisał:

Już dłuższy czas są.

Bo zawodowe programy na mikrokontrolery pisze się w asemblerze, z pełną kontrolą tego co się dzieje w układzie, w każdej chwili. A nie z wykorzystaniem badziewiastych crossasemblerów z C, który to język nijak nie przystaje do efektywnej obsługi skromnych zasobów.

Autonomiczny mikrokontroler w obudowie SOT ma niepowtarzalne walory, choć jak na dzisiaj trudno tam wepchnąć strukturę z dużą pamięcią :)

Swoja drogą, duże i elastyczne 18Fxxxz tez pobierają 100nA w trybie SLEEP, nic nowego.

P.S. Atmel jak zwykle jeszcze w krzakach... :)))))))))))))))))))

Reply to
A.Grodecki

Użytkownik Pszemol napisał:

Ale skoro rozwiązanie jest takie "stare" i zasiedziałe,

Nie jest stare, ale też nie z ostatniej chwili. Niestety u nas ich jeszcze ostatnio nie było, bo nie było zapotrzebowania przemysłowego. A jak wiadomo na szpuli trochę się mieści..., za dużo żeby sobie kupić na próbę albo do zabawy :) Procesor jest do ultraminiaturowych układów o nieskomplikowanych możliwosciach - specyficzne potrzeby.

Reply to
A.Grodecki

Użytkownik Pszemol napisał:

Oczywiście że tak, szczególnie jeśli chodzi o aplikacje nie pracujące w czasie rzeczywistym. Troche fanatyzuję, to fakt, Ostatnio zapchałem całą pamięć 18F485 czystym saemblerem :) Ale gdybym piał w C, to by mi tam nawet program nie wlazł, niestety! Pomijam inne kłopoty z działaniem systemu.

Akurat pilot potrzebuje sporo nóg tylko na potrzeby skanowania klawiatury, jak szalonego układu by nie wymyślić. Potrzebuje też sporo pamięci na kody sterowania. Taki mały 6-nogowiec może być do (improwizuję):

- miniaturowych czujników

- miniaturowych układów sterowania czasowego

- generatorów, np syrenek

- detektorów słów transmisji szeregowej

- ...

Reply to
A.Grodecki

Użytkownik Pszemol napisał:

Szybciej - niezbyt. Pisanie w asemblerze nie polega przecież na pisaniu każdej linii z osobna, są makra, instrukcje sterujące... To kwestia podejścia. Wychodzę z założenia, że urządzenie buduje się takimi środkami, jakie są wystarczające a nie nagina sprzęt do niedorobionego, niewydajnego softu. Innymi słowy nie podzielam filozofii PC i Windows (2GHz procesor tylko po to, żeby klatki filmu nie przeskakiwały :)) Moim zdaniem ta technika rozwija się w złym kierunku. Zamiast zaawansoanych pomysłów stosuje się zaawansowane rozwiązania siłowe.

Reply to
A.Grodecki

Wiesz, widać, że nie pracowałeś nigdy nad żadnym większym projektem. Akurat profesjonalne aplikacje pisze się w językach wysokiego poziomu ze względu na przenośność kodu. Nie piszę z powietrza - wszystkie nasze falowniki są oprogramowane w C, baza kodu jest wspólna dla całej linii produktów mimo skrajnie nieraz różnych peryferiów i różnych procesorów. Dzięki temu przeniesienie kodu na nową platformę zajęło jakieś niecałe dwa miesiące, i to i tak dużo, bo jakiś idiota uparł się na wstawki assemblerowe i programowanie trikowe w poprzedniej "edycji" firmware... Zobacz, jak oprogramowane są komputery pokładowe Daimlera - tam w ogóle latają aplikacje pisane nie dość, że językiem wysokiego poziomu, to jeszcze w dużej mierze przez automatyczne generatory kodu (!) bazujące na opisach behawioralnych w np. UML. Jasne, że takie ekstremizmy nie są popełniane w przypadku np. jednostki sterowania wtrysku, ale i w takich wypadkach po prostu pisze się efektywnie w C, a nie rzeźbi w assemblerze.

Reply to
Marek Lewandowski
Reply to
Andrzej Kamieniecki

Mój ostatni system, największy jaki do tej pory zrobiłem, zawiera 15 mikrokontrolerów w tym 8 różnych programów, zamkniete w 6 obudowach. Sterownik ma ~150 okien menu (każde inne i co innego wykonuje, nie ma powieleń) a urządenie sterowane jest 90 parametrami użytkowanika i około

40 liczonymi automatycznie. Sterownik potrafi modyfikować własny kod. Całość steruje całkowicie autonomicznym robotem poruszającym się na kołach i napędzanym silnikiem diesla (też pod kontrolą) z hydraulicznym przeniesieniem napedu na 9 elementów wykonawczych sterowanych proporcjonalnie. Urządzenie pozycjonuje się na płaszczyźnie wykrywając spreparowane pole elektromagnetyczne przy pomocy specjalnych anten i obsługuje wagę mierzącą w zakeresie 0-3tony z dokładnoscia 1kg (w ruchu) i rozdzielczością 100g. Ponadto robot steruje drogą radiową innymi urządzeniami. Wszystkie systemy pod kontrolą, pełne autotesty i zabezpieczenia. Jeszcze parę bajerów mam mu dorobić w niedalekiej przyszłości, ale najpierw prototypy muszą troszkę popracować żeby niedociągnięcia wyszły...

To "mały" czy "duży" projekt? ;)

Całość (sprzęt i soft) w ciągu 7 (nie 17 ani 70) miesięcy z przerwami na "szybkie" mniejsze projekty. Soft tylko w asemblerze. JEDNA OSOBA! System zastępuje inny, zbudowany na PLC. Jest tańszy, lżejszy, mniejszy objętościowo kilkakrotnie i zużywa kilka % energii poprzedniego. Robi tez od niego więcej, bo przejął funkcje dodatkowych modułów nie należących wcześniej do systemu PLC. Poprzrdnia firma robiła to sterowanie na PLC przez 1.5 miesiąca. Krócej, ale to było kilku inżynierów na raz a poza tym system który stworzyli był w stanie tylko sterować zdarzeniami a funkcje motoryczne (np pozycjonowanie, prędkość) były realizowane poza systemem, przez odrębne moduły specjalizowane. To jest zaledwie 1/3 programu mojego sterownika, reszta to nadzór nad hardware i funkcjami motorycznymi.

To na prawdę tylko i wyłącznie kwestia wprawy w czym się pisze, ja wybrałem asembler jako najwydajniejszy dla małych projektów, które robię. Ten ostatni też zaliczam do małych. Trudno nazwać dużym projektem taki, który jest w stanie zrobić jedna osoba, choćby nie wiem jak sprawna. Falownik to też mały projekt!

Nie ma też problemów z powrotem do projektu, co czesto zarzuca się językom niskiego poziomu. To kwestia organizacji programu, opisów i makr. Wracałem do tego projektu po 3 tygodniowych przerwach pisząc w międzyczasuie inne programy do zbudowanego sprzętu i nie miałem problemu z kontynuacją.

C tak mało używam, że go praktycznie zapomniałem. Zgadzam się, że jeśli jest potrzeba częstego przenoszenia kodu na inne platformy to jest to inny problem, ale ja się z takim nie spotykam. Jeśli biorę większego Microchipa, to nie mam najmniejszych problemów z przeniesieniem kodu na niego! O to zadbali mądrzy inżynierowie z Microchipa i między innymi dlatego związałem się z tą firmą. To co robią jest przemyślane, stanowi kontynuację i ma kontynuację.

Jest jeszcze problem ceny pracy ludzkiej. To właśnie jest powodem pojawienia się PLC, które generalnie rzecz biorąc sa do bani w konfrontacji z urządzeniami dedykowanymi. Chodziło o to, żebny zrobić funkcjonalne urządzenie jak najmniejszym kosztem ludzkim, bo praca łebskiego inżyniera na zachodzie jest cholendarnie droga, a poziom techniczny ustojstwa ma mniejsze znaczenie. Dlatego wymyślono elektroniczne klocki LEGO czyli PLC a konstruktora sprowadzono do poziomu programisty w C (o takich dużo łatwiej), byle mniej za robociznę wyszło. "Konstrukcja hardware" sprowadza się do zapięcia modułów na szynę i połączenia ich kabelkami.

Uff, ale sie rozpisałem, sorry. Pa, spadam do roboty. Mam za 2 tygodnie zrobić nowe udządzenie, niezbyt skomplikowane, ale w "międzyczasie" jeszcze muszę zrobić w domu poręcz schodów :))))) Jakoś tam będzie ;)

Reply to
A.Grodecki

[ciach dużo o fajnym projekcie]

Dobrze. Zrobiłeś to w 7 miesięcy. Fajny, w miarę złożony projekt. Załóżmy, że robiłbym to ja (to znaczy, zakładam, że jestem niżej rangą jeśli chodzi o płące i prace itepe).

załóżmy, że to nie był mój jedyny projekt, czyli, że max mogę przeznaczyć pół etatu.

20h tygodniowo x 7 miesięcy x 4 tygodnie = 560h = 5,5 tysiąca euro + to, co dostał fiskus i socjalni, pracodawcę kosztowałoby to około 10 tysięcy euro. Jeśli mógłbym wykorzystać część kodu napisaną na inny procesor, przez kogo innego, nawet kosztem wsadzenia niecos silniejszego CPU, napisać to w C, dzięki czemu mój czas pracy nad projektem skróciłby się o 50%, to oznacza to oszczędność na NAJTAŃSZYM PRACOWNIKU UMYSŁOWYM W ZESPOLE w wysokości około 5 tysięcy euro. Capisce?

Obejrzyj sobie nasze falowniki. Jak na jednoprocesorowy system to dzieje się tam dużo, a jak dołożysz wymagania niezawodności i gwarancji utrzymania pracy to siwieje się nadzwyczaj szybko.

Kontynuacja to małe piwo.

To powiedz mi, co zrobisz, jak się okaże, że Twój układ musi pracować przy 100 stopniach w obudowie, a nie ma akurat proca Microchipa z wymaganymi peryferiami, który byłby specyfikowany do +125oC? To taki przykład... Przenośność kodu kosztuje - wydajność, flash, czas CPU, ale nie można postrzegać tego jednostronnie. Jasne, Windowsy itp to ekstremum, posunięcie w drugą stronę absurdu...

Reply to
Marek Lewandowski

no ale o jakim my kodzie na małym PICu mówimy? Przecież przestawienie dyrektyw kompilacji wymaga więcej napisania, niż cały program na takim picu :P przeginam, jasne.

Reply to
Marek Lewandowski

Użytkownik Andrzej Kamieniecki napisał:

Coś w tym rodzaju, choć nie do końca to miałem na myśli ;) Chodziło mi o to, że obiecujące techniki (jak na przykład sieci neuronowe itp) stoją w miejscu (a może nie...(?)- ktoś coś wie?), a "rozwój" komputerów polega na dodaniu kolejnego miliona tranzystorów do struktury i zmniejszeniu napięcia o kolejny wolt, żeby "nowoczesny" scalak nie sfajczył się z nadmiaru potu.

Zeby zapisać i odtworzyć film na ekranie TV potrzeba albo:

  1. kawałek taśmy z magnetycznymi drobinami, silnik i... paręset tranzystorów albo:
  2. podziurawionego matalizowany dysk, silnik i... parę milionów tranzystorów.

Gdybyś był, powiedzmy, kosmitą, albo przybyszem z przeszłości, który nie wie o co chodzi, i dostałbyś te dwa puynkty do porównania, co byś sobie pomyślał? Czy 2. jest technologicznym następstwem (udoskonaleniem) 1., czy moż na odwrót??? O to mi włąśnie chodziło.

Reply to
A.Grodecki

To ja mam dla Ciebie lepsze porównanie:

Masz do wyboru odtworzenie video kosztem 500mW mocy przy MTBF pół miliona godzin bez degradacji sygnału w czasie, albo kosztem 90W przy MTBF 100h z degradacją postępującą do nieczytelności. Które rozwiązanie jest bardziej zaawansowane technicznie?

Reply to
Marek Lewandowski

Ja jestem ciekawy kto zlecił taki złożony projekt jednoosobowej firmie, która z powodu bycia jednoosobową nie może zagwarantować serwisu (bo "firma" może chociażby złamać nogę na nartach, albo wyjechać na długie wakacje). Z tym "job insurance" to też nie takie pewne, skoro wymienili ten sprzęt raz na zupełnie inny, to mogą wymienić drugi raz :)

Paweł

Reply to
Paweł Paroń

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.