On Fri, 30 Apr 2021 11:24:05 +0200, heby wrote:
> On 30/04/2021 11:06, J.F wrote:
>>> Mamy całkiem sensowne procesory współczesne do cieżkich zadań, których
>> Ale czy sa odporne na szeroki zakres temperatur, na promieniowanie
>> kosmiczne itp?
> Tak.
>
>> I czy mozna w jakis sposob zbadac, czy nie maja bledow ?
> Tak.

Hm ...

>>> programowanie jest "normalne" i nie ma problemu ze znalezieniem
>>> programistów.
>> Ale tu pewnie tez jest normalne - w C. Ewentualnie w Ada.
>> Plus system operacyjny i biblioteki, a te i tak specyficzne.
>
> Na 8051 nie ma "C". jest jakaś proteza ogarniająca dziwaczne tryby
> adresowania i udajaca że z C ma coś wspólnego podobną składnią. Skrajnie
> utrudnia to testowanie kodu i praktycznie przekreśla przenośność.

OK, ale w Boeingu jest jakis lepszy procesor, to moze i C jest
normalne.

A moze tez harwardzki, i kod z 51 sie przydaje :-)

>>> Do 8051 cieżko znaleźc programistę który ogarnie go i jednoczesnie ma
>>> pojęcie o jakości, procedurach, współczesnych technikach pisania z
>>> naciskiem na jakość. To są biegunowo odległe grupy.
>> 8051 ma 8KB pamieci programu, no - 64 czasem, to jeden programista
>> ogarnia :-)
>
> Jak by taka zależności RAM<->ogarnianie była prawdziwa...

Latwiej zapanowac nad malym programem.

>>> Taka uwaga: nie abym tak uważał, ale mam wrażenie że na stare lata będę
>>> tak uważał: to nie programiści decydują o jakości, tylko procedury i
>>> testowanie.
>> IMO - programisci tez.
>> Ale czy zatrudniasz programistow w roznym wieku, czy starsi jakos tam
>> dbaja o "ład korporacyjny" w pisaniu programow, uczą mlodszych jak to
>> sie robi, czy zatrudniasz z doskoku i to najtanszych ...
>
> Na końcu jest kontrola jakości. Jesli jest zrobiona na odpiernicz się
> albo wcale, to programiści mają wypływ na jakość.

Owszem, ale potem przychodzi deadline, kontrola mowi "tego nie mozemy
wypuscic" a szef mowi "musimy" :-)

Poza tym jak programista sie skupi na kontroli, to moze tak napisac
program, ze testy przejdzie ...


>>> Odwrotnie, współczesne pokolenie zna doskonale. Nawet jeśli nie make, to
>>> koncepcje za nim stojące. Korzysta z tego bardzo dużo języków. Tylko że
>>> to mowa o programistach. W EDA też jest programowanie, ale robione przez
>>> elektroników. I tutaj jest podstawowy problem. Elektronicy od rysowania
>>> bramek nagle muszą ogarniać problemy typowego programisty. I ogarniają
>>> na swój sposób.
>> Hm. Make owszem, sie przydaje, ale wymaga narzedzi "command line".
>
> Ciekawostka: przykładowo syntezer Xilinxa nie obsługuje command line.
> Trzeba mu dostarczyć plik który interpretuje. Na dzień dobry wybija to
> zęby pisząc makefile.

IMO - i tak jest niezle, ze przewiduje taki plik,

>> Aczkolwiek niedawno widzialem ladne oprogramowanie, mozna sobie
>> narysowac maszyne w CAD, podlaczyc wirtualne PLC, zaprogramowac to
>> PLC, i zobaczyc jak bedzie dzialalo.
>> Tylko cos mi sie widzi, ze make tam nie ma :-)
>
> Bo make nie służy do robienia prototypów. Przypuszczalnie Photoshp też
> nie ma wsparcia dla make.

A potem masz zadanie "redakcja nie chce png tylko jpg. Jak przerobic
setke zdjec z png na jpg" :-)

J.