Svenska ElektronikForumet

Just nätverksbiten är väl den största motiveringen till att använda en "javaprocessor". Körde Dallas TINI för några år sedan i en applikation som bara skulle skyffla data från serieporten till tcp/ip och tillbaks, men TINIn höll inte riktigt måttet vad gällde prestanda. Så jag provade en modul från Imsys istället och om jag minns rätt så var det minst 10 gånger högre prestanda iden. Typ en sådan här: http://www.imsystech.com/products/devkits/snapkit05.htm

Man ska dock vara medveten om att javan är lite begränsad så det är inte bara att köra sin javakod för en fullskalig JVM ner i sådana här moduler. Men det kan iofs ha hänt en del sedan jag höll på med det.

IM3910 verkar vara en trevlig controller.

Det där med att läsa ur en tempsensor i Java och javelin skulle jag vilja påstå är minst lika lätt om inte lättare i t ex C och en pic med libs från t ex MikroC.

Jag tittade mycke på Basic Stamp i början men övergav det snart då priset var såpass högt att det inte var lönt. Bättre att lägga den tiden på nåt annat.

Ja det är väl inga stora skillnader mellan C och Java förutom objektorienteringen.

Här var också en variant på PIC för att kunna programmera i Java...

http://www.oopic.com/

Nybörjarvänligt!

OK. Det är väl sannolikt så att den som "nyligen läst 15p Java" självklart förstår sig på
detta mycket bättre än den som har ägnat 30 år aktivt arbetsliv med datorer och
programmering med alla möjliga slags miljöer och "språk". Jag har följt Java's utveckling
ända sedan någon kille på jobbet sprang omkring på kontoret med en kaffekopp på T-tröjan
för 15 år (eller vad det nu var) sedan. Så det är väl bara naturligt att du förstår detta bättre
än (t.ex) mig eller andra här i tråden...

Men men, en dag kommer även du att förstå hur saker och ting fungerar "out there".

Och angående http://www.oopic.com/...

"Ordering" sidan säger :
"Last call for ooPIC Microcontrollers! Get them while they last! Firmware will still be available...."
Tydligen har de helt gett upp och gjort det hela open-source. Antagligen är det ingen som vill
köpa prylarna. Man undrar varför... (Ja, *du* kanske inte förstår, men i alla fall...)

Java och objektorientering är inte riktigt lämpligt för nybörjare
som vill komma igång snabbt fast tanken med ooPIC verkar just
vara enkelhet. Många väljer assembler och c (och miljoner frågor
i forum). Där är SUN bra för det finns allt om Java samlat på samma
ställe.

Javas syntax är i stort sett samma som C och C++ och bygger
på dom. Allt bra från C finns i Java och så har man plockat
bort det dåliga. Sedan att det är en virtuell maskin som kör
en bytekod är en annan femma. Den blir bättre och bättre
och har i måga fall jämförbar prestanda med kompilerad C-kod.

Sedan går det programmera Java på det vanliga viset utan
att utnyttja arv och sånna lite svårare bitar.

"...och så har man plockat bort det dåliga"
Det är väl ändå att ta i en hel del. Man kanske har plockat bort de delar som kan vara flertydiga och de delar som många klantar sig med, tyvärr är en del funktionalitet försvunnit med dessa delar också.

För mig är C och Java på olika nivåer, Java är till högre abstraktionsnivåer och C är till när man faktisk ska jobba med hårdvaran så att utnämna dom till konkurrenter är i mina ögon fel. Lite som att jämföra ett OS med BIOS och tycka att det ena är bättre än det andra.

Att de överlappar (speciellt C++ och Java) och till stor del är till samma nivå är för mig inlysande och jag kan inte se speciellt många vettiga anledningar till att välja Java om man redan kan C och då lätt kan migrera till C++. Om sedan Javan är interpreterat eller inte är av ringa betydelse i detta, det är en prestandafråga.

Att Java är svårare att göra bort sig med är nog sant, syntaxen är hårdare så att säga, men det betyder även att "fiffiga lösningar" är uteslutet, något som i en hel del fall är en fördel (lite väl kreativa programmörer) men nog i lika många fall är ett problem (dom som faktisk vet vad de gör).

Du bodde på vilken planet?

Jag tycker snarare att Java håller på att gå i från att vara ett universal- och GUI-applikationsspråk och mer och mer kör på serversidan i affärssystem.

C och Java har nog rätt olika användningsområden, även om C är så mångsidigt att det KAN användas till det mesta. Om man skulle jämföra Java med något C-liknande språk så tycker jag C# kommer närmast, även om det i praktiken saknar Javas plattformsoberoende.

edit: inte riktat till Icecap då...

4kTRB:
Nu är det ju inte så att Java är språket som löser alla problem här i världen. Tvärtom så är vi nu med om en exponentiell tillväxt av programmeringsspråk för tillfället och det finns nog en anledning till det. Det finns en uppsjö språk som är minst lika kraftfulla som Java (Java är ju faktiskt ganska jobbigt) och fler lär komma.

Just nu känns eLua bra mycket hetare för embedded än Java http://elua.berlios.de/.

