Searching \ for '[PIC]: Java PICmicro MCU Development Tools' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Java PICmicro MCU Development Tools'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Java PICmicro MCU Development Tools'
2001\03\01@084754 by myke predko

flavicon
face
Hi Folks,

I have just gotten a question regarding programming the PICmicro MCU in Java
and why didn't I reference it in the new PICmicro book.

As far as I know, there aren't any Java VMs that have been created for the
PICmicro (not to mention PICmicro specific libraries or IDEs).

Are there any out there?

Another question would be is it something that people would want?

myke

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\01@085401 by Bob Ammerman

picon face
The PIC is not about to do JAVA (except possibly a PIC18, and even that
would be surprising).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2001\03\01@091735 by Spehro Pefhany

picon face
At 08:52 AM 3/1/01 -0500, you wrote:
>The PIC is not about to do JAVA (except possibly a PIC18, and even that
>would be surprising).

As you say, Sun's downsized VM (KVM) boasts a super lean memory footprint
of < 100K.

If Gordon Moore's law holds, though, from 3K bytes (PIC12CE674) to 150K
could only be 8 or 9 years.

Best regards,


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\01@103815 by Robert Swirsky-Warner

flavicon
face
Java is a rotten language for embedded programming (and nearly
everything else, too! We all dislike it here, and use it when we
absolutely have to).

A compliant Java VM would be very large, and would consume vast
amounts of RAM: memory is allocated and freed automatically
by its "garbage collector"--not a good choice when you only have
a precious 47 bytes of memory! I know Sun is working on "tiny"
version of this, but even those would be a minimum of several
hundred K for the exeuctable code itself.

Also, since you never know when it will decide to clean up
its memory, it makes it difficult to do real-time applications
where something must be guaranteed to happen within a predictable
time period.

A long time ago, Forth (it's spelled that way!) was popular
for embedded work. It runs on 8051s and PICs, and just about
everything else, too: http://www.forth.org/compilers.html
You may want to take a look at Forth if you want a HLL!

--
Robert Swirsky-Warner
Walt Disney Imagineering, R&D

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\03\01@104510 by David VanHorn
flavicon
face
At 07:38 AM 3/1/01 -0800, Robert Swirsky-Warner wrote:
>Java is a rotten language for embedded programming (and nearly
>everything else, too! We all dislike it here, and use it when we
>absolutely have to).

Remember when Java was going to take over embedded controllers? :)
Well... I'm still working in assembler.


--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\03\01@110529 by jamesnewton

face picon face
The Ubicom (formerly Scenix) SX52 has a Java VM available. It is not
intended for other than very serious applications (the license is $25,000)
but it does include source code and can be extended (some) to add Virtual
Peripherals for additional hardware support. It executes byte codes from an
external memory, so the Java program size can be quite substantial.
http://www.ubicom.com/java_vm.html

Although cost is... stunning?... The idea behind this approach is quite
exciting to me... You have a two chip solution that can

A) do low level hardware type things VERY quickly (100MIPS) like A2D, RS232,
mild DSP like DTMF IO, FSK IO, etc... keyboard debounce, Matrix display
drive, and so on with only a few external passive components

B) have butt loads of program space left over to do highlevel, complex
functions at a slower rate.

Hobbyists should look at XPL0 for a similar but open source solution.
www.sxlist.com/techref/language/xpl0.htm
This language allows development in a Pascal style syntax of byte code that
will run on the following processors 6502, 8080, 6800, PDP-10, IBM-360, a
homebrew machine, 65802, 680x0, PIC, SX, and the 80x86 family used by the
PC. GUI support and win32 versions are also available.

I have been AMAZED that the word about this beautiful little language has
not spread like wildfire. It's really nice and worth a try.

---
James Newton (PICList Admin #3)
jamesnewtonspamspam_OUTpiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org



{Original Message removed}

2001\03\01@111516 by Brandon, Tom

flavicon
picon face
Yes Java will proaly never be suitable for the majority of real-time
embedded systems, but it still has a place. Just like C is less effective in
a real time environment (still have to write low level stuff in ASM) it
certainly has a place and for some tasks it is almost as efficient as hand
coded ASM (not taking into account competency of the programmer which will
always be the major problem). Likewise Java has a place, not for real-time
embedded systems but for embedded systems performing more complex, less time
critical tasks.

Not sure which tiny Java you're talking about. Sun (and others) have
published specs for Real-Time Java (JSR-001) which deals to some extent with
the shortcomings of Java for real time systems. For instance:
- Garbage Collection now allows different implementations and is more
tailored to real time design. So you can have synchronous (or I believe
manual) garbage collection if you wish. Also asynchronous (mark and collect)
collection is supposed to be more deterministic.

Thread scheduling has also been improved vastly. As with GC it suports
multiple implementations. For example, one can create cyclic (or acyclic)
tasks and do some pre-runtime scheduling.

And a primary aim is more determinism. Obviously it will never be suitable
for all tasks, but it has it's place. Devices such as PDA's, Mobile Phones,
Wearable Computers, Embedded Web\Database Servers will start to make
increasing use of high level languages such as Java due to the comlexity of
current products and short development cycles neccesary.

Tom.
{Original Message removed}

2001\03\01@113341 by jamesnewton

face picon face
A) Is there a byte code interpreted FORTH or C for the Microchip PIC or
Ubicom SX? (answer in advance: NO. Please prove me wrong). How much non-time
critical code can you get into the internal memory of a PIC before you have
to say "no, I can't do this. You need an embedded x86 development house"
Does anybody get the advantage of an byte code VM?

