@Thomas, Sounds like you have some good progress.
I started looking at VP's in PASM and have at least the Timer working although the native code read/write interface doesn't seem to "get it" -- maybe Peter's example will bring some light. I'll continue following Peter's basic roadmap and the requirements previously discussed, but this is "teeth cutting" for me and my time is limited, so I can't define a delivery timeframe. I have a "curve" to condend with and certain "issues" to work out before I post anything. Wish I could be more timely and direct. Thanks to Insonix their PASD debugger [noparse]:)[/noparse]
@Hippy, if you re-appear that would be great, but I'm not holding my breath. Hello ???? echo, echo, echo.
@Peter, I now remember other reasons my Javelin collected dust for years. The JIDE debugger doesn't have a "step out" button. That would be quite easy to implement from a JVM point of view given FP accounting. Why don't you do us all a favor and add that button? I also find the, "gee, didn't i hit the step button already?" factor intolerable ... I can see why it's done like that, but a step in source should step, not creep[noparse]:)[/noparse] If there's anything that can be done, great otherwise <sigh text="oh well"/>
@Jazzed,
Stepout might not be so simple. I can not just drop a frame. Currently the step over
puts a breakpoint after an invoke and then just runs.
So what you can do is put a breakpoint on the next source line while stepping into
the current line. The moment you want to step out just hit the run button.
I will have to go through the IDE sources to see if the current debugger structure
allows another 'virtual' breakpoint, without changing the structure setup, as this
is also·used during the linkage process to build the debugger tables.
@ Jazzed, Peter, Kaio, all : Still here, still paying attention. You guys have done astoundingly well and as I had nothing useful I felt I could contribute during recent times I was happy to step back and let those doing well simply get on with it.
Thomas (Kaio) seems to have taken the PASM version of the interpreter on which is great and also has a Java background as well. I'll be happy to throw my input into that as it develops but again I'm largely happy to let Thomas progress without interference. I'm not sure I'm well fitted to PASM coding the Virtual Peripherals as I don't have any Javelin experience.
Development drifted out of my comfort zone of knowledge and experience but with the progress done it's hopefully now mainly a learning curve for me. I've got to get up to date with the latest software and IDE but should be back into the thick of things quite soon and more able to be a useful hand.
deSilva mentioned the need for non-Java, non-Javelin people to have some quick-start guide to using what we have and I'd agree there. Christopher (CJO) seems interested in creating that. Maybe doing that on the Wiki or Whiteboard would be useful so it's not just one person the weight falls on ?
Once I'm up and running, I'll be very happy to contribute what I can. As I'm picking-up from where others would be starting from I'll keep notes on doing that which should hopefully help others get on the PropJavelin bandwagon.
Finally : You guys do realise you've gone from virtually nothing to what we have today in just five weeks ? That is a phenomenal achievement. Well done.
Attached is an updated jvmVirtualPeripheral.
Methods are still coded in spin, but this time I passed the
address of vpRambank to the isr routine which is the main pasm entry.
I believe this is the way to pass variables to an assembly routine.
Apart from the uart routines (at the file end) most code is simular
to SX code, although coded in spin. Only the isr and the private
methods need to be converted to pasm, as these run in a seperate cog.
So the code now never references another file, except jvmData for some
constants.
This should make it easier to convert to pasm.
Also note that now 255 VP types are supported because the vectorbyte
is entirely dedicated to the VP type, with value 0 indicating an empty VP slot.
Two updates: jvmData has added methods eeWriteByte and eeReadByte,
these perform the stamp\core\EEPROM.java read() and write() methods.
jvmNative has updated methods readPin, writePin, readPort, writePort,
nap, setInput, setOutput, eeRead, eeWrite·and writeObject.
The last one writes a 16bit value into an implied 16 bits register
that is stored using Big Endian.
The others are updated to support 32 pins. For this I wrote a java file
PROP.java that holds the·pin and port constants for use with the propeller.
That file should be placed in ...\lib\stamp\core folder.
Peter
When I input text to TerminalTest2. For example, if I was to enter cmd or flash, the message window will echo ccmmdd or ffllaasshh, invalid command.
I am a using Prop RPM proto board, wilh USB adapter, hence no flow control. All other output in normal.
Peter
IDE 2.0.3 and other files per your post of 2/26/2008 @ 3.19
IDE was downloaded from Parallax link which you provided. JMV, Javelin and TerminalTest2 zips from you post.
Something I forgot, since you have a fresh v2.0.3 installation.
Rename the file Terminal.java in folder ...\lib\stamp\core
to Terminal_org.java
and install the attached version.
Let me know if that resolves the issue.
Having a little trouble here. Added some CPU write/read verify code
to the tick tocker (private copy) because I suspected reads not working.
Not sure about writes, but reads don't work ... adding some debug code
in the JVM shows that the address/value that should be read are
generally correct, but java never gets the right value.
I just realized my example was horrible. The address would never work.
Address 0xE0 is invalid.
The only valid addresses are listed under writeRegister and readRegister in jvmData.
These addresses are all used in core java files, the readRegister and writeRegister
should not be used directly in applications.
I have given the Timer VP in spincode in jvmVirtualPeripheral.
hippy said...
... deSilva mentioned the need for non-Java, non-Javelin people to have some quick-start guide to using what we have and I'd agree there.
I was especially referring to people WITH some JAVA experience (and implicitely to people WITHOUT ANY Propeller experience)
Explaining JAVA is a lot. The great thing with C and JAVA is that you get it around all corners and you have only to explain the shortcommings ...ahem: "differences"
Missing "interface" is no good at all. Simple inheritance is not as useful as generally thought, and interfaces have always been JAVA's excuse for missing multiple inheritance....
I just have no time.... If you give me a piece of SPIN and ask me to convert it I shall do.. but nothing else before Easter...
@DeSilva,
We can use abstract classes. I have written many javelin classes and found that is all
that is really needed. You can write an abstract class where just the byte read and write
methods are abstract while the other methods in that class implement something useful,
like a filesystem. All that is then needed to support a filesystem via I2C or Uarts
is just extending the class with the proper read and write methods.
Peter Verkaik said...
Address 0xE0 is invalid.
The only valid addresses are listed under writeRegister and readRegister in jvmData.
These addresses are all used in core java files, the readRegister and writeRegister
should not be used directly in applications.
I have given the Timer VP in spincode in jvmVirtualPeripheral.
regards peter
Ya, sure I tried 0x80 also. I suggest you to produce a working example with CPU read/write.
Can someone run this benchmark perhaps on a JAVELINStamp?
PUB spinFibo(n)
if n>2
return spinFibo(n-1)+ spinFibo(n-2)
else
return 1
fibo(29) needed:
On the propeller: 26 sec with SPIN as given
1.8 sec with PHP on my mid-range Windows Notebook
800 ms with a transcript to PASM ( as posted in the "Assembly for Beginners" Sticky )
30 ms with a very efficient FORTH Implementation on same Notebook
15 ms PureBasic compiled to 16kB EXE-file on same Notebook.
I should expect a JAVA PASM VM (although most likely needing 2 COGs!) running similarly fast as SPIN (there is no reason why not). However it might be interesting to learn how the JAVELIN behaves... The reference should be the 26 secs it takes SPIN on the Propeller.
Note: Don't try fibo(29) with the current JAVA implementation, it could take 1 hour !
@DeSilva or any pasm expert,
I attached the latest jvmVirtualPeripheral file.
I added a spin method start from which the pasm code needs to be started
in a seperate cog. All PRI methods are to be converted to pasm. All PUB methods
are initialization routines to set VP parameters.
The shared datastructure among the VP's is vpRambank byte 0[noparse][[/noparse]MAX_NUM_VPS*16]
declared in jvmData file. I understand the parameter passed to a cognew must be
a long. We can redefine to vpRambank long 0[noparse][[/noparse]MAX_NUM_VPS*4].
For best pasm optimization: Is it better to define vpRambank long 0[noparse][[/noparse]MAX_NUM_VPS*16]
so we reserve a long for each register of which only the lower 8 bits are used?
If you could convert only the PRI methods·isr, vpTimer, vpAdc, vpDac and vpPwm
then we would have a beginning. These methods are all very small.
The VP code for uarts can be ignored for now as this need to be revisited because of
the buffering involved.
I noticed all the VP·routines that access pins, use something like: · pin := >| byte[noparse][[/noparse]vpRambank + vpBank + nmDacPin] · case byte[noparse][[/noparse]vpRambank + vpBank + nmDacPort] ··· 1: pin += 8 ··· 2: pin += 16 ··· 3: pin += 24
I could change the writeRegister method in jvmData to convert the port[noparse]:p[/noparse]in format
into a binary pin number as used by the prop. That way the VP code does not need
to convert the port[noparse]:p[/noparse]in format. This saves cycles in the pasm code but it will increase
the writeRegister code. Is it wise to change the writeRegister method?
Edit: I just realized changing writeRegister won't do as it is unknown from where
it is called (Uart, PWM etc). But I can do the conversion of the port[noparse]:p[/noparse]in format
in the VP initialization routines for the different VP's.
regards peter
Post Edited (Peter Verkaik) : 3/1/2008 10:33:16 AM GMT
If anyone wants to add anything there they are welcome to. I started from a 'well defined point' which isn't the latest version and will add "bringing things up to date" as necessary.
Well, I finally realized that because of at least one bad Javelin java source
design feature (bug) in Timer.java, the virtual peripherals will almost never work
until the JVM is entirely done in asm. Fixing the bug·makes·real-time TickTock work.
The why follows immediately, possible solutions are listed afterwards:
Problem Description:
1. Timer.timeout(hi,lo) ... looks for an exact match in the timer value
rather than an inequality condition that most real-time systems would use.
It is not clear if such programming mistakes are made elsewhere, but
given this example from the "primary" author of the java source, it is likely.
2. For Timer.timout(hi,lo) to have any chance of working in it's current state,
Timer.latch would be responsible for ticking the timer. Well, since it takes
more than 100ms for a bytecode to execute with the .spin JVM, it is unlikely
that the desired result would be obtained in less than 20x the timeout.
3. The further affects of this problem are that since the java code is
apparently managing the VP's closely, devices such as Uart TX/RX will·most
likely be non-functional until the JVM is entirely rewritten in asm.
Possible Solutions:
1. Have JVM fully implemented in PASM ... hopefully this will allow the
current design time enough to function properly. Desired "apparent" solution.
2. Fix time sensitive bugs in Timer.java and other places and have a competent
real-time solution. Fixing java bugs is undesirable for compatibility, but possible.
In any event, I want whatever Peter feels is the right thing to happen because
he is obviously committed to the Javelin product and will have to lay in this bed.
> diff -c12 ~Timer.java Timer.java
*** ~Timer.java Sat Mar 1 13:21:34 2008
--- Timer.java Sat Mar 1 13:45:47 2008
***************
*** 131,154 ****
--- 131,162 ----
// Get the current timer value.
int l = tickLo();
int h = tickHi();
// Calculate the elapsed time since last mark.
if (startHi != 0 || startLo != 0) {
h = h - startHi;
l = l - startLo;
if (!CPU.carry())
h--;
}
+ // Check if elapsed time >= timeout value.
+ int currentTime = (h << 8) | l;
+ int previousTime = (hi << 8) | lo;
+
+ if (currentTime >= previousTime) {
+ return true;
+ }
+
// Check if elapsed time == timeout value.
if (h == hi && l == lo)
return true;
Now that you mention it,
there was a bug in Timer.java that I once fixed.
The constant 119 was used which must be 115.
I am not sure if this 119 error still exists in v2.0.3 IDE distribution·.
(just search Timer.java for 119)
I attached my version that also has an added passedMS() method
that returns the passed milliseconds since the last call to mark().
Just rename your current Timer.java to Timer_org.java and
install the attached version.
I agree that the JVM must be in pasm, as must the VP code, to
make it all work using 8.68 usec ticks.
We must wait for·Thomas what he comes up with.
I tried the Tick Tock example a few days ago and could not get it to work.
I guessed the issue might be associated with VP code and the need to write this in PASM. I have undated my Timer.java file and will test again
when the VP code has been ported to PASM. I noticed that you have provided code to implement pins 16..31 on Prop. I have updated files to reflect these updates but still have the same compiler error if Iwhen try to read or write to these pins. Is this still, work in progress?
I have run other some simple code of my own, keeping away from anything in VP and have had no problems.
Thats fine, just lurking and learning, its good to see under the cover whilst you are both working on Javelin Prop.
If it doesn't work I assume its still Work in Progress.
@Jazzed,
The distribution of v2.0.3 is the latest and most up to date official release.
I have however modified some of the core classes to provide me more methods
or better implemented methods. I attached my core classes that can replace
the v2.0.3 classes.
In case of Timer, I wrote a class ScaledTimer16 that also uses the TickHi() and TickLo()
methods of Timer but then selects only 16bits to create a 16bits timer.
This is the timer I mostly use because you can define the timeunits.
@Ron,
Anything in this thread is a work in progress. The moment we have a fully working
jvm we will create a new thread for a first beta release.
If you install (some of) the modified core classes, make sure to rename the original
files·first, before installing the modified ones.
regards peter
Post Edited (Peter Verkaik) : 3/2/2008 8:40:55 AM GMT
Comments
I started looking at VP's in PASM and have at least the Timer working although the native code read/write interface doesn't seem to "get it" -- maybe Peter's example will bring some light. I'll continue following Peter's basic roadmap and the requirements previously discussed, but this is "teeth cutting" for me and my time is limited, so I can't define a delivery timeframe. I have a "curve" to condend with and certain "issues" to work out before I post anything. Wish I could be more timely and direct. Thanks to Insonix their PASD debugger [noparse]:)[/noparse]
@Hippy, if you re-appear that would be great, but I'm not holding my breath. Hello ???? echo, echo, echo.
@Peter, I now remember other reasons my Javelin collected dust for years. The JIDE debugger doesn't have a "step out" button. That would be quite easy to implement from a JVM point of view given FP accounting. Why don't you do us all a favor and add that button? I also find the, "gee, didn't i hit the step button already?" factor intolerable ... I can see why it's done like that, but a step in source should step, not creep[noparse]:)[/noparse] If there's anything that can be done, great otherwise <sigh text="oh well"/>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
Stepout might not be so simple. I can not just drop a frame. Currently the step over
puts a breakpoint after an invoke and then just runs.
So what you can do is put a breakpoint on the next source line while stepping into
the current line. The moment you want to step out just hit the run button.
I will have to go through the IDE sources to see if the current debugger structure
allows another 'virtual' breakpoint, without changing the structure setup, as this
is also·used during the linkage process to build the debugger tables.
regards peter
Thomas (Kaio) seems to have taken the PASM version of the interpreter on which is great and also has a Java background as well. I'll be happy to throw my input into that as it develops but again I'm largely happy to let Thomas progress without interference. I'm not sure I'm well fitted to PASM coding the Virtual Peripherals as I don't have any Javelin experience.
Development drifted out of my comfort zone of knowledge and experience but with the progress done it's hopefully now mainly a learning curve for me. I've got to get up to date with the latest software and IDE but should be back into the thick of things quite soon and more able to be a useful hand.
deSilva mentioned the need for non-Java, non-Javelin people to have some quick-start guide to using what we have and I'd agree there. Christopher (CJO) seems interested in creating that. Maybe doing that on the Wiki or Whiteboard would be useful so it's not just one person the weight falls on ?
Once I'm up and running, I'll be very happy to contribute what I can. As I'm picking-up from where others would be starting from I'll keep notes on doing that which should hopefully help others get on the PropJavelin bandwagon.
Finally : You guys do realise you've gone from virtually nothing to what we have today in just five weeks ? That is a phenomenal achievement. Well done.
Methods are still coded in spin, but this time I passed the
address of vpRambank to the isr routine which is the main pasm entry.
I believe this is the way to pass variables to an assembly routine.
Apart from the uart routines (at the file end) most code is simular
to SX code, although coded in spin. Only the isr and the private
methods need to be converted to pasm, as these run in a seperate cog.
So the code now never references another file, except jvmData for some
constants.
This should make it easier to convert to pasm.
Also note that now 255 VP types are supported because the vectorbyte
is entirely dedicated to the VP type, with value 0 indicating an empty VP slot.
regards peter
these perform the stamp\core\EEPROM.java read() and write() methods.
jvmNative has updated methods readPin, writePin, readPort, writePort,
nap, setInput, setOutput, eeRead, eeWrite·and writeObject.
The last one writes a 16bit value into an implied 16 bits register
that is stored using Big Endian.
The others are updated to support 32 pins. For this I wrote a java file
PROP.java that holds the·pin and port constants for use with the propeller.
That file should be placed in ...\lib\stamp\core folder.
regards peter
··
When I input text to TerminalTest2. For example, if I was to enter cmd or flash, the message window will echo ccmmdd or ffllaasshh, invalid command.
I am a using Prop RPM proto board, wilh USB adapter, hence no flow control. All other output in normal.
Any thoughts.
Ron
regards peter
IDE 2.0.3 and other files per your post of 2/26/2008 @ 3.19
IDE was downloaded from Parallax link which you provided. JMV, Javelin and TerminalTest2 zips from you post.
Menu help...I am looking
regards Ron
IDE Version 2.2.0 Build 4
Ron
Rename the file Terminal.java in folder ...\lib\stamp\core
to Terminal_org.java
and install the attached version.
Let me know if that resolves the issue.
regards peter
to the tick tocker (private copy) because I suspected reads not working.
Not sure about writes, but reads don't work ... adding some debug code
in the JVM shows that the address/value that should be read are
generally correct, but java never gets the right value.
I just realized my example was horrible. The address would never work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
Post Edited (jazzed) : 2/29/2008 9:24:17 PM GMT
The only valid addresses are listed under writeRegister and readRegister in jvmData.
These addresses are all used in core java files, the readRegister and writeRegister
should not be used directly in applications.
I have given the Timer VP in spincode in jvmVirtualPeripheral.
regards peter
Explaining JAVA is a lot. The great thing with C and JAVA is that you get it around all corners and you have only to explain the shortcommings ...ahem: "differences"
Missing "interface" is no good at all. Simple inheritance is not as useful as generally thought, and interfaces have always been JAVA's excuse for missing multiple inheritance....
I just have no time.... If you give me a piece of SPIN and ask me to convert it I shall do.. but nothing else before Easter...
We can use abstract classes. I have written many javelin classes and found that is all
that is really needed. You can write an abstract class where just the byte read and write
methods are abstract while the other methods in that class implement something useful,
like a filesystem. All that is then needed to support a filesystem via I2C or Uarts
is just extending the class with the proper read and write methods.
regards peter
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
Can someone run this benchmark perhaps on a JAVELINStamp?
PUB spinFibo(n) if n>2 return spinFibo(n-1)+ spinFibo(n-2) else return 1fibo(29) needed:
On the propeller: 26 sec with SPIN as given
1.8 sec with PHP on my mid-range Windows Notebook
800 ms with a transcript to PASM ( as posted in the "Assembly for Beginners" Sticky
30 ms with a very efficient FORTH Implementation on same Notebook
15 ms PureBasic compiled to 16kB EXE-file on same Notebook.
I should expect a JAVA PASM VM (although most likely needing 2 COGs!) running similarly fast as SPIN (there is no reason why not). However it might be interesting to learn how the JAVELIN behaves... The reference should be the 26 secs it takes SPIN on the Propeller.
Note: Don't try fibo(29) with the current JAVA implementation, it could take 1 hour !
Attached is my register test program.
Works as expected.
regards peter
On a javelin, spinFibo(16) takes 419 milliseconds.
spinFibo(24) takes 19.243 seconds
regards peter
Post Edited (Peter Verkaik) : 2/29/2008 10:13:13 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
New version Terminal.java fixed problem.
Will try some of my own stuff now.
Regards
Ron
I attached the latest jvmVirtualPeripheral file.
I added a spin method start from which the pasm code needs to be started
in a seperate cog. All PRI methods are to be converted to pasm. All PUB methods
are initialization routines to set VP parameters.
The shared datastructure among the VP's is vpRambank byte 0[noparse][[/noparse]MAX_NUM_VPS*16]
declared in jvmData file. I understand the parameter passed to a cognew must be
a long. We can redefine to vpRambank long 0[noparse][[/noparse]MAX_NUM_VPS*4].
For best pasm optimization: Is it better to define vpRambank long 0[noparse][[/noparse]MAX_NUM_VPS*16]
so we reserve a long for each register of which only the lower 8 bits are used?
If you could convert only the PRI methods·isr, vpTimer, vpAdc, vpDac and vpPwm
then we would have a beginning. These methods are all very small.
The VP code for uarts can be ignored for now as this need to be revisited because of
the buffering involved.
I noticed all the VP·routines that access pins, use something like:
· pin := >| byte[noparse][[/noparse]vpRambank + vpBank + nmDacPin]
· case byte[noparse][[/noparse]vpRambank + vpBank + nmDacPort]
··· 1: pin += 8
··· 2: pin += 16
··· 3: pin += 24
I could change the writeRegister method in jvmData to convert the port[noparse]:p[/noparse]in format
into a binary pin number as used by the prop. That way the VP code does not need
to convert the port[noparse]:p[/noparse]in format. This saves cycles in the pasm code but it will increase
the writeRegister code. Is it wise to change the writeRegister method?
Edit: I just realized changing writeRegister won't do as it is unknown from where
it is called (Uart, PWM etc). But I can do the conversion of the port[noparse]:p[/noparse]in format
in the VP initialization routines for the different VP's.
regards peter
Post Edited (Peter Verkaik) : 3/1/2008 10:33:16 AM GMT
propeller.wikispaces.com/Fast-Track+for+PropJavelin
If anyone wants to add anything there they are welcome to. I started from a 'well defined point' which isn't the latest version and will add "bringing things up to date" as necessary.
design feature (bug) in Timer.java, the virtual peripherals will almost never work
until the JVM is entirely done in asm. Fixing the bug·makes·real-time TickTock work.
The why follows immediately, possible solutions are listed afterwards:
Problem Description:
1. Timer.timeout(hi,lo) ... looks for an exact match in the timer value
rather than an inequality condition that most real-time systems would use.
It is not clear if such programming mistakes are made elsewhere, but
given this example from the "primary" author of the java source, it is likely.
2. For Timer.timout(hi,lo) to have any chance of working in it's current state,
Timer.latch would be responsible for ticking the timer. Well, since it takes
more than 100ms for a bytecode to execute with the .spin JVM, it is unlikely
that the desired result would be obtained in less than 20x the timeout.
3. The further affects of this problem are that since the java code is
apparently managing the VP's closely, devices such as Uart TX/RX will·most
likely be non-functional until the JVM is entirely rewritten in asm.
Possible Solutions:
1. Have JVM fully implemented in PASM ... hopefully this will allow the
current design time enough to function properly. Desired "apparent" solution.
2. Fix time sensitive bugs in Timer.java and other places and have a competent
real-time solution. Fixing java bugs is undesirable for compatibility, but possible.
In any event, I want whatever Peter feels is the right thing to happen because
he is obviously committed to the Javelin product and will have to lay in this bed.
> diff -c12 ~Timer.java Timer.java *** ~Timer.java Sat Mar 1 13:21:34 2008 --- Timer.java Sat Mar 1 13:45:47 2008 *************** *** 131,154 **** --- 131,162 ---- // Get the current timer value. int l = tickLo(); int h = tickHi(); // Calculate the elapsed time since last mark. if (startHi != 0 || startLo != 0) { h = h - startHi; l = l - startLo; if (!CPU.carry()) h--; } + // Check if elapsed time >= timeout value. + int currentTime = (h << 8) | l; + int previousTime = (hi << 8) | lo; + + if (currentTime >= previousTime) { + return true; + } + // Check if elapsed time == timeout value. if (h == hi && l == lo) return true;▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
there was a bug in Timer.java that I once fixed.
The constant 119 was used which must be 115.
I am not sure if this 119 error still exists in v2.0.3 IDE distribution·.
(just search Timer.java for 119)
I attached my version that also has an added passedMS() method
that returns the passed milliseconds since the last call to mark().
Just rename your current Timer.java to Timer_org.java and
install the attached version.
I agree that the JVM must be in pasm, as must the VP code, to
make it all work using 8.68 usec ticks.
We must wait for·Thomas what he comes up with.
regards peter
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
I tried the Tick Tock example a few days ago and could not get it to work.
I guessed the issue might be associated with VP code and the need to write this in PASM. I have undated my Timer.java file and will test again
when the VP code has been ported to PASM. I noticed that you have provided code to implement pins 16..31 on Prop. I have updated files to reflect these updates but still have the same compiler error if Iwhen try to read or write to these pins. Is this still, work in progress?
I have run other some simple code of my own, keeping away from anything in VP and have had no problems.
Ron
Thats fine, just lurking and learning, its good to see under the cover whilst you are both working on Javelin Prop.
If it doesn't work I assume its still Work in Progress.
Ron
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
The distribution of v2.0.3 is the latest and most up to date official release.
I have however modified some of the core classes to provide me more methods
or better implemented methods. I attached my core classes that can replace
the v2.0.3 classes.
In case of Timer, I wrote a class ScaledTimer16 that also uses the TickHi() and TickLo()
methods of Timer but then selects only 16bits to create a 16bits timer.
This is the timer I mostly use because you can define the timeunits.
@Ron,
Anything in this thread is a work in progress. The moment we have a fully working
jvm we will create a new thread for a first beta release.
If you install (some of) the modified core classes, make sure to rename the original
files·first, before installing the modified ones.
regards peter
Post Edited (Peter Verkaik) : 3/2/2008 8:40:55 AM GMT