En kollega lärde mig lite Java en gång, drygt 7år sedan. Han var utbildad civilingenjör och hade läst betydligt mer än 15 poäng programmering och jobbat med embedded ett par år efter det. Jag höll då på med ett tidtagningsprojekt med en hel del MCU'er och displayer inblandade. Han lärde mig en hel del (redan förträngt). Men när jag kom in på att använda Java till att kommunicera med MCU'erna i tidtagningsprojektet la han först ner en massa tid på det innan han gav upp. Tidigare hade han avrått mig att ens börja med att köra Java mot dessa enheter, att ens tänka på Java i embedded sammanhang ansåg han förkastligt.

Efter att ha gett upp blev det c som fick lösa kommunikationen med MCU'erna som var programmerade i assembler.

Icecap skrev:"...och så har man plockat bort det dåliga"
Det är väl ändå att ta i en hel del. Man kanske har plockat bort de delar som kan vara flertydiga och de delar som många klantar sig med, tyvärr är en del funktionalitet försvunnit med dessa delar också.

Lite otydlig var jag där, syftade på C++ som man ska jämföra Java med
när det gäller det som Java löser på ett bättre sätt och inte tillåter
program som blir svåra att utveckla. Det är objektorienteringen Java
löser på ett bra sätt.

Det behövs ingen virtuell maskin för en specifik processor utan Java kan kompileras
direkt på samma sätt som C. Och det går ställa bitar i register och liknande
på samma sätt som i C. Men då går det inte köra programmet på en annan
processor vilket är själva grundtanken med Java.

Virtuella maskinen är till för att samma javaprogram
ska kunna köras på olika processorer utan att behöva
genomföra en kompilering för varje ny processor.
Det är bara att klicka igång programmet (bytekoden).

Den Virtuella maskinen kör den kompilerade bytekoden all eftersom den behövs
och det är det som går lite långsammare men också det börjar gå riktigt snabbt
på de nyare varianterna av virtuella maskiner. Den virtuella maskinen ska ju göra
om bytekoden till maskininstruktioner.

Java är inte ett interpreterande språk som läser syntaxen, det skulle bli långsamt som bara den.

Med en processor som kan köra bytekoden direkt så behövs ingen virtuell maskin,
det är en renodlad Javaprocessor.

Dvs den har inbyggd kompilator. Hur som helst så måste oavsett språk programkoden ner i maskinkod. Spelar ingen roll vilken cpu man har.

Nej inte inbyggd kompilator.
Virtuella maskinen interpreterar bytekoden.
Man kompilerar sin Javasyntax till bytekod.

Jag tror knappast att du behöver föreläsa om hur Java fungerar "under the hood".
Alla här är nog helt medvetna om det. Det är ju inget konstigt eller nytt med
det igentligen. Interpreterande språk (som alltså bygger på i princip samma
grundprincip som JAVA/JVM) har ju funnits väldigt länge.

> Lite otydlig var jag där, syftade på C++ som man ska jämföra Java med

Nu så ser det ju ut som att du tänker på helt andra processorer än de som normalt
avhandlas här (AVR/PIC o.s.v), men generellt är C++ lika olämpligt för
mikrokontrollers som Java (OK, kanske lite mindre olämpligt). Så jämförelsen
är mest akademisk utan större praktiskt värde.

> Men då går det inte köra programmet på en annan
> processor vilket är själva grundtanken med Java.

Och det är *stora* problemet med Java. Att man försöker göra det till "allt för alla"
vilket gör att det igentligen inte fungerar riktigt bra någonstans. Enanvändarmiljöer
som en PC eller desktop Linux/unix maskin undantaget kanske.

> Det är bara att klicka igång programmet (bytekoden).

Och JVM'en. Bara bytekoden i sig går inte att köra på någon (normal) processor
utan någonting som tolkar den. Att du väljer att betrakta det som att bytekoden
faktiskt "körs" av processorn kan jag bara tolka som att du inte riktigt förstått
hur det fungerar.

> Den virtuella maskinen ska ju göra om bytekoden till maskininstruktioner.

Njae, JVM'er med JIT gör väl det *delvis*, annars så *tolkas* (interpreteras) bytekoden.
Eller hur menar du igentligen ?

> Java är inte ett interpreterande språk som läser syntaxen,

Nej, mer som vissa Pascal varianters p-kod. Eller hur ?

> Med en processor som kan köra bytekoden direkt så behövs ingen virtuell maskin,
> det är en renodlad Javaprocessor.

OK, det är inte helt tydligt vad du menar med att "köra direkt", men så vitt
jag förstår så har alla "Java-processorer" en firmware med en (slags) JVM som
"kör" den bytekod som man kastar in. Jag har i alla fall aldrig sett en processor som
exekverar bytecode direkt i microkoden (d.v.s i själva hårdvaran).

En undran...
Vad kan du om programmering förrutom det du läste på Java kursen ?
Har du programmerat någonting alls i något annat språk ?
Har du läst/studerat någonting annat än Java ?
Ge oss gärna lite referensramar så är det lättare att förstå hur du ser på det hela.

> Nej inte inbyggd kompilator.

Nej, jag tror att danielr112 menade "inbyggd interpretator", d.v.s i princip en (lite bantad) JVM.
Om danielr112 faktiskt menade "inbyggd kompilator" så håller jag dock med dig...

Intepreter ja. Lite dumt skrivit. Det jag menar är att oavsett vad så har man javan så behöver man ett steg extra mot ett färdigkompilerat program gjort i C.


Jag menar du kan inte köra ett java program på samma sätt som ett C-program. Där behövs ett steg emellen. Fördelen med javan är att man kan köra det "här och där" men nackdelen är som sagt det extra steget..