Actually since I don't have any of your hardware, I was planning to use another RAM solution for the time being. I also have other projects to multi-task.
Any ram solution will work - all you need to modify is BSTART, BREAD, BWRITE.
Let me know if you have any questions, I'll be glad to help you port it to another ram type.
I have defines at the top for all the solutions I know of [noparse]:)[/noparse]
jazzed said...
Actually since I don't have any of your hardware, I was planning to use another RAM solution for the time being. I also have other projects to multi-task.
Here are some comparative Propeller JVM configuration performance results.
The first one fetches from EEPROM and uses a 2KB cache (the FIBO (0) result
is now correct).
Since EEPROM with cache is working so nice and we get about 32KB code/data
space, I think I'll keep this idea going forward (and save archives of HUB only
designs). The reason is at some point I should be able to make it work with a
much larger 64K+ EEPROM. When that is functional, Propeller JVM should be
able to support up to 32KB (up to 128KB or more) code and 14KB data/stack.
Thanks to Bill for inspiration. Some day I'll make this run vmcog and external RAM.
--Steve
1 COG JVM Result running from EEPROM with 2KB cache.
This design is limited to about 18KB code size and 14KB object/stack size.
1 COG JVM Result running from EEPROM without comparable cache.
Just for comparison[noparse]:)[/noparse] This uses a 16 byte read-ahead buffer that is
constantly over-written. Amazing what a direct-mapped cache can do.
I now have Propeller JVM running FiboTest from upper 32KB+ EEPROM with cache.
This opens many possibilities for Java usage with Propeller. How much? We'll see.
Now the JVM should be able to run Javelin Java byte-code program size > 32KB
with bigger EEPROM. The object/stack data space is a little less than 14KB.
Now FIBO(24) runs in under 9 seconds from EEPROM with 2KB cache.
I have some testing and most likely some debugging to do before a general release.
Look like you made many progress over my vacations [noparse];)[/noparse]
I have a couple of 24LC256. Is that what I need to test this new version? Also, you said that: "I don't have any of your hardware". Is there anything I can get to run this testing?
Just let me know if there is anything I can do/test/try/improve/scrap [noparse];)[/noparse]
With the EEPROM version, it's already faster than the original Javelin. Which mean we might be able to improve that even more with the Prop2....
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
jmspaggi said...
I have a couple of 24LC256. Is that what I need to test this new version? Also, you said that: "I don't have any of your hardware". Is there anything I can get to run this testing?
Just let me know if there is anything I can do/test/try/improve/scrap [noparse];)[/noparse]
Hi JM,
Sorry for the delay. Attached is a PropellerJVM that executes from upper EEPROM address $8000 (a second 24LC256 should work, but I've not tested that). Currently, this is all set up to run with Windows so some porting for Linux is required (does not work with Wine yet because the modified JavelinDirect application has dll problems). I'm looking at what it takes for Linux now, and will post a version later.
The build/load/run procedure on Windows assuming Propeller on COM8 is:
1. Unpack .zip file to a folder.
2. Look at properties.spin and make sure the definitions match your hardware.
3. Enter build src\FiboTest
4. Enter load COM8
5. Enter make COM8
6. Watch output on serial terminal program
While it is not possible to rebuild completely under linux now, you can download the current image to the upper EEPROM and run it using BST. To do that, load jvm/EEprog32Kplus.spin and F10, then load jvm/pjvm_demo.spin and F10.
Here is output from BST building the default FiboTest.
I will test that soon (probably this evening) and let you know.
Regarding the EEPROM operation. It's 32K, correct? So that mean we have 16K for the java code? Also, if I chain 8 EEPROMs, does it mean I will be able to have a 256K java code???
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
I will test that soon (probably this evening) and let you know.
Regarding the EEPROM operation. It's 32K, correct? So that mean we have 16K for the java code? Also, if I chain 8 EEPROMs, does it mean I will be able to have a 256K java code???
JM
Yes with some clarifications/caveats:
1. The first 32KB EEPROM will hold the pjvm_demo virtual machine.
2. The next 32KB EEPROM will hold the Javelin program byte-code.
3. Actual object/stack/variable space for Javelin programs is about 14KB.
4. I have to figure out a way to download Javelin programs > 32KB.
With your help which I greatly appreciate, we can ensure that all functionality is equivalent.
Bottom line?
PropellerJVM today provides twice the code space, pins, and performance at half the Javelin price
--Steve
I have rewire the original Propeller Pro. Demo board EEPROM to the prototyping area, and I have add another EEPROM at the next address. It's seems to be working fine since I re-pushed my tick demo in it and it's working fine.
Here is my feedback regarding the build.
First, I have modified the build.sh to look at jikes into the bin directory. Then I have copied Jike there.
Then I had to remove the target parameter which is not available on my jike version.
After that, seems that it's generating the jem file correctly!
When I try to load it with bst, I get: "PasmA0EEPROM - Object Position is negative! - This binary will not work - Report this please!
I tried with the JEM file wich is working for me with the old PVJM, and it's still not working.
Thanks for looking at this build. It's good to know you have a suitable solution for bigger EEPROM now.
The JEM file from the old PJVM will not work with this JVM, so don't bother with that.
The "Object Position is negative ..." error was fixed in BST/C. The recent bst and bstc.linux in PropellerJVM*/bin do not have this problem.
My plan is to use the most recent jikes compiler (requires -target ...) and I would much rather users get their own jikes compiler for their O/S. I expect the windows solution will be the first to break [noparse]:)[/noparse] Also there size (which does matter[noparse]:)[/noparse]. Windows jikes is 1MB. The latest jikes is 1.5MB. At some point, the .zip package will exceed 2MB and will not be sharable on the forum.
Also, please make sure the javelin linker your using is the one I provided in ./bin/jlink. The EEPROM solution will only work with this version of the javelin direct linker since it moves all byte-code references relative to 0x8000 start point.
I have some other tests to do, but in the mean time get the latest BST and/or use the scripts I provided and re-test.
Thanks a bunch.
--Steve
jmspaggi said...
Hi Steve,
I have rewire the original Propeller Pro. Demo board EEPROM to the prototyping area, and I have add another EEPROM at the next address. It's seems to be working fine since I re-pushed my tick demo in it and it's working fine.
Here is my feedback regarding the build.
First, I have modified the build.sh to look at jikes into the bin directory. Then I have copied Jike there.
Then I had to remove the target parameter which is not available on my jike version.
After that, seems that it's generating the jem file correctly!
When I try to load it with bst, I get: "PasmA0EEPROM - Object Position is negative! - This binary will not work - Report this please!
I tried with the JEM file wich is working for me with the old PVJM, and it's still not working.
Do you have a jikes version to share with me? I only found the one I have which is the 0.47.
Regarding BST, the version I'm using is the 19.4-pre12. I'm not able to find a recent one in BST site. Should I look somewhere else?
Regarding the linker, it's using the one you send in theb package.
But all of that seems to not be working [noparse];)[/noparse]
Let me explain. Here is what I did
phenom:/home/jmspaggi/Desktop/propeller/PropellerJVM-32K-EeCache# ./build.sh HelloWorld
Linking
phenom:/home/jmspaggi/Desktop/propeller/PropellerJVM-32K-EeCache# ./load.sh
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object EEprog32Kplus
Loading Object properties
Loading Object PasmEEPROM
Loading Object FullDuplexSingleton
Program size is 7492 longs
1 Constants folded
Compiled 638 Lines of Code in 0.027 Seconds
Timeout Failed at read 1
No Propeller detected on port /dev/ttyUSB0
phenom:/home/jmspaggi/Desktop/propeller/PropellerJVM-32K-EeCache# ./load.sh
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object EEprog32Kplus
Loading Object properties
Loading Object PasmEEPROM
Loading Object FullDuplexSingleton
Program size is 7492 longs
1 Constants folded
Compiled 638 Lines of Code in 0.027 Seconds
We found a Propeller Version 1
Propeller Load took 1.093 Seconds
phenom:/home/jmspaggi/Desktop/propeller/PropellerJVM-32K-EeCache#
So I'm expecting the HelloWord code to be on the propeller. But when I reset it, what I have is my previous application.
What you tried programs the loader as the boot image; please reverse that change.
You want the JVM to be the boot image which is an advantage of course and I tested already [noparse]:)[/noparse]
The make.sh loads the JVM to propeller RAM by default.
If you want to store JVM in EEPROM the make.sh needs to change.
# use -p2 to program eeprom and run
bin/bstc.linux -Oxcr -f -p2 -L ${PROPLIB_PATH} -d $1 ${JVM_PATH}/pjvm_demo
I'm looking at the stacked 24LC256 programming and am having issues. There should be no difference, but apparently there is. I'll debug and post a new EEprog32Kplus.spin if necessary. For the time being, it would be good to load the ./jvm/EEprog32Kplus.spin, F10 in BST, and watch the output. Also I've attached a bit of text from README.LINUX for you to consider.
This is the PropellerJVM README.
Build and download the Propeller JVM FiboTest application from the top level directory:
~/PropellerJVM$ ./build.sh FiboTest ' build the FiboTest javelin application
~/PropellerJVM$ ./load.sh /dev/ttyUSB0 ' make sure this finishes before doing make
~/PropellerJVM$ ./make.sh /dev/ttyUSB0 ' load the jvm to propeller ram to run program
The argument /dev/ttyUSB0 can be replaced with your dev name and number.
At some point we want to burn the JVM image into EEPROM so the make step is not necessary.
1. The 24C0124B parts I have work fine (added: so do the Propeller Protoboard's 24LC512).
2. The 24LC256 parts are much slower than I expected.
3. The stacked 24LC256 parts do not work for programming both JVM and bytecode - don't know why yet.
4. The stacked parts are "aliased" - that is address $8000 should select the second part but it does not.
I'm very sorry that this has not been so productive ... I should have known to test the stacked parts before suggesting you try it :-( I have other commitments today and tomorrow morning so I won't be looking at this again until at least tomorrow night.
No worries. It was quite easy to stack (I simply used jumper wires all over the board), and now we know we (you) have to see how to fix that [noparse];)[/noparse]
By the end of the week, I will have both the 24C0124B and the stacked 24LC256 so I will be able to test the 2 options. Also, I will see the difference in speed between the 2...
In the meantime, I will try to put my DS1620 intto the JVM.
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
No worries. It was quite easy to stack (I simply used jumper wires all over the board), and now we know we (you) have to see how to fix that [noparse];)[/noparse]
Hi JM,
I found a little time to make a solution for the stacked 32KB eeproms. Find attached files and put in your ./jvm directory. You will need to define EE32STACK in EEprog32Kplus.spin and PasmAOEEPROM.spin for the code to work. I left the define out because I think it's best to support 24LC512 and 24LC1024 chips only longer term.
I defined EE32STACK in the 2 files, but seems that it's still not working. Should I used A0 or A2 for the 2nd EEPROM? It tried with both without success.
Do I have missed something? Or is tehre anything else I should update? I will continue to try.
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
jmspaggi said...
Should I used A0 or A2 for the 2nd EEPROM?
On first 24LC256 device, A0 (pin 1) should be connected to ground. On second 24LC256 device, A0 (pin 1) should be connected to pin 8. All other pins (including pin 8) on second device should be connected the same way as the first 24LC256.
In the code fragment below from EEprog32Kplus.spin, you can set the readonly flag to dump the EEPROM contents. Also change the dump(loadfile_len,$8000) address to 0 or $8000 to see values from different devices. The end of the java bytecode will typically have 20 20 20 20 20 20. Set the verbose flag if you want to dump write/read as programming progresses (the read address will be different from the write address but the data should be the same).
dat verbose long 0
dat readonly long 1 ' set 1 to read, change back to 0 to program
pub main
sx.start(hw#UCRXP, hw#UCTXP, hw#UCMODE, hw#UCBAUD)
'waitcnt(clkfreq+cnt)
waitcnt(clkfreq*hw#UCWAIT/2+cnt)
ee.start(hw#BEESCLP,hw#BEESDAP)
if readonly
sx.str(string($d,$d,"Read from Next 32K EEPROM",$d))
sx.hex(loadfile_len,6)
dump(loadfile_len,$8000) ' change $8000 to $0 to dump contents of first device
repeat
This is all I can give you for now. I won't be available again today until evening.
--Steve
Also, I'm not really sure to undertstand what I should see/do... I'm not familiar with this 2 EEPROMs option.
Is it working for you with stacked EEPROMs?
Maybe I should wait for my 1024 to arrived (next week).
JM
Hi JM.
Yes it is working for me with stacked EEPROMs. You can wait for for the 1024's if you like, but I think it's best that we have some easy to use tools to help debug. The more EEPROM samples the better.
I was trying to get you to use the debug facilities of the EEprog32Kplus.spin file to dump some bytes. Try this procedure:
1) Program the pjvm_demo.spin to EEPROM using BST F11.
2) Set EEprog32Kplus.spin verbose to 0, readonly to 0, program with F10.
2.a) If you get this message (wait about a minute for verified), everything should work:
"Programming Next 32K EEPROM with 0xxxx Bytes ... verified. Operation Complete"
If it's still not working, either the EE32STACK was not defined (#define EE32STACK) or there is a timing issue.
2.b) If you get a message like this let me know:
"Programming Next 32K EEPROM with 00238A Bytes ...004C A4 23E4 FF
Verify Error.
Expected...
004C: A4 24 01 26 80 2C 83 51 80 B7 80 4B A2 C2 00 00
005C: 83 D4 23 90 83 51 00 04 00 00 98 4F 00 00 02 00
Received...0000004C
23E4: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
23F4: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF"
2.c) If you get a message like this press Y and wait for results like 2b/2c:
Data in EEPROM at address 0 and $8000 are identical.
It is possible that your EEPROM is only 32K.
Would you like to continue programming EEPROM?
3) If you get errors, do this for me:
3.a) Set EEprog32Kplus.spin to readonly and read address 0 with dump(loadfile_len,0) and program with F10
3.b) Send me the data at address 0000: ... Looking for the bytes at 0000: 00 B4 C4 04 (80_000_000MHz)
4.a) Set EEprog32Kplus.spin to readonly and read address 0 with dump(loadfile_len,$8000) and program with F10
4.b) Send me the data at address 8000: Look for the bytes at 0000: not 00 B4 C4 04 .
The bytes are most likely FF in all locations if the part has not been programmed.
Comments
VMCOG, as of v0.92, is now functional [noparse]:)[/noparse]
This could be used to make a JVM with (currently) 64KB of free memory with just two 23K256's... I am just sayin'... [noparse]:)[/noparse]
I'll look at what you have and see if I can get a demo running.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
It will be really interesting to compare Fibo() results with different working set sizes - not to mention the FlexMem version when that is ready...
I predict JVM with VMCOG will be significantly faster than running byte code from eeprom, but 2x-3x slower than running directly out of the hub.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Let me know if you have any questions, I'll be glad to help you port it to another ram type.
I have defines at the top for all the solutions I know of [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The first one fetches from EEPROM and uses a 2KB cache (the FIBO (0) result
is now correct).
Since EEPROM with cache is working so nice and we get about 32KB code/data
space, I think I'll keep this idea going forward (and save archives of HUB only
designs). The reason is at some point I should be able to make it work with a
much larger 64K+ EEPROM. When that is functional, Propeller JVM should be
able to support up to 32KB (up to 128KB or more) code and 14KB data/stack.
Thanks to Bill for inspiration. Some day I'll make this run vmcog and external RAM.
--Steve
1 COG JVM Result running from EEPROM with 2KB cache.
This design is limited to about 18KB code size and 14KB object/stack size.
1 COG JVM Result running from EEPROM with 1KB cache.
This design is limited to about 16KB code size and 16KB object/stack size.
1 COG JVM Result running from EEPROM without comparable cache.
Just for comparison[noparse]:)[/noparse] This uses a 16 byte read-ahead buffer that is
constantly over-written. Amazing what a direct-mapped cache can do.
1 COG JVM Result (running from HUB):
This design is limited to about 20KB code and object/stack size.
Original 3 COG JVM Result:
This design is limited to about 24KB code and object/stack size.
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Post Edited (jazzed) : 6/16/2010 2:47:26 PM GMT
This opens many possibilities for Java usage with Propeller. How much? We'll see.
Now the JVM should be able to run Javelin Java byte-code program size > 32KB
with bigger EEPROM. The object/stack data space is a little less than 14KB.
Now FIBO(24) runs in under 9 seconds from EEPROM with 2KB cache.
I have some testing and most likely some debugging to do before a general release.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Look like you made many progress over my vacations [noparse];)[/noparse]
I have a couple of 24LC256. Is that what I need to test this new version? Also, you said that: "I don't have any of your hardware". Is there anything I can get to run this testing?
Just let me know if there is anything I can do/test/try/improve/scrap [noparse];)[/noparse]
With the EEPROM version, it's already faster than the original Javelin. Which mean we might be able to improve that even more with the Prop2....
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
Sorry for the delay. Attached is a PropellerJVM that executes from upper EEPROM address $8000 (a second 24LC256 should work, but I've not tested that). Currently, this is all set up to run with Windows so some porting for Linux is required (does not work with Wine yet because the modified JavelinDirect application has dll problems). I'm looking at what it takes for Linux now, and will post a version later.
The build/load/run procedure on Windows assuming Propeller on COM8 is:
1. Unpack .zip file to a folder. 2. Look at properties.spin and make sure the definitions match your hardware. 3. Enter build src\FiboTest 4. Enter load COM8 5. Enter make COM8 6. Watch output on serial terminal program
While it is not possible to rebuild completely under linux now, you can download the current image to the upper EEPROM and run it using BST. To do that, load jvm/EEprog32Kplus.spin and F10, then load jvm/pjvm_demo.spin and F10.Here is output from BST building the default FiboTest.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I will test that soon (probably this evening) and let you know.
Regarding the EEPROM operation. It's 32K, correct? So that mean we have 16K for the java code? Also, if I chain 8 EEPROMs, does it mean I will be able to have a 256K java code???
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
1. The first 32KB EEPROM will hold the pjvm_demo virtual machine.
2. The next 32KB EEPROM will hold the Javelin program byte-code.
3. Actual object/stack/variable space for Javelin programs is about 14KB.
4. I have to figure out a way to download Javelin programs > 32KB.
With your help which I greatly appreciate, we can ensure that all functionality is equivalent.
Bottom line?
PropellerJVM today provides twice the code space, pins, and performance at half the Javelin price
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I have rewire the original Propeller Pro. Demo board EEPROM to the prototyping area, and I have add another EEPROM at the next address. It's seems to be working fine since I re-pushed my tick demo in it and it's working fine.
Here is my feedback regarding the build.
First, I have modified the build.sh to look at jikes into the bin directory. Then I have copied Jike there.
Then I had to remove the target parameter which is not available on my jike version.
After that, seems that it's generating the jem file correctly!
When I try to load it with bst, I get: "PasmA0EEPROM - Object Position is negative! - This binary will not work - Report this please!
I tried with the JEM file wich is working for me with the old PVJM, and it's still not working.
Any clue?
JM
Thanks for looking at this build. It's good to know you have a suitable solution for bigger EEPROM now.
The JEM file from the old PJVM will not work with this JVM, so don't bother with that.
The "Object Position is negative ..." error was fixed in BST/C. The recent bst and bstc.linux in PropellerJVM*/bin do not have this problem.
My plan is to use the most recent jikes compiler (requires -target ...) and I would much rather users get their own jikes compiler for their O/S. I expect the windows solution will be the first to break [noparse]:)[/noparse] Also there size (which does matter[noparse]:)[/noparse]. Windows jikes is 1MB. The latest jikes is 1.5MB. At some point, the .zip package will exceed 2MB and will not be sharable on the forum.
Also, please make sure the javelin linker your using is the one I provided in ./bin/jlink. The EEPROM solution will only work with this version of the javelin direct linker since it moves all byte-code references relative to 0x8000 start point.
I have some other tests to do, but in the mean time get the latest BST and/or use the scripts I provided and re-test.
Thanks a bunch.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Do you have a jikes version to share with me? I only found the one I have which is the 0.47.
Regarding BST, the version I'm using is the 19.4-pre12. I'm not able to find a recent one in BST site. Should I look somewhere else?
Regarding the linker, it's using the one you send in theb package.
But all of that seems to not be working [noparse];)[/noparse]
Let me explain. Here is what I did
So I'm expecting the HelloWord code to be on the propeller. But when I reset it, what I have is my previous application.
I tried with -p2 option with the same result.
Here is what I tried:
bin/bstc.linux -p2 -Oxcr -f -d /dev/ttyUSB0 -p0 -w2 -L . ${JVM_PATH}/EEprog32KplusI don't see any error message anywhere. So I don't really know what's going wrong.
JM
You want the JVM to be the boot image which is an advantage of course and I tested already [noparse]:)[/noparse]
The make.sh loads the JVM to propeller RAM by default.
If you want to store JVM in EEPROM the make.sh needs to change.
# use -p2 to program eeprom and run bin/bstc.linux -Oxcr -f -p2 -L ${PROPLIB_PATH} -d $1 ${JVM_PATH}/pjvm_demo▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
So I went back to the initial package you sent, and I changed my jikes by the one you just sent.
[code]
phenom:/home/jmspaggi/Desktop/propeller/PropellerJVM-32K-EeCache# ./build.sh HelloWorld
Linking
cp: impossible d'
I'm looking at the stacked 24LC256 programming and am having issues. There should be no difference, but apparently there is. I'll debug and post a new EEprog32Kplus.spin if necessary. For the time being, it would be good to load the ./jvm/EEprog32Kplus.spin, F10 in BST, and watch the output. Also I've attached a bit of text from README.LINUX for you to consider.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
For EEprog32Kplus, there is no output. Nothing is displayed in BST, and there is nothing in the console too.
I retried the steps above (build, load, make) and there is still no results.
Regarding the stacked EEPROMs, I changed A0. I looked at the datasheet, and maybe I should change A2 instead. So I will try and let you know.
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
Make took 2s when I changed A0, and it's taking 6s with A2.
But at the end it's still not working.
Do I have a way to validate if the data are inside the EEPROM? Like by switching the 2?
I ordered the 1024 EEPROM (A24C1024BPU) which should arrive on Friday.
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
Here's what I see:
1. The 24C0124B parts I have work fine (added: so do the Propeller Protoboard's 24LC512).
2. The 24LC256 parts are much slower than I expected.
3. The stacked 24LC256 parts do not work for programming both JVM and bytecode - don't know why yet.
4. The stacked parts are "aliased" - that is address $8000 should select the second part but it does not.
I'm very sorry that this has not been so productive ... I should have known to test the stacked parts before suggesting you try it :-( I have other commitments today and tomorrow morning so I won't be looking at this again until at least tomorrow night.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Post Edited (jazzed) : 7/28/2010 11:58:44 PM GMT
No worries. It was quite easy to stack (I simply used jumper wires all over the board), and now we know we (you) have to see how to fix that [noparse];)[/noparse]
By the end of the week, I will have both the 24C0124B and the stacked 24LC256 so I will be able to test the 2 options. Also, I will see the difference in speed between the 2...
In the meantime, I will try to put my DS1620 intto the JVM.
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
I found a little time to make a solution for the stacked 32KB eeproms. Find attached files and put in your ./jvm directory. You will need to define EE32STACK in EEprog32Kplus.spin and PasmAOEEPROM.spin for the code to work. I left the define out because I think it's best to support 24LC512 and 24LC1024 chips only longer term.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I defined EE32STACK in the 2 files, but seems that it's still not working. Should I used A0 or A2 for the 2nd EEPROM? It tried with both without success.
Do I have missed something? Or is tehre anything else I should update? I will continue to try.
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
In the code fragment below from EEprog32Kplus.spin, you can set the readonly flag to dump the EEPROM contents. Also change the dump(loadfile_len,$8000) address to 0 or $8000 to see values from different devices. The end of the java bytecode will typically have 20 20 20 20 20 20. Set the verbose flag if you want to dump write/read as programming progresses (the read address will be different from the write address but the data should be the same).
dat verbose long 0 dat readonly long 1 ' set 1 to read, change back to 0 to program pub main sx.start(hw#UCRXP, hw#UCTXP, hw#UCMODE, hw#UCBAUD) 'waitcnt(clkfreq+cnt) waitcnt(clkfreq*hw#UCWAIT/2+cnt) ee.start(hw#BEESCLP,hw#BEESDAP) if readonly sx.str(string($d,$d,"Read from Next 32K EEPROM",$d)) sx.hex(loadfile_len,6) dump(loadfile_len,$8000) ' change $8000 to $0 to dump contents of first device repeatThis is all I can give you for now. I won't be available again today until evening.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I tryed with no success [noparse]:([/noparse]
Sorry.
Also, I'm not really sure to undertstand what I should see/do... I'm not familiar with this 2 EEPROMs option.
Is it working for you with stacked EEPROMs?
Maybe I should wait for my 1024 to arrived (next week).
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
Yes it is working for me with stacked EEPROMs. You can wait for for the 1024's if you like, but I think it's best that we have some easy to use tools to help debug. The more EEPROM samples the better.
I was trying to get you to use the debug facilities of the EEprog32Kplus.spin file to dump some bytes. Try this procedure:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM