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

No panie, jak prundu nima to d** zbita... ;-)

O sze¶cionó¿kowych procesorach Microchipa maj±cych 256 lub 512 s³ów kodu programu na pok³adzie ;-)

Wiesz, falowniki, które tylko tyle robią, to skończyły się epokę temu. Akurat regulacja w podręcznikowej pętli zajmuje najmniej czasu procesora, a zapewnienie uniwersalności - każdy silnik może być wyposażony w jeden z kilkunastu różnych sensorów położenia lub nie mieć go w ogóle, może pracować od trybu prostej pętli pilnującej zadanych obrotów przez robienie za napędy wykonawcze na jednej z kilku możliwych przemysłowych magistral do pracy jako uproszczony SPS nadający ton reszcie, na czubek funkcje monitorujące i możliwość oscylografowania wewnętrznych wartości mierzonych z mierna, bo mierną ale zawsze rozdzielczością czasową na czterech kanałach... Ale o tym możesz poczytać w dokumentacji jak Ci się kiedyś będzie nudziło.

Ale ich palenie się kosztuje drogo, jak co 8 minut z taśmy zjeżdża Mercedes klasy S....

ALe przekodowanie programu wydłuża TimeToMarket...

U¿ytkownik "futu" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news:cm6buf$1n8$ snipped-for-privacy@news.onet.pl... [ciap]

powiedzia³ co wiedzia³ tak to ZX Spectrum mo¿e s³u¿yc do wszystkiego, wystarczy odpowiedni specjalizowany obwód i ZX do obs³ugi klawiatury.

Andrzej Kamieniecki

I dopiero za 10 lat wymy¶li swoj± seriê ATtyny ;)))

I co ? Chcia³by¶ chodziæ ze swoim komputerem do lekarza, aby leczyæ go ze sklerozy ?

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

Moze, ale nie musi - poza tym wez pod uwage, ze ja policzylem prace jednej osoby, pracujacej na studenckiej stawce, czyli de facto pracownika bez wyksztalcenia. W zespole, w ktorym pracuje, jestem w tej chwili najgorzej oplacany (reszta pracuje na pelnym etacie za stawki inzynierskie i doktorskie...) W wielkoseryjnej i dlugofalowej produkcji skrajna optymalizacja sie oplaca. W takiej na 10.000 sztuk oszczednosc 10 euro robi roznice. Ale jesli tydzien pracy ekipy kosztuje 10k euro, do tego klienci sa gotowi odbierac cala produkcje od zaraz, to czas robi sie na wage zlota, i nawet jesli cos sie optymalizuje do oporu, to robi sie to pozniej... Jak rynek sie ustabilizuje i wiadomo, ze wyjdzie tego wiecej jak 100 sztuk prototypow do testow polowych...

lol :)

Jest jeszcze jedna sprawa... Akurat nie dotyczy mojej branzy, ale z racji ilosci pieniedzy tam latajacych - nie do zignorowania. Mianowicie 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...

Użytkownik Plumpi napisał:

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.

Raczej ze wzgledu na latwosc utrzymywania kodu, czytelnosc, szybkosc tworzenia programu i znaczne zredukowanie liczby miejsc, w ktorych mozna popelnic blad. Przenosnosc na poziomie kodu zrodlowego nie jest az tak istotna (tj. znacznie wiecej sie o niej mowi niz rzeczywiscie w tej sprawie robi). Mozna nawet powiedziec (choc to kwestia pryjetej definicji przenosnosci...), ze w jezykach programowania takich jak Java albo C# zrezygnowano z przenosnosci -- istnieje tylko _jedna_ maszyna docelowa, na ktora jest kompilowany kod zrodlowy (czyt. maszyna wirtualna), a wiec nie ma miedzy czym tego programu przenosic. Natomiast na kazdej rzeczywistej platformie sprzetowej trzeba napisac odpowiednie srodowisko wykonawcze, no ale ono nie jest czescia programu. :-)

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.

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

Pozdrawiam Piotr Wyderski

Użytkownik Plumpi napisał:

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.

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

pozdrawiam entrop3r

;P Coś w tym jest, ale przy odrobinie pomyślunku daje się zrobić w C bardzo przenośny i uniwersalny kod...

licząc na jednego pracownika, uruchamiając to na prototypie urządzenia poddawanym ostatnim modyfikacjom, wziąwszy pod uwagę, że kodu wynikowego jest coś 130kB zpo zipowaniu... Nie jest tak źle...

Jaki kompilator polecisz mi do tytu³owego PIC10F200 ?

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

Dla obrazkow fascynujaca, dla danych komputerowych nie, bo tam kazdy szczegol wazny :-)

Podobnie fascynujace moze byc CD - malujesz szeroka kreske a bledow nie ma.

J.

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.

pozdrawiam entrop3r

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 mierzysz czy zliczasz - a wiêc jak ? Robisz 2 b³êdy na ka¿de 100 linii kodu ? To raczej kiepsko, bym powiedzia³... :-)

Użytkownik Pszemol napisał:

Mozna by powiedzieć, że co druga procedura nie działa poprawnie ;) Czyli program wywala się zaraz po inicjalizacji RAM-u :))))))))