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

Nov 01, 2004 63 Replies

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

mierzysz

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.

pozdrawiam entrop3r

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... Takie pomy³ki natychmiast wykrywa kompilator i nie dochodz± one nigdy do u¿ytkownika programu... Ma³o tego - programista jako¶ testuje wyniki swojej pracy i usuwa "grube" b³êdy... Co jest w tym wszystkim istotne to ILE B£EDÓW W PROGRAMIE ZOSTAJE PO UKOÑCZONYM PROCESIE PROJEKTOWANIA/IMPLEMENTACJI/KODOWANIA/TESTOWANIA. Bo te b³êdy s± widoczne dla koñcowego u¿ytkownika... Je¶li chodzi o mnie, to ja mam ogromn± liczbê b³êdów kompilacji bo piszê szybko i literówek robiê sporo a kompilatory jeszcze nie s± a¿ tak bystre aby domy¶leæ siê, ¿e zamiast prinf() chcia³em napisaæ printf()... Albo piszê nazwê rzadko u¿ywanej funkcji bibliotecznej z pamiêci i co¶ przekrêcê. To siê jednak nie liczy w koñcowym rozrachunku bo ten rodzaj pomy³ek jest trywialny w usuwaniu - kompilator automatycznie pisze ¿e czego¶ nie rozumie i poprawienie takich b³êdów zajmuje 2 minuty... Problemem s± b³êdy funkcjonalne a nie literówki.

(...)

upieram sie, ze stac. Oczywiscie, wykonanie czegos na liczbie typu float wyczerpie pewnie cala pamiec w jednej instrukcji C. Ale juz proste operacje na portach, bajtach lub bitach, warunki, petle, itp - czyli wlasciwie wszystko, co mozna na takim malym procku zrobic, bedzie sie kodowac niezwykle wydajnie. Sprawdzalem to na procesorach niewiele wiekszych (12C509 na przyklad) i tak po prostu jest.

(...)

no, nie jest, ale tez nie jest to 10 razy mniej lub wiecej

akurat literowka moze byc w C tak samo bledem trywialnym jak i nietrywialnym (np. i=3 zamiast i==3). A te nieszczesne 2% odnosi sie pewnie do czynnosci w miare prostych, ewentualnie do bledow tego samego typu, bez mieszania literowek z bledami w zakodowaniu czegos, czy tez w ogolnej koncepcji programu. Choc, wcale nie jest wykluczone, ze np. na 100 gotowych koncepcji czy algorytmow obmyslanych przez pojedyncza osobe tez np. 2 sa bledne :) Poza tym, ja tej przekletej liczby nie bronie, to jest po prostu ciekawostka...

moze przekrecasz wlasnie 2 na 100 ? :)

to sie nie ma liczyc w koncowym rozrachunku, jak mniemam. Tak samo nie chodzi o to, czy taki blad to jest pozniej problem, czy nie.

pozdrawiam entrop3r

Daimler Chrysler pakuje różne, 16/32 bit. Mają własny RTOS, architektura ogólnie klient-serwer z transparentną warstwą komunikacyjną opartą o CAN

- pozwala to już napisane moduły rozdzielić na procesory post factum. Te same kawałki softu chodzą w różnych samochodach na różnych konfiguracjach sprzętowych. Na piechotę pisany jest firmware. Reszta głównie syntezowana ze Statemate itp. pakietów modelującyh. Język pośredni syntezy to C.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required