Procesor za -10 złotych. :)

W zasadzie tak, ale ... to skad to narzekanie na '51 ?

Tam juz chyba cos lepszego potrzeba ... a moze nie?

Za to dosc istotne bedzie, jaki rozmiar ma ten kod zrodlowy. W 64KB nie zmiescisz paru mln linii programu :-)

Dobrze piszesz ... ale szef ma nieco inny punkt widzenia :-)

Musza byc bardzo szerokie.

OWszem, ale przewidzisz wszyskie sytuacje ?

Jakas tam automatyka moze juz z tego wyjsc.

O ile sa toole.

Bo tez moze byc odwrotnie - Heniek juz przerobil 100 plikow, co mu zajelo 2 godziny, a oni ciagle czytaja dokumentacje :-)

J.

Bo zostaly po nim techniki pisania kodu, które Heńki przenoszą na inne dziedziny EDA.

Jakieś zastosowanie Bytomska najszybsza bryczka na świecie miała. Ponoć w telefonach i ponoć w układach GSM. Masz wtedy 60x szybciej naliczanie sekundowe i 200x dokładniejszy zegar uarta do komend AT!

Problem w tym, że to ma niewielkie znaczenie. Można mieć nieweryfikowalny kod na tysiąc linijek i weryfikowalny na milion zajmujacy gigabajt flash.

Kryterium pamieci czy długości kodu jest czynnikiem, ale raczej nie decydującym, o możliwosciach stwierdzenia czy kod jest czy nie "dobry".

Dalej nie wydaje mi się aby crunching miał miejsce w firmie zajmującej się produkcją poduszek powietrznych czy autopilotów. To nie kolejny zegarek szkolny.

I są. Baza testów powinna być zdecydowanie większa niż kod, szczególnie w zastosowaniach safety. Jaka będzie tego miara to inna sprawa, ale bez wątpienia, ilość roboczogodzin napisanych na testy będzie większa niż na kod.

Po to jest weryfikacja formalna aby przewidzieć *wszystkie*. Programista ma tak pisać, aby mozna było *przynajmniej* wydzielić bloki kodu, które są formalnie weryfikowalne lub są napisane w sposób pozwalajacy je traktować i weryfikować osobno. To powoduje że testowanie wszystkiego nie brzmi już tak utopijnie.

Do tej konwersji? Na pęczki. Np. imagemagick.

I tu jest problem Heńka: 40 lat przeleciało za oknem i nagle trzeba się orientować. Nic dziwnego że Heńkowie tak strasznie bronią swoich okopów usypanych z 8051, TTLi i BC107 w których się orientują, przed śladem złej innowacji.

Formalnie nie są gorsze, są inne. Tak więc trzeba na nowo weryfikować czy realtimowe założenia z Heńkowego 8051 są spełnione w nowej architekturze.

Tego nie wiemy ani (prawdopodobnie) Ty, ani ja ... Jednakowoż po coś powymyślali DO-178 i inne wynalazki ...

A co Ty z tym git-em ciągle ... Jak Heniek ma certyfikowany proces notowania w kajeciku która z nowych wersji jest najnowsza to ma się tego trzymać a nie kombinować z git-em ...

IMHO zupełnie niesłusznie się spodziewasz. Programiści nie są od formalnego dowodzenia poprawności algorytmów ...

Piotrek

No nie wiem - to byl pewien margines, a kod zazwyczaj w assemblerze :-)

ale czy obsluga GSM nie wymaga czegos lepszego? No chyba ze - do GSM byl osobny uklad/y, a 51 robil tylko gdzies w interfejsie.

Ale zweryfikowac kod o milionie linii jest zdecydowanie trudniej i drozej :-)

no, 737MAX troche Boeingowi nie wyszedl.

Ale to jest obok testow. Jak myslisz, ze testy nalepsze i wszystko wylapia ... Z drugiej strony - jak sie mozna pomylic przy algorytmie, przy pisaniu programu - tak mozna i przy weryfikacji. A test na symulatorze ... moze wylapie blad.

Ale jak to wszystko w windows - najlepiej obsluguje sie myszka :-)

W tym przykladzie to IMO niekoniecznie - Heniek z niechecia przerobil te 100 plikow ... ale tak bylo najprosciej.

J.

Przecież to ogarnia 6 letnie dziecko w bash'u:

$ for i in *.jpg; do f=`basename $i .png`; convert $f.jpg $f.png; done

basename $i .jpg oczywiście.

Ogarnia, jesli masz taki zgrabny program convert. A zaplaciles za Photoshopa i jego chcesz wykorzystac.

Zreszta *** wie jak ten convert sobie radzi z zapisaniem do jpg. Tam jest pare parametrow. A PS dobrze sobie radzi, przynajmniej prawie wszyscy zawodowcy tak uwazaja :-P

