Sebastian Biały pisze:


> _Tylko_ przerwanie paru lat. Skoro taniej można zrobić N razy szybszego
> RISCa to po co się męczyć z '51?

Pic polega na tym, że projekt rdzenia 51 można kupić za psie pieniądze
albo znaleźć nawet darmowy. Do tego masz za darmo mnóstwo dokumentacji,
assemblerów, komercyjne kompilatory i doświadczonych ludzi. Więc po co
producent SoCów miałby się pchać w jakiegoś nikomu nieznanego RISCa albo
płacić za licencję np. ARMowi jeśli rdzeń 51 jest w danym zastosowaniu
wystarczający?

do góry

Zbych wrote:
> Pic polega na tym, że projekt rdzenia 51 można kupić za psie pieniądze
> albo znaleźć nawet darmowy.

http://www.opencores.org/projects.cgi/web/avr_core/o
verview/

nie tylko '51 jest implementowalny w sprzecie.

> Do tego masz za darmo mnóstwo dokumentacji,

Zupelnie jak u innych.

> assemblerów

To trywialne i nie dziwi.

>, komercyjne kompilatory

Jakis z nich obsługuje cos poza C ?

> i doświadczonych ludzi.

Niedługo odchodzących na emeryturę.

> Więc po co
> producent SoCów miałby się pchać w jakiegoś nikomu nieznanego RISCa

Obawiam się że AVR na ten przykład jest troche juz znany.

> albo
> płacić za licencję np. ARMowi jeśli rdzeń 51 jest w danym zastosowaniu
> wystarczający?

Po co brać mercedesa skoro 126p jest w tej samej cenie? Co prawda ktos
mógłby zauważyć że proces developingu na cpu którego projektowano pod
kątem współczesnych kompilatorów może być szybszy, ale kto by się
przejmował szczegółami skoro mamy w zespole samych miszczuf znających
tylko '51 i piszących kod wprost w hex.

do góry

Zbych pisze:
> Sebastian Biały pisze:
>
>
>> _Tylko_ przerwanie paru lat. Skoro taniej można zrobić N razy
>> szybszego RISCa to po co się męczyć z '51?
>
> Pic polega na tym, że projekt rdzenia 51 można kupić za psie pieniądze
> albo znaleźć nawet darmowy. Do tego masz za darmo mnóstwo dokumentacji,
> assemblerów, komercyjne kompilatory i doświadczonych ludzi. Więc po co
> producent SoCów miałby się pchać w jakiegoś nikomu nieznanego RISCa albo
> płacić za licencję np. ARMowi jeśli rdzeń 51 jest w danym zastosowaniu
> wystarczający?

E tam. Atmel kupi jakąś firmę od SoCów i będziesz miał SoCe z rdzeniem
RISCowym. Zresztą robi SOCe ale na razie zdaje się bez analogówki.


--
Pozdrawiam
MD

do góry

Sebastian Biały pisze:

>> , komercyjne kompilatory
>
> Jakis z nich obsługuje cos poza C ?

A po co? To że ty nie potrafisz obyć się bez c++ to nie znaczy, że nie
znajdą się ludzie, którzy to potrafią.

>> i doświadczonych ludzi.
>
> Niedługo odchodzących na emeryturę.

Spokojnie, moje pokolenie też zaczynało od 51 (bo była to najłatwiej
osiągalna architektura na początku lat 90) a do emerytury zostało mi
jakieś 30..40 lat.

>
>> Więc po co producent SoCów miałby się pchać w jakiegoś nikomu
>> nieznanego RISCa
>
> Obawiam się że AVR na ten przykład jest troche juz znany.

I oczywiście można kupić licencję na jego rdzeń?

> Po co brać mercedesa skoro 126p jest w tej samej cenie?

Zapominasz o takim szczególe jak powierzchnia zajętego krzemu.

do góry

Zbych wrote:
> A po co? To że ty nie potrafisz obyć się bez c++ to nie znaczy, że nie
> znajdą się ludzie, którzy to potrafią.

Ależ oczywiście. Szkoda że jedynym merytorycznym powodem będzie brak
kompilatora C++. Ale rozumiem - zawsze lepiej mieć w razie czego jakis
inny powód typu "my potrafimy bez C++".

