On Tue, 27 Apr 2021 21:03:35 +0200, Piotr Wyderski wrote:
> J.F wrote:
>> Ale nie zawsze NAK cie satysfakcjonuje, czasem trzeba poczekac na
>> wynik.
>
> Spytaj później.

a pozniej bedzie wynik czy kolejny NAK?

>> O ile procek mastera na taki pozwoli.
>> A czy nie powinien poczekac do konca spodziewanej transmisji?
>
> Ma czekać an koniec nie wykrywszy początku?

A bedziesz mial info o poczatku, czy jest gotowiec ktory caly pakiet
odbiera ... i zglasza na koniec ?

>> A jak kabelek sie urwie, to ile bedzie czekal ?
> Ustaloną liczbę cykli, po czym sobie sam wygeneruje NAK.

Swietnie ... dopoki wszystkie urzadzenia beda odpowiednio szybkie.

J.

do góry

J.F wrote:

> a pozniej bedzie wynik czy kolejny NAK?

Się zobaczy; spytasz, to się dowiesz. NAK to dobry sygnał, bo wskazuje,
że urządzenie żyje. Wykrywanie zbyt wielu NAKów pod rząd to zadanie
mastera, równoważne timeoutowi, ale na poziomie logicznym, a nie
blokowania szyny.

> A bedziesz mial info o poczatku, czy jest gotowiec ktory caly pakiet
> odbiera ... i zglasza na koniec ?

No masz wykrywanie bezczynności szyny. Jak nie jest bezczynna, to ktoś
nadaje i reszta słucha, z masterem włącznie. Jak nie nadaje przez N
mikrosekund od otrzymania prośby o odpowiedź, to znaczy, że już nie
zacznie i master odpytuje kolejny moduł.

> Swietnie ... dopoki wszystkie urzadzenia beda odpowiednio szybkie.

No ale to jest z łatwością do zrealizowania przez FPGA, więc czemu z
tego nie skorzystać? Dostaje zapytanie, patrzy w FIFO, czy coś ma do
wysłania, a jak nie, to od razu wysyła NAK. To się w kilka cykli zegara
da obskoczyć, kilkanaście przy jakimś złożonym protokole z dekodowaniem
w pipeline. 200 nanosekund, powiedzmy.

Pozdrawiam, Piotr

do góry

Zbych wrote:

> Właśnie sobie oglądam porównanie FRAMów, MRAMów i "data retention" dupy
> nie urywa:

Porównaj temperatury, to urwie. :) Avalanche ma milion lat w 65 stopni
vs 10 lat w 55 stopni dla dyskutowanego chipu FLASH. 10 lat jest dla 105
stopni. BTW, Twoje informacje nie są zgodne z tabelką na str. 48
Avalanche: w 85 stopni jest 1000 lat, nie 20.

https://pl.mouser.com/datasheet/2/1122/1Mb_16Mb_Seri
al_HP_MRAM-1949444.pdf

Pozdrawiam, Piotr

do góry

Piotrek wrote:

> Chodziło mi o wynalazki Python-owe, których - jak rozumiem - używasz w
> charakterze preprocesora do właściwych narzędzi "firmowych".

A -- to samoróbek.

Pozdrawiam, Piotr

do góry

On 28/04/2021 16:28, J.F wrote:
> Ale tu nie chodzi o skansen. Boeing, Airbus, Ariane, Space X, czy
> nawet wposlczesny samochod osobowy ... kto stworzyl elektronike ?

Nie brodacze od 8051 którym 40 lat przeleciało za oknem. Wbrew pozorom w
lotnictwie poziom pewności co czym i jak developujesz/testujesz wynika z
procedur. Nie ze średniowiecznych poglądów Henia, co zatrzymał się w
NortonCommanderze i Keilu. Te procedury, to często coś podlegające audytom.

>> Ludzie od FPGA też są zakonserwowani w formalinie. Jest zdumiewające,
>> ale ludzie od FPGA prawie nie używają kontroli wersji. To jedna z
>> najbardziej szokujących informacji jakie do mnie dotarły, dotyczących
>> pracy w zespołach hardwareowców. I to jest pogląd z pewnego miejsca,
>> gdzie to dobrze widać w skali statystycznej.
> No wiesz - w plikach binarnych to prawie nie ma sensu.
> A w tekstowych ... mozna sobie radzic inaczej.

