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

Widzieliście PIC10F? Tego jeszcze nie było: 6-nóżkowa obudowa procka:

Użytkownik "Pszemol" <Pszemol_at_nospam_PolBox.com> napisał w wiadomości
news:microchip_at_nospam_poczta.onet.pl...

Widzieliście PIC10F? Tego jeszcze nie było: 6-nóżkowa obudowa procka:

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

to czy pojawiły się jakieś ciekawe zastosowania tego układu?
Jakieś interesujące aplikacje? Jakie urządzenia na tym budujecie?

Widzieliście PIC10F? Tego jeszcze nie było: 6-nóżkowa obudowa procka:
http://www.newarkinone.com/eflyer/microchip/EFlyer-Pic10details.html?CMP=ecurrent10&link=microchip6pin

To maleństwo może zastąpić np. układ 555 w generowaniu fikuśnej fali
prostokątnej albo kontroli mocą urządzenia w jakimś układzie PWM... :-)
Wiele innych zastosowań w mikroskopijnej wręcz na procek obudowie.
Śpiący procek pobiera około 100nA prądu z 2V i może być obudzony zmianą
sygnału na jednym ze swoich 4 I/O. Jak na procek RISC to ma chyba
jednak małą pamięć programu: 256-512 bajtów, tylko dla hardcorowców
zaprawionych na optymalizacji każdego bajtu programu i danych :-)

Jak na procek RISC to ma chyba
jednak małą pamięć programu: 256-512 bajtów, tylko dla hardcorowców
zaprawionych na optymalizacji każdego bajtu programu i danych :-)

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.

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.

Autonomiczny mikrokontroler w obudowie SOT ma niepowtarzalne walory,
choć jak na dzisiaj trudno tam wepchnąć strukturę z dużą pamię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...

• miniaturowych czujników


• miniaturowych układów sterowania czasowego


• generatorów, np syrenek


• detektorów słów transmisji szeregowej


• ...

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

E tam, gdybyś pisał w C, to kupiłbyś większą kostkę i napisał
program szybciej :-)

Moim zdaniem ta technika
rozwija się w złym kierunku. Zamiast zaawansoanych pomysłów stosuje się
zaawansowane rozwiązania siłowe.

Zamiast zaawansoanych pomysłów stosuje się
zaawansowane rozwiązania siłowe.

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

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

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?

Kontrprzykład. Z życia: magnetowid Toshiba, kaseta Maxell HG 240.
Odtwarzane 2 lata codziennie (średnio - bajki). Brak widocznego
pogorszenia jakości obrazu(!!!!)
kontra:
nagrywarka SONY GX, płyta DVD TDK -RW, nieostrożnie wyjęta przez dziecko
z szuflady. "Przeskakuje" na powstałej rysie.

To tak, jak z 90-letnim dziadkiem, który całe życie pali papierosy i jest
zdrowy, ktoś mógłby się upierać, że to dowód dobroczynnych skutków palenia.
Ale jak zrobisz statystykę dla 1000 takich dziadków, okaże się, że paliło
np. 700 z nich, z tego 699 już nie żyje :)

)))

Kontrprzykład. Z życia: magnetowid Toshiba, kaseta Maxell HG 240.
Odtwarzane 2 lata codziennie (średnio - bajki). Brak widocznego
pogorszenia jakości obrazu(!!!!)
kontra:
nagrywarka SONY GX, płyta DVD TDK -RW, nieostrożnie wyjęta przez dziecko
z szuflady. "Przeskakuje" na powstałej rysie.

To tak, jak z 90-letnim dziadkiem, który całe życie pali papierosy i jest
zdrowy, ktoś mógłby się upierać, że to dowód dobroczynnych skutków palenia.
Ale jak zrobisz statystykę dla 1000 takich dziadków, okaże się, że paliło
np. 700 z nich, z tego 699 już nie żyje :)

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?