J.

Nie. Wszystko zależy od stylu pisania.

Nie wiadomo.

Boening nie jest doskonały i ogólnie nie ma takich firm. Balansujemy.

Nie wyłapią. Zakłądamy pewien poziomy ryzyka. Jesli to safety, poprzeczka jest wysoko.

Lepsze to, niż licznie na brak błedów.

Nie najlepiej ani najszybciej. *Zależy*.

Nie było najprościej. Nie było najwygodniej. Było tak, jak potrafi. Podobnie z EDA: będzie dziobał te swoje pliki na dyskietkach bez konstroli wersji, bo nie potrafi i uznaje że tak jest najlepiej.

A ci zawodowcy to troche nie są jak audiofile?

Chyba mniej - bo jednak efekty ich pracy co chwila ogladasz. Wiec musi byc w miare dobrze.

Ale moze i oni maja dyskusje o wyzszosci czy przekonanie, ze najlepszy program ... no przeciez nie convert z linuxa :-)

J.

swego czasu słyszałem od godnych zaufania osób, że do zastosowań w lotnictwie nie wolno stosować rozwiązań bazujących na technologii bodajże 22nm i poniżej - kwestia niezawodności, odporności na promieniowanie i trwałości.

Albo protokol - niech wysyla czas zmiany.

Ale tu nie tylko o chwile zmiany chodzi, tylko o to ze wysylasz zapytanie, a do czasu odpowiedzi ... zatrzymujesz proces sterujacy, czy poslugujesz sie poprzednia wartoscia? Wiec trzeba kiedys rozpoznac "urzadzenie od xxx sekund nie odpowiada".

A jak sie termopara od modulu odepnie?

ale np te

J.

Jak przez pewien czas nie masz wiarygodnych informacji, to musisz wdrożyć obsługę takiej sytuacji. Przykładowo, jeżeli 3 kolejne ramki będą uszkodzone lub nie wrócą (master wysyła i oczekuje powrotu - w EtherCat przykładowo), to urządzenia podłączone do takiej magistrali mogą zmienić status z opercyjnego na synclost, a co się wtedy stanie, czy magistrala się podniesie i będzie można kontynuować, to już inna bajka i mocno zależna od konkretnej sytuacji i podłączonych urządzeń. O ile nie widzę problemu w automagicznym podniesieniu się modułu I/O, o tyle nie bardzo wiedzę możliwość takiego podniesienia serwa czy chociażby obwodów safety.

To po pierwsze moduł powinien zmienić statut dla czujnika, a po drugie odczyt będzie z czapki. O ile statut można czasami pominąć, o tyle widząc 850C na przykładowo PT100 można chyba założyć, że coś jest nie teges? ;)

Nie wiem, otwiera mi się strona z której nie wynika dla mnie nic. Dokumentacji nie czytałem. Co do umiejętności, to czasami mam wrażenie, że ST jest znacznie łatwiejszy niż drabinki, przy założeniu że robimy coś więcej niż miganie diodą.

Miłego. Irek.N.

Statut...ale mi się napisało. Przepraszam, status.

Irek.N.

Ale to to badziewie konsumenckie, do tego wiele razy macane, wyginane i ogólnie 2/4 bity w jednej komórce pamięci, wręcz przewidziane do "sypniecia" pamięci ... i nic się niestanie. Porównujesz pan nieporównywalne.

A widział kum.

OT. Ja nie w temacie STM`ów, być może kiedyś do nich podejdę. Co to za cudo te "Safety: Up to ASIL-D"

Nie widziałem też na własne oczy katastrofy samolotu, a ponoć się zdarzają. Nie projektuję urządzeń w oparciu o wiarę, te sprawy pozostawiam innym fachowcom. Jest w datasheecie napisane 10 lat, to przyjmuję 10 lat, pomijam i szukam elementu spełniającego wymagania. Istnieją takie, więc problemu nie ma.

Pozdrawiam, Piotr

Piotr Wyderski napisał(a):

Zgadza się. Tak samo istnieją badziewne karty pamięci/pendrajwy jak i lepsze przemysłowe:) Oczywiście w cenie x4 wyższej niż badziewie konsumenckie.

Taaa ... a co z napisami "not for life support" ? Szukac elementu bez takiego napisu, czy kombinowac jak uzyc popularne elementy ?

Bo mam jakies dziwne wrazenie, ze to czesto to samo ...

J.

Czasami cena elementu nie ma znaczenia, jego awaria oznacza co najmniej upierdliwą naprawę, albo wręcz katastrofę. Tutaj na szczęście chodzi tylko o to pierwsze, więc dopłata kilku złotych za procesor z FRAM zamiast FLASH to niska cena za spokojny sen.

Pozdrawiam, Piotr