>> Obawiam się że AVR na ten przykład jest troche juz znany.
> I oczywiście można kupić licencję na jego rdzeń?

Po co. Autor wątku nie będzie go implementował w SoC. Ale gdyby chciał
bedzie mógł - prawdopodobnie ten sam kompilator będzie używalny na innym
rdzeniu i przy przemyślanej abstrakcji sprzętu kod będzie używalny. Jak
weźmie '51 to wkopie się w bagno jedynych-w-swoim-rodzaju kompilatorów w
dodatku czesto z feature: płać-i-płacz.

>> Po co brać mercedesa skoro 126p jest w tej samej cenie?
> Zapominasz o takim szczególe jak powierzchnia zajętego krzemu.

Krzem jest _tani_. A wybór czegos innego niż '51 moze miec uzasadnienie
ekonomiczne w dłuższej perspektywie.

Sugerowałbym zamknąc tematykę SoC - nie ma nic wspolnego z watkiem.

do góry

Sebastian Biały pisze:
> Zbych wrote:
>> A po co? To że ty nie potrafisz obyć się bez c++ to nie znaczy, że nie
>> znajdą się ludzie, którzy to potrafią.
>
> Ależ oczywiście. Szkoda że jedynym merytorycznym powodem będzie brak
> kompilatora C++. Ale rozumiem - zawsze lepiej mieć w razie czego jakis
> inny powód typu "my potrafimy bez C++".
>
>>> Obawiam się że AVR na ten przykład jest troche juz znany.
>> I oczywiście można kupić licencję na jego rdzeń?
>
> Po co. Autor wątku nie będzie go implementował w SoC. Ale gdyby chciał
> bedzie mógł - prawdopodobnie ten sam kompilator będzie używalny na innym
> rdzeniu i przy przemyślanej abstrakcji sprzętu kod będzie używalny. Jak
> weźmie '51 to wkopie się w bagno jedynych-w-swoim-rodzaju kompilatorów w
> dodatku czesto z feature: płać-i-płacz.

Popieram. Przecież on zaczyna hobbystycznie i potrzebuje czegoś
popularnego a nie niszowego, po to żeby łatwiej uzyskać pomoc lub
przykłady w necie. Jeśli będzie się tym na poważnie zajmował zawodowo to
wtedy potrzebne jest profesjonalne podejście. Jest możliwość dobrze
zrobić na 51, PICach czy MSP to siada i się przyucza do nowej platformy.

--
Pozdrawiam
MD

do góry

Sebastian Biały pisze:

> Ależ oczywiście. Szkoda że jedynym merytorycznym powodem będzie brak
> kompilatora C++. Ale rozumiem - zawsze lepiej mieć w razie czego jakis
> inny powód typu "my potrafimy bez C++".

No cóż, moim zdaniem jest to lepszy argument niż "bez c++ nie da się".

> Krzem jest _tani_.

Czyli dążenie do zmniejszania powierzchni układu to tylko sport?

> Sugerowałbym zamknąc tematykę SoC - nie ma nic wspolnego z watkiem.

Bezpośrednio nie ma. Ale tłumaczy czemu wciąż się pojawiają nowe uC z
rdzeniem 51 i wcześniej czy później można się o nie "otrzeć"

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:gp08ni$o99$1@achot.icm.edu.pl...
> Ghost wrote:
>> naprawde wystarczy tylko zauwazyc, ze jednak sporo software'u bankowego
>> leci na COBOLU
>
> Nie myl skali. COBOLowe aplikacje bankowe są powiązane ze sobą i ich
> wymiana nie jest opłacalna ekonomicznie.

Nie chodzi o zadne powiazania.

> Startując nowe projekty siedzisz w samym środku bagna i wyboru nie masz.

Alez masz wybor i robisz je w nowym srodkowisku o ile projekt nie dotyczy
samej zmiany funkcjoinalnosci tego co w COBOLu. Caly klopot w tym, ze to co
juz jest musi byc pielegnowane.

