jmspaggi said...
@steve: Seems that there is still some issues [noparse];)[/noparse]
19200: "/12345678901234567890"
9600: "901234567890"
2400: "901234567890"
Yes. I did not mention any change for the Uart code.
However, this looks a lot like output without the Uart.stop modification.
Did you add the wait for tx complete code I listed before?
Did you try the 1302 RTC with this zip package?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
/**
* Stops the Uart.
*/
public void stop() {
if (!started) return; //already stopped
while (!sendBufferEmpty()); //wait until character transmitted
CPU.removeVP(this);
started = false;
}
The RTC with you new version is still not working [noparse]:([/noparse] I tried DS1302_full-demo.spin and it's still working fine.
Also...
I modified pnative.spin
case nm_function
0: prm2 := pjd.pop
prm1 := pjd.pop
prm0 := pjd.pop
case prm0
def#nmPeriph0Bank..(def#nmPeriph0Bank+def#MAX_NUM_VPS*16-1):
writeVPregister(prm0,prm1)
other:
pjd.writeJVMregister(prm0,prm1,prm2)
Methods renamed to readPort16() and writePort16().
If the port identifier is a 8bits port (CPU.PORTA, CPU.PORTB, PROP.PORTC, PROP.PORTD)
then the CPU.writePort() is called.
If the port identifier is a 16bits port (PROP.PORTAB, PROP.POPTCD) then
there are 2 consecutive calls to CPU.readRegister or CPU.writeRegister.
In propellercode
nmPortAB con 2
nmPortCD con 4
nmPortA con 6
nmPortB con 7
nmPortC con 8
nmPortD con 9
PORTABout var word
PORTCDout var word
PORTABin var word
PORTCDin var word
Don't we have a way to reduce the 2 consecutives calls to CPU.writeRegister? If we move the logic regarding 16bits vs 8bits in the spin code, that should improve the speed, no? Because with the solution you proposed above, we are doing 2 calls, which is barely the same as calling 2 times CPU.writePort(). We don't save a call.
CPU.writeRegister was already taking an int as the parameter. Can't we just re-use it?
We can only read and write bytes. So to read and write ints requires 2 calls.
But the PROP.readPort16() and PROP.writePort16() hides that for us.
But the propeller code I showed reads or writes a 16bit values. If you call readRegister or writeRegister
with the 8bit port identifiers then the 16bits port is read or written in two steps.
That's why I used nmPortAB and nmPortCD so values can be assembled before
the method ends.
Now you can update multiple bits that are on different ports simultaneously,
for example bit3 of portA and bit4 of portB.
This mechanism can also be used to implement your own VP's.
Just use unused register addresses.
The RTC with you new version is still not working [noparse]:([/noparse] I tried DS1302_full-demo.spin and it's still working fine.
It worked for me. At first glance using the Oscope, it looked like the hold bit was always set. Then I used ds1320.hold(false) and it seemed to work always thereafter ... but isn't that what the constructor does? Maybe the lack of battery backup on the PPDB 1302 is causing part of that problem? ... no real idea really, just speculating. I'll pull it out again Thursday.
Peter, thanks for your guidance on the port features. Do you have a methodology that works for nicely for integrating library code? I use CVS often, etc .... I wouldn't want to see the libraries diverge, but I'm not against keeping a separate one if necessary.
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.
@peter:Ok. I see for the bytes/words.
Do you think this will be faster? Since we already have to do 2 calls, are we not just adding overhead?
What do you mean by "This mechanism can also be used to implement your own VP's."? Can you give me more details?
Also, attached is an updated PROP version. I think writePort16 should call CPU.writePort instead of CPU.writeRegister.
Thanks,
@Steve:
This is what the DS1302 constructor is doing:
public DS1302(int data, int clock, int enable){
dataPin = data;
clockPin = clock;
enablePin = enable;
// initialize pins -- make low for high-going pulses
CPU.writePin(enablePin,false); // init the bus
CPU.writePin(clockPin, false);
CPU.delay(SETTLE_TIME); // settle down
CPU.writePin(enablePin,true);
CPU.shiftOut(dataPin,clockPin,8,CPU.SHIFT_LSB,CLEAR_PROTECT);
CPU.shiftOut(dataPin,clockPin,8,CPU.SHIFT_LSB,0);// control byte
CPU.writePin(enablePin,false);
try {
int tmp = readRam(1); // test location 0
}
catch (Exception e) {
System.out.println("DS1302 Read Exception - Check wires");
}
}
I'm not really sure what Oscope is [noparse]:([/noparse] Also, there is no hold methode is the java class I have.
Looks familiar. It doesn't have the call I used in it. Wish I could remember the name now ... was it halt ?. it's a function that has a boolean parameter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Uart rx = new Uart(Uart.dirReceive, PROP.pin31, Uart.invert, Uart.speed19200, Uart.stop1);
while (true)
{
boolean dataReceived = rx.byteAvailable();
if (dataReceived)
{
System.out.print((char)rx.readByte());
}
}
Pin 31 is the one connected to the BST Terminal, no? When I type on the terminal, I see the PPDB led blinking, but I'm not receiving anything on my program. What's wrong? Any clue?
I tried to connect pin 31 to pin 27 and used this pin for the UART, same result.
[noparse];)[/noparse] This is not for the Serial LCD. I unplugged it. Now I just want to receive bytes on the Prop side from my PC.
So I build the UART on the Serial pin (31), and tried also with another pin. What's speed is the Terminal using for sx? The same as what we configure for the rx?
I'm a french guy. Sorry for my poor english skills.
I tried your·awesome JVM program (JVM0418) and I have tested I2C with a PCF8591 chip·(it's working fine!).
I modified the file I2C.java·because it did not work. (I·only modified this line "CPU.shiftOut(sdaPin, sclPin, 8, CPU.SHIFT_MSB, (i2cData << 8));"··per "CPU.shiftOut(sdaPin, sclPin, 8, CPU.SHIFT_MSB, i2cData);" ).
I post both files.
However I·have·one question for you about propdirect link, it creates me an error when I use a variable long type ?!? Why ? I can't use this type of variable ?
To improve your program, I think·you should give priority to program·execution speed. (if it's possible)
Longs are·not supported natively. Only char, byte, short and int.
Ints are 16bit signed, range is -32768 to +32767
Shorts are 16bit signed/unsigned
you can do short value = (short)0xD46A for example
but int value = 0xD46A produces error.
But int value = (short)0xD46A works.
@Chimere, welcome to the forum. I'm glad you enjoy the code here.
I started working yesterday to make the JVM run programs straight from EEPROM.
As I expected it is quite slow, but it opens a door to faster external device support
such as 8 bit SRAM or SPI SRAM at some point.
Now that I know this is at least possible, I'll get back to the main idea. Unfortunately,
I'm dog tired and it is too late to work on anything else today.
@JM, I'll look at your other failing serial port configuration early tomorrow.
Just for future reference here is some output running FiboTest.java from EEPROM.
Today has been a long haul for Javelin Propeller. Reasonable progress [noparse]:)[/noparse]
@JM, I tried your serial loopback configuration today. It worked fine for me.
@Chime're, I see why you had to add the change to the I2C code for it to work.
I will be updating this so the standard class will run.
I'm preparing some zip packages to post tomorrow for testing. They will include
Javelin Stamp class libraries I use with the new PROP.java from JM, the tool set,
and the Propeller JVM sources.
I've decided to keep on the 1 COG JVM path. It is somewhat slower than the
3 COG JVM, but it is better in several ways including allowing more free COGs.
Just for comparison, the 3 COG JVM runs FIBO(24) in 5.9 seconds. The 1 COG
JVM runs FIBO(24) in 7.7 seconds (and there is "room" in COG for improvements).
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Is it not possible to maintain the 3 cogs version and the 1 cog one? Sometime, the speed is critical.
I drived the 6 LED Display Digits on the PPDB with the last version, and it's not fast enought to avoid the blinking. I removed everything from the driver to just keep the display, and it's still blinking a little. Might be interesting the try with the old 3cogs version to see how it's faster.
For the loopback how are you defining it?
Here is my code
Uart rx = new Uart(Uart.dirReceive, PROP.pin31, Uart.invert, Uart.speed19200, Uart.stop1);
while (true)
{
boolean dataReceived = rx.byteAvailable();
msdd.draw();
if (dataReceived)
{
System.out.print((char)rx.readByte());
}
msdd.draw();
}
It's supposed to do like an echo of the terminal. But I'm not receiving anything Should I use different speed/configuration for the Uart? How did you tried yours?
The code I used for testing is essentially the same as yours. I think you should try a new set of zips that include my java class library and new JVM from the attachments. If you have problems running a class, let me know what class changes would fix the problem and I'll fix the JVM. For example, I think the CPU.shiftOut method should now work with a normal I2C.java class.
There is one more performance optimization I can do for the 1 COG JVM, and I'm working on that this morning. As far as your blinking problem in the 16 segment LCD, a different approach may be required such as employing a new JNI that would allow loading and running a COG with special PASM similar to what can be done with ICC. This method can be developed later.
For now though, even the 1COG JVM outperforms Javelin in some cases and is no slower than the 3 COG JVM in other cases. The one example is FiboTest. Javelin runs FIBO(0..3) in 1ms or less. Both 1 COG and 3 COG JVMs run the same in 4ms. Javelin runs FIBO(24) in about 9s, 1 COG JVM runs it in 7.7s, 3 COG JVM runs it in 5.9s.
import stamp.core.*;
public class SerialLoop
{
public static void main() {
System.out.println("Starting Loopback Test");
System.out.println("Type in terminal for echo.");
Uart rx = new Uart(Uart.dirReceive, PROP.pin31, Uart.invert, Uart.speed19200, Uart.stop1);
while (true)
{
boolean dataReceived = rx.byteAvailable();
if (dataReceived) {
int data = rx.readByte();
System.out.print((char)data);
}
}
}
}
For the attachments, they are designed to sit at the same directory level.
In JavaBuild, there is a build.bat. I use it to build the applications from the command
line to generate the included jem.bin. Example would be "cd JavaBuild" then "build FiboTest"
For BradC:
Something about BST keeps the jem.bin from getting updated if built with the pre-build step.
Also in JavaBuild there is a src directory. That is where my test sources live.
The attached JVM runs all sources.
The JavaPropJVM attachment contains the JVM source.
The pjvm_demo.spin requires BST to build now (or BSTC with proper options).
The BST project file to load for a successful build is in the folder JavaBuild\JavaProp.sprj
If we get anywhere with these attachments, I'll post them in the top thread post for general use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 will test this version. So far I'm not able to compile it (Expected object definition) in the first ifdef line. Should I configure something somewhere?
I will test this version. So far I'm not able to compile it (Expected object definition) in the first ifdef line. Should I configure something somewhere?
@JM, etal: Looks like the JavaPropJVM .zip file did not include SingleSerial.spin.
Use the attached .zip instead. It also has the faster 1 COG code.
Included is a make.bat that you can use from the JavaBuild directory with bstc flags.
The batch file could be easily converted to a shell script file as before.
I changed the way the build is done to keep from constantly copying java code for new versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
jmspaggi said...
BST projects are not cross-plateforms compatibles. So I can't open it. "c:\\users\Steve\Documents\Propeller....." is missing.
So I have done one for my plateform.
So far, it's seems to be working. You example is working, but not mine. So I suspect something...
Just add that:
Uart screenUart = new Uart(Uart.dirTransmit, PROP.pin27, Uart.invert, Uart.speed19200, Uart.stop1);
before your RX definition, and it will not work any more. Comment it, it will work again. Something should be wrong when there is more than one UART.
I will continue my testing.
What's the next thing you will work on? [noparse];)[/noparse]
Thanks,
JM
I would work on this problem, but I can't make it fail
import stamp.core.*;
public class SerialLoop
{
public static void main() {
System.out.println("Starting Loopback Test with Uart TX P27");
System.out.println("Type in terminal for echo.");
Uart screenUart = new Uart(Uart.dirTransmit, PROP.pin27, Uart.invert, Uart.speed19200, Uart.stop1);
Uart rx = new Uart(Uart.dirReceive, PROP.pin31, Uart.invert, Uart.speed19200, Uart.stop1);
while (true)
{
boolean dataReceived = rx.byteAvailable();
if (dataReceived) {
int data = rx.readByte();
System.out.print((char)data);
}
}
}
}
Note in the attachment the PST window has an input bar and an output window. Whatever I type is echoed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Comments
In PROP.java
public static final int PORTAB = 2;
public static final int PORTCD = 4;
//additional·writeRegister method (different argument types)
public static void writeRegister(int addr, int value) {
· switch (addr) {
····case PORTAB:
··· case PORTCD:·writeRegister(addr,(byte)value);
······················· writeRegister(addr+1,(byte)(value >>>·8));
······················· break;
··· default: writeRegister(addr,(byte)value);
· }
}
//modify existing readRegister
public static int readRegister(int addr) {
· int value;
· switch (addr) {
····case PORTAB:
··· case PORTCD:·value = readRegister(addr);
······················· value·= (readRegister(addr+1) << 8) | (value & 0xFF);
······················· break;
··· case PORTA:·· ....
··· default: value = 0;
· }
· return value;
}
In propellercode
PORTABout var word
PORTCDout var word
PORTABin var word
PORTCDin var word
PUB·writeJVMregister(address,value)
{{·write·value·to·register·}}
··address·&=·$FF
··case·address
····nmPortA:·outa[noparse][[/noparse]7..0]·:=·value
····nmPortB:·outa[noparse][[/noparse]15..8]·:=·value
····nmPortC:·outa[noparse][[/noparse]23..16]·:=·value
····nmPortD:·outa[noparse][[/noparse]31..24]·:=·value
····nmPortAB:·PORTABout =·value AND·$FF
····nmPortAB+1:·PORTABout =·PORTABout OR (value << 8)
······················outa[noparse][[/noparse]15..0]·:=·PORTABout
····nmPortCD:·PORTCDout =·value AND·$FF
····nmPortCD+1:·PORTCDout =·PORTCDout OR (value << 8)
······················outa[noparse][[/noparse]31..16]·:=·PORTCDout
PUB·readJVMregister(address) : value
{{·read·value·from·register·}}
··address·&=·$FF
··case·address
····nmPortA:·value =·ina[noparse][[/noparse]7..0]
····nmPortB:·value = ina[noparse][[/noparse]15..8]
····nmPortC:·value = ina[noparse][[/noparse]23..16]
····nmPortD:·value = ina[noparse][[/noparse]31..24]
····nmPortAB:·PORTABin = ina[noparse][[/noparse]15..0]
·················· value = PORTABin AND $FF
····nmPortAB+1:·value = PORTABin >> 8
····nmPortCD:·PORTCDin = ina[noparse][[/noparse]31..16]
·················· value = PORTCDin AND $FF
····nmPortAB+1:·value = PORTCDin >> 8
· return value
regards peter
19200: "/12345678901234567890"
9600: "901234567890"
2400: "901234567890"
@peter: Attached are 2 updated PROP and CPU version. Can you please review them?
Also attached is the updated pjdata.spin file.
I compiled everything with my existing code and it's working as previously. So it's seems to be compatible.
I also tried by replacing
by
But it's not working anymore [noparse];)[/noparse] So there is something wrong somewhere. I will investigate. Let me know if you see it.
Thanks,
JM
If I do that
Where should I take care of the 2nd parameter? Should I simply send it from PROP.java?
JM
However, this looks a lot like output without the Uart.stop modification.
Did you add the wait for tx complete code I listed before?
Did you try the 1302 RTC with this zip package?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 mixed up RTC and UART [noparse];)[/noparse]
Here is the stop code I'm using
The RTC with you new version is still not working [noparse]:([/noparse] I tried DS1302_full-demo.spin and it's still working fine.
Also...
I modified pnative.spin
pjdata.spin
and PROP and CPU (attached).
This is working at 90%... I think I'm note receiving the 2 parameters. One seems to be blank.
That way, with only one call, we can push 16 bits, instead of calling 2 times for 8 bits.
I will try to find the small glitch and update the writeRegister too.
JM
Methods renamed to readPort16() and writePort16().
If the port identifier is a 8bits port (CPU.PORTA, CPU.PORTB, PROP.PORTC, PROP.PORTD)
then the CPU.writePort() is called.
If the port identifier is a 16bits port (PROP.PORTAB, PROP.POPTCD) then
there are 2 consecutive calls to CPU.readRegister or CPU.writeRegister.
In propellercode
nmPortAB con 2
nmPortCD con 4
nmPortA con 6
nmPortB con 7
nmPortC con 8
nmPortD con 9
PORTABout var word
PORTCDout var word
PORTABin var word
PORTCDin var word
PUB·writeJVMregister(address,value)
{{·write·value·to·register·}}
··address·&=·$FF
··case·address
····nmPortA:·outa[noparse][[/noparse]7..0]·:=·value
····nmPortB:·outa[noparse][[/noparse]15..8]·:=·value
····nmPortC:·outa[noparse][[/noparse]23..16]·:=·value
····nmPortD:·outa[noparse][[/noparse]31..24]·:=·value
····nmPortAB:·PORTABout =·value AND·$FF
····nmPortAB+1:·PORTABout =·PORTABout OR (value << 8)
······················outa[noparse][[/noparse]15..0]·:=·PORTABout
····nmPortCD:·PORTCDout =·value AND·$FF
····nmPortCD+1:·PORTCDout =·PORTCDout OR (value << 8)
······················outa[noparse][[/noparse]31..16]·:=·PORTCDout
PUB·readJVMregister(address) : value
{{·read·value·from·register·}}
··address·&=·$FF
··case·address
····nmPortA:·value =·ina[noparse][[/noparse]7..0] AND $FF
····nmPortB:·value = ina[noparse][[/noparse]15..8] AND $FF
····nmPortC:·value = ina[noparse][[/noparse]23..16] AND·$FF
····nmPortD:·value = ina[noparse][[/noparse]31..24] AND·$FF
····nmPortAB:·PORTABin = ina[noparse][[/noparse]15..0] AND $FFFF
·················· value = PORTABin AND $FF
····nmPortAB+1:·value = PORTABin >> 8
····nmPortCD:·PORTCDin = ina[noparse][[/noparse]31..16] AND $FFFF
·················· value = PORTCDin AND $FF
····nmPortAB+1:·value = PORTCDin >> 8
· return value
regards peter
Don't we have a way to reduce the 2 consecutives calls to CPU.writeRegister? If we move the logic regarding 16bits vs 8bits in the spin code, that should improve the speed, no? Because with the solution you proposed above, we are doing 2 calls, which is barely the same as calling 2 times CPU.writePort(). We don't save a call.
CPU.writeRegister was already taking an int as the parameter. Can't we just re-use it?
Thanks,
JM
But the PROP.readPort16() and PROP.writePort16() hides that for us.
But the propeller code I showed reads or writes a 16bit values. If you call readRegister or writeRegister
with the 8bit port identifiers then the 16bits port is read or written in two steps.
That's why I used nmPortAB and nmPortCD so values can be assembled before
the method ends.
Now you can update multiple bits that are on different ports simultaneously,
for example bit3 of portA and bit4 of portB.
This mechanism can also be used to implement your own VP's.
Just use unused register addresses.
regards peter
Peter, thanks for your guidance on the port features. Do you have a methodology that works for nicely for integrating library code? I use CVS often, etc .... I wouldn't want to see the libraries diverge, but I'm not against keeping a separate one if necessary.
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.
Do you think this will be faster? Since we already have to do 2 calls, are we not just adding overhead?
What do you mean by "This mechanism can also be used to implement your own VP's."? Can you give me more details?
Also, attached is an updated PROP version. I think writePort16 should call CPU.writePort instead of CPU.writeRegister.
Thanks,
@Steve:
This is what the DS1302 constructor is doing:
I'm not really sure what Oscope is [noparse]:([/noparse] Also, there is no hold methode is the java class I have.
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 played with writePort and writeRegister. With the last version from previous post, it's now working fine.
First read is still strange, but subsequents are correct.
JM
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Pin 31 is the one connected to the BST Terminal, no? When I type on the terminal, I see the PPDB led blinking, but I'm not receiving anything on my program. What's wrong? Any clue?
I tried to connect pin 31 to pin 27 and used this pin for the UART, same result.
Thanks,
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
So I build the UART on the Serial pin (31), and tried also with another pin. What's speed is the Terminal using for sx? The same as what we configure for the rx?
Thanks,
JM
I'm a french guy. Sorry for my poor english skills.
I tried your·awesome JVM program (JVM0418) and I have tested I2C with a PCF8591 chip·(it's working fine!).
I modified the file I2C.java·because it did not work. (I·only modified this line "CPU.shiftOut(sdaPin, sclPin, 8, CPU.SHIFT_MSB, (i2cData << 8));"··per "CPU.shiftOut(sdaPin, sclPin, 8, CPU.SHIFT_MSB, i2cData);" ).
I post both files.
However I·have·one question for you about propdirect link, it creates me an error when I use a variable long type ?!? Why ? I can't use this type of variable ?
To improve your program, I think·you should give priority to program·execution speed. (if it's possible)
Thanks in advance.
See you later.
Marco.
Ints are 16bit signed, range is -32768 to +32767
Shorts are 16bit signed/unsigned
you can do short value = (short)0xD46A for example
but int value = 0xD46A produces error.
But int value = (short)0xD46A works.
regards peter
See you later
So if I do (short)0x8000 and -0x8000 it's the same?
JM
I started working yesterday to make the JVM run programs straight from EEPROM.
As I expected it is quite slow, but it opens a door to faster external device support
such as 8 bit SRAM or SPI SRAM at some point.
Now that I know this is at least possible, I'll get back to the main idea. Unfortunately,
I'm dog tired and it is too late to work on anything else today.
@JM, I'll look at your other failing serial port configuration early tomorrow.
Just for future reference here is some output running FiboTest.java from EEPROM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/1/2010 1:43:02 AM GMT
@JM, I tried your serial loopback configuration today. It worked fine for me.
@Chime're, I see why you had to add the change to the I2C code for it to work.
I will be updating this so the standard class will run.
I'm preparing some zip packages to post tomorrow for testing. They will include
Javelin Stamp class libraries I use with the new PROP.java from JM, the tool set,
and the Propeller JVM sources.
I've decided to keep on the 1 COG JVM path. It is somewhat slower than the
3 COG JVM, but it is better in several ways including allowing more free COGs.
Just for comparison, the 3 COG JVM runs FIBO(24) in 5.9 seconds. The 1 COG
JVM runs FIBO(24) in 7.7 seconds (and there is "room" in COG for improvements).
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Is it not possible to maintain the 3 cogs version and the 1 cog one? Sometime, the speed is critical.
I drived the 6 LED Display Digits on the PPDB with the last version, and it's not fast enought to avoid the blinking. I removed everything from the driver to just keep the display, and it's still blinking a little. Might be interesting the try with the old 3cogs version to see how it's faster.
For the loopback how are you defining it?
Here is my code
It's supposed to do like an echo of the terminal. But I'm not receiving anything Should I use different speed/configuration for the Uart? How did you tried yours?
Thanks,
JM
The code I used for testing is essentially the same as yours. I think you should try a new set of zips that include my java class library and new JVM from the attachments. If you have problems running a class, let me know what class changes would fix the problem and I'll fix the JVM. For example, I think the CPU.shiftOut method should now work with a normal I2C.java class.
There is one more performance optimization I can do for the 1 COG JVM, and I'm working on that this morning. As far as your blinking problem in the 16 segment LCD, a different approach may be required such as employing a new JNI that would allow loading and running a COG with special PASM similar to what can be done with ICC. This method can be developed later.
For now though, even the 1COG JVM outperforms Javelin in some cases and is no slower than the 3 COG JVM in other cases. The one example is FiboTest. Javelin runs FIBO(0..3) in 1ms or less. Both 1 COG and 3 COG JVMs run the same in 4ms. Javelin runs FIBO(24) in about 9s, 1 COG JVM runs it in 7.7s, 3 COG JVM runs it in 5.9s.
For the attachments, they are designed to sit at the same directory level.
In JavaBuild, there is a build.bat. I use it to build the applications from the command
line to generate the included jem.bin. Example would be "cd JavaBuild" then "build FiboTest"
For BradC:
Something about BST keeps the jem.bin from getting updated if built with the pre-build step.
Also in JavaBuild there is a src directory. That is where my test sources live.
The attached JVM runs all sources.
The JavaPropJVM attachment contains the JVM source.
The pjvm_demo.spin requires BST to build now (or BSTC with proper options).
The BST project file to load for a successful build is in the folder JavaBuild\JavaProp.sprj
If we get anywhere with these attachments, I'll post them in the top thread post for general use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 will test this version. So far I'm not able to compile it (Expected object definition) in the first ifdef line. Should I configure something somewhere?
Thanks,
JM
You should load the JavaBuild\JavaProp.sprj project if you didn't already.
Also, make sure your BST Tools->Compiler Preferences->Optimizations are set as:
- Fold Constants
- Eliminate unused SPIN methods
- Generic "Safe" optimizations
- Non-Parallax compatible Extentions
Items without bullet are un-checked.Fold Constant/Unary pairs
Fast Constants ...
The last is most important of all since that's how #ifdef ... are recognized as valid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Original 3 COG JVM Result:
So now the 1 COG code is actually faster at under 5.8s for FIBO(24).
I'll post the new code in the package later. No more optimizing now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
@JM, etal: Looks like the JavaPropJVM .zip file did not include SingleSerial.spin.
Use the attached .zip instead. It also has the faster 1 COG code.
Included is a make.bat that you can use from the JavaBuild directory with bstc flags.
The batch file could be easily converted to a shell script file as before.
I changed the way the build is done to keep from constantly copying java code for new versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
So I have done one for my plateform.
So far, it's seems to be working. You example is working, but not mine. So I suspect something...
Just add that:
before your RX definition, and it will not work any more. Comment it, it will work again. Something should be wrong when there is more than one UART.
I will continue my testing.
What's the next thing you will work on? [noparse];)[/noparse]
Thanks,
JM
I would work on this problem, but I can't make it fail
Note in the attachment the PST window has an input bar and an output window. Whatever I type is echoed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.