Re: PIC vs AVR - Grupy dyskusyjne w eGospodarka.pl

eGospodarka.pl › Grupy › pl.misc.elektronika › PIC vs AVR › Re: PIC vs AVR

Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.cyf-kr.edu.pl!news.nask
.pl!news.nask.org.pl!news.internetia.pl!not-for-mail
From: Mario <m...@...pl>
Newsgroups: pl.misc.elektronika
Subject: Re: PIC vs AVR
Date: Sun, 06 Apr 2014 23:59:09 +0200
Organization: Netia S.A.
Lines: 46
Message-ID: <lhsjl4$glu$1@mx1.internetia.pl>
References: <533ddbbb$0$2158$65785112@news.neostrada.pl> <lhpavu$914$1@dont-email.me>
<lhpeqj$ct4$1@speranza.aioe.org> <lhpgfo$kjn$1@dont-email.me>
<lhpluc$v7a$1@speranza.aioe.org> <lhpr39$4rf$1@dont-email.me>
<lhq0sf$7gn$1@speranza.aioe.org> <lhrhmg$tsf$1@mx1.internetia.pl>
<lhrhub$kmg$1@speranza.aioe.org> <lhrm67$d0s$1@mx1.internetia.pl>
<lhrugk$kpt$1@speranza.aioe.org> <lhs4bu$she$1@mx1.internetia.pl>
<lhs5o9$c5h$1@speranza.aioe.org> <lhsb09$j45$1@mx1.internetia.pl>
<lhsek4$692$1@speranza.aioe.org>
NNTP-Posting-Host: 159-205-85-152.adsl.inetia.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: mx1.internetia.pl 1396822501 17086 159.205.85.152 (6 Apr 2014 22:15:01 GMT)
X-Complaints-To: a...@i...pl
NNTP-Posting-Date: Sun, 6 Apr 2014 22:15:01 +0000 (UTC)
In-Reply-To: <lhsek4$692$1@speranza.aioe.org>
X-Tech-Contact: u...@i...pl
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Server-Info: http://www.internetia.pl/
Xref: news-archive.icm.edu.pl pl.misc.elektronika:662536
[ ukryj nagłówki ]
W dniu 2014-04-06 22:49, AlexY pisze:
> Użytkownik Mario napisał:
>> W dniu 2014-04-06 20:17, AlexY pisze:
>>> Użytkownik Mario napisał:
>>>> W dniu 2014-04-06 18:14, AlexY pisze:
> [..]
>>>>> Tu jest sedno sprawy, uC to ściśle określony sprzęt, system operacyjny
>>>>> ma działać na całej rodzinie sprzętu, ponadto poziom komplikacji
>>>>> jednak
>>>>> przewyższa atmelkowe miganie diodką, na uC program napiszesz, produkt
>>>>> sprzedasz i możesz o nim zapomnieć,
>>>>
>>>> Tylko po co w takim razie argumentacja, że pisanie w c jest
>>>> niebezpieczne z powodu błędów kompilatora czy ogólnie mówiąc szybkie
>>>> tanie i kiepskie? Skoro kod skompilowany z c jest poprawny i stabilny w
>>>> routerach czy w serwerach to czemu miałby być niepoprawny w przypadku
>>>> atmelkowego migania LEDem?
>>>
>>> Nie wiem w czym windows jest pisany ale daleko mu do bycia stabilnym.
>>> Linuxa ciężko ale też da się wywalić.
>>
>> Weź pod uwagę, że te systemy działają na bardzo szerokiej platformie
>> sprzętowej z obcymi sterownikami i na nich chodzą z kolei tysiące lepiej
>> czy gorzej napisanych programów
>
> Czyż nie to właśnie napisałem powyżej? To jest słuszny argument użycia
> języka wysokiego poziomu, w uC argumentem jest czas pisania programu i
> to uważam za niewłaściwe.

Czas wdrożenia produktu jest jednym z istotniejszych parametrów. Produkt
ma możliwie szybko uzyskać postać gotową do sprzedaży i zarobić na
programistę i innych biorących udział w produkcji. Nie musi być
najdoskonalszy na świecie, pozbawiony nadmiarowych instrukcji. Ma
realizować swoje zadanie i być bezawaryjny. Dla mnie błąd w kodzie jest
wtedy gdy urządzenie nie działa zgodnie z przeznaczeniem lub jest
awaryjne (np podatne na zakłócenia). Nie sądzę żeby był gorszy przyrząd
z prockiem, który 90% czasu krąży w pustej pętli, a przez 100 ms
realizuje zadanie (a mógłby realizować 65 ms gdyby był w asm), od
przyrządu, który ma procek wytężony na 95% ale napisany przez wybitnego
fachowca w asm (bo pisany w c by się w tym procku nie zmieścił albo nie
wyrabiał by czasowo).

--
pozdrawiam
MD