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

U¿ytkownik "Pszemol" snipped-for-privacy@PolBox.com napisa³ w wiadomo¶ci news: snipped-for-privacy@poczta.onet.pl...

no wiesz, nawet jak kto nie zagl±da na stronê producenta, to by³o o tym i w Elektroniku i w EP i bynajmniej nie w tym miesi±cu a wcze¶niej...

Andrzej Kamieniecki

No to sorry, ja ani do Elektronika ani do EP nie zagl±dam ostatnio :-) Moja strata. Ale skoro rozwi±zanie jest takie "stare" i zasiedzia³e, to czy pojawi³y siê jakie¶ ciekawe zastosowania tego uk³adu? Jakie¶ interesuj±ce aplikacje? Jakie urz±dzenia na tym budujecie?

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... :)))))))))))))))))))

Widzê, ¿e Twoja wypowied¼ tr±ci nieco fanatyzmem i zaczepkami w stylu ¶wiêtej wojny "C - do piachu, tylko ASM króluje!" :-) Nie rozpoczynajmy tu tego typu ¶wiêtej wojny, dla równowagi jednak powiem, ¿e s± procesory CISC które maj± po 64-128kb pamiêci programu i nie widzê przeciwskazañ aby w takim przypadku zastosowaæ kompilator C nawet w "zawodowych" programach... Wszystko zale¿y przecie¿ od zastosowania i celów jakie siê przed projektem stawia... Z ca³± pewno¶ci± ciê¿ko bêdzie uzasadniæ zastosowanie kompilatora C w przypadku procka z 256 s³owami kodu :-) Tu Ci rzeczywi¶cie przyznajê racjê, ¿e tam tylko asembler siê zmie¶ci.

Zgadza siê - ja jednak ci±gle nie potrafiê sobie wyobraziæ zbyt wiele zastosowañ przy tak skromnej ilo¶ci we/wy - nawet taki g³upi pilot do telewizora, który wiele inteligencji nie potrzebuje ma zwykle rozbudowan± klawiaturê z kilkunastoma guzikami, wiêc maj±c do dyspozycji 3 wyj¶cia i 4 wej¶cia razem na 4 pinach nie bardzo siê to nadaje nawet do takiego prostego zastosowania...

Bardzo jestem ciekaw projektów w których grupowicze wykorzystali ten procesor... Czy kto¶ siê pochwali co ciekawego na nim zrobi³?

No sorry - na codzieñ siedzê raczej w standardzie 8051. Ale widzê ¿e warto siê PICami zainteresowaæ... ;-)

Wiesz... Nie tylko Atmel garnki lepi.

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.

E tam, gdyby¶ pisa³ w C, to kupi³by¶ wiêksz± kostkê i napisa³ program szybciej :-)

... i innych duperelek ;-) W sumie sprawdzi³em cenê tego PICF200 na

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

- ...

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.

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.

U¿ytkownik "A.Grodecki" <ag.usun snipped-for-privacy@modeltronik.com napisa³ w wiadomo¶ci news:cm5sdn$gh8$ snipped-for-privacy@atlantis.news.tpi.pl... [ciap]

jasne, jasne przez to na ZX Spectrum nie mo¿na ogl±dac DVD, gdyby jednakowo¿ u¿yli sprytnej sztuczki asemblerowej....

Andrzej Kamieniecki

Marek spokojnie, sa zastosowania gdzie taki PIC jest niezastapiony. Jego programowanie mozna wlasciwie nazwac rzezba (w miekkim materiale), ale na wyjsciu mozna z tego uzyskac male cudenko. Oczywiscie przy PIC'u (zwlaszcza tym omawianym) nie ma mowy o jezyku wysokiego poziomu ani o przenoszeniu kodu na inne procesory niespokrewnione wystarczajaco blisko :-) Sprobuj zrobic jakis micro projekt na PIC'a i zobaczysz o czym mowie, jest to niewatpliwie niezapomniane przezycie. Tylko nie szalej bo masz maksymalnie 512 instrukcji 12 bitowych i dwa poziomy stosu :-).

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

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 ;)

Nie mia³em na my¶li samego kodowania czy pisania ¼róde³ a raczej ca³y proces tworzenia softu - nie powiesz mi chyba, ¿e programy w asemblerze tworzy siê szybciej i ³atwiej ni¿ programy w C - znam oba te jêzyki i w tak± herezjê nie uwierzê :-) Wiêc je¶li staæ Ciê na miejsce w pamiêci to nie ma powodu aby¶ sobie nagina³ kark i robi³ nieefektywn±, mrówcz± robotê tam gdzie nie p³yn± z niej ¿adne konkretne korzy¶ci - w asemblerze mozesz sobie pisaæ dla sportu gdzie¶ na uczelni, ale je¶li konkretna aplikacja tego nie wymaga to oprogramowanie pisze siê po najmniejszej linii oporu, aby ³atwo by³o go napisaæ, szybciej uruchomiæ i potem po miesiacach ³atwiej poprawiæ jakiæ znaleziony b³±d, zw³aszcza gdy do zespo³u przyjd± nowi ludzie... Nie odwracajmy do góry nogami techniki programowania komputerów.

Soft jest tak wydajny i budowany takimi ¶rodkami jak to jest wystarczaj±ce do danego zastosowania... Jak trzeba to w³a¶nie nagina siê sprzêt kupuj±c kostkê o dolar dro¿sz± z wiêksz± pamiêci± tylko po to aby skróciæ cykl produkcji software z

Mieszasz ¶wiat embedded z drobinkami takimi jak PIC czy 8051 tworzonymi pod konkretne zastosowanie i zamówienie z maszyn± biurkow± robion± w milionach sztuk - z takiego zamieszania g³upoty Ci wychodz± jako wnioski. Proponowa³bym nie mieszaæ w ogóle pecetów do ¶wiata embedded, bêdzie o wiele bardziej przejrzy¶cie.

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.

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...

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.

No to masz kolego tzw. "job insurance" gwarantowane... Nie ma mowy aby zatrudnili kogokolwiek na Twoje miesjce :-))

Ciekaw jestem ja by³oby z powrotem po 3 miesi±cach albo 3 latach :-)

No proszê... taki super hiper fachowiec a wci±¿ nie zarobi wystarczaj±co du¿o aby sobie stolarza zatrudniæ z w³asnej pensji... Kiszka panie ;-)

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.

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?

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ł