Janko Muzykant wrote:
> Ja np. wciąż siedzę w 51, bo to proste w miarę, do ogarnięcia w
> całości i piszę sobie tylko w asemblerze.

Problem w tym, ze '51 nie ma _żadnych_ zalet z czymkolwiek współczesnym
poza stertą legacy code ktorego powtórne użycie i tak nie ma sensu bo
jest pisany w większości w asm przez wymiataczy znających na pamięc
adresy rejestrów. Oby autor watku nie musiał kiedykolwiek parać się
archeologią elektroniczną jaką jest '51.

PS. AVRy są znacznie prostsze do ogarniecia niz '51. Ktoś na trzeźwo
wymyślał asm.

do góry

Sebastian Biały pisze:
>> Ja np. wciąż siedzę w 51, bo to proste w miarę, do ogarnięcia w
>> całości i piszę sobie tylko w asemblerze.
>
> Problem w tym, ze '51 nie ma _żadnych_ zalet z czymkolwiek współczesnym
> poza stertą legacy code ktorego powtórne użycie i tak nie ma sensu bo
> jest pisany w większości w asm przez wymiataczy znających na pamięc
> adresy rejestrów.

No to właśnie ja :)
Nie namawiam, mówię jak jest. Działają budziki, sterowniki midi, jakaś
prosta automatyka przemysłowa, po co chcieć więcej... od więcej mam
palmy i małe notebooki.

--
pozdrawia Adam
różne takie tam: www.smialek.prv.pl
/dojrzałość następuje z chwilą, gdy kończy się chemia, a zaczyna fizyka/

do góry

Janko Muzykant wrote:
> Nie namawiam, mówię jak jest. Działają budziki, sterowniki midi, jakaś
> prosta automatyka przemysłowa, po co chcieć więcej...

Czasami trzeba mieć utrzymywalny i rozwijalny kod - asm do tego nijak
nie pasuje. Sensowne zużycie mocy, wiekszą predkość, perspektywe zakupu
za $1 za 5 lat, małe rozmiary, programowanie małą ilościa kabli,
hardware do robienia ciekawych rzeczy itd. Niebezpieczne jest nawet
wspominanie o '51 w kontekście czego by się tu nauczyć. Ten procesor
odejdzie wraz z ostatnim programistą, a to niedaleka przyszłość.

> od więcej mam
> palmy i małe notebooki.

Zniknąłes prawie cały rynek normalnych uC.

do góry

Sebastian Biały pisze:
>> Nie namawiam, mówię jak jest. Działają budziki, sterowniki midi, jakaś
>> prosta automatyka przemysłowa, po co chcieć więcej...
>
> Czasami trzeba mieć utrzymywalny i rozwijalny kod - asm do tego nijak
> nie pasuje. Sensowne zużycie mocy, wiekszą predkość, perspektywe zakupu
> za $1 za 5 lat, małe rozmiary, programowanie małą ilościa kabli,
> hardware do robienia ciekawych rzeczy itd. Niebezpieczne jest nawet
> wspominanie o '51 w kontekście czego by się tu nauczyć. Ten procesor
> odejdzie wraz z ostatnim programistą, a to niedaleka przyszłość.

Pewnie tak, ale
1) Ja z tego żyję tak na... na waciki mam,
2) Będziemy emulować :)

>> od więcej mam palmy i małe notebooki.
> Zniknąłes prawie cały rynek normalnych uC.

Czasem taniej kupić i oprogramować gotowca. W ogóle czasy romantyczne w
uC się skończyły, a ja jestem stary romantyk :)

--
pozdrawia Adam
różne takie tam: www.smialek.prv.pl
/autorytet? - no, nie wiem, zupełnie nic mi do głowy nie przychodzi.../

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:gouotk$8md$1@achot.icm.edu.pl...
> Janko Muzykant wrote:
>> Nie namawiam, mówię jak jest. Działają budziki, sterowniki midi, jakaś
>> prosta automatyka przemysłowa, po co chcieć więcej...
>
> Czasami trzeba mieć utrzymywalny i rozwijalny kod - asm do tego nijak nie
> pasuje. Sensowne zużycie mocy, wiekszą predkość, perspektywe zakupu za $1
> za 5 lat, małe rozmiary, programowanie małą ilościa kabli, hardware do
> robienia ciekawych rzeczy itd. Niebezpieczne jest nawet wspominanie o '51
> w kontekście czego by się tu nauczyć. Ten procesor odejdzie wraz z
> ostatnim programistą, a to niedaleka przyszłość.

Oj chyba jeszcze troche to potrwa.

do góry

Ghost wrote:
>> nawet wspominanie o '51 w kontekście czego by się tu nauczyć. Ten
>> procesor odejdzie wraz z ostatnim programistą, a to niedaleka przyszłość.
> Oj chyba jeszcze troche to potrwa.

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.

do góry

>>> AVR-ami. Można przejrzeć listy błędów gcc z lat 2003-2005 aby się o
>>> tym przekonać.
>>
>>
>> Wiesz, gcc jednak wyznacza pewien standard. Zauwaz: gcc, _nie_ avr-gcc.
>
> Ostatnio co używałem to WinAVR 20030913 z GCC 3.3.1, wystarczy. Chociaż
> MOŻE się polepszyło.

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.

do góry

> wyjasnie: kupilem kompilator IAR do jednego z prockow Toshiby...
> ....powychodzily rozne kwiatki (pamietam juz tylko jeden: program byl zle
> _skompilowany_ jesli pewne instrukcje w plikach .obj wychodzily na
> nieparzystym adresie - kurwicy mozna bylo dostac wstawianiem nop() w
> prawie kazdej funkcji).

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

> Aha - jak _mocno_ poszukam to powinienem znalezc email w ktorym jest
> napisane ze IAR 'nie jest zainteresowany' poprawieniem bledow.

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


zbyszek

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:gouufp$gcl$1@achot.icm.edu.pl...
> Ghost wrote:
>>> nawet wspominanie o '51 w kontekście czego by się tu nauczyć. Ten
>>> procesor odejdzie wraz z ostatnim programistą, a to niedaleka
>>> przyszłość.
>> Oj chyba jeszcze troche to potrwa.
>
> 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.

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.

do góry

Ghost wrote:
> Po pierwsze spora ilosc firm musi sie opiekowac oprogramowani, ktore
> kiedys wyposcilo, co bedzie robilo nacisk na nauke kolejnych ludzi 51.

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.

> Po drugie stale sie produkuje coraz lepsze procesory w tej technologii,
> raczej nie zwiastuje to jego upadku.

_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.

> 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. 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?

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

do góry