Microchip PIC10F - innowacyjny 6-nóżkowy procesor do PWM i generacji fal prostokątnych

Tue Nov 02, 2004 10:01 pm   

"entroper" <entroper@CWD.spamerom.poczta.onet.pl> wrote in message news:cm8omv$v8t$1@achot.icm.edu.pl...

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

Tue Nov 02, 2004 11:57 pm   

Użytkownik Pszemol napisał:


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

--

Pozdrawiam,

A. Grodecki

Wed Nov 03, 2004 11:05 am   

"Pszemol" <Pszemol@PolBox.com> wrote in message
news:cm8b17.1m4.0@poczta.onet.pl...
(...)

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


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

Wed Nov 03, 2004 2:52 pm   

"entroper" <entroper@CWD.spamerom.poczta.onet.pl> wrote in message news:cmadh4$36f$1@achot.icm.edu.pl...

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.

Wed Nov 03, 2004 4:50 pm   

"Pszemol" <Pszemol@PolBox.com> wrote in message
news:cma67m.21c.0@poczta.onet.pl...

(...)

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

Mon Nov 08, 2004 11:06 pm   

Marek Lewandowski wrote:


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

--
Adam Dybkowski
adybkows@amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/

Tue Nov 09, 2004 9:36 pm   

Adam Dybkowski wrote:


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.
--
Marek Lewandowski ICQ# 10139051/GG# 154441
locustXpoczta|onet|pl
http://www.stud.uni-karlsruhe.de/~uyh0
[! Odpowiadaj pod cytatem. Tnij cytaty. Podpisuj posty. !]