B) Can any college graduate in computer science crank out ASM or FORTH code
to take care of the non-timing critical parts of the development effort?
Does anybody get the difference between PROGRAMMER TIME EFFICIENT and
PROCESSOR TIME EFFICIENT? Does anybody understand that both are "good
things"tm in their place?

Again, you need a fast little embedded controller with an external serial
FLASH or EEPROM memory attached so you can:

A) do low level hardware type things VERY quickly like A2D, RS232,
mild DSP like DTMF IO, FSK IO, etc... keyboard debounce, matrix display
drive, and so on with only a few external passive components. This part is
written by a really high pay embedded developer or drawn from a library.
(piclist.com)

B) have butt loads of program space left over to do high-level, complex
functions at a slower rate and hire any Tom, Dick or Harry to write that
Java or XPL0 (Pascal) code.

http://www.sxlist.com/techref/language/xpl0.htm

We are selling our little chips short of what they can actually do...

---
James Newton (PICList Admin #3)
@spam@jamesnewtonKILLspamspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\03\01@114131 by Alan B. Pearce

face picon face
>Hobbyists should look at XPL0 for a similar but open source solution.
>www.sxlist.com/techref/language/xpl0.htm
>This language allows development in a Pascal style syntax of byte code that
>will run on the following processors 6502, 8080, 6800, PDP-10, IBM-360, a
>homebrew machine, 65802, 680x0, PIC, SX, and the 80x86 family used by the
>PC. GUI support and win32 versions are also available.

Wasn't developed at UCSD by any chance? Remember how UCSD Pascal died when they
insisted that you had to buy the complete development system to get the engine
for a second platform?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\02@021003 by dr. Imre Bartfai

flavicon
face
Hi,

I am always desperately seeked for a bytecode-interpreted system. Unless I
did hear about XPL0 the only alternative would for me the CFLEA from
Mr. Dunfield (http://www.dunfield.com). However, I never did manage to decide
myself to buy that thing.

I am glad to hear now there would be a bytecode interpreter for XPL0 also
for PIC, not only for SX. My question is: where?

I would be very grateful as my projects would require a PIC larger than 8k
EEPROM (do you hear, Microchip?), but at this moment the 18Cxxx series
should be ignored by me (17Cxxx also) as there is no severe development
environment for DOS available.

Regards,
Imre

PS: I have looked at XPL0 already, and I am also fascinated of it.

On Thu, 1 Mar 2001, James Newton wrote:

{Quote hidden}

> {Original Message removed}

2001\03\02@045316 by wzab

flavicon
picon face
On Fri, Mar 02, 2001 at 08:10:03AM +0100, dr. Imre Bartfai wrote:
> Hi,
>
> I am always desperately seeked for a bytecode-interpreted system. Unless I
> did hear about XPL0 the only alternative would for me the CFLEA from
> Mr. Dunfield (http://www.dunfield.com). However, I never did manage to decide
> myself to buy that thing.
>
> I am glad to hear now there would be a bytecode interpreter for XPL0 also
> for PIC, not only for SX. My question is: where?
>
I think it is there (It is for SX, but should be useful for PIC's as well):
http://www.sxlist.com/techref/scenix/xpl0/I2L.ASM

However this interpreter is licensed under GPL, and it may make it difficult
to use it for commercial closed source projects.

Well, the bytecode itself may remain hidden, AFAIK.
--
                               HTH & Regards
                             Wojciech M. Zabolotny
       http://www.ise.pw.edu.pl/~wzab  <--> spamBeGonewzabspamBeGonespamise.pw.edu.pl

http://www.debian.org  Use Linux - save your data and time

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2001\03\02@073637 by klpauba

picon face
Robert Swirsky-Warner wrote:

> Java is a rotten language for embedded programming (and nearly
> everything else, too! We all dislike it here, and use it when we
> absolutely have to).

I, too, think Java may not be ideal for embedded programing but as far
as a programming language, I have the contrary opinion.  We've found
that Java allows our programmers to increase their productivity
drastically and the resulting programs tend to have fewer bugs than the
C-language predecessors.  I think Java would be an ideal language for
developing PIC tools.

>
> A compliant Java VM would be very large, and would consume vast
> amounts of RAM: memory is allocated and freed automatically
> by its "garbage collector"--not a good choice when you only have
> a precious 47 bytes of memory! I know Sun is working on "tiny"
> version of this, but even those would be a minimum of several
> hundred K for the exeuctable code itself.

I'm using a "non-compliant" Java VM on a Lego Mindstorms that is less
than 16K (no much chance of shoehorning this in to a PIC, though)!
My young son, however, found that Forth was a little easier to learn as
a first language.


>
> Also, since you never know when it will decide to clean up
> its memory, it makes it difficult to do real-time applications
> where something must be guaranteed to happen within a predictable
> time period.

I concur, as this behavior can put a big wrench in embedded programming.

>
>
> A long time ago, Forth (it's spelled that way!) was popular
> for embedded work. It runs on 8051s and PICs, and just about
> everything else, too: http://www.forth.org/compilers.html
> You may want to take a look at Forth if you want a HLL!
>

There's a free Forth cross compiler for the PIC called Mary available on
the 'net.

>
> --
> Robert Swirsky-Warner
> Walt Disney Imagineering, R&D
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...