Ok, here are some test results.
Some of the results are somewhat imperfect, and others are clipped to save space.
All tests are done with garbage collection running. 20KB are free for user Java jem bytecode.
I'll post code later after some cleanup. Uart VP debug is up next.
Look like we will be able to have all Javelin packages working in Propeller soon...
I ordered my PPDB and some other toys yesterday, so I will be able to test all of that soon... Also, I'm already playing with pPropellerSim to learn Spin and PASM. I will run my own Fibo when I will received my prop and compare with your results [noparse];)[/noparse]
heater said...
I'm not really fussed, emulator, simulator, virtual machine who cares? Well except that no one would call the Java runtime system an emulator or simulator.
Interesting thoughts on the relative code sizes of LMM, Java Zog etc. Problem for me is that Zog was supposed to give us smaller executables than LMM due to it's byte code nature. That being the plus side of the trade off against its slower speed. I have yet to convince myself that it achieves that in practice.
I have not followed ZOG from its entirety, but if the C compiler generates Z80 code, it's unlikely to be as compact as it can be since it does not have > 8 bits capability and everything has to go through the accumulators.
ImageCraft: Zog does not use Z80 codes. It implements the 32 bit CPU architecture called ZPU as defined by ZyLin.
The ZPU is designed to be a very small processor in terms of logic blocks it requires to be implemented in an FPGA. As such it has no working registers (stack based) and all opcodes are byte wide.
I picked up on it for the Prop because ZyLin have made a ZPU backend for GCC. The ZPU virtual machine fits easily into a COG. The byte wide opcodes are a nice fit with our current byte wide external RAM buses.
Also, why just 4 VPs? Is there a way to have 7 like in the Javelin?
COGs mainly. One COG can host 2 VPs. Here's the current COG allocation:
0: Spin startup and other code.
1: FullDuplex Serial Console
2: JVM interpreter 1
3: JVM interpreter 2
4: JVM interpreter 3
5: VP 0 and 1
6: VP 2 and 3
7: JVM runner and garbage collector.
(COG 0 other code includes memory allocator, exception handler, and JNI simple native functions.)
Up to 4 more VPs can be added quickly with consequences: Replace the FullDuplexSerial console with the Spin SimpleSerial - this would allow for 2 more VPs, but the console would be limited to about 19200 Baud and free HUB space will decrease. Move the JVM runner to Spin and get rid of the garbage collector - this would allow another VP set, but overall performance would suffer by about 10x.
Longer term, the 3 COG JVM interpreter solution might be trimmed down using dispatch tables; it could become 2 COGs, but a 1 COG solution is unlikely. There would be advantages to a 1 COG JVM solution, but I'm not sure how much at this point because HUB memory available for Java byte-code will decrease.
Here is my current list of possible TODO in no strict order:
Maintenance: continue testing the current solution and fix bugs as they are identified.
Add a profile.spin file to allow setting clocks, VP count, (#defines for #ifdef logic), etc....
Try to trim the 3 COG JVM interpreter to fewer COGs.
Add #ifdef logic to allow removing Garbage Collection.
Add #ifdef logic to allow using SimpleSerial instead of FullDuplexSerial.
Add #ifdef logic to allow use Spin runner and Garbage Collection instead of PASM.
Add real exception handling that will handle try/catch/throw. Today the machine stops dead.
Provide a mechanism for specifying additional custom Propeller drivers via JNI.
Provide custom Propeller drivers to support QVGA LCD, and other devices.
Think about implementing a real Java Runtime Engine on Propeller.
Change JVM interpreter/runner to fetch byte-codes from external hardware via VMCOG.
Comments on this list are welcome. The "Add" items are easier than the rest. Trimming the 3 COG JVM is important but will take time.
Having a stable Javelin-like solution is more important than anything else. I'll do more testing with new Java code to see how far I can push the solution, but I need help from experienced Javelin users (jmspaggi and others) on the test front. Once we have something that works to Javelin expectations within the memory limit, we can post a release candidate to the Javelin forum for Beta testing and general use.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
jmspaggi said...
I just hope I bought all what is required to connect it to my computer.
What did you buy exactly? Which PPDB? With the right PPDB, Propeller, and Power Brick, you should be set for a while.
jmspaggi said...
Is the CPU object working fine on the Propeller? I mean, can I read pins ....
Last time I checked it is. Use PROP.java in the lib.zip to access more than 16 pins.
jmspaggi said...
use the UART to communicate with sensors, BlueTooth, etc.?
I've tested the Uarts up to 115200 in both directions.
jmspaggi said...
I think having a Propoeller JVM backward compatible with the Javelin will help a lot. But for that, I think we need to have 7 VPs... Which mean we have to free 2 additionnal cogs.
This is doable with consequences previously outlined. 8 VPs are possible.
jmspaggi said...
Is there a reason why a COG can only handle 2 VPs? Can't we push them to support 3 VPs?
In the current design there is not enough time per 8.68us tick to process more than 2 UART VP transactions. Other VPs have lots of time margin, but the way the RAM-Bank is setup there is no room left in the COG for more than 2 VPs. I've given some thought to reworking this, but at this point the return on time invested doesn't make sense for me. Reworking the VP code is just as hard as trimming the number of COGs used for the JVM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
My concern is more on the connection to the computer. Wll I need any "Parallax USB2SER" or stuff like that? I will have prefered a serial connection instead of an USB one, but I will take what they have.
Jazzed said...
Use PROP.java in the lib.zip to access more than 16 pins.
Ok., I will try to test this one also. But will not be able, of course, to test it on the Javelin...
Jazzed said...
In the current design there is not enough time per 8.68us tick...
Ok, I see... So in the version you posted, we have 4 VPs. Let's say 1 for Time, that give 3 UARTs. Should be enought for now.
Jazzed said...
the console would be limited to about 19200 Baud
In the Javelin, it's 28 800. I don't think 19 200 is a real issue.
Jazzed said...
and free HUB space will decrease.
How much do we have in the current version, compared to the Javelin, and how much are we going to lose with the SimpleSerial?
Your hardware should be fine ... I prefer the built-in USB serial port in some ways especially for speed. I would recommend a lower voltage power supply (7.5VDC is preferred), but 12VDC will do unless you are over concerned about the heat from the 5VDC regulator (just don't touch that). The 5VDC regulator will get hot and dissipate more power than necessary with a 12V adapter, but it is no big deal short term at least. The regulator stays cool with a 7.5V adapter.
jmspaggi said...
How much do we have in the current version, compared to the Javelin, and how much are we going to lose with the SimpleSerial?
Javelin has 32K for bytecode and other storage; Propeller has 20K left after JVM, etc.... SimpleSerial will cost just a little more than FulDuplexSerial (I'll get numbers later).
If I can get the JVM to run bytecode fetched from SD Card via VMCOG, performance will be less (unquantifiable at this point), but the Java bytecode image can be much larger depending on the amount of Propeller HUB memory used for object and stack references for the Java program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I'd suggest leaving the SD card for filesystem use, and adding 1..4 spi 23K256 sram chips. I am building some boards today, but I will continue working on VMCOG tonight. It is really close to working with 128 pages of 512 bytes. After that version is solid, I'll make a 128 pages of 1KB version, which will provide 128KB of memory to VM applications. To make significantly larger VM's, I'll have to put the TLB in the hub, or have very large pages.
jazzed said...
Your hardware should be fine ... I prefer the built-in USB serial port in some ways especially for speed. I would recommend a lower voltage power supply (7.5VDC is preferred), but 12VDC will do unless you are over concerned about the heat from the 5VDC regulator (just don't touch that). The 5VDC regulator will get hot and dissipate more power than necessary with a 12V adapter, but it is no big deal short term at least. The regulator stays cool with a 7.5V adapter.
jmspaggi said...
How much do we have in the current version, compared to the Javelin, and how much are we going to lose with the SimpleSerial?
Javelin has 32K for bytecode and other storage; Propeller has 20K left after JVM, etc.... SimpleSerial will cost just a little more than FulDuplexSerial (I'll get numbers later).
If I can get the JVM to run bytecode fetched from SD Card via VMCOG, performance will be less (unquantifiable at this point), but the Java bytecode image can be much larger depending on the amount of Propeller HUB memory used for object and stack references for the Java program.
Bill Henning said...
I'd suggest leaving the SD card for filesystem use ....
Good idea and I'm definitely interested in porting for your solution, but I would like to do this incrementally least common denominator first (Propeller/EEPROM, add SDCARD, add other memory, etc...). I should probably try to shrink the JVM first for various reasons before adding support for VMCOG. Do you have a time-line in mind? In any event, I have to branch my source tree.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Sounds good. Quite frankly, I am very much looking forward to trying the various solutions!
Timeline?
Best case: VMCOG will run by Friday with 64KB
Wost case: another 2-3 weeks, I am building a whole pile of boards for a customer right now.
Once it runs with 64KB it should only be a couple of days to make a 128KB version.
Regardless of its exact state, I will upload the latest version on Friday, even if it is not 100%
I am looking forward to running Java on both PropCade and Morpheus!
jazzed said...
Bill Henning said...
I'd suggest leaving the SD card for filesystem use ....
Good idea and I'm definitely interested in porting for your solution, but I would like to do this incrementally least common denominator first (Propeller/EEPROM, add SDCARD, add other memory, etc...). I should probably try to shrink the JVM first for various reasons before adding support for VMCOG. Do you have a time-line in mind? In any event, I have to branch my source tree.
I agree.
That should be a very good idea and I will be one of the firsts to test it.
BUT...
First we need a backward compatible version as simple as possible which do not need any external components. And then try to add it all the possible options.
If you added a Hydra compatible socket, and modified VMCOG to drive that card, yes - however note that I think it needs 12 pins (I could be wrong)
jmspaggi said...
I agree.
That should be a very good idea and I will be one of the firsts to test it.
BUT...
First we need a backward compatible version as simple as possible which do not need any external components. And then try to add it all the possible options.
Bill Henning said...
modified VMCOG to drive that card
I tooks me the 2 last weekd to make a Fibo in PASM, it will take me the rests of my life to do that [noparse];)[/noparse]
I'm better to test what other are doing than doing it myself.
JM
PS: I read barely all the links in your signature, they are all chinese for me, but that look awesome! I hope my Prop knowledge will grow quickly to use all of that.
@JM, I have one of those Hydra memory cards. The design is horribly cumbersome and was a complete waste of my money.
I've started working on compacting the JVM to one COG. Wish me luck. I'll add #ifdefs as the need arises.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
So I want to try Java in it now. I have downloaded all the files in the first post, but some are Window$ related. I'm using BST for Linux. Can I go without those files?
I saw many spin files in the pjvm zip. Which one should I push to the Propeller to start?
Hydra itself is fine ... and I blame it primarily for my Propeller obsession [noparse]:)[/noparse]
Since you are on Linux, you will have to change the make process a little.
You have JavelinDirect apparently, but you will need a Linux version of bstc for the make.sh file below
Find linux bstc at www.fnarfbargle.com/bst/bstc/
All archives have a _README_ file. The top file in the tree is the main file to build. In this case it's pjvm_demo.spin
#make.bat original
del *.class
jikes -classpath .;./lib %1.java
propdirect --path .;./lib --link %1
copy %1.jem jem.bin
rem del *.class
rem del *.jem
bstc -d %2 -p0 -f -ls -L"C:\Program Files\Parallax Inc\Propeller Tool v1.2.6" pjvm_demo
Congrats on getting Hello World running to the console! If that works, I think you're set.
On FiboTest.java, did you change the ScaledTimer16 parameters at startup as Peter pointed out?
I only posted one version I think and it has ...
public FiboTest() {
timer = new ScaledTimer16(400,200); //timeUnit = 1000usec = 1msec
}
but should have ...
public FiboTest() {
timer = new ScaledTimer16(400,100);
}
Assuming that's the issue, the numbers look like they will be right. Let me know.
Did you try your TickTock.java without the RTC device?
On the compressed JVM, I have a strategy, but it may be a little slower and the Java byte-code
space may be reduced some ... we'll see. There is always a trade-off somewhere though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
The 4hours was well invested I hope [noparse];)[/noparse] I will start to learn that 4-year old tools are not all 64b compatibles [noparse];)[/noparse]
I also tried an LCD screen using an Uart, but this is not working. I tried at 19200 with no results. I tried also to reduce to 2400 with no success.
Will be very useful to have it working because each time I want to reprogram the prop, I have to disconnect and reconnect BST consol [noparse]:([/noparse]
I also tried an LCD screen using an Uart, but this is not working. I tried at 19200 with no results. I tried also to reduce to 2400 with no success.
Will be very useful to have it working because each time I want to reprogram the prop, I have to disconnect and reconnect BST consol [noparse]:([/noparse]
JM
I tested the Uart stuff with 2 USB/Propeller PropPlugs connected to two serial terminal emulators. One to console and the other to P0,P1,P2 with ground pin near P0. A loopback test would be useful ... type a character and echo it back, etc....
Point me to your LCD uart code ... I can only assume it works on Javelin, but it would still help for me to see it.
Some things to check:·do not initialize·either TX/RX with flow control just in case there is a problem (I tested it long ago).
Try a different "invert" parameter when you initialize the device. RS232 inverts the logic sense of data to/from devices that have only one RS232 interface.
The Propeller pin-out logic levels are 0 to 3.3VDC. Do not subject any Propeller pin to voltages outside 0 to 3.3VDC (a series resistor can help for over 3.3VDC, but negative voltages are not allowed).
This disconnect/reconnect problem is I think the biggest "physical" annoyance for Propeller development and to be clear it is not just a BST issue (I've always wondered why this could not be coordinated in BST with its terminal though). There are ways to auto-connect, but they all require applications that know what to do.
I think your Propeller investments will pay off in various ways. I have something of a love/loathe relationship with it but I mostly enjoy it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Regarding the disconnect/reconnect, I think I will "simply" build my own Console, which push the file to the prop, and then reconnect. Then when I need to repush, simply press the righ button, and it disconnect, push, and reconnect...
I will try tomorrow with the DC16 for the UART
Also, something which is bugging me, it's the way the packages are handled [noparse];)[/noparse] I need to compile manually every single file I have. But Eclipse is also doing it, so I have often to re-do everything manually. I think I will have to build an Ant script, but I'm not familiar with that. And when you place the file in a package, jikes and javelindirect don't like it....
This is very intriguing and probably has something to do with the problem.
I would never, ever write it this way, so I have not tested it this way [noparse]:)[/noparse]
Maybe it's done to produce a delay?
public void write(char c)
{
lcdUart.start();
lcdUart.sendByte(c);
lcdUart.stop();
}
I'll look at this tomorrow. Meanwhile, you can try removing the start/stop calls?
BTW: This is very good! This is what independent testing catches ....
During the initial software test cycle, the number of bugs reported should be peak.
The more problems uncovered early on, the easier a general release should go.
Thanks!
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
This disconnect/reconnect problem is I think the biggest "physical" annoyance for Propeller development and to be clear it is not just a BST issue (I've always wondered why this could not be coordinated in BST with its terminal though). There are ways to auto-connect, but they all require applications that know what to do.
Que?
The bst terminal will automatically disconnect while the propeller is being loaded and immediately reconnect afterwards, in the background with no user intervention. Is it not working for you?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
The bst terminal will automatically disconnect while the propeller is being loaded and immediately reconnect afterwards, in the background with no user intervention. Is it not working for you?
I didn't realize you already did this! Thanks for pointing it out.
My actual BST use has been limited because I like BSTC so much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Ok, here are some test results.
Some of the results are somewhat imperfect, and others are clipped to save space.
All tests are done with garbage collection running. 20KB are free for user Java jem bytecode.
I'll post code later after some cleanup. Uart VP debug is up next.
FiboTest.java -------------------------------------------------------------------------------------- FIBO(00) = 1 ( 7 ticks) ( 4 ms) FIBO(01) = 1 ( 7 ticks) ( 4 ms) FIBO(02) = 1 ( 7 ticks) ( 4 ms) FIBO(03) = 2 ( 8 ticks) ( 4 ms) FIBO(04) = 3 ( 8 ticks) ( 4 ms) FIBO(05) = 5 ( 8 ticks) ( 4 ms) FIBO(06) = 8 ( 9 ticks) ( 5 ms) FIBO(07) = 13 ( 10 ticks) ( 6 ms) FIBO(08) = 21 ( 12 ticks) ( 7 ms) FIBO(09) = 34 ( 14 ticks) ( 8 ms) FIBO(10) = 55 ( 20 ticks) ( 11 ms) FIBO(11) = 89 ( 27 ticks) ( 15 ms) FIBO(12) = 144 ( 37 ticks) ( 21 ms) FIBO(13) = 233 ( 61 ticks) ( 34 ms) FIBO(14) = 377 ( 93 ticks) ( 52 ms) FIBO(15) = 610 ( 147 ticks) ( 82 ms) FIBO(16) = 987 ( 234 ticks) ( 130 ms) FIBO(17) = 1597 ( 375 ticks) ( 208 ms) FIBO(18) = 2584 ( 601 ticks) ( 334 ms) FIBO(19) = 4181 ( 969 ticks) ( 538 ms) FIBO(20) = 6765 ( 1564 ticks) ( 869 ms) FIBO(21) = 10946 ( 2527 ticks) ( 1404 ms) FIBO(22) = 17711 ( 4084 ticks) ( 2269 ms) FIBO(23) = 28657 ( 6600 ticks) ( 3666 ms) FIBO(24) = 46368 (10677 ticks) ( 5931 ms) ScaledTimer16_test.java -------------------------------------------------------------------------------------- time = 556 ticks = 1001 delay=11, passed=10, passedMS=6 delay=22, passed=12, passedMS=7 delay=33, passed=13, passedMS=7 delay=44, passed=15, passedMS=8 delay=55, passed=17, passedMS=9 delay=66, passed=19, passedMS=11 delay=77, passed=20, passedMS=11 delay=88, passed=22, passedMS=12 delay=99, passed=24, passedMS=13 delay=110, passed=25, passedMS=14 delay=121, passed=24, passedMS=13 delay=132, passed=29, passedMS=16 delay=143, passed=30, passedMS=17 delay=154, passed=33, passedMS=18 delay=165, passed=34, passedMS=19 delay=176, passed=33, passedMS=18 delay=187, passed=38, passedMS=21 delay=198, passed=39, passedMS=22 delay=209, passed=38, passedMS=21 delay=220, passed=43, passedMS=24 delay=231, passed=45, passedMS=25 UnsignedIntMath_test.java -------------------------------------------------------------------------------------- Test program for UnsignedIntMath class test 123/678 = 11889/65536 = 1814/10000 results 11889/65536 1814/10000 test -123/678 = 11889/65536 = 1814/10000 results 11889/65536 1814/10000 test 0x0123/0x0678 = 11516/65536 = 1757/10000 results 11516/65536 1757/10000 test 0x9123/0x0678 = 22 + 28612/65536 = 22 + 4365/10000 results 22 28610/65536 4366/10000 test 0x0123/0xABCD = 433/65536 = 66/10000 results 432/65536 66/10000 test 0x9123/0xABCD = 55364/65536 = 8447/10000 results 55364/65536 8448/10000 test 100/10000 655/65536 = 100/10000 results 655/65536 20 usqrt(x) 3 1.73 4 2.00 7 2.64 12 3.46 19 4.36 28 5.29 39 6.24 52 7.21 67 8.18 84 9.16 103 10.15 124 11.13 147 12.12 172 13.11 199 14.11 228 15.10 259 16.09 292 17.09 327 18.08 364 19.08 403 20.07 444 21.07 IntegerMath_test.java -------------------------------------------------------------------------------------- sin(45) = 70 sin(135) = 70 sin(225) = -70 sin(315) = -70 cos(45) = 70 cos(135) = -70 cos(225) = -70 cos(315) = 70 atan2(45,45) = 45 atan2(45,-45) = 135 atan2(-45,-45) = 225 atan2(-45,45) = 315 Program completed TickTock.java -------------------------------------------------------------------------------------- 1821 ticks. 1015 ms. tick 1813 ticks. 1011 ms. tock 1820 ticks. 1015 ms. tick 1815 ticks. 1013 ms. tock 1819 ticks. 1014 ms. tick 1815 ticks. 1012 ms. tock 1822 ticks. 1014 ms. tick 1817 ticks. 1011 ms. tock 1817 ticks. 1013 ms. tick 1821 ticks. 1015 ms. tock 1824 ticks. 1017 ms. tick 1820 ticks. 1015 ms. tock 1815 ticks. 1012 ms. tick 1819 ticks. 1014 ms. tock 1810 ticks. 1009 ms. tick 1817 ticks. 1013 ms. tock 1821 ticks. 1015 ms. tick 1813 ticks. 1013 ms. tock 1820 ticks. 1015 ms. tick 1816 ticks. 1013 ms. tock 1819 ticks. 1014 ms. tick 1815 ticks. 1012 ms. tock▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Look like we will be able to have all Javelin packages working in Propeller soon...
I ordered my PPDB and some other toys yesterday, so I will be able to test all of that soon... Also, I'm already playing with pPropellerSim to learn Spin and PASM. I will run my own Fibo when I will received my prop and compare with your results [noparse];)[/noparse]
JM
I have not followed ZOG from its entirety, but if the C compiler generates Z80 code, it's unlikely to be as compact as it can be since it does not have > 8 bits capability and everything has to go through the accumulators.
The ZPU is designed to be a very small processor in terms of logic blocks it requires to be implemented in an FPGA. As such it has no working registers (stack based) and all opcodes are byte wide.
I picked up on it for the Prop because ZyLin have made a ZPU backend for GCC. The ZPU virtual machine fits easily into a COG. The byte wide opcodes are a nice fit with our current byte wide external RAM buses.
opensource.zylin.com/zpu.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
All files necessary for running Javelin Propeller Java should be in the first post.
Let me know if something is missing.
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I should receive my Propeller and the PPDB this week. I will test as soon as I get it.
Also, why just 4 VPs? Is there a way to have 7 like in the Javelin?
JM
- 0: Spin startup and other code.
- 1: FullDuplex Serial Console
- 2: JVM interpreter 1
- 3: JVM interpreter 2
- 4: JVM interpreter 3
- 5: VP 0 and 1
- 6: VP 2 and 3
- 7: JVM runner and garbage collector.
(COG 0 other code includes memory allocator, exception handler, and JNI simple native functions.)Up to 4 more VPs can be added quickly with consequences: Replace the FullDuplexSerial console with the Spin SimpleSerial - this would allow for 2 more VPs, but the console would be limited to about 19200 Baud and free HUB space will decrease. Move the JVM runner to Spin and get rid of the garbage collector - this would allow another VP set, but overall performance would suffer by about 10x.
Longer term, the 3 COG JVM interpreter solution might be trimmed down using dispatch tables; it could become 2 COGs, but a 1 COG solution is unlikely. There would be advantages to a 1 COG JVM solution, but I'm not sure how much at this point because HUB memory available for Java byte-code will decrease.
Here is my current list of possible TODO in no strict order:
- Maintenance: continue testing the current solution and fix bugs as they are identified.
- Add a profile.spin file to allow setting clocks, VP count, (#defines for #ifdef logic), etc....
- Try to trim the 3 COG JVM interpreter to fewer COGs.
- Add #ifdef logic to allow removing Garbage Collection.
- Add #ifdef logic to allow using SimpleSerial instead of FullDuplexSerial.
- Add #ifdef logic to allow use Spin runner and Garbage Collection instead of PASM.
- Add real exception handling that will handle try/catch/throw. Today the machine stops dead.
- Provide a mechanism for specifying additional custom Propeller drivers via JNI.
- Provide custom Propeller drivers to support QVGA LCD, and other devices.
- Think about implementing a real Java Runtime Engine on Propeller.
- Change JVM interpreter/runner to fetch byte-codes from external hardware via VMCOG.
Comments on this list are welcome. The "Add" items are easier than the rest. Trimming the 3 COG JVM is important but will take time.Having a stable Javelin-like solution is more important than anything else. I'll do more testing with new Java code to see how far I can push the solution, but I need help from experienced Javelin users (jmspaggi and others) on the test front. Once we have something that works to Javelin expectations within the memory limit, we can post a release candidate to the Javelin forum for Beta testing and general use.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
All of that is quite amazing!
I understand all the configurations you proposed above, and ifdef might be a good option to allow jvm customization.
My Propeller is somewhere between SAN FRANCISCO and Montr
Last time I checked it is. Use PROP.java in the lib.zip to access more than 16 pins.
I've tested the Uarts up to 115200 in both directions.
This is doable with consequences previously outlined. 8 VPs are possible.
In the current design there is not enough time per 8.68us tick to process more than 2 UART VP transactions. Other VPs have lots of time margin, but the way the RAM-Bank is setup there is no room left in the COG for more than 2 VPs. I've given some thought to reworking this, but at this point the return on time invested doesn't make sense for me. Reworking the VP code is just as hard as trimming the number of COGs used for the JVM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
www.parallax.com/Store/Microcontrollers/PropellerDevelopmentBoards/tabid/514/CategoryID/73/List/0/SortField/0/Level/a/ProductID/515/Default.aspx
www.parallax.com/Store/Accessories/PowerSupplies/tabid/165/CategoryID/39/List/0/SortField/0/Level/a/ProductID/75/Default.aspx
www.parallax.com/Store/Accessories/CablesConverters/tabid/166/CategoryID/40/List/0/SortField/0/catpageindex/2/Level/a/ProductID/33/Default.aspx
3 prop and some switchs for my Javelin.
My concern is more on the connection to the computer. Wll I need any "Parallax USB2SER" or stuff like that? I will have prefered a serial connection instead of an USB one, but I will take what they have.
Ok., I will try to test this one also. But will not be able, of course, to test it on the Javelin...
Ok, I see... So in the version you posted, we have 4 VPs. Let's say 1 for Time, that give 3 UARTs. Should be enought for now.
In the Javelin, it's 28 800. I don't think 19 200 is a real issue.
How much do we have in the current version, compared to the Javelin, and how much are we going to lose with the SimpleSerial?
JM
Javelin has 32K for bytecode and other storage; Propeller has 20K left after JVM, etc.... SimpleSerial will cost just a little more than FulDuplexSerial (I'll get numbers later).
If I can get the JVM to run bytecode fetched from SD Card via VMCOG, performance will be less (unquantifiable at this point), but the Java bytecode image can be much larger depending on the amount of Propeller HUB memory used for object and stack references for the Java program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Timeline?
Best case: VMCOG will run by Friday with 64KB
Wost case: another 2-3 weeks, I am building a whole pile of boards for a customer right now.
Once it runs with 64KB it should only be a couple of days to make a 128KB version.
Regardless of its exact state, I will upload the latest version on Friday, even if it is not 100%
I am looking forward to running Java on both PropCade and Morpheus!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
That should be a very good idea and I will be one of the firsts to test it.
BUT...
First we need a backward compatible version as simple as possible which do not need any external components. And then try to add it all the possible options.
My opinion.
Update: Can this be used as the sram? www.parallax.com/StoreSearchResults/tabid/768/txtSearch/sram/List/0/SortField/4/ProductID/444/Default.aspx
JM
Message Edité (jmspaggi) : 4/19/2010 8:26:17 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I tooks me the 2 last weekd to make a Fibo in PASM, it will take me the rests of my life to do that [noparse];)[/noparse]
I'm better to test what other are doing than doing it myself.
JM
PS: I read barely all the links in your signature, they are all chinese for me, but that look awesome! I hope my Prop knowledge will grow quickly to use all of that.
I've started working on compacting the JVM to one COG. Wish me luck. I'll add #ifdefs as the need arises.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I just got my propeller and it's up and running.
So I want to try Java in it now. I have downloaded all the files in the first post, but some are Window$ related. I'm using BST for Linux. Can I go without those files?
I saw many spin files in the pjvm zip. Which one should I push to the Propeller to start?
Thanks,
JM
Hydra itself is fine ... and I blame it primarily for my Propeller obsession [noparse]:)[/noparse]
Since you are on Linux, you will have to change the make process a little.
You have JavelinDirect apparently, but you will need a Linux version of bstc for the make.sh file below
Find linux bstc at www.fnarfbargle.com/bst/bstc/
All archives have a _README_ file. The top file in the tree is the main file to build. In this case it's pjvm_demo.spin
Use this make,sh file instead ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I built my new PC few weeks ago, and did not tried this tool since. And I just figured it was not working anymore.
The issue? It's not working in Linux 64bits [noparse]:([/noparse] So I will have to continue to use my VirtualBox to build the files...
Anyway, my hello world is in! And is working!
So I will start to push stuff in it. Will start with the DS1302 since it's on the board. Then will be DS1620. UART will come next...
So far, the only think I figured is that Prop is sending #00 to the console. Not sure the Javelin is doing. We will have to ask Peter.
Also, I hope you will compress the 3 cogs in 1. That will be awesome!
JM
This is the result of Java Fibo The timing is wrong I think. It seems to be half of what it should be... I used the code you send few posts above.
JM
Congrats on getting Hello World running to the console! If that works, I think you're set.
On FiboTest.java, did you change the ScaledTimer16 parameters at startup as Peter pointed out?
I only posted one version I think and it has ...
public FiboTest() { timer = new ScaledTimer16(400,200); //timeUnit = 1000usec = 1msec }but should have ...
public FiboTest() { timer = new ScaledTimer16(400,100); }Assuming that's the issue, the numbers look like they will be right. Let me know.
Did you try your TickTock.java without the RTC device?
On the compressed JVM, I have a strategy, but it may be a little slower and the Java byte-code
space may be reduced some ... we'll see. There is always a trade-off somewhere though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Here are some results from my tests.
You was right for the ScaledTimer16 parameter.
TickTock results:
I also tried an LCD screen using an Uart, but this is not working. I tried at 19200 with no results. I tried also to reduce to 2400 with no success.
Will be very useful to have it working because each time I want to reprogram the prop, I have to disconnect and reconnect BST consol [noparse]:([/noparse]
JM
[noparse][[/noparse]/code]
Point me to your LCD uart code ... I can only assume it works on Javelin, but it would still help for me to see it.
Some things to check:·do not initialize·either TX/RX with flow control just in case there is a problem (I tested it long ago).
Try a different "invert" parameter when you initialize the device. RS232 inverts the logic sense of data to/from devices that have only one RS232 interface.
The Propeller pin-out logic levels are 0 to 3.3VDC. Do not subject any Propeller pin to voltages outside 0 to 3.3VDC (a series resistor can help for over 3.3VDC, but negative voltages are not allowed).
This disconnect/reconnect problem is I think the biggest "physical" annoyance for Propeller development and to be clear it is not just a BST issue (I've always wondered why this could not be coordinated in BST with its terminal though). There are ways to auto-connect, but they all require applications that know what to do.
I think your Propeller investments will pay off in various ways. I have something of a love/loathe relationship with it but I mostly enjoy it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
This is the Serial Screen I'm using: www.parallax.com/Store/Accessories/Displays/tabid/159/CategoryID/34/List/0/SortField/0/Level/a/ProductID/51/Default.aspx
It needs to be powered with 5V. I hope that it's not the issue, else I will be in big troubles. All what I have is using UART and is power with 5V (DC16, screen, keyboards, memory extention, etc.)
Regarding the disconnect/reconnect, I think I will "simply" build my own Console, which push the file to the prop, and then reconnect. Then when I need to repush, simply press the righ button, and it disconnect, push, and reconnect...
I will try tomorrow with the DC16 for the UART
Also, something which is bugging me, it's the way the packages are handled [noparse];)[/noparse] I need to compile manually every single file I have. But Eclipse is also doing it, so I have often to re-do everything manually. I think I will have to build an Ant script, but I'm not familiar with that. And when you place the file in a package, jikes and javelindirect don't like it....
JM
I would never, ever write it this way, so I have not tested it this way [noparse]:)[/noparse]
Maybe it's done to produce a delay?
public void write(char c) { lcdUart.start(); lcdUart.sendByte(c); lcdUart.stop(); }I'll look at this tomorrow. Meanwhile, you can try removing the start/stop calls?
BTW: This is very good! This is what independent testing catches ....
During the initial software test cycle, the number of bugs reported should be peak.
The more problems uncovered early on, the easier a general release should go.
Thanks!
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Que?
The bst terminal will automatically disconnect while the propeller is being loaded and immediately reconnect afterwards, in the background with no user intervention. Is it not working for you?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
My actual BST use has been limited because I like BSTC so much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.