I just figured it's comming from my initilisation blocks which was not included above.
for (int i = 0; i < PROP.pins.length - 1; i++)
{
PROP.setOutput(PROP.pins[i]);
PROP.writePin(PROP.pins[i], false);
}
PROP.setInput(PROP.pin23);
PROP.setInput(PROP.pin24);
PROP.setInput(PROP.pin25);
PROP.setInput(PROP.pin26);
[/i][/i]
Can you please test attached code?
In loop 1, it's working, in loop 2, it's not working anymore.
The for loop is initialisation pin0 to pin30 so it should not impact pin31. I tried with -2 instead of -1 with the same result. But if I comment the for loop, then it's working fine...
Ok, it works fine except for an exception at the end which is fixed by having "while(true);" added to the end of main.
Added: If I'm not mistaken, your for loop sets pins 0 to 30 to output with 0 on outputs. Total pins length is 32. If you write pin30 high instead, you would see no output after the loop.
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.
Jazzed: "So now the 1 COG code is actually faster at under 5.8s for FIBO(24)."
Interesting. Following my failed multi-prop Z80 attempt and I believe a multi-prop 6502 attempt elsewhere the Javelin must be the third of fourth VM/emulator project to arrive at this same result.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
[noparse]:([/noparse] Sorry was my mistake [noparse]:([/noparse] I had a wire between pin 26 and pin 31. So when I was configuring pin26, this was affecting Pin31 and not working anymore.
I removed the damned wire, and it's now working fine.
Regarding the speed, I want to say that it's faster and reducing the blinking, but it's difficult to mesure. So I will rely on your results [noparse];)[/noparse]
So far, my 2 projects for my props are:
- fully-configurable LED Digits driver (in Java, Spin and if I can PASM)
- A javelin 30 I/O extender. (Java, and again, Spin and PASM if I can)
Also, I will rebuild my test suite with the DS1302, the LCD screen, the LCD Digits, Fibo, and some other stuff to do some testing.
@heater: Are you saying that since the JVM is running on one single COG, it will be able to have a multi-prop JVM to increase the spead?
I'm just making the observation that there have now been a number of attempts to implement emulations/virtual machines using multiple COGs.
In each case the reason for using multiple COGs was simply that a single COG does not have the space to get all the raw PASM code in. Not necessarily to get speed.
In each case it has turned out quicker to use some other technique to get the code into a single COG than to spread the code over many COGS.
So for example using overlays or LMM to get more code into one COG is quicker than spreading that same code over two COGs.
Please, excuse any mis-statements about Javelin I may be making now, I have not looked into the code. Does it use LMM? Does it use overlays?
Seems that the overheads of sharing state information and synchronizing COGS is greater that using overlays or LMM in general. This is a somewhat surprising result and points to the idea that the Prop needs more help in inter-COG communications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ok I see. And I agree. Will be nice to have a way to share data between cogs whitout going to the hub... Maybe for Prop2? [noparse];)[/noparse] I don't think we need a big memory area for that, but at least, we need some...
Regarding the Javelin architecture, I'm don't know. Peter is the expert and might be able to resply to that question...
I'm so glad you have a working Serial Loopback configuration now.
Did you happen to try your SerialLCD with the Java library I provided?
I've attached a demo that should have much better timer performance.
@heater,
The JVM uses overlay to fetch the byte code implementation routines.
I decided against LMM in this case because 1) the number of instructions
to load is deterministic, 2) LMM kernel services take up precious COG
space, and 3) LMM jumps are clumsy. There are many COG stubs that
overlay routines use to speed up operations such as push/pop etc....
For the overlay loader, I chose not to use the decrementing load mainly
because it is a PITA to configure and use. The solution I'm using now
has a very short instruction decode and load setup. Most byte codes are
implemented in less than 5 instructions with in-COG helper routines, so
I use the unrolled fetch method to grab 4 instructions at a time before
missing a hub window. The one disadvantage of my implementation is
that NOP in the overlay code must be non-zero since I use 0 to terminate
the load; however, this allows for not keeping a length table.
One performance enhancement between the current JVM COG and the
last ones is that the JVM actively reads byte codes rather than "spinning"
for another COG to send a byte-code as done in a multi-COG design.
This also lets the core solution (without VP, etc...) use only 2 COGs.
Surprisingly, the JVM footprint is small enough to allow 19KB user code.
This could have never been achieved using LMM C.
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.
LCD screen is now working perfectly. I have "12345678901234567890" displayed, and no other extra char.
DS1302 is no more working. I will look at the wiring first [noparse];)[/noparse]
Also, the Uart loopback is working, but I have an extra char that I'm not expecting.
The tick/tock is working fine, but sometime I receive 500ms instead of 1000ms.
Well, that's a great relief! [noparse]:)[/noparse]
Looks like I don't have to spend $40 now on a SerialLCD I won't use.
The timer thing is a big PITA!
Like I said, it should work better but it's not perfect. The math for
CPU.carry in Timer.java works otherwise other math stuff like
divide_u32_u16 and others would fail. I'm experimenting with timer
values now to see if there is something I don't expect happening.
Don't know what to suggest about those extra characters except
that all main()'s should end with a "while(true);" loop. Funny how
the output looks kind of like a keyboard line ... qwertyuiop
I'll retest some DS1302 code on my PPDB today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 @JM, I got it.
The timer calculation is bad if pnative.nm_core_Timer_latch lower word is $0000.
To prevent this, one fix is to add increment latchCount after getting it and before the writeVpRegister calls:
PUB nm_core_Timer_latch(bank) | latchedCount
'/**
' * Latch the 32bit counter into the latch registers.
' * Called by Timer.tickLo()
' *
' * @param bank The allocated area for the Timer registers.
' */
latchedCount := vp.ReadTimer(getDev(bank))
ifnot (latchedCount & $ffff) ' if lower word of latchedCount is 0, increment it
latchedCount++
writeVPregister(bank + def#nmLatchTimer1, (latchedCount >> 0) & $ff)
writeVPregister(bank + def#nmLatchTimer2, (latchedCount >> 8) & $ff)
writeVPregister(bank + def#nmLatchTimer3, (latchedCount >> 16) & $ff)
writeVPregister(bank + def#nmLatchTimer4, (latchedCount >> 24) & $ff)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 saved you $40, so can you send me $20? [noparse];)[/noparse]
The ds1302 is also working for me with the halt call.
Also, I don't know where this qwertyuiop is coming from [noparse];)[/noparse]
What's the next thing you will work on? Will it be the JNI option? Might be usefull. Because I will be happy to have a dedicated cog to run my main loop. It's VERY small, just 5 lines in Java.
I just implemented the fix in pnative. It's running since 2000 seconds. I will let it run for another 20000. I will let you know the result.
@JM, I'll find a non-currency method of paying you back [noparse]:)[/noparse]
jmspaggi said...
What's the next thing you will work on? Will it be the JNI option? Might be usefull. Because I will be happy to have a dedicated cog to run my main loop. It's VERY small, just 5 lines in Java.
JNI is in the near future. JNI provides an interface to methods written in the CPU's Native language ... Spin/PASM in this case. JNI is important based on the kinds of peripherals I'm used to having on Propeller so it's a high priority item. Any JNI beyond the current set should be pluggable and not part of the standard Javelin code base.
I'm thinking to update the top post package first. Does the current directory structure suit you? There is another alternative where we can put the JVM code in the same directory as JavaBuild and that might be easier to maintain and use for new users.
I also want to turn garbage collection GC back on. Last I checked it was broken. GC can periodically get in the way of Java performance but not VPs or other code running in non-java COGs. Without GC, memory can be a bigger issue in this 19KB user byte-code JVM. There is some debugging that would have been impossible without it for example.
One thing worth doing is building the Javelin BOE-BOT. That would be a good hardware interface test.
I won't have much time the rest of the week, but will get back in it next hard and heavy week.
jmspaggi said...
Regarding the timing fix, in which file should I update that?
That goes in pnative.spin ... just add the missing lines to the method (CTRL-F to search method name).
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.
JNI is in the near future. JNI provides an interface to methods written in the CPU's Native language ... Spin/PASM in this case. JNI is important based on the kinds of peripherals I'm used to having on Propeller so it's a high priority item. Any JNI beyond the current set should be pluggable and not part of the standard Javelin code base.
Yep, I'm fine with that. I will build my own Spin or PASM object and try to interface it with the Java code though JNI when this will be available.
jazzed said...
I'm thinking to update the top post package first. Does the current directory structure suit you? There is another alternative where we can put the JVM code in the same directory as JavaBuild and that might be easier to maintain and use for new users.
I have not really test the packaging itself since I'm using my own build script and so on. I will try to start back from scratch and see how it's going with the last packages I have.
jazzed said...
I also want to turn garbage collection GC back on. Last I checked it was broken. GC can periodically get in the way of Java performance but not VPs or other code running in non-java COGs. Without GC, memory can be a bigger issue in this 19KB user byte-code JVM. There is some debugging that would have been impossible without it for example.
I prefer whitout the GC. I'm managing the memory carrefully everywhere, so a GC wil just weast few cycles. BUT... If we can activate/de-activate it with IFDEF, then it will be perfect.
Just le me know if you activate it, and I will test it actively.
jazzed said...
I won't have much time the rest of the week, but will get back in it next hard and heavy week.
That will give me some time to help on pPropellerSim and to learn Spin.
jazzed said...
That goes in pnative.spin ... just add the missing lines to the method (CTRL-F to search method name).
I found it and tried it. So far it's running for 4600 secs now with no issue. I will keep it running, maybe all night long, and report the result.
Something went wrong over the night for the tick/tock... Good luck. I will keep it running and let you know. I already got the issue yesterday evening and tought it was because I touched something (wire, etc.). So I re-ran it. And got the same issue this morning.
jmspaggi said...
Yep, I agree. Kind of defect we don't like to troubleshot...
I tried up to -24400 with no other issue. I just restarted it. I will let you know in 17610 seconds [noparse];)[/noparse] Which is about 5h.
Since yesterday I'm loging all propeller outputs in a file, so I can also go back and see the past results.
JM
Logging (script or stdout piping) is a wonderful advantage of unix/linux [noparse]:)[/noparse]
Ah, so the counter wrapped. I'm not sure if it is significant though.
I stopped my test after the wrap.
Could you do me a favor and restart with the following timer latch method?
It will print 3 to 4 counter lines between tick-tocks.
PUB nm_core_Timer_latch(bank) | latchedCount
'/**
' * Latch the 32bit counter into the latch registers.
' * Called by Timer.tickLo()
' *
' * @param bank The allocated area for the Timer registers.
' */
latchedCount := vp.ReadTimer(getDev(bank))
if (savedCount & $ffff_8000) <> (latchedCount & $ffff_8000)
sio.hex(latchedCount,8)
sio.tx(" ")
sio.hex(savedCount,8)
sio.tx(" ")
sio.str(string("diff = "))
sio.dec(latchedCount-savedCount)
sio.tx($d)
savedCount := latchedCount
ifnot (latchedCount & $ffff)
latchedCount++
writeVPregister(bank + def#nmLatchTimer1, (latchedCount >> 0) & $ff)
writeVPregister(bank + def#nmLatchTimer2, (latchedCount >> 8) & $ff)
writeVPregister(bank + def#nmLatchTimer3, (latchedCount >> 16) & $ff)
writeVPregister(bank + def#nmLatchTimer4, (latchedCount >> 24) & $ff)
var long savedCount
BTW, I verified the Spin based GC works with some modifications and
it is enclosed with #ifdef GCOLLECT. I don't have any room for GC in
the JVM COG. Guess I'll have to use a different data-structure for heap
to improve performance ... the "heap" structure gives O(log N) searching.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 plan sometime to implement the Java2 VM. That will have long data type.
The Javelin "standard" does not use longs. I want to the current VM to run all the legacy Javelin code.
I very much appreciate your help in verifying compatibility with the Javelin by testing I2C.java.
Agreed, the GC is better done in a separate PASM COG. Since I already have that code, it will be easier to implement. Still, at some point I do want to improve heap efficiency; right now it is a chunk list allocator. I have to search for object references in stack, static, and heap areas ....
BTW, please say if you have a preference on directory structure for JavaBuild and JavaPropJVM.
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.
Ya I saw this in my office before I left today. At least it gives a clue.
So this is the first round ? I mean it didn't go past FFFFFFFF already right?
Does this happen on Javelin by any chance?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Same issue few hours later. Again, with the same kind of pattern. (0x800000000)
I did not get a chance to try with the Javelin yet because it's handling my water heaters and my solar pannels [noparse];)[/noparse] I will try next night.
Hi everyone,
Waiting for BradC to solve my RTS related problem, I made another temporary cable link with DTR signal and The link BST works !
@jazzed : Sadly, I2C.java don't work with The last version. It freezes at a certain point. I don't know why yet. Can you tell me where you use "shiftOut".
I can send to you my test program.
jazzed said...
If your test program is different than before, it would be good to see.
.....
Did you remove your changes from I2C.java?
Here is my test program:
import stamp.core.*;
import stamp.peripheral.io.*;
import stamp.util.text.*;
/** ·* Simple command processor ·*/
public class test1 {
public static void main() { ·int s=5000; ··// I2C Bus, PCF8591, LT1446, Lcd init ··· I2C ioBus = new I2C(PROP.pin29, PROP.pin28); ··· PCF8591 ioAdcDac = new PCF8591(ioBus, 0x00, 64); ·//LT1446 dacA12bits = new LT1446(PROP.pin15, PROP.pin14, PROP.pin13); ·//LCD4094 Lcd = new LCD4094(PROP.pin0,PROP.pin1,LCD_FUNCTION_4BIT_2LINES); ·//dac12bits.dac(1024,512); ·CPU.delay(30000); ·//Lcd.out(Format.sprintf(buffer,"%10u",xtal),buffer);
Finally, I tried by modifying both file pnative and I2C.java with the last version JVM_05_03 to test The I2C.
It makes the same thing: It freeses after a while who is short.
So, the problem is somewhere else.
jmspaggi said...
I tried today and stopped after 18163. Timer was always very stable. Between 1002 and 1005. Never got anything below.
Thanks JM. That helps, but it is not the answer I wanted
Looking at the ScaledTimer16 currentTime, it can return small values near the timer roll-over point which is what we're seeing and I'm not sure why ... the math seems to be working though. This leaves me scratching my head a bit and a fix will take more time.
Comments
I just figured it's comming from my initilisation blocks which was not included above.
for (int i = 0; i < PROP.pins.length - 1; i++) { PROP.setOutput(PROP.pins[i]); PROP.writePin(PROP.pins[i], false); } PROP.setInput(PROP.pin23); PROP.setInput(PROP.pin24); PROP.setInput(PROP.pin25); PROP.setInput(PROP.pin26); [/i][/i]Can you please test attached code?
In loop 1, it's working, in loop 2, it's not working anymore.
The for loop is initialisation pin0 to pin30 so it should not impact pin31. I tried with -2 instead of -1 with the same result. But if I comment the for loop, then it's working fine...
Any clue?
JM
Added: If I'm not mistaken, your for loop sets pins 0 to 30 to output with 0 on outputs. Total pins length is 32. If you write pin30 high instead, you would see no output after the loop.
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.
Post Edited (jazzed) : 5/3/2010 2:50:21 AM GMT
Interesting. Following my failed multi-prop Z80 attempt and I believe a multi-prop 6502 attempt elsewhere the Javelin must be the third of fourth VM/emulator project to arrive at this same result.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I removed the damned wire, and it's now working fine.
Regarding the speed, I want to say that it's faster and reducing the blinking, but it's difficult to mesure. So I will rely on your results [noparse];)[/noparse]
So far, my 2 projects for my props are:
- fully-configurable LED Digits driver (in Java, Spin and if I can PASM)
- A javelin 30 I/O extender. (Java, and again, Spin and PASM if I can)
Also, I will rebuild my test suite with the DS1302, the LCD screen, the LCD Digits, Fibo, and some other stuff to do some testing.
@heater: Are you saying that since the JVM is running on one single COG, it will be able to have a multi-prop JVM to increase the spead?
JM
Message Edité (jmspaggi) : 5/3/2010 2:25:58 PM GMT
I'm just making the observation that there have now been a number of attempts to implement emulations/virtual machines using multiple COGs.
In each case the reason for using multiple COGs was simply that a single COG does not have the space to get all the raw PASM code in. Not necessarily to get speed.
In each case it has turned out quicker to use some other technique to get the code into a single COG than to spread the code over many COGS.
So for example using overlays or LMM to get more code into one COG is quicker than spreading that same code over two COGs.
Please, excuse any mis-statements about Javelin I may be making now, I have not looked into the code. Does it use LMM? Does it use overlays?
Seems that the overheads of sharing state information and synchronizing COGS is greater that using overlays or LMM in general. This is a somewhat surprising result and points to the idea that the Prop needs more help in inter-COG communications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Regarding the Javelin architecture, I'm don't know. Peter is the expert and might be able to resply to that question...
JM
I'm so glad you have a working Serial Loopback configuration now.
Did you happen to try your SerialLCD with the Java library I provided?
I've attached a demo that should have much better timer performance.
@heater,
The JVM uses overlay to fetch the byte code implementation routines.
I decided against LMM in this case because 1) the number of instructions
to load is deterministic, 2) LMM kernel services take up precious COG
space, and 3) LMM jumps are clumsy. There are many COG stubs that
overlay routines use to speed up operations such as push/pop etc....
For the overlay loader, I chose not to use the decrementing load mainly
because it is a PITA to configure and use. The solution I'm using now
has a very short instruction decode and load setup. Most byte codes are
implemented in less than 5 instructions with in-COG helper routines, so
I use the unrolled fetch method to grab 4 instructions at a time before
missing a hub window. The one disadvantage of my implementation is
that NOP in the overlay code must be non-zero since I use 0 to terminate
the load; however, this allows for not keeping a length table.
One performance enhancement between the current JVM COG and the
last ones is that the JVM actively reads byte codes rather than "spinning"
for another COG to send a byte-code as done in a multi-COG design.
This also lets the core solution (without VP, etc...) use only 2 COGs.
Surprisingly, the JVM footprint is small enough to allow 19KB user code.
This could have never been achieved using LMM C.
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.
Things are working pretty well!
LCD screen is now working perfectly. I have "12345678901234567890" displayed, and no other extra char.
DS1302 is no more working. I will look at the wiring first [noparse];)[/noparse]
Also, the Uart loopback is working, but I have an extra char that I'm not expecting.
The tick/tock is working fine, but sometime I receive 500ms instead of 1000ms.
I will try to add the DS1620 today to see.
Thanks,
JM
Well, that's a great relief! [noparse]:)[/noparse]
Looks like I don't have to spend $40 now on a SerialLCD I won't use.
The timer thing is a big PITA!
Like I said, it should work better but it's not perfect. The math for
CPU.carry in Timer.java works otherwise other math stuff like
divide_u32_u16 and others would fail. I'm experimenting with timer
values now to see if there is something I don't expect happening.
Don't know what to suggest about those extra characters except
that all main()'s should end with a "while(true);" loop. Funny how
the output looks kind of like a keyboard line ... qwertyuiop
I'll retest some DS1302 code on my PPDB today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
until I added "ds1302.halt(false);" after instantiating a new object.
Works fine now except that initial 0:0:0 the JVM probably not causing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 timer calculation is bad if pnative.nm_core_Timer_latch lower word is $0000.
To prevent this, one fix is to add increment latchCount after getting it and before the writeVpRegister calls:
PUB nm_core_Timer_latch(bank) | latchedCount '/** ' * Latch the 32bit counter into the latch registers. ' * Called by Timer.tickLo() ' * ' * @param bank The allocated area for the Timer registers. ' */ latchedCount := vp.ReadTimer(getDev(bank)) ifnot (latchedCount & $ffff) ' if lower word of latchedCount is 0, increment it latchedCount++ writeVPregister(bank + def#nmLatchTimer1, (latchedCount >> 0) & $ff) writeVPregister(bank + def#nmLatchTimer2, (latchedCount >> 8) & $ff) writeVPregister(bank + def#nmLatchTimer3, (latchedCount >> 16) & $ff) writeVPregister(bank + def#nmLatchTimer4, (latchedCount >> 24) & $ff)▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 ds1302 is also working for me with the halt call.
Also, I don't know where this qwertyuiop is coming from [noparse];)[/noparse]
What's the next thing you will work on? Will it be the JNI option? Might be usefull. Because I will be happy to have a dedicated cog to run my main loop. It's VERY small, just 5 lines in Java.
I just implemented the fix in pnative. It's running since 2000 seconds. I will let it run for another 20000. I will let you know the result.
Thanks,
JM
Message Edité (jmspaggi) : 5/3/2010 9:17:19 PM GMT
JNI is in the near future. JNI provides an interface to methods written in the CPU's Native language ... Spin/PASM in this case. JNI is important based on the kinds of peripherals I'm used to having on Propeller so it's a high priority item. Any JNI beyond the current set should be pluggable and not part of the standard Javelin code base.
I'm thinking to update the top post package first. Does the current directory structure suit you? There is another alternative where we can put the JVM code in the same directory as JavaBuild and that might be easier to maintain and use for new users.
I also want to turn garbage collection GC back on. Last I checked it was broken. GC can periodically get in the way of Java performance but not VPs or other code running in non-java COGs. Without GC, memory can be a bigger issue in this 19KB user byte-code JVM. There is some debugging that would have been impossible without it for example.
One thing worth doing is building the Javelin BOE-BOT. That would be a good hardware interface test.
I won't have much time the rest of the week, but will get back in it next hard and heavy week.
That goes in pnative.spin ... just add the missing lines to the method (CTRL-F to search method name).
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.
Yep, I'm fine with that. I will build my own Spin or PASM object and try to interface it with the Java code though JNI when this will be available.
I have not really test the packaging itself since I'm using my own build script and so on. I will try to start back from scratch and see how it's going with the last packages I have.
I prefer whitout the GC. I'm managing the memory carrefully everywhere, so a GC wil just weast few cycles. BUT... If we can activate/de-activate it with IFDEF, then it will be perfect.
Just le me know if you activate it, and I will test it actively.
That will give me some time to help on pPropellerSim and to learn Spin.
I found it and tried it. So far it's running for 4600 secs now with no issue. I will keep it running, maybe all night long, and report the result.
Thanks,
JM
JM
System.out.println ("\nStarting ScaledTimer test..."); boolean tick = false; int i = 0; int errors = 0; while (!rx.byteAvailable()) { i++; scaledTimer.mark(); for (clock.mark(); !clock.timeout(1000);); int ticks = scaledTimer.passedTicks(); int time = scaledTimer.passedTime(); System.out.print(i); System.out.print(" "); System.out.print(ticks); System.out.print(" ticks. "); System.out.print(time); System.out.print(" ms. "); System.out.print(tick?"tick":"tock"); if (time < 1000) errors++; System.out.print(errors); System.out.println(" error(s)."); tick=!tick; } // end for System.out.println ("End...");These are the worst kinds of problems to debug.
Did both failures happen around the same count 17610 ?
I ran a test to see what would happen when the 32 bit counter
wrapped from FFFFFFFF back to 0. That worked fine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 tried up to -24400 with no other issue. I just restarted it. I will let you know in 17610 seconds [noparse];)[/noparse] Which is about 5h.
Since yesterday I'm loging all propeller outputs in a file, so I can also go back and see the past results.
JM
Ah, so the counter wrapped. I'm not sure if it is significant though.
I stopped my test after the wrap.
Could you do me a favor and restart with the following timer latch method?
It will print 3 to 4 counter lines between tick-tocks.
PUB nm_core_Timer_latch(bank) | latchedCount '/** ' * Latch the 32bit counter into the latch registers. ' * Called by Timer.tickLo() ' * ' * @param bank The allocated area for the Timer registers. ' */ latchedCount := vp.ReadTimer(getDev(bank)) if (savedCount & $ffff_8000) <> (latchedCount & $ffff_8000) sio.hex(latchedCount,8) sio.tx(" ") sio.hex(savedCount,8) sio.tx(" ") sio.str(string("diff = ")) sio.dec(latchedCount-savedCount) sio.tx($d) savedCount := latchedCount ifnot (latchedCount & $ffff) latchedCount++ writeVPregister(bank + def#nmLatchTimer1, (latchedCount >> 0) & $ff) writeVPregister(bank + def#nmLatchTimer2, (latchedCount >> 8) & $ff) writeVPregister(bank + def#nmLatchTimer3, (latchedCount >> 16) & $ff) writeVPregister(bank + def#nmLatchTimer4, (latchedCount >> 24) & $ff) var long savedCountBTW, I verified the Spin based GC works with some modifications and
it is enclosed with #ifdef GCOLLECT. I don't have any room for GC in
the JVM COG. Guess I'll have to use a different data-structure for heap
to improve performance ... the "heap" structure gives O(log N) searching.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Test is running.
I will post the result in 5h.
Regarding the GC, maybe we can dedicate a COG for those who want to have it?
JM
@jmspaggi : I think that is a good idea !
@jazzed : As soon as BST works on my computer, I would confirm the file I2C.java.
Is it possible to implement a variable long type too ?
Marco.
I plan sometime to implement the Java2 VM. That will have long data type.
The Javelin "standard" does not use longs. I want to the current VM to run all the legacy Javelin code.
I very much appreciate your help in verifying compatibility with the Javelin by testing I2C.java.
Agreed, the GC is better done in a separate PASM COG. Since I already have that code, it will be easier to implement. Still, at some point I do want to improve heap efficiency; right now it is a chunk list allocator. I have to search for object references in stack, static, and heap areas ....
BTW, please say if you have a preference on directory structure for JavaBuild and JavaPropJVM.
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.
Look like it's not even going to this method....
JM
So this is the first round ? I mean it didn't go past FFFFFFFF already right?
Does this happen on Javelin by any chance?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Same issue few hours later. Again, with the same kind of pattern. (0x800000000)
I did not get a chance to try with the Javelin yet because it's handling my water heaters and my solar pannels [noparse];)[/noparse] I will try next night.
JM
Waiting for BradC to solve my RTS related problem, I made another temporary cable link with DTR signal and The link BST works !
@jazzed : Sadly, I2C.java don't work with The last version. It freezes at a certain point. I don't know why yet. Can you tell me where you use "shiftOut".
I can send to you my test program.
@jmspaggi: Thanks for your cool informations...
See you later.
import stamp.core.*;
import stamp.peripheral.io.*;
import stamp.util.text.*;
/**
·* Simple command processor
·*/
public class test1 {
public static void main() {
·int s=5000;
··// I2C Bus, PCF8591, LT1446, Lcd init
··· I2C ioBus = new I2C(PROP.pin29, PROP.pin28);
··· PCF8591 ioAdcDac = new PCF8591(ioBus, 0x00, 64);
·//LT1446 dacA12bits = new LT1446(PROP.pin15, PROP.pin14, PROP.pin13);
·//LCD4094 Lcd = new LCD4094(PROP.pin0,PROP.pin1,LCD_FUNCTION_4BIT_2LINES);
·//dac12bits.dac(1024,512);
·CPU.delay(30000);
·//Lcd.out(Format.sprintf(buffer,"%10u",xtal),buffer);
·System.out.print("Hello1");
··· if(ioAdcDac.isPresent()){
···
···························· ioAdcDac.writeDac(100);
······· System.out.print("Hello2");
··}
··· else{
······ while ( true ) {
··· //CPU.shiftOut(PROP.pin29, PROP.pin28, 8, CPU.SHIFT_MSB, i2cData);
······· CPU.writePin(PROP.pin0,true);
······· CPU.delay(s);
······· CPU.writePin(PROP.pin0,false);
······· CPU.delay(s);···
··· }
··· }
···
··· while ( true ) {
··· System.out.print("Hello3");
······· //CPU.writePin(PROP.pin0,true);
······· //CPU.delay(s);
······· CPU.writePin(PROP.pin0,false);
······· System.out.print("_"+ioAdcDac.readAdc());//CPU.delay(s);
·····
···
··· }
·}
}
YES
I'll look at this tomorow...
Marco
I tried today and stopped after 18163. Timer was always very stable. Between 1002 and 1005. Never got anything below.
JM
It makes the same thing: It freeses after a while who is short.
So, the problem is somewhere else.
At tomorow...
Looking at the ScaledTimer16 currentTime, it can return small values near the timer roll-over point which is what we're seeing and I'm not sure why ... the math seems to be working though. This leaves me scratching my head a bit and a fix will take more time.
@Chim