Kontrprzykład. Z życia: magnetowid Toshiba, kaseta Maxell HG 240.
Odtwarzane 2 lata codziennie (średnio - bajki). Brak widocznego
pogorszenia jakości obrazu(!!!!)
kontra:
nagrywarka SONY GX, płyta DVD TDK -RW, nieostrożnie wyjęta przez
dziecko z szuflady. "Przeskakuje" na powstałej rysie.

Tylko jaka jest różnica w stopniu upakowania danych na powierzchnii ?

Tylko jaka jest różnica w stopniu upakowania danych na powierzchnii ?

A kogo to obchodzi?
W przypadku pamięci holograficznej np o jakiej "powierzchni zapisu"
chciałbyś powiedzieć? a można odłamać kawałek i wszystkie dane są
nadal zachowane!

Tylko jaka jest różnica w stopniu upakowania danych na powierzchnii ?

A kogo to obchodzi?
W przypadku pamięci holograficznej np o jakiej "powierzchni zapisu"
chciałbyś powiedzieć? a można odłamać kawałek i wszystkie dane są
nadal zachowane!

Niezupełnie. Ilość szczegółów zależy od jakości nośnika oraz od wielkości
ziaren emulsji światłoczułej. Czyli jest także ograniczona.

Użytkownik Plumpi napisał:

Tylko jaka jest różnica w stopniu upakowania danych na powierzchnii ?

A kogo to obchodzi?
W przypadku pamięci holograficznej np o jakiej "powierzchni zapisu"
chciałbyś powiedzieć? a można odłamać kawałek i wszystkie dane są
nadal zachowane!

Niezupełnie. Ilość szczegółów zależy od jakości nośnika oraz od wielkości
ziaren emulsji światłoczułej. Czyli jest także ograniczona.

No jasne, zaczynamy tracić szczegóły, ale mimo ubytku fragmentu pamieci
mamy cały czas dostęp do ogólnego obrazu całości. Fascynująca technologia.

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.

Użytkownik "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com> napisał w wiadomości
news:cm5sdn$gh8$1_at_nospam_atlantis.news.tpi.pl...
[ciap]

Moim zdaniem ta technika
rozwija się w złym kierunku. Zamiast zaawansoanych pomysłów stosuje się
zaawansowane rozwiązania siłowe.

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

Wystarczy uzyc DMA i dekodera MPEG2 - do zarzadzania ZXSpectrum by
wystarczyl :D naprawde! nie potrzeba zaraz P4 2,5GHz zeby plynnie dekodowac
MPEG2/DVD

Wystarczy uzyc DMA i dekodera MPEG2 - do zarzadzania ZXSpectrum by
wystarczyl :D naprawde! nie potrzeba zaraz P4 2,5GHz zeby plynnie

MPEG2/DVD

Użytkownik Pszemol napisał:

E tam, gdybyś pisał w C, to kupiłbyś większą kostkę i napisał
program szybciej :-)

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.

E tam, gdybyś pisał w C, to kupiłbyś większą kostkę i napisał
program szybciej :-)

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

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.

Wiesz, widać, że nie pracowałeś nigdy nad żadnym większym projektem.
Akurat profesjonalne aplikacje pisze się w językach wysokiego poziomu

takich wypadkach po prostu pisze się efektywnie w C, a nie rzeźbi w
assemblerze.

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

takich wypadkach po prostu pisze się efektywnie w C, a nie rzeźbi w
assemblerze.

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

Zaczyna brakować zasobów, bierze
się bez bólu większy a przeniesienie kodu nie trwa dłużej niż wieczór-dwa!

A.Grodecki wrote:

Zaczyna brakować zasobów, bierze
się bez bólu większy a przeniesienie kodu nie trwa dłużej niż wieczór-dwa!

czyli ok. 100 euro + dodatek za nadgodziny kosztuje zmiana proca,
zamiast 0.20 (przestawienie "target" w kompilatorze)

A.Grodecki wrote:

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.

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.

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.

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.

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?

• było to mniej niz 1/2 etatu


• procedury były w znacznej mierze gotowe (baza z wcześniejszych rozwiązań)


• czas opracowania to w dużej części (choć mniejszość) opracowanie

• CPU i tak został wsadzony z zapasem, bo nowe potrzeby klienta

