Post by thread:[PIC]: Java PICmicro MCU Development Tools

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_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

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" .....speffKILLspam@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 listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

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 .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body

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_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

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) jamesnewtonspam_OUTpiclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org {Original Message removed}

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}

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@jamesnewtonKILLspampiclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org {Original Message removed}

>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 KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

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}> 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) > RemoveMEjamesnewtonTakeThisOuTpiclist.com 1-619-652-0593 > PIC/PICList FAQ: http://www.piclist.com or .org > > > > {Original Message removed}

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 <--> spamBeGonewzabspamBeGoneise.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-requestEraseMEspam_OUTmitvma.mit.edu

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 RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu