Mikrokontrolery ATMEL dla początkujących: Książki, zestawy i zasoby do automatyki domowej

Sun Mar 08, 2009 12:03 am   

Ghost wrote:

Wręcz przeciwnie, młode pokolenie programistow uC mając do wyboru
wypasionego avr/pic/arm i żenade w postaci 30-letniej koncepcji mającej
za kolegów Z80 czy 8048 ma dość jasny wybór. Reanimacja 51 w postaci
dosztukowywania mu nowych features zawsze rozbije sie o brak sensownego
asm który utrudnia pisanie programów w językach wyższego poziomu. Po
prostu pewne pokolenie musi odejść a widząc młodych inzynierów
wychodzących z uczelni myśle że to juz się dzieje.

Sun Mar 08, 2009 12:42 am   

Wiesz, wypowiadanie sie w 2009 roku na temat wersji kompilatora sprzed 6
lat to lekka przesada.
Kompilatory komercyjne na AVR maja pewne przewagi - generuja krotszy kod
i maja wygodniejsze i wiecej dodatkowych bibliotek. Niemniej avr-gcc
jest ciekawa i niezla alternatywa. Z zalet to przenosnosc kodu, czego
komercyjne kompilatory nie oferuja i jak chcesz przekompilowac fragment
na ARMa czy PC to masz problem. Polem na ktorym gcc bije inne jest
kompilator c++, ktorego komercyjne po prostu nie oferuja wcale.

Sun Mar 08, 2009 1:13 am   

A ja kupiłem "profesjonalny" kompilator C IAR do procków 51 chyba w 1999
roku (albo rok wcześniej). Błedów było sporo, pamiętam że czasem polecenia
if
źle się kompilowały i coś innnego robiły niz powinny, a kiedy do funkcji
przekazało
się jakiś element struktury to niekoniecznie on był brany pod uwagę w
obiliczeniach :)

Szczytem wszystkiego było to ze w 2000 roku kompilator wylatywał za każdym
razem - nie dało się nic skompilować!!!...a wspaniała IAR wspaniałomyślnie
zaproponowała mi upgrade do kolejnej wersji za 50% ceny zwykłej licencji.

Aby skompilować musiałem za każdym razem cofać zegar w PC, a następnie
pamiętać aby go znów ustawić bo moje emaile "stawały" się dla klientów
trochę zbyt "archiwalne".

I tak z tym zegarkiem ciągnęło się aż kiedyś zapomniałem go przestawić a tu
IAR i tak działa !!!
- działał bo był już rok 2001 - przypadek? - ja w to nie wierzę.

Oszukiwał też na poprawie optymalizacji zajętości kodu, jedną wersję
poprawiał a
w następnej znów pogarzszał optymalizację by znów w kolejnej móc ją
poprawić -
ale ja to już tylko dla ciekawości miałem okazję sprawdzać bo więcej IAR dla
mnie nie istnieje.....


a co miałby poprawiać skoro nie ma blędów w jego kodzie :)


zbyszek

Sun Mar 08, 2009 11:50 am   

Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:gouufp$gcl$1@achot.icm.edu.pl...

Po pierwsze spora ilosc firm musi sie opiekowac oprogramowani, ktore kiedys
wyposcilo, co bedzie robilo nacisk na nauke kolejnych ludzi 51. Po drugie
stale sie produkuje coraz lepsze procesory w tej technologii, raczej nie
zwiastuje to jego upadku. Dlugo moznaby pisac. Ale tak naprawde wystarczy
tylko zauwazyc, ze jednak sporo software'u bankowego leci na COBOLU, mimo,
ze juz malo kto sie go chce uczyc - ktos sie tym jednak zajmuje. Mozna
liczyc, ze 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.

Sun Mar 08, 2009 12:04 pm   

Ghost wrote:

Opiekowanie się starym softem jest wyjatkowo nudnym zajęciem. Oczywiście
jesli płacą to ok, ale praca nie rozwija. W '51 nowych projektów się nie
będzie robić (statystycznie). Brak uzasadnienia merytorycznego i
ekonomicznego.


_Tylko_ przerwanie paru lat. Skoro taniej można zrobić N razy szybszego
RISCa to po co się męczyć z '51? Tylko po to żeby Pan Kaziu produkujacy
centralki na pilota nie musiał się przemęczać tylko klepal dalej to samo
od 10 lat. Nowa technologia nic mu nie pomoże, on potrzebuje 8051 +
EEPROM. Nowy zamiast tego weźmie ARM w tej samej cenie i napisze soft 10
szybciej. Rynek uC nie wymaga kompatybilnosci wstecznej bo aplikacje sa
na tyle małe ze można je pisac od 0 w większości przypadków.


Nie myl skali. COBOLowe aplikacje bankowe są powiązane ze sobą i ich
wymiana nie jest opłacalna ekonomicznie. Startując nowe projekty
siedzisz w samym środku bagna i wyboru nie masz. W uC zazwyczaj nie ma
żadnych powiązań wiec nowy projekt da się wystartowac w czymkolwiek -
czemu więc nie w czymś znacznie lepszym niż techonologia średniowieczna?


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.

Sun Mar 08, 2009 12:28 pm   

Sebastian Biały pisze:



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?

Sun Mar 08, 2009 12:36 pm   

Zbych wrote:

http://www.opencores.org/projects.cgi/web/avr_core/overview/

nie tylko '51 jest implementowalny w sprzecie.


Zupelnie jak u innych.


To trywialne i nie dziwi.


Jakis z nich obsługuje cos poza C ?


Niedługo odchodzących na emeryturę.


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


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.

Sun Mar 08, 2009 12:40 pm   

Zbych pisze:

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

Sun Mar 08, 2009 12:47 pm   

Sebastian Biały pisze:


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


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.


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


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

Sun Mar 08, 2009 1:09 pm   

Zbych wrote:

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++".


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.


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.

Sun Mar 08, 2009 1:18 pm   

Sebastian Biały pisze:

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

Sun Mar 08, 2009 1:18 pm   

Sebastian Biały pisze:


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


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


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ć"

Sun Mar 08, 2009 1:20 pm   

Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:gp08ni$o99$1@achot.icm.edu.pl...

Nie chodzi o zadne powiazania.


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.


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.

Sun Mar 08, 2009 1:28 pm   

Zbych wrote:

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.


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.


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.

Sun Mar 08, 2009 1:35 pm   

Zbych pisze:

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