• za opracowanie płaci z góry zamawiający, płaci dużo, ale jednocześnie

• urzadzenia sa drogie, i koszty opracowania się nie licza specjalnie,

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.

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.

Ja mam raczej problem z niskimi temperaturami, bo niektóre ustrojstwa nasze pracują pod kręgiem polarnym :)

Nasze też, i z tym zawsze mamy najmniej problemów...
Wystarczy trochę prądu prze opornik przepuścić ;-)

Użytkownik Pszemol napisał:

Nasze też, i z tym zawsze mamy najmniej problemów...
Wystarczy trochę prądu prze opornik przepuścić ;-)

Trzeba go najpierw dosyć mieć, nie wszystko chodzi z sieci.

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.

Wiem jak działa falownik, co nadzoruje procesor i jak wyglada pętla
regulacji. Nie jest to rzecz banalna, ale nie przesadzajmy - również nie
rzuca na kolana.

Falowniki też się palą, nie ma urządzeń niezawodnych.

No wiesz, tak zawsze mozna argumentować. Na wszystko też da się znaleźć
rozwiązanie. Gdyby jakieś specjalne urządzenie musiało mieć inny
sterownik, to pewnie by się takiego uzywało. Używaliśmy i '51 i
Motoroli, ale przecież normalnie się nie skacze z firmy na firmę. To
żadkość i zwykle rewolucja i problem na większą skalę niż tylko
przekodowanie programu.

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?

• ile sztuk projektu, bo oszczedzajac powiedzmy 5 euro na sztuce

• skrocilbys czas o polowe ? Popatrz - tu kolega juz drugi dzien

Obejrzyj sobie nasze falowniki.

Dwa zastrzezenia:
- ile sztuk projektu, bo oszczedzajac powiedzmy 5 euro na sztuce
to sie moze szybko zwrocic.

- skrocilbys czas o polowe ? Popatrz - tu kolega juz drugi dzien
walczy z pomiarem dlugosci impulsu, w assemblerku juz dawno byloby
napisane :-)

Naprawde zwroci sie dopiero przy przejsciu na nowy procesorek.
Przy czym .. na tytulowe malenstwo tresci przenosnej w programie
bedzie malo. A duzo czesci hardwaro-zaleznej. I to wszystko przy
przenoszeniu trzeba bedzie przeanalizowac.

Obejrzyj sobie nasze falowniki.

A gdzie obejrzec ?

samochody. Cykl produkcji to w tej chwili max 2 lata. Wiekszosc softu
musi byc napisana i wstepnie zdebugowana zanim zapadna ostateczne
decyzje jakie, gdzie i ile procesorow w systemie bedzie... Firmware jest
dopisywane na samym koncu... pod juz uzywane API.
Zrobta to w ASM...

A jakie procesorki siedza w ostatnio wypuszczanych samochodach i w jakim
jezyku pisze sie na nie soft?

• pozwala to już napisane moduły rozdzielić na procesory post factum. Te

Dwa zastrzezenia:
- ile sztuk projektu, bo oszczedzajac powiedzmy 5 euro na sztuce
to sie moze szybko zwrocic.

- skrocilbys czas o polowe ? Popatrz - tu kolega juz drugi dzien
walczy z pomiarem dlugosci impulsu, w assemblerku juz dawno byloby
napisane :-)

Naprawde zwroci sie dopiero przy przejsciu na nowy procesorek.
Przy czym .. na tytulowe malenstwo tresci przenosnej w programie
bedzie malo. A duzo czesci hardwaro-zaleznej. I to wszystko przy
przenoszeniu trzeba bedzie przeanalizowac.

Obejrzyj sobie nasze falowniki.

A gdzie obejrzec ?

Dwa zastrzezenia:
- ile sztuk projektu, bo oszczedzajac powiedzmy 5 euro na sztuce
to sie moze szybko zwrocic.

- skrocilbys czas o polowe ? Popatrz - tu kolega juz drugi dzien
walczy z pomiarem dlugosci impulsu, w assemblerku juz dawno byloby
napisane :-)

