What is the future for Javelins? How long will will they be supplied?
GregS
Posts: 15
What is the future for Javelins?· How long will Parallax continue to supply these AMAZING devices?· And does anyone know how many have been sold so far?
I realise that Parallax has given up on the development/updates of the Javelin IDE, and that the SX chips (on which the Javelin is based) are no longer being produced,·but does this mean that we are DOOMED to development in mindless Basic, (or not so mindless·Spin)?
Are there any alternatives if Parallax drops the chip?
·
I realise that Parallax has given up on the development/updates of the Javelin IDE, and that the SX chips (on which the Javelin is based) are no longer being produced,·but does this mean that we are DOOMED to development in mindless Basic, (or not so mindless·Spin)?
Are there any alternatives if Parallax drops the chip?
·
Comments
We've sold somewhere between 5-10K Javelin Stamps.
The product has been considered for end of life (EOL) internally due to the following reasons:
- flat to declining sales
- general lack of internal support of further programming examples and IDE improvements (Peter Verkaik has done some, thankfully)
- technical obsolescence - the Propeller does it all, much easier
- difficulty obtaining certain components (we designed this module ten years ago and many parts have become obsolete)
The SX EOL isn't why we'd discontinue the Javelin. We have 15-20 years of SX chips locked away for BASIC Stamps and the Javelin is less than 1% of the SX usage.
At present we have about 300 units in stock and another 1000 in manufacturing. I suspect this will be the last of them, but I'll check back. This is over a year's worth of supply.
Several customers use the JS1-IC consistently but we've moved some of them to the Propeller. This is your best alternative. Come on over!
I'll be back with more information.
Sincerely,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken Gracey
Parallax Inc.
Follow me at http://twitter.com/ParallaxKen for some insider news.
Solve all my problems (and most of the world's!) and provide (compatibile) Java on the Propeller.
The real problem is the library of Java I, and others have for the Javelin - that is the big benefit of Java.· I have piles of code for Basic Stamps which·I accept is write once/use once.· Decent Java can be reused.
Anyway, thanks for the great products.
Greg
I totally support Greg's comments.
Java allow to re-use code and components. I use my Javelin to control my solar panels, my water tanks heaters, my cheese aging room temperature, and many other things. But I wrote only about 50% of the code. Everything else is coming from the libs we are sharing.
So I agree with Greg. The Javelin is a great product. Maybe is also the Propeller, but I don't really want to code back in Basic since I saw how Java can help.
Maybe having a way to code in Java on the Propeller will be very good?
But so far, I will check the Javelin stock and order one when there will be only few remaining, just in case I break mine... don't want to have to re-code all my home automation...
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't click on this.....
Use the Propeller icon!!
You had better not start ANOTHER PropII thread.
I imagine most of the objects you need for the Propeller are already written. Consider what you could do with a VGA and TV, too!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken Gracey
Parallax Inc.
Follow me at http://twitter.com/ParallaxKen for some insider news.
Hopefully my final comments on this issue:
One of the reasons IBM mainframes and Windows (despite their many shortcomings) are still around is that they maintained backward compatibility.
Athough the siren call to come across to the dark(er) side (=Propeller) is strong, one has to be realistic. Java will be around for a long time. Javelins are on the way out. Who knows how long Propeller/Spin will thrive? It is quite a specialist product with a unique language and in this format will probably never be a "mass market" or significant educational/hobby product.
But Java on the Propeller, from single-threaded bottom-end chips to multi-threaded Java on multiple cogs, with an upgrade path as the hardware develops - a worthwhile proposition! And the multi-cog/multi-threaded configuration gives Parallax a unique position in the market (which is something I am arguing against as a user!!!).
By the way Ken, VGA and TV are on my PC - smaller embedded systems that I work with don't have such exotic requirements. Maybe our market views are diverging.
I know that the Propeller is a great product. Maybe just not the right product for me.
Greg
·
However this Propeller thread might be worth a read:
·
http://forums.parallax.com/showthread.php?p=784478
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike
Thanks for posting that...I was just about to say, with all the emulation of other languages and even processors our customers have been doing with the Propeller, I figured someone would eventually tackle Java. Seems that is exactly the case. So GregS, while there is no current plan to develop Java for the Propeller, it seems you can bet someone will make an effort out of it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
·
http://forums.parallax.com/showthread.php?p=703261
Mike's post shows a follow up thread that does improve on the jvm mainloop speed,
but as I understood, the IDE communication is omitted (and therefore also
the source level debugger).
Running on a spin stamp (as this has identical footprint as javelin).
I managed to download new javelin programs via the SOUT and SIN pins.
just like on the javelin.
Three major problems:
Execution speed turned out 15x slower than javelin (Interpreted SPIN interpreting java bytecodes).
Memory, only 16KB ram for javelin program (javelin has 32KB ram)
Virtual Peripherals, the COG address space is too small to implement 6 VP's
in a decent way.
PropII may be better suited but that won't be available in DIP24 module like spin stamp.
regards peter
There would still be a RAM limitation on main RAM, but if you wrote the interpreter in PASM and used a COG to run it and launched each VP into a seperate COG, it would seem you'd be ahead of the game. Sadly I am not familiar enough with the Javelin firmware to know if this is feasible. But from a theoretical stand-point it seems sound. I know...theory and practice... [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
·
That effort does follow work that Peter and I both did in his celebrated JVM for Prop thread.
I invite Peter and others to help. The road is rough, and the solo effort is difficult.
Current Java performance is close to that of Spin. There are still issues I'm working through.
I plan to make the current VP package work (testing in progress), but I also plan to make it optional
over time. Allowing custom VPs instead of a fixed set to me is less wasteful. I'm also more interested
in using those resources to do things like creating GUI LCD displays, mouse/keyboard drivers etc....
Another item I want to try is fetching/running Java classes from SdCard and using the free Propeller
HUB memory for static data, object references, and stack. Currently, the only possible way to do this
is by compiling and running *real* Java. It is not clear whether this can be done.
I don't really care for using the Javelin IDE ... if you care about that, the COMM code can be added
back. I've ported most of it in one source tree.
The PASM code HUB space today is over-written with Java byte-code after the JVM engine is started
(allowing for some EEPROM tricks when necessary) the way Chris mentions.
The current implementation allows 20KB with a comfortable 2KB left over for the Spin stack.
--Steve
If I was a Java programmer I would be in the loop. Alas I am not. However, having written in many languages over the years I can see from an outside perspective how I might attempt to emulate a Javelin on the Propeller if I was so inclined. Of course, many things are easier said than done, especially when you're the sayer and not the doer. I tend to break things down into smaller more managable chunks. I would have implemented the Java runtime in a single COG in ASM if at all possible. The SPIN interpreter fits in there, so it stands to reason Java could too. VPs have an advantage when running as a background process so intuitively I would attempt to make them loadable into different cogs. I also agree limiting someone to a fixed set is constraining, but if these VPs were written to communicate with the java runtime from one cog to another then you could make any kind you want. At this point you'd still have one cog free for debugging purposes or some other use. Just my thoughts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
·
When I'm finished with what I have, I'll look into features/optimizations beyond my goals.
Meanwhile if you have ideas on contributing some kind of tangible support I'm all ears.
--Steve