Mówisz o kontroli wersji? A i owszem:
1) można zgrywać na pendrive
2) można zgrywać na NAS
3) można wysyłać mailem

Tylko że od kilkudziesięciu lat doskonale wiemy że to wszystko g...
Natomiast jest ciągle duża grupa ludzi, którzy najzwyczajniej nie
pojmują zalet (nie rozumiejąc ich) i wymyślają kwadratowe koła. Często
to postawy czysto ideologiczne (myślmy zawsze tak robili/w poprzedniej
firmie tak robiliśmy/ja jestem najmądrzejszy i tak wymyśliłem/not
invented here).

I o ile w przypadku małego skansenu z kilkoma Heńkami to nie dziwi, to
jak mówie że tutaj jest cała branża EDA która najzwyczajneij ignoruje
zdobycze informatyki na poziomie inżynieri (o)programowania, a wyjątki
są raczej glitchami. I nie, nie mają powodów, poza
tradycją/ignorancją/"nikt tak nie robi". To problem czysto białkowy, EDA
ma ogromną bezwładność na pojmowanie zmian organizacji pracy, zupełnie
przeciwnie jak zwykli programiści. Mozliwe że to wynika z faktu że
programistó w EDA jak na lekarstwo, choć robią głównie programowanie.

do góry

Piotr Wyderski wrote on 28.04.2021 17:10:

> stopni. BTW, Twoje informacje nie są zgodne z tabelką na str. 48
> Avalanche: w 85 stopni jest 1000 lat, nie 20.

Te 20 lat to akurat z ich własnych materiałów porównujących fram i mram.

do góry

On Wed, 28 Apr 2021 18:29:16 +0200, heby wrote:
> On 28/04/2021 16:28, J.F wrote:
>> Ale tu nie chodzi o skansen. Boeing, Airbus, Ariane, Space X, czy
>> nawet wposlczesny samochod osobowy ... kto stworzyl elektronike ?
>
> Nie brodacze od 8051 którym 40 lat przeleciało za oknem. Wbrew pozorom w
> lotnictwie poziom pewności co czym i jak developujesz/testujesz wynika z
> procedur. Nie ze średniowiecznych poglądów Henia, co zatrzymał się w
> NortonCommanderze i Keilu. Te procedury, to często coś podlegające audytom.

No i kto jest pryszczatym nastolatkiem - programisci, czy audytorzy?
:-)

A potem mozna przeczytac taki tytul

https://antyweb.pl/dwa-16-bitowe-komputery-z-1996-ma
ja-naprawic-konstrukcyjne-bledy-boeinga-737-max-nie-
wiem-jak-wy-ale-ja-do-takiego-samoloty-nie-wsiade/

Hm, moze i audytorzy sa pryszczatymi nastolatkami, skoro
https://www.komputerswiat.pl/aktualnosci/nauka-i-tec
hnika/boeing-737-max-z-nowymi-bledami-w-oprogramowan
iu-moze-prowadzic-do-utraty-kontroli/xsyt9km


Albo
https://www.dobreprogramy.pl/airbus-a350-wadliwe-opr
ogramowanie-wymusza-twardy-restart-co-149-godzin,662
8574829315713a

Przy czym wydaje mi sie, ze czytalem z rok temu o podobnym bledzie w
Boeingu ... albo mamy dwa, albo mi sie firmy pomylily.

A, pamiec mi jeszcze dziala

https://www.dailymail.co.uk/sciencetech/article-8184
405/Boeing-787s-turned-51-days-prevent-potentially-c
atastrophic-failure.html
"Boeing 787s need to be turned off and on again every 51 days to
prevent 'potentially catastrophic failure' "

Bo tam w srodku jest procesor z 1996 :-)



J.

do góry

On 29/04/2021 17:21, J.F wrote:
>> Nie brodacze od 8051 którym 40 lat przeleciało za oknem. Wbrew pozorom w
>> lotnictwie poziom pewności co czym i jak developujesz/testujesz wynika z
>> procedur. Nie ze średniowiecznych poglądów Henia, co zatrzymał się w
>> NortonCommanderze i Keilu. Te procedury, to często coś podlegające audytom.
> No i kto jest pryszczatym nastolatkiem - programisci, czy audytorzy?
> :-)