Naprawde zwroci sie dopiero przy przejsciu na nowy procesorek.
Przy czym .. na tytulowe malenstwo tresci przenosnej w programie
bedzie malo. A duzo czesci hardwaro-zaleznej. I to wszystko przy
przenoszeniu trzeba bedzie przeanalizowac.

Obejrzyj sobie nasze falowniki.

A gdzie obejrzec ?

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!

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

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

"A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com> wrote in message
news:cm62kq$qjf$1_at_nospam_nemesis.news.tpi.pl...

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!

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

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

Hej, może zleceniodawca i zleceniobiorca są jakoś spokrewnieni
a projekt finansuje państwowa firma? Przecież różnie to bywa
z tymi przetargami na projekty z wiązane z autostradami i wagami
dla tirów... ;-)

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

Zadaj sobie np pytanie, dlaczego firmy zachodnioeuropejskie budują
fabryki w Chinach, BIORĄC POD UWAGĘ (serio), że może tam nastąpić wtórna
nacjonalizacja?

Bo mają tam siłę roboczą prawie za darmo, a ewentualne straty z powodu
jakiejś rewolucji to tylko rozkradzione maszyny w fabryce, maszyny można
kupić nowe (zyski z prawie darmowej pracy na to pozwolą), a cała wiedza jest
zgromadzona gdzie indziej.

O czym my w ogóle dyskutujemy?

"A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com> wrote in message
news:cm62kq$qjf$1_at_nospam_nemesis.news.tpi.pl...

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!

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

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

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

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

No proszę... taki super hiper fachowiec a wciąż nie zarobi
wystarczająco dużo aby sobie stolarza zatrudnić z własnej pensji...
Kiszka panie ;-)

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.

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!

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

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

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

Dzięki temu przeniesienie kodu na nową platformę zajęło jakieś niecałe
dwa miesiące

Nie piszę z powietrza - wszystkie nasze
falowniki są oprogramowane w C

Wiesz, trudno nazwac C jezykiem wysokiego poziomu, a jeszcze
trudniej przypisac mu przenosnosc, skoro standard nie okresla nawet
ile bitow ma typ calkowity. Znajomy nazywa ten jezyk
"wysokopoziomowym asemblerem", a ja sie z ta opinia zgadzam.

Dzięki temu przeniesienie kodu na nową platformę zajęło jakieś niecałe
dwa miesiące

To strasznie dlugo (na granicy czasu stworzenia programu od nowa).

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

Bo zawodowe programy na mikrokontrolery pisze się w asemblerze, z

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

nie przystaje do efektywnej obsługi skromnych zasobów.

to wszystko zalezy, jak sie pisze, czym sie kompiluje i pod jaki
procesor. Mozna napisac w C cos wydajnego (szczegolnie, jak sie wie,
z czym kompilator sobie dobrze radzi, a z czym nie), a mozna i w
asemblerze napisac cos do d... (znaczy, zbyt wydajnego, tak
wydajnego, ze czasem zapomni cos zrobic itp.). Osobiscie pod PIC-e
bardzo dobrze pisze mi sie w C.

A pelna kontrola to takie ladne haslo - czlowiek statystycznie
popelnia 2% bledow, w asemblerze tez...

Jaki kompilator polecisz mi do tytułowego PIC10F200 ?

A pelna kontrola to takie ladne haslo - czlowiek statystycznie
popelnia 2% bledow, w asemblerze tez...

A jak te procenty się liczy? 2 byki na 100 linii kodu czy jak?

"Pszemol" <Pszemol_at_nospam_PolBox.com> wrote in message
news:cm81oc.27k.0_at_nospam_poczta.onet.pl...

Jaki kompilator polecisz mi do tytułowego PIC10F200 ?

CCS-a. Pod ten procek moze nie byc (nie sprawdzalem), ale PIC-e maja
architekture klockowa i wystarczy wiedziec, czego dany procek nie
ma, by rozumnie uzyc konfiguracji dla procka wiekszego.

