Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Programowanie AVR w języku JAVA

Jakoob80 27 Gru 2008 22:25 11496 40
  • #1 27 Gru 2008 22:25
    Jakoob80
    Poziom 11  

    Czy język JAVA nadaje się do zaprogramowania
    mikro kontrolerów.

    Pisałem w Turbo Pasacalu i Cliperze. Obecnie zajmuje się JAVA.
    Znam trochę C ++ jednak przeczytałem ze w odpowiednio dobranym procesorze można wykorzystać programiki JAVA.
    Dla mnie było by to dużo wygodniejsze.
    Obecnie jestem na etapie wyboru Płyty AVR.

    Jakie procesory wybrać dla Java ?? Rodzina -niekoniecznie che przepłacać ale to przede wszystkim edukacja.

    0 29
  • #3 27 Gru 2008 23:09
    Balu
    Poziom 38  

    Kolega nei podsyła linków tylko krzyczy od razu...
    Nie, nie ma sensu programować uC w JAVIE!

    C, asm, basic, ew C++ ale na boga JAVA!?

    Może jeszcze we flashu?

    0
  • #4 27 Gru 2008 23:33
    MarasK
    Poziom 18  

    no raczej, ze procesory programuje się we Flashu.. bo przecież nie w ramie :D

    (odnośnie gier słownych dotyczących sporu 6 czy 7 linii do LCD :))

    0
  • #5 27 Gru 2008 23:38
    Balu
    Poziom 38  

    Jak już gramy w słówka;)
    Kolega poczyta o ARMach i wypluje co napisał;)
    L.

    0
  • #6 28 Gru 2008 00:15
    Freddie Chopin
    Specjalista - Mikrokontrolery

    rdzenie ARM zawierajace jednostke Jazelle maja wewnetrzny interpreter JAVY. nie chcesz przeplacac, wiec powodzenia w szukaniu takowego dostepnego w detalu [;

    4\/3!!

    0
  • #7 28 Gru 2008 00:46
    BoskiDialer
    Poziom 34  

    MarasK: Pod stwierdzeniem "flash" kryją się dwa znaczenia: pamięć nieulotna elektrycznie kasowana, oraz takie coś, co znamy z tego, że wyświetla animowane reklamy na stronach. Jak Balu pisze(pośrednio), program nie musi być we flashu, może być w pamięci ram (lub czymkolwiek, co jest dostępne do odczytu z poziomu procesora i jest widoczne w przestrzeni adresowej - arm i inne platformy temu podobne w architekturze von Neumanna). Pamięć flash jest tylko nośnikiem dostarczającym dane, to że w avr'ach jest to jedyne źródło dostarczające instrukcje (architektura harwardzka) nie oznacza, że w innych procesorach jest tak samo. Co do języków interpretowanych jak java, nie jest to skrajnie głupi pomysł - jeśli mamy duży procesor z podłączoną zewnętrzną pamięcią ram, możemy chcieć dać możliwość załączania zewnętrznych programów bez zapisywania do pamięci flash lub chcemy ograniczyć dostęp do sprzętu, to owszem język taki ma sens. Sensu nie ma, kiedy chcemy go traktować jako język, w którym piszemy właściwy kod - kod bajtowy musiał by zostać przekompilowany do kodu maszynowego lub musiał by być wgrany interpreter, co w przypadku niektórych procesorów mija się z celem.

    0
  • #8 28 Gru 2008 11:32
    MarasK
    Poziom 18  

    Balu, BoskiDialer - wiem, że ARMy pozwalają na pracę zarówno z flasha jak i z RAMu. Moja wypowiedź odnosiła się to tego tematu (Programowanie AVR w języku JAVA) :)

    żeby nie było offtopu - popieram przedmówców i stanowczo odradzam programowanie w Javie na uC

    0
  • #9 28 Gru 2008 16:16
    atom1477
    Poziom 43  

    Ja mam swoją teorię na temat języków programowania.
    Języki takie jak BASIC czy JAVA wcale nie muszą być interpretowane.
    To że kiedyś ktoś wymyślił że akurat będą interpretowane i tylko interpretowane to żadna przeszkoda.
    Równie dobrze można by zrobić interpreter C.
    Tak samo można stworzyć normalny kompilator języka BASIC czy JAVA który będzie kompilował do kodu maszynowego. Oczywiście jeżeli jest jakaś definicja mówiąca że BASIC jest językiem interpretowanym, to przerobienie go na nieinterpretowany spowoduje że przestanie on być językiem BASIC. Więc moja teoria teoretycznie jest błędna. Ale to tylko zmiana nazwy. Nie będę się bawił w grę słów.
    Przecież w BASCOMie piszę się w BASICu a jakoś nie zauważyłem żeby do ATMEGi trafiaj interpreter tego języka.
    Tak samo zrobienie normalnego kompilatora do JAVA, tak żeby procesor nie musiał zawierać interpretera, jest możliwe i mogło by mieć sens. Mogło by, ale moim zdaniem nie ma. Języków jest już dostatecznie dużo i przystosowywanie kolejnego, w dodatku JAVA, to moim zdaniem przegięcie.
    Moim zdaniem powinieneś zapomnieć o tym i tyle.
    Ale oczywiście zrób jak uważasz.
    A tak na marginesie. Jakie Twoim zdaniem zalety miał by język JAVA przy programowaniu mikrokontrolerów?

    0
  • #10 28 Gru 2008 16:51
    BoskiDialer
    Poziom 34  

    atom1477: Twój tok myślenia jest oczywiście poprawny, wszak język służy tylko do zapisania programu, który potem podlega kompilacji, nie ważne czy kod jest uruchamiany na rzeczywistym procesorze, czy na wirtualnym/emulowanym, gdzie VM od javy można traktować jak procesor, tylko że emulowany. Może nawet być bezpośrednio interpretowany, składnia języka wymusza jednoznaczną interpretację kodu.

    Wady Javy dyskwalifikujące ją z zastosowań bezpośrednio na uC, to:
    - założenie dotyczące zarządzania pamięcią - algorytm odśmiecania pożerał by sporo czasu procesora, ciężko było by go wyeliminować z kodu wynikowego, nawet stosując liczniki referencji nie usuwało by to cykli (chyba, że o czymś nie wiem)
    - ograniczenie składni języka do takiego stopnia, aby kod mógł być niezależny od platformy, podczas gdy nam zależy na zależności od platformy.
    - brak wskaźników mógł by być uciążliwy, chociaż powinno się dać bez nich obejść kosztem większego skomplikowania programu w niektórych przypadkach.

    W ostateczności kod pewnie nie osiągnął by takiej wydajności, jak kod pisany w C, asm czy nawet w bascom.

    0
  • #11 28 Gru 2008 17:12
    atom1477
    Poziom 43  

    Zapytałem nie dlatego żeby pojechać autorowi, ale żeby się dowiedzieć. Bo ja absolutnie nie znam się na Javie.
    Ten algorytm „odśmiecania” zapewne nie był by problemem przy bezpośredniej kompilacji na kod maszynowy.
    Ale ograniczenie składni (a co dopiero brak wskaźnikowania (indexowania)) to już przegięcie.
    Na FLASu to już całkowicie się nie znam. Ale domyślam się że jego polecenia ograniczają się do „Odtwórz film”, „Start”, „Stop”.
    Coś takiego na AVR? Litości.
    A co do pogardzanego BASCOMA. Ja w nim odpaliłem koder Video na ATMEGA8 ;p No dobra. Kompiluję w BASCOMie, ale w zasadzie pisze a assemblerze.
    Może nie jest to założeniem mikrokontrolerów, ale tak zawsze było i zawsze będzie, że mikrokontrolery są „mikro” w stosunku do normalnych procesorów. Więc pisanie w zbyt wysokim poziomie na mikrokontrolery nie ma sensu.
    Nawet jak mikrokontrolery osiągną poziom dzisiejszych procesorów siedzących w komputerach, to wtedy procesory siedzące w komputerach także będą nowocześniejsze, więc język programowania mikrokontrolerów jaki wysokopoziomowy by nie był, zawsze powinien być niższy niż języki na komputery (Delphi, C++, C#).
    Mój przykład z koderem Video potwierdza że na mikrokontrolerach można zrobić fajne rzeczy, ale stosując przemyślane rozwiązania i optymalizację, a nie waląc gotowca w postaci niezwykle wysokopoziomowego języka.

    Dodano po 11 [minuty]:

    Acha. I jeszcze jedno. O ile możliwe jest skompilowanie JAVA do kodu maszynowego, to nie ma to sensu z jeszcze jednego poziomu.
    Języki interpretowalne powstały po to żeby je interpretować. Oczywiście czasami powstają kompilatory takich języków (BASCOM).
    Ale głównym celem takich języków jest to żeby urządzenie (procesor) je interpretowało, a nie wykonywało skompilowany kod maszynowy. Pozwala to na szybka zmianę kodu.
    Zatem programowanie w JAVA sposobem z kompilowaniem nie ma sensu, bo mamy przecież BASCOMa, C, assembler a może i inne bajery.
    Z kolei dodawanie interpretera na procesor ma pewien sens (gry w JAVA? (takie jak na komórki)), ale procesor nie wyrobi. Coś mi się zdaje że nawet ATMEGA256 miał by problemy z obsłużeniem tego. Z samym obsłużeniem, o działaniu w czasie rzeczywistym nie wspomnę!

    0
  • Pomocny post
    #12 28 Gru 2008 17:23
    BoskiDialer
    Poziom 34  

    atom1477 napisał:
    Ale ograniczenie składni (a co dopiero brak wskaźnikowania (indexowania)) to już przegięcie.
    Indeksowanie.. tablice owszem istnieją, ale jako obiekty. Wskaźniki są zastąpione referencjami. Nie ma możliwości dowolnego grzebania po pamięci, dzięki czemu wypada nam cała klasa algorytmów, jak zarządzanie pamięcią (java narzuca swój alokator o którym pisałem) i inne. Nie jest to język aż tak do końca interpretowany, pliki java są kompilowane do kodu bajtowego (.class). Z kompilatorów do kodu maszynowego znalazłem GCJ. Mimo to zastosowania czasu rzeczywistego odpadają.

    Stąd odpowiedź na temat: Java nie nadaje się do zaprogramowania mikrokontrolerów.

    0
  • #13 28 Gru 2008 20:22
    mirekk36
    Poziom 42  

    Jeśli mogę dodać swoje 3 grosze - to powiem, że jeśli ktoś wymyślił i napisał kompilator JAVA dla takich procków (ktoś podał link na początku tematu) to dlaczego mówić, że się nie nadaje? - wg mnie nadaje się bo jeśli autor będzie chciał zrobić sobie prosty układzik do migania diodą LED to zrobi to zapewne i w JAVIE.

    Autor poszukuje JAVY bo na PCtach programuje w Javie ;) .... niedługo inny ktoś tam będzie poszukiwał może nawet kompilatora HTML dla procków bo programuje tylko w HTML'u ;) ..... ja jakiś czas temu też poszukiwałem Pascala do mikrokontrolerów i po fascynacji gdy udało się zrobić miganie diodą LED a zaczęły się poważniejsze projekty to i tak skończyło się samoistnie na czym??? ... jezyk C do tego assembler - no czasem na szybciorka jeszcze sporadycznie Bascom.

    i tak samo skończy autor jak i inni, którzy na początku "na siłę" szukają podobnego środowiska programistycznego do tego które w jakimś tam stopniu znają z PC'ta a nie chce im się uczyć czegoś innego.

    czyli powrót do korzeni typu ASM + C albo C + ASM zwykle zawsze sam nastąpi. A jeśli nie to tylko dlatego, że znudziły się mikrokontrolerki albo potrzeby ograniczają się do programów typu migania diodą LED. Oczywiście nie chcę przesadzać i wcale nie twierdzę, że w takich językach jak Bascom, Pascal a może nawet JAVA nie da się czegoś większego zrobić - wszystko zależy od zacięcia oraz od ew bardzo drogiego kompilatora czy środowiska, które w wielu przypadkach wyręcza programistę z oprogramowywania wielu podstawowych modułów itp

    1
  • #14 28 Gru 2008 22:09
    Jakoob80
    Poziom 11  

    Dziekuje za Pomoc.
    Znalazłem w internecie kilka procesorów z interpretatorem JAVA.

    Rzeczywiście jak panowie podali mogą one ułatwiać działanie aplikacji np na Telefonach lub Palmtopach.

    Cuż w sprawie AVR nie pozostaje nic innego jak zaprzyjanić się bardziej z językiem C , C++.

    A dla cieawskich moje pytanie narodziło się z tąd ze spotkałem podobne niedokończone watki na Elektrodzie w zeszłym roku.
    A po drugie w jednym z podrecznikow Java [ nie JAVA SCRIPT - opisywany jest jako łatwy jezyk majacy w zamyśle zastapic C, C++ i ułatwiać miedzyinnymi programowanie obsługi paneli lodówek, pralek, etc]


    Jednak autor Ksiazki conieco przesłodził bo do kilku cyferek LCD uzywa się chyba prostszego kodu ;)

    0
  • #15 29 Gru 2008 10:21
    Freddie Chopin
    Specjalista - Mikrokontrolery

    atom1477 napisał:

    Równie dobrze można by zrobić interpreter C.

    to juz zrobili, nazywa sie to .NET Framework [;

    4\/3!!

    0
  • #16 29 Gru 2008 10:55
    Klima
    Poziom 30  

    Na uC z Javą jeszcze chwilę poczekamy, ale zapewne nie za długą. Przewiduję, że wkrótce do wyboru będzie mały ARM (taki cortex na przykład) albo Atom Intela do ambitniejszych projektów. Założę się, że niedługo nastąpi zmierzch AVR, Piców, st7, msp i podobnych. Nawet do mrugania diodą będzie się używało 32 bitowego arma. Więc Java? Czemu nie?

    0
  • #17 29 Gru 2008 11:29
    mirekk36
    Poziom 42  

    Klima napisał:
    Założę się, że niedługo nastąpi zmierzch AVR, Piców, st7, msp i podobnych.


    a wiesz ilu już było takich proroków, którzy przewidywali rychłą śmierć 8-bitowych procków ??? duużo. Ja z chęcią bym się założył ale wątpię abyśmy my i nasze dzieci nawet dożyli do momentu rozstrzygnięcia tego zakładu, więc nie ma sensu ;)

    0
  • #18 29 Gru 2008 12:06
    Klima
    Poziom 30  

    Zauważ tylko, że ARM będzie musiał szukać sobie niszy rynkowej, jeśli układy atomopodobne zaczną pojawiać się w większej ilości.
    Jak będziesz miał do wyboru AVR za 5 zł i Cortexa za 5 zł to co weźmiesz? Przy założeniu, że mW/MIPS mają podobny?

    0
  • #19 29 Gru 2008 13:31
    piotr_go
    Poziom 27  

    @Klima
    jeżeli wystarczył by avr to ja bym brał avra, choćby z takiego powodu że zwykle łatwiej go polutować(mniej wyprowadzeń, możliwe że nawet pcb jednostronna wystarczy) i wymaga mniejszej ilości elementów zewnętrznych.

    0
  • #20 29 Gru 2008 14:51
    markosik20
    Poziom 33  

    piotr_go napisał:
    .... i wymaga mniejszej ilości elementów zewnętrznych.


    Żeby uruchomić cortex'a....wystarczy samo zasilanie :wink:.
    Jednak lutowanie obudowy może zniechęcić.

    0
  • #21 29 Gru 2008 15:46
    MarasK
    Poziom 18  

    i żeby napisać prosty program typu migająca dioda nie trzeba pisać 10 plików, konfigurować 100 rejestrów w ARM (no chyba,że źle interpretuję posty na tym forum :)). W AVR jeden prosty pliczek i działa :)

    0
  • #22 29 Gru 2008 15:55
    atom1477
    Poziom 43  

    MarasK napisał:
    i żeby napisać prosty program typu migająca dioda nie trzeba pisać 10 plików, konfigurować 100 rejestrów w ARM (no chyba,że źle interpretuję posty na tym forum :)). W AVR jeden prosty pliczek i działa :)


    I z podobnego powodu nigdy nie lubiłem C.
    Jeszcze nie spotkałem kompilatora C, który działał by od razu po zainstalowaniu.
    Zawsze trzeba w nich ustawiać jakieś ścieżki do paserów, linkerów czy innych cudów których nazw nie znam albo myślę że znam ale pewnie przekręcam.
    A do tego jakieś #include bo przecież jak nie napiszę 10-ciu takich linii to nic nie skompiluję.

    A w Delphi czy BASCOMie jest jeden plik. Piszę co trzeba i działa. Żadnej konfiguracji.


    Ale swoją drogą to taki kompilator JAVA mógł by samodzielnie dbać o inicjalizację tych 100 rejestrów.
    Ale na razie tego nie wiem. Może niedługo programowanie w JAVA będzie miało sens ale na pewno jeszcze nie teraz.

    A AVRy prędko nie znikną. A jak zaczną to zrobię sobie porządne zapasy.
    Nie po to ATMEL wprowadza XMEGA żeby zaraz kończyć produkcję.

    0
  • #23 29 Gru 2008 23:37
    szeryf.rm
    Poziom 22  

    Cytat:
    Jeszcze nie spotkałem kompilatora C, który działał by od razu po zainstalowaniu.

    A ja spotkałem. Na PC działa wiele wiele bez problemu. GCC nie wymaga instalacji i chodzi. Port na windows (gcc z mingw) działa też od razu. Borlandy itp na PC też, choć już czasami trzeba coś do nich dorzucić, jeśli chcemy korzystać z cudów. Co do AVR, to WinAVR chodzi także bez kłopotu. Ze środowiskiem AVRStudio współpracuje też bez problemu, podobnie jak z VMLAB. Wszystko działa od zainstalowania.

    #include? Wierz mi na słowo, że można nie użyć żadnego include w całym programie i nie ma w tym nic skomplikowanego :). Ale się przydaje, bo wiesz że PORT siedzi tu i tu, a nie szukasz tego w dokumentacji.
    O inicjalizację to bym się nie martwił, bo prawda jest taka, że ona była, jest i będzie zawsze potrzebna prędzej czy później i to cię nie ominie. Wystarczy tylko wziąć pod uwagę dynamiczną zmianę wejść/wyjść podczas działania programu.

    Poza tym zgadzam się, że AVR dłuuuuugo jeszcze nie znikną, a próba pracy w JAVIE na AVR jest głupotą i jak napisał kolega wyżej, nawet jak się da, to szybko się okaże, że granice możliwości javy w AVRach są zbyt wąskie, żeby dało się zrobić coś ciekawego i trzeba będzie zejść niżej. Ja w życiu nawet optymalizowałem kod z C przepisując go w części do ASM, żeby mi się zmieścił procesorze, a C i tak był już ustawiony na optymalizację Os i udało się :).

    A poza tym jestem wielbicielem C, C++, ASM (nie na PC). JAVA to cudaczny język, który dzięki reklamie zrobił furorę i teraz pojawiają się właśnie tacy, co chcą ją wrzucić wszędzie :). A jak się nie da, to zrobią 2 migające diody i powiedzą, że się dało :P

    Pozdr.

    0
  • #24 30 Gru 2008 00:14
    atom1477
    Poziom 43  

    szeryf.rm napisał:
    Cytat:
    Jeszcze nie spotkałem kompilatora C, który działał by od razu po zainstalowaniu.

    A ja spotkałem.


    Po prostu miałem pecha oraz znajomego który podrzucał mi kompilatory które nie działały bez tych cudów (oczywiście nie podrzucał mi ich w złej wierze).

    Myślę że nie ma co dłużej ciągnąć tego tematu. JAVA się nie nadaje i tyle.

    0
  • #25 01 Sty 2009 21:42
    Klima
    Poziom 30  

    Pozwólcie, że zacytuję klasyka:
    "640kB powinno wystarczyć każdemu".
    Myślę, że jest to dobre podsumowanie dyskusji.

    0
  • #26 01 Sty 2009 23:24
    szeryf.rm
    Poziom 22  

    Klima, ten klasyk tutaj pasuje i nie pasuje. Jeśli spojrzeć obiektywnie to masz rację. Dzisiejszy świat brnie w kierunku głupoty.
    Jeszcze nie dawno w lodówce był jedynie agregat i trochę bimetalu itp, a dzisiaj już niezbędny jest tam procesor i to spory, a w najbliższym czasie będzie jeszcze wejście do sieci, bo przecież lodówki będą zamawiały same jedzienie, a już dzisiaj mają telewizor na drzwiach.
    Tylko patrzeć jak pojemnik na chleb będzie miał więcej elektroniki niż dzisiejszy komputer, bo będzie sam po ten chleb chodził, a krajalnica do chleba będzie przypominała zaawansowaną obrabiarkę, żeby mogła jednocześnie kroić chleb, ale także obierać wszystkie warzywa i owoce, wyciskać sok itd. Kuchenki gazowe wyposaży się w całą serię czujników i jakiś wieeeeeeeeelo rdzeniowy superkomputer do symulacji pieczonego ciasta, tak że po wpisaniu składników policzy czy się uda czy się nie uda.
    Itd itd.
    W ten sposób myśląc można dojść do wniosku, że 640kB to będzie grubo za mało, ale jak spojrzeć w głąb to okaże się, że cały podsystem tej kuchenki będzie sterowany centralnie, a mniejsze bloki będą działać na malutkich sterownikach. Lodówka wpięta do sieci, ale czujniki kontrolowane przez mniejsze sterowniki niż główny. Krajalnica sterowana centralnie ale sterowniki silników itd. będą systemami niezależnymi opartymi na mniejszych sterownikach. Pojemnik na chleby będzie szedł, ale sterownik też zostanie podzielony...

    Reasumując: Każdy system, chociażby największy zawsze gdzieś tam najniżej znajdzie miejsce na malutki mikroprocesor z 1kB flash'a, który z problemem sobie poradzi. Zresztą, wystarczy spojrzeć dzisiaj. Dobre procki nadające się do cudów można nabyć za grosze, a jednak AVR, małe PIC itp. nadal są w użyciu :).

    Dawno temu jak java się rozwijała, ogłaszano szybki koniec C, C++ itd. a tu nici. Wiele systemów jest opartych głównie na tych językach (jądra systemów). Programów w javie jest malutko na PC z których korzystamy na codzień, a te które są, często są bardziej dziurawe, niż te w C, bo do Javy siadają byle głąby (nie jest to reguła i bez urazy dla dobrych programistów), którym wmówiono, że java jest prosta i można szybko się nauczyć programować. Zapomniano jedynie dodać, że programować można się nauczyć we wszystkim, nawet w językach opisowych, słownych, meta językach, ale i tam trzeba rozumieć co się robi.

    Dlatego java nie jest panaceum na wszystko. A tak z logicznego punktu widzenia, jakbym dostał sterownik regulacji fazowej oparty na czymś w rodzaju ARM 200MIPS lub na jakimś sygnałowym 200MIPS, który nic by nie robił szczególnego, a radosną twórczość opatrzono by notatką: "Zrobiłem tak, bo tam była java" to bym padł ze śmiechu :P.

    Wyszło dłuższe, ale myślę że jasno wyraziłem to co chciałem powiedzieć. Zawsze po prostu będą problemy, które można rozwiązać prościej, bez zaprzęgania cudów techniki. A dlaczego warto być trochę przeciwko cudom tam gdzie nie są potrzebne? Proste: diagnostyka, naprawa, poziom skomplikowania, czas potrzebny na testy, niezawodność itd.

    0
  • #27 02 Sty 2009 20:56
    Klima
    Poziom 30  

    szeryf.rm napisał:
    Programów w javie jest malutko na PC z których korzystamy na codzień, a te które są, często są bardziej dziurawe, niż te w C, bo do Javy siadają byle głąby (nie jest to reguła i bez urazy dla dobrych programistów), którym wmówiono, że java jest prosta i można szybko się nauczyć programować. Zapomniano jedynie dodać, że programować można się nauczyć we wszystkim, nawet w językach opisowych, słownych, meta językach, ale i tam trzeba rozumieć co się robi.

    Nie obraź się, ale tą wypowiedzią udowodniłeś, że po prostu "się nie znasz". Nawet nie zdajesz sobie sprawy, gdzie korzystasz z Javy :).
    szeryf.rm napisał:

    Dlatego java nie jest panaceum na wszystko. A tak z logicznego punktu widzenia, jakbym dostał sterownik regulacji fazowej oparty na czymś w rodzaju ARM 200MIPS lub na jakimś sygnałowym 200MIPS, który nic by nie robił szczególnego, a radosną twórczość opatrzono by notatką: "Zrobiłem tak, bo tam była java" to bym padł ze śmiechu :P.

    Ja bym się powoli psychicznie zaczął do tego przygotowywać. I nie ma się co obrażać na rzeczywistość. Trzeba było iść na "marketing i zarządzanie" albo "finanse", miałbyś na te zmiany większy wpływ ;).

    A co do postępu i wsadzaniu komputerów do lodówek - w dużej mierze masz rację, ALE:
    Samochodowy silnik to też banalny kawał żelastwa i nie wiadomo po co tkają do tego tyle elektroniki. Możemy psioczyć, że więcej tam powoli jest krzemu niż stali, tyle że fajnie jest jeździć samochodem zużywającym poniżej 5 l / 100 km i dającym z pojemności 1.5 litra ponad 100 koni mechanicznych, co nie? A to wszystko dzięki temu "przekomplikowaniu".

    0
  • #28 02 Sty 2009 21:44
    Balu
    Poziom 38  

    Akurat z tymi koniami z 1,5l silnika to nie kwestia jako takiej elektroniki:> a doładowania i lat badań:>

    0
  • #29 02 Sty 2009 21:44
    szeryf.rm
    Poziom 22  

    Sorki za offtopic, choć w sumie to nadal ten sam temat.

    Klima to ty się nie obraź, ale wymień mi te multum dobrze działających programów napisanych w javie, bo ja rękę dam sobie uciąć, że na moim komputerze i większości komputerów takie oprogramowanie to mniejszość. Przykładów nie brakuje, ale jak chcesz to postaram się poszukać.
    NetBeans - na pewno java bez spradzania, prędkość działania, zużycie pamięci itd. to ewidentnie zasługa javy. Nie korzystam jak nie mam przymusu z uczelni, bo ten program fajny, ale czasami potrzebuje dodatkowy rdzeń, bo jeden dla niego nie wystarczy :)
    Open Office - widać, że java. I znów widać po prędkości, zużyciu pamięci itd. Korzystam, aczkolwiek każdy dobrze wie, że prędkość MS Office jest dużo większa.
    Eclipse - java bez wątpienia. Nie wiele środowisk zaraz po uruchomieniu zrzera 111MB ramu :P. Kpina. Dlatego nie korzystam jak z uczelni nie wymagają. Pamięć to nie problem, ale działa z prędkością odwrotnie proporcjonalną do użycia pamięci :). Podobnie jak netbeans

    Kicad - raczej nie java, bo po uruchomieniu pokaźnych schematów i płytek razem wszystko zrzera poniżej 100MB
    Opera - raczej nie java, bo za szybko chodzi i pomimo wielu otwartych stron nie ma 100MB

    Gry, szczególnie te najlepsze z pierwszych stron gazetek, grafika 3D, akcja, dynamika itd. Java małoprawdopodobna.

    Jądro Windows - jak nic nie Java

    Jądro Linux - na pewno nie Java

    Jądro BSD - bodajże większość napisana w C, ale java nie

    Sterowniki - oj, lepiej nie mówić, większość normalnego sprzętu ma najniższe sterowniki napisane w C/C++, obecnie rzadko w ASM. Ale jest też sprzęt nienormalny typu drukarki HP, gdzie sterownikom trudno przypisać język. Wcale bym się nie ździwił gdyby to była Java, bo nie wiele sprzętu wymaga blisko 40 minutowej instalacji sterownika! I oczywiście chodzi tak jak eclipse, czyli odwrotnie proporcjonalnie do ilości zużywanych zasobów pamięci ram.

    I tak można jeszcze wiele wymieniać, ale na moim kompie tylko OpenOffice jest używany normalnie. Resztę oprogramowania w Javie ignoruje dopóki ktoś mnie nie zmusi :).

    Z programami napisanymi typowo w javie to już wolę się ich nie czepiać. Temat woda. Programy fajne, ale jedynie na zdjęciach, bo jak włączam i po 4 godzinach pracy i zapisie co 5min wywala błąd i kasuje plik z zapisaną pracą, to normalnie dzieło sztuki. Miałem parę takich motywów i widziałem trochę softu, który działał jedynie na zdjęciach. To podobnie jak z Wine. Jest i działa, ale lepiej nie korzystać, bo różnie z nim bywa :P.

    Samochodu to bym nie porównywał z lodówką. Samochody zawsze były małooptymalne itd., ale w samochodzie nie potrzeba np. TV 32'' :P a w lodówkach TV (mniejszy) obecnie się przydaje :P.

    Marketingowców to bym zamknął i skazał na dożywocie za robienie ludziom wody z mózgów. Mamy przecież takie perełki (lub przyszłe perełki) i cuda techniki jak tv LCD z odświeżaniem 480Hz i czasem reakcji 8ms :P, matryce 8MP w komórce co nie wiele daje prócz szumów itd itd. Proponuję dalej nie schodzić poniżej pewnego poziomu dyskusji i nie wywoływać takich "autorytetów" jak marketingowcy.

    Także temat woda, do porozumienia nie dojdziemy. Już dzisiaj głosi się szybszy kres javy niż C/C++, mimo że to java miała wyprzeć właśnie te języki :). A 8 bitowcą głoszono kres już daaawno temu. Pierwsze takie pogłoski pamiętam z lat 90-tych :). A do dzisiaj są i mają się dobrze. Projektów z nimi nie brakuje nawet tutaj na tym forum. I jeszcze długo świat o nich nie zapomni, bo trzeba pamiętać, że to nie system jest popularny, a dostępność oprogramowania na ten system. Nie ma oprogramowania, nie ma systemu. Póki ma kto wykorzystywać 8bitowce, biznes się kręci, a póki się kręci, będą 8 bitowce. Ja i wiele wiele innych ludzi nie mają zamiaru z nich zrezygnować :).

    PS. Ale wyszło. Felieton.

    1
  • #30 02 Sty 2009 22:33
    hotdog
    Poziom 26  

    szeryf.rm napisał:

    NetBeans - na pewno java bez spradzania, prędkość działania, zużycie pamięci itd. to ewidentnie zasługa javy. Nie korzystam jak nie mam przymusu z uczelni, bo ten program fajny, ale czasami potrzebuje dodatkowy rdzeń, bo jeden dla niego nie wystarczy :)
    Open Office - widać, że java. I znów widać po prędkości, zużyciu pamięci itd. Korzystam, aczkolwiek każdy dobrze wie, że prędkość MS Office jest dużo większa.
    Eclipse - java bez wątpienia. Nie wiele środowisk zaraz po uruchomieniu zrzera 111MB ramu :P. Kpina. Dlatego nie korzystam jak z uczelni nie wymagają. Pamięć to nie problem, ale działa z prędkością odwrotnie proporcjonalną do użycia pamięci :). Podobnie jak netbeans


    Z kwestią dotyczącą eclipse i netbeans (i innych w tym podobnych) się z tobą 100% nie zgadzam. Jeżeli ja osobiście pisząc program w javie napiszę go szybciej korzystając z tych programów chociaż o 10 minut. To wolę włączyć program który zabiera nawet 512 MB ramu przy starcie. On ma przyspieszyć i usprawnić naszą pracę (programistów). Jak ktoś robił kiedyś GUI dla javy najpierw w notepadzie, a później korzystając z mechanizmów NetBeans'a wie o czym mówię (mniej więcej to samo jak pisanie aplikacji okienkowej w WinAPI i a w C++ Builder'rze). W NetBeans'ie GUI się robi w 5 minut w notatniku są to godziny i więcej (i itak nie mamy tego co chcieliśmy ;p).

    Jak chyba nie wszyscy wiedzą główną różnicą między javą i C#, a między np C, C++, czy asm jest to że java to język ZARZĄDZALNY. To znaczy tyle że coś zarządza wykonywanym programem. Niesie to oczywiście za sobą dużo wad (wolny program, potrzebuje dużo pamięci) i zalet (przenoszalność kodu, mniejszy wysiłek ze strony programisty itp). Język zarządzalny musi być wielowątkowy (java ma wielowiątkowość "w sobie"). Obsługuje on rzeczy - wyjątki, strumienie, przydział czasu (priorytety).

    Tak naprawdę to że kod w javie jest bajtowy nie ma tutaj dużego znaczenia. Jasne że można by to było prze kompilować (pisząc odpowiedni kompilator, w c też kompilacja jest podzielona na etapy) na kod binarny ale to już nie była by java. Weźmy np garbage collector. Jest to takie coś które zarządza pamięcią. To znaczy tyle że jeżeli w naszym programie tracimy referencje do jakiegoś obiektu, zostanie on usunięty z pamięci. Wskaźników jako takich w javie nie ma bo są po prostu nie potrzebne.

    Język java jest wzorowany na C++ (który z kolei był wzorowany na C). Składnia bardzo podobna (w sumie narzędzie do programowania Eclipse też można wykorzystać do AVR). Filozofia i podejście jest jednak zupełnie inne.

    Ja proponuje zapomnieć o Javie na uC (a w szczególności na 8bitowe AVR'y). Dużo ludzi nie pisze w C++ na AVR ze względu na nadmiarowość kodu itp.

    Java została stworzona zupełnie w innym celu. Między innymi raportowania, aplikacje bazodanowe, aplikacje internetowe, systemy rozproszone. Wszędzie tam gdzie wydajność raczej nie ma większego znaczenia.

    jeżeli się gdzieś pomyliłem mnie poprawić
    pozdrawiam hot-dog

    0
  Szukaj w 5mln produktów