>> stopniowo bedzie 51 marginalizowany i ze powstanie nisza dla slabszych
>> programistow w tym wlasnie miejscu, skoro nikt nie bedzie chcial sie nim
>> zajmowac, konkurencja bedzie mniejsza.
>
> Obyś się nie przeliczył - koszt wymiany software na '51 jest porównywalny
> z długością kodu. Może sie okazać ze ta nisza dla '51 zniknie bardzo
> prędko bo taniej jest zatrudnić 2 programistów na 4 miesiące niż klepać z
> dziada pradziada legacy hardware i patrzeć jak konkurencja znika za
> horyzontem licząc straty.

Demonizujesz 51. Piszac w C wcale nie bedziesz az tak bardzo w plecy z
kosztem realizacji o ile w ogole. Z drugiej strony taki Visual Basic, nie
jest szczytem osiagniec inzynierii programowania, a skutkiem m.in. polityki
Microsoftu zdobyl niezla czesc rynku, teraz MS sie wypial i lansuje C#.
Gdyby najlepsze rozwiazania techniczne zawsze wygrywaly na rynku, zyli bysmy
w innym swiecie.

do góry

Zbych wrote:
> No cóż, moim zdaniem jest to lepszy argument niż "bez c++ nie da się".

Argumenty za C++ przedstawialem niedawno na pl.comp.lang.c.
kontrargumentacji merytorycznej nie było. Ale tu nie chodzi o C++.
Kompilatory na uC mają masę dodatkowych features które może i pomagają
pisać kod specyficzny dla platformy ale jednoczesnie uniemożliwiaja
zrobienie abstrakcji na rdzeń. Pewnego dnia padnie decyzja o zmianie
rdzenia (merytoryczna) i masz cały soft lądujący w smietniku bo
super-jedyny kompilator innej firmy ma inne poglądy na temat standardu C
niz nowy. A jeżeli agumentujesz to SoC to tym bardziej - Soc nie sluzy
do migania diodami i wdepniecie w niestandardowy kompilator może byc
niebezpieczne. O ile mi wiadomo do '51 sa same magiczne kompilatory C.

>> Krzem jest _tani_.
> Czyli dążenie do zmniejszania powierzchni układu to tylko sport?

Tylko pod warunkiem że jedynym elementem SoC jest rdzeń cpu (czyli żaden
SoC). Jak nie, to zapewne jego rozmiar przestaje byc istotny w obliczu
masy innych elementow systemu.

> Bezpośrednio nie ma. Ale tłumaczy czemu wciąż się pojawiają nowe uC z
> rdzeniem 51 i wcześniej czy później można się o nie "otrzeć"

Jak mówiłem: stada Panow Kaziow produkujących centralki alarmowe beda je
kupowac jeszcze przez 10 lat bo im się nie opłaca pisać na nowo
software. Firma robiąca coś od zera wybierze '51 tylko dlatego ze ma
stado developerów o wąskich horyzontach myślowych dłubiących 20 lat w
asm tego cuda. Cała reszta zaswieci swieczkę ku pamieci '51.

do góry

Zbych pisze:
> Sebastian Biały pisze:
>
>> Ależ oczywiście. Szkoda że jedynym merytorycznym powodem będzie brak
>> kompilatora C++. Ale rozumiem - zawsze lepiej mieć w razie czego jakis
>> inny powód typu "my potrafimy bez C++".
>
> No cóż, moim zdaniem jest to lepszy argument niż "bez c++ nie da się".
>
>> Krzem jest _tani_.
>
> Czyli dążenie do zmniejszania powierzchni układu to tylko sport?

Dążenie do zmniejszenia powierzchni jest działaniem producenta w celu
obniżenia jednostkowych kosztów produkcji. Nie jest to żaden argument
dla klienta/dewelopera. Jego interesuje cena tego układu. Nie wiem na
ile mała powierzchnia i darmowe core przekłada się na niską cenę układu.
Zresztą co to za różnica w powierzchni core. Core 51 możesz porównać do
2313. A reszta powierzchni to porty no i inne peryferia w przypadku SoC.
W sumie przy SoC korzyść jest z rezygnacji z kilku obudów i ich
późniejszego montażu a nie ze zmniejszania powierzchni krzemu.


--
Pozdrawiam
MD

do góry