nie wiem, czy na linie kodu, czy na komende, prawdopodobnie na jakas
powtarzana czynnosc. Ta liczba jest raczej obiegowa wartoscia, ale
rzucil ja bardzo madry czlowiek i z dokladnoscia do rzedu wielkosci
raczej sie potwierdza (tzn, taka zauwazam u siebie i
wspolpracownikow - dokladnie nie liczylem tego nigdy, ale tez wiem,
ze nie mozna marzyc np. o 0.1%). Oczywiscie, mozna te swoista
wartosc troche zmniejszyc, ale przy wyraznym zwiekszeniu wysilku,
wracaniu do tego samego po 5 razy itp.

Dla mnie interesujące jest to, że mierzysz niezawodność metodą
której nie do końca znasz... To znaczy na pytanie jak ten procent
obliczyć odpowiadasz, że nie jesteś pewny, ale w następnym zdaniu
twierdzisz, że potwierdzasz te 2% u siebie, czyli jakoś to mierzysz
czy zliczasz - a więc jak ? Robisz 2 błędy na każde 100 linii kodu ?
To raczej kiepsko, bym powiedział... :-)

Nie wiem czy zauważyłeś, ale ten procek ma tylko 256
słów na pamięć programu... Moje pytanie o kompilator C
było trochę "podchwytliwe" :-)

Dla mnie interesujące jest to, że mierzysz niezawodność metodą
której nie do końca znasz... To znaczy na pytanie jak ten procent
obliczyć odpowiadasz, że nie jesteś pewny, ale w następnym zdaniu
twierdzisz, że potwierdzasz te 2% u siebie, czyli jakoś to

czy zliczasz - a więc jak ? Robisz 2 błędy na każde 100 linii kodu

To raczej kiepsko, bym powiedział... :-)

zauwazylem, a moja odpowiedz jest najzupelniej powazna - ten
kompilator, odpowiednio uzyty, jest niesamowicie wydajny - bardzo
czesto jedna linia w C to jedna linia w asm. A pewnych rzeczy nie
trzeba juz pilnowac (moze przelaczanie bankow to nie bedzie za dobry
przyklad w tym procku :D).

potwierdzam z dokladnoscia do rzedu wielkosci, czytaj uwaznie :)
Nie robilem zadnych badan, traktuje to jako ciekawostke, ktora sie z
pewna dokladnoscia potwierdza i w tym momencie zarzuty, ze tego
dokladnie i metodycznie nie zbadalem, sa troche smieszne. Po prostu
kompiluje cos, i widze na pasku na_przyklad 200 lines, errors 1
itp. i wtedy usmiecham sie do tego madrego wykladowcy, ktory rzucil
tamta liczbe. To wszystko.

A, no i nie uwierze, ze robisz 1 blad na
1000 lub wiecej linii kodu. Zaryzykuje nawet bezczelne stwierdzenie,
ze robisz dokladnie tyle samo bledow co inni, w swoim mniemaniu
bezbledni, co sie tutaj zaraz odezwa. I nie podstawie glowy, ile to
jest - czy 1%, czy 0.5%. A przy odrobinie dobrej woli zrozumiesz
tez, do czego sie ta liczba odnosi - jesli np. piszesz procedure i
pozniej jej uzywasz, to oczywiste jest, ze masz jakas okazje pomylic
sie w procedurze, a pozniej blad dotyczy jednej linii wywolania tej
procedury, bo to jest ta pojedyncza wykonywana czynnosc.

Być może Twoja odpowiedź jest poważna, ale użycie C w tym
akurat konkretnym przypadku wydaje się jednak śmieszne...
Jak masz do dyspozycji tylko 256 instrukcji na cały program
to sądzę, że nie stać Cię na taką ekstrawagancję jak język C.

1 na 200 to nie jest 2% :-)

W ogóle nie rozumiesz chyba co to jest "błąd programisty"...
Nie chodzi tu o trywialną literówkę w nazwie wywołania funkcji
czy też brakujący gdzieś tam średnik na końcu przypisania...

Albo piszę nazwę rzadko używanej funkcji bibliotecznej z pamięci
i coś przekręcę.

To się jednak nie liczy w końcowym rozrachunku