Nikt, oni wszyscy mają garnitury i krawaty, więc są profesjonalni.
Natomaist wszyscy uzywają w jakimś stopniu oprogramowania pisanego przez
pryszczatych nastolatków.

> A potem mozna przeczytac taki tytul
> https://antyweb.pl/dwa-16-bitowe-komputery-z-1996-ma
ja-naprawic-konstrukcyjne-bledy-boeinga-737-max-nie-
wiem-jak-wy-ale-ja-do-takiego-samoloty-nie-wsiade/

To może być arument przeciwny archaicznym metodom dev jak i pokazujące
co przesadna nowoczesność może popsuć.

> Hm, moze i audytorzy sa pryszczatymi nastolatkami, skoro
> https://www.komputerswiat.pl/aktualnosci/nauka-i-tec
hnika/boeing-737-max-z-nowymi-bledami-w-oprogramowan
iu-moze-prowadzic-do-utraty-kontroli/xsyt9km

Audytorzy nie ogarniają dużego kodu, będą się skupiać na metodyce pracy
a nie na tym że przeżytnik ma niepodpięty reset. Kod nie jest pokryty
testami w 100%, a jeśli nawet jest w znacznej częsci pokryty, to nie
wiadomo kto testuje te testy itd... Budowanie zauwania kończącego się
pieczątką jest skomplikowane i nie zawsze zgodne w tym co nam się wydaje
o kontroli jakości.

Ogólnie pisanie dużego oprogramowania robi się korzystajac z różnych
technik zwiększania jakosci. Ale przypadku EDA i HDL jest odwrotnie:
duże firmy zatrzymały się na etapie kopiowania plików na dyskietkę.

Może zobrazuje to w taki sposób: znaczna część dostępnych symulatorów
korzysta z czegoś co nazywa się "systemem biblitecznym".

Działa to tak że jakiś kod w HDL jest "kompilowany" i umieszczany w
"bibliotece" i już można z niego korzystać.

Po kilku iteracjach możesz zauwazyć, że nikt nie kontroluje co w
biblitece się znajduje, w szczególnosci mogą znajdować się tam
skompilowane kawałki z plików źrodłowych które już nie istnieją lub
zmieniły zawartość, napisane kawałki o tych samych nazwach, framgmenty
od inncyh userów których możemy nie chcieć.

Dlaczego tak jest? Pewnie dlatego, że kilku brodatych Heńków lat temu 30
nie zuważyło, że istnieje make. I wymyślili kwadratrowe koło. Rozlazło
się to po producentach symulatorów i obecnie jest standardem
przemysłowym. Generującym niebotyczne ilości workaroundów. I Twój
samolot też lata weryfikowany na tym g...

Nikt w EDA nie chce make. I zaznaczam: nie mają śladu argumentu. A
wlaściwie mają: nie da się zrobić w obecnym systemie biblitecznym.

> Bo tam w srodku jest procesor z 1996 :-)

A ja zaryzykuje nastepujące: wolałbym wsiąść w samolot z lat 90 niż w
cokowliek nowoczesnego, z powodu overengineering. Dotyczy to
wszystkiego, od elektroniki do machaniki. Ale najbardzoej elektroniki co
do której proces devu znam i czasami trzęsą mi się kolana na myśl ilu
Heńków majstrowało przy samolocie w którym siedzę i jak skrajnie
popsutych narzędzi, ale certyfikowanych, używali, jak wygląda proces dev
przeciętnej firmy w EDA i dlaczego uże układy, które sterują tym
samolotem, weryfikuje się randomizacją a nie formalnie...

do góry

On 29/04/2021 21:23, heby wrote:
> przeżytnik

rzutnik ;) Widać weekend blisko i destylaty w myśli.

do góry

On Thu, 29 Apr 2021 21:23:23 +0200, heby <h...@p...onet.pl> wrote:
> A ja zaryzykuje nastepujące: wolałbym wsiąść w samolot z lat 90 niż
> w
> cokowliek nowoczesnego, z powodu overengineering.

Zdajesz sobie sprawę, że jeśli to nie jest tylko Twoja subiektywna
ocena to za jakiś czas powiedzenie przypisywane Einsteinowi o kijach
i kamieniach w 3 Wojnie Światowej jest całkiem realną wizją i to
niekoniecznie jakiegoś konfliktu zbrojnego ale przyszłych narzędzi
życia codziennego?

--
Marek

do góry