Invert and leading characters should be fixed. Try the attached .zip to see if most of the Uart problems have gone. Also, you must add a wait for tx complete in Uart.stop. Example:
/**
* Stops the Uart.
*/
public void stop() {
if (!started) return; //already stopped
while (!sendBufferEmpty())
; //wait until character transmitted
CPU.removeVP(this);
started = false;
}
This is to prevent restarts before the chars are done with slower bauds ... Propeller Java PASM JVM is fast enough to interfere with character timing without good message coordination. One of the fixes was to change the tail pointer only after the char is finished so that sendBufferEmpty() works.
I found one issue that needs more attention though. Seems that defining just 2 Uart VPs causes a problem. If you add any other VP like timer, etc... the problem goes away. I'll search for the root cause tomorrow.
EDIT: Previous post had "should not be fixed" ... not what I meant [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
It's better, but it's still missing one char at the beginning. I got "2345678901234567890" instead of "12345678901234567890". This is with the updated Uart as suggested.
I tried to take a look at the writePort issue. Was able to find the code for writeByte, but not the one for writePort [noparse]:([/noparse]
It's better, but it's still missing one char at the beginning. I got "2345678901234567890" instead of "12345678901234567890". This is with the updated Uart as suggested.
I tried to take a look at the writePort issue. Was able to find the code for writeByte, but not the one for writePort [noparse]:([/noparse]
Let me know if there is anything I can do.
JM
Ok [noparse]:)[/noparse] ·Is this on the SerialLCD or a normal serial port? All my testing is with the Propeller Serial Terminal "PST" from 600 baud to 57600 without errors (115200 has some problems) ... maybe PST is just too good of an RS232 terminal. Did you happen to try a slower baud rate this time?
Both writePort and readPort are in lib\stamp\core\CPU.java near the bottom. They call CPU.writeRegister and CPU.readRegister. There is no support there currently for PORTC and PORTD. I would like to see PROP.java extend CPU.java since PROP is just a special CPU (it seems). If you feel like doing that, it would be great!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
For the Uart, I'm using the Uart directly without using SerialLD class. But I'm sending to the LCD screen, and not to the terminal. It's always working with the term, so there is no challenge [noparse];)[/noparse]
Here is the summary.
19200: "2345678901234567890"
9600: "01234567890"
2400: "3f5678901234567890" (it's a f instead of a 4)
For PROP vs CPU. I will take care of that right now.
Somebody said...
Both writePort and readPort are in lib\stamp\core\CPU.java near the bottom. They call CPU.writeRegister and CPU.readRegister. There is no support there currently for PORTC and PORTD. I would like to see PROP.java extend CPU.java since PROP is just a special CPU (it seems). If you feel like doing that, it would be great!
The values 6 and 7 are used for PORTA and PORTB.
In my spin version I reserved 8 and 9 to support PORTC and PORTD.
To write to PORTC you would use CPU.writeRegister(8,value)
jmspaggi said...
For the Uart, I'm using the Uart directly without using SerialLD class. But I'm sending to the LCD screen, and not to the terminal. It's always working with the term, so there is no challenge [noparse];)[/noparse]
Grimmace [noparse]:)[/noparse] Guess I'll have to buy one
Peter said...
The values 6 and 7 are used for PORTA and PORTB.
In my spin version I reserved 8 and 9 to support PORTC and PORTD.
To write to PORTC you would use CPU.writeRegister(8,value)
Peter, Thanks for pointing this out. Most of the pnative.spin code handling is yours with very few changes ... same goes for pjdata.spin. Encapsulating the Propeller in a java class should be lot's of fun and will add value.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 said...
Grimmace [noparse]:)[/noparse] Guess I'll have to buy one
That's not what you said first [noparse];)[/noparse] Is there anything I can do on my side to help troubleshooting?
Attached is the PROP.java file. It's quit small and simple. There was only few constants to remove, and 2 methods to overwrite. Maybe I missed things, but this version is working fine for me so far... I used the 2 values (8 and 9) reserved by Peter.
That PROP class is looking good.
As I have said earlier using writeRegister and readRegister is the way to
add functionality to existing native functions or totally new ones.
The spin (or are they already in PASM) code that handles readRegister
and writeRegister calls does the dispatching of register addresses,
setting or retrieving parameters.
That's not what you said first [noparse];)[/noparse] Is there anything I can do on my side to help troubleshooting?
I'm not sure if this project is important enough for the first version of my comment [noparse]:)[/noparse] Maybe I'll send an email.
I was thinking that extending the start just a little might help, but it's pretty hard to do in the PASM. My instinct is to look at the hardware and see if there is a way to understand what it's doing, but I haven't thought much about it yet.
There are some minor things to consider in PROP.java :
1. This and the next final static int comment should say "third I/O port" and "fourth I/O" port.
/**
* A constant representing the first I/O port on the Propeller. This port
* contains pins 16-23.
*/
public final static int PORTC = 0x02FF;
2. I'm not sure, but I bet·that case statements would be faster than if-else if-else constructs in the new readPort/writePort methods. Case uses a VM bytecode so it can be done in a few microseconds for example.
I'll include your PROP.java in my lib.zip if you would be kind enough to make those changes.
Thanks.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Attached is the updated version. I have also done small type corrections.
For the switch, I was not sure. I was 2 if in the CPU code, so I just kept the same format.
File has been tested successfully for PORTC. Not yet for PORTD, but I don't see why there will be any issue with it.
@Peter, look like for Spin/PASM baby will grow [noparse];)[/noparse] When Javelin going end of life, I'm sure more people will try Java on Propeller...
Attached is a .zip that allows 6 VPs with the console port limited to 19200 baud. The JVM and VP code is the same as last posted just that 2 more VPs are available.
I've added the PROP.java to my library and will post a clean version (without .class files) on top post later.
I have an overlay design that compresses the JVM down to 1 COG from 3 COGs, but we lose over half the available Java byte-code storage space (relative to the 3 COG design). I'll devote some time integrating with VMCOG, but it will take a while to get there.
--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.
JM> I still have the same issue with "3f5678901234567890" for the LCD ...
There has been no change for VP function with pjvm6.zip just the number available since a spin only serial driver is being used.
JM> I tried with sx.start(31,30,0,19200) but it's stillk not working.
It's not clear why you need to do this. The image should "start" the console for you. You can uncomment the debug statement "sx.str(string($d,"JVM Startup"))" in pjvm6_demo.spin main to see if your propeller is talking to a console.
JM> Regarding 3 cogs vs 2 cogs vs 1 cogs, can't we target 2 cogs? That will free 1 cog, and keep some place for the byte-code?
What I'm trying to do now is make an image run where the bytecode is loaded from an external source (EEPROM) and run from within Propeller. This will mean that VMCOG will be used to fetch and save bytecode into its cache in one COG and the interpreter will run in another COG.
The net effect will be running Java programs up to size of excess EEPROM storage capacity with an extra free COG. The main concern with this will be the amount of Propeller RAM available for object references and stack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Below are some preliminary results for a 1 COG JVM solution (2nd COG for VM is not integrated yet).
As you can see it is comparable to Javelin performance for FiboTest.java (about 2x slower than the 3 COG solution).
The memory available for Java byte code and data is 15KB. This is 5KB less than the 3 COG solution, but it free's up a COG for more VPs and should allow easier integration with VMCOG. Also I'm thinking almost all of the 15KB will be available for objects and stack when the byte code is fetch-able from EEPROM or other devices via VMCOG.
Note for BradC I've hit some interesting differences between BSTC and the Propeller Tool. BSTC is more relaxed than Propeller Tool for some label usage ... I'll post the examples if/when it makes sense. Basically though, the Propeller Tool can not compile the image and because of that I don't think releasing source publicly is a good idea now.
After some testing, I'll post a binary. Meanwhile, I'll look at some optimizations and VMCOG integration.
Note for BradC I've hit some interesting differences between BSTC and the Propeller Tool. BSTC is more relaxed than Propeller Tool for some label usage ... I'll post the examples if/when it makes sense.
I know bstc is more relaxed with regard to labels for "res" definitions when accessing them from SPIN blocks. If there are other issues I'll certainly look at them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Hi BradC. I sent you a PM explaining the situation.
Meanwhile, with one optimization I was able to shave almost 2 seconds off of FIBO(24) [noparse]:)[/noparse] Basically the INVOKESTATIC (static method call) byte code got moved to the COG from HUB RAM. With that there are only a few longs left for VMCOG though ... wish me luck.
1st feedback:
SerialLCD still display the same thing, so at least, it's responding.
I'm able to see console results. (I uncommented the 2 first lines).
Seems to be an issue with the ports. My leds are not working anymore. I retried with version 0423 and it's not working. I retried with version 0422 and it's working fine. Each time, same jem.bin.
My code is very simple.
protected void init ()
{
for (int i = 0; i < maxDigits; i++)
{
portA[i] = 0; // 00111110
portB[i] = 115; // 01110011
portC[i] = 1; // 00000001
}
}
.
.
.
for (int i = 0; i < 2; i++)
{
// Fast working option for fixed pin assignation.
PROP.writePort(PROP.PORTA, portA[i]); // 00000000
PROP.writePort(PROP.PORTB, portB[i]); // 01110011
PROP.writePort(PROP.PORTC, portC[i]); // 00000000
PROP.writePin(digitPin[i], true);
PROP.delay(1);
}
[/i][/i][/i][/i][/i][/i][/i]
Make sure you have a "while(true);" infinite loop at the end of each main method.
Please attach your .java test files for me so I can reproduce the software conditions.
I'm out of Propeller time for today and will get to this tomorrow morning.
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
jmspaggi said...
So I think there is something wrong in this new version.
No doubt about that, and it's kind of expected ... sorry about that. One thing I found when debugging this one is that in the 3 COG version, there are various stubs per section that have different code. I had to choose one set of stubs, and there may still be a problem. Still, so far I've found this version much easier to debug since there is room for the debugger tool and I only need to debug one COG (my debugger has multi-cog capability, but it's more difficult to handle). On your list of issues, I'll debug this last·simple example first tomorrow then try out the RTC. One big thing that changed from 0422 to 0423 was replacing FullDuplexSingleton with SingleSerial - might want to revert that. 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.
No worries. As long as you will do new versions, I will test them [noparse];)[/noparse]
Do you think there will be a way to write 16bits registers? Instead of calling writeRegister 2 times? Maybe we can add that on the doto list [noparse];)[/noparse]
jmspaggi said...
No worries. As long as you will do new versions, I will test them [noparse];)[/noparse]
Do you think there will be a way to write 16bits registers? Instead of calling writeRegister 2 times? Maybe we can add that on the doto list [noparse];)[/noparse]
JM
[noparse]:)[/noparse]
I believe that adding a 16 bit read/write will require JNI·additions to the Javelin Direct linker. Trying this is a good building block to prove whether or not something more complicated like a QVGA LCD driver is possible (one of my end goals). We should still try to be conservative with native functions since there is a limited number available.
The Javelin Direct package can be built without Borland tools (except for the download serial port stuff which we don't need since we have BST, BSTC, and PropellerTool). If you like, I'll zip you what I have for experiments tomorrow ... I'm away from my office now.
For now I'm building the linker under MS C++, but there is a set of #ifdefs for building with linux ... I just haven't tried to make that work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Maybe there is a solution without adding a new native function?
public native static void writeRegister( int address, int valueLSB, int valueMSB );
If address is a 8 bits register, we use only value LSB. If it's a 16 bits register, we use both LSB and MSB to form a 16 bits value?
Then on java side to keep compatibility:
public static void writeRegister( int address, int value )
{
writeRegister(address, value, 0);
}
On Prop side:
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: outa[noparse][[/noparse]15..0] := value
nmPortCD: outa[noparse][[/noparse]31..16] := value
It's just a draft idea. Maybe it's a very bad one [noparse];)[/noparse] But at least, it's an idea [noparse];)[/noparse]
jmspaggi said...
Maybe there is a solution without adding a new native function?
That might work.
Add the port definitions to PROP.java, try it in your private JVM copy and let me know.
I found and fixed the bug that caused the program to stop prematurely.
On the RTC front, the return value from shiftIn was not properly shifted for LSB mode.
Try the attached zip with these fixes.
Maybe this is a clue to the SerialLCD problem? Looks like the VP TX Uart is sending a 0
at startup ... not sure why. System.out.println("") also sends 0 before end of line.
Strange. I'll look into this further on Thursday as I have a heavy schedule tomorrow AM.
--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.
Comments
It seems that I found another issue.
CPU.writePin(PROP.pin16, true); CPU.writePin(PROP.pin17, true);Turn on 2 leds on the board, when
CPU.writePort(PROP.PORTC, (byte) 3); // 00000011Is not doing anything.
writePort for PORTA and PORTB is working fine.
Regarding the DS1302, I tested it successfully in Spin. Not working in Java.
JM
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.
Invert and leading characters should be fixed. Try the attached .zip to see if most of the Uart problems have gone. Also, you must add a wait for tx complete in Uart.stop. Example:
/** * Stops the Uart. */ public void stop() { if (!started) return; //already stopped while (!sendBufferEmpty()) ; //wait until character transmitted CPU.removeVP(this); started = false; }This is to prevent restarts before the chars are done with slower bauds ... Propeller Java PASM JVM is fast enough to interfere with character timing without good message coordination. One of the fixes was to change the tail pointer only after the char is finished so that sendBufferEmpty() works.
I found one issue that needs more attention though. Seems that defining just 2 Uart VPs causes a problem. If you add any other VP like timer, etc... the problem goes away. I'll search for the root cause tomorrow.
EDIT: Previous post had "should not be fixed" ... not what I meant [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Post Edited (jazzed) : 4/22/2010 10:17:58 PM GMT
It's better, but it's still missing one char at the beginning. I got "2345678901234567890" instead of "12345678901234567890". This is with the updated Uart as suggested.
I tried to take a look at the writePort issue. Was able to find the code for writeByte, but not the one for writePort [noparse]:([/noparse]
Let me know if there is anything I can do.
JM
Both writePort and readPort are in lib\stamp\core\CPU.java near the bottom. They call CPU.writeRegister and CPU.readRegister. There is no support there currently for PORTC and PORTD. I would like to see PROP.java extend CPU.java since PROP is just a special CPU (it seems). If you feel like doing that, it would be great!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Here is the summary.
19200: "2345678901234567890"
9600: "01234567890"
2400: "3f5678901234567890" (it's a f instead of a 4)
For PROP vs CPU. I will take care of that right now.
JM
In my spin version I reserved 8 and 9 to support PORTC and PORTD.
To write to PORTC you would use CPU.writeRegister(8,value)
regards peter
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
That's not what you said first [noparse];)[/noparse] Is there anything I can do on my side to help troubleshooting?
Attached is the PROP.java file. It's quit small and simple. There was only few constants to remove, and 2 methods to overwrite. Maybe I missed things, but this version is working fine for me so far... I used the 2 values (8 and 9) reserved by Peter.
JM
As I have said earlier using writeRegister and readRegister is the way to
add functionality to existing native functions or totally new ones.
The spin (or are they already in PASM) code that handles readRegister
and writeRegister calls does the dispatching of register addresses,
setting or retrieving parameters.
regards peter
I was thinking that extending the start just a little might help, but it's pretty hard to do in the PASM. My instinct is to look at the hardware and see if there is a way to understand what it's doing, but I haven't thought much about it yet.
There are some minor things to consider in PROP.java :
1. This and the next final static int comment should say "third I/O port" and "fourth I/O" port.
2. I'm not sure, but I bet·that case statements would be faster than if-else if-else constructs in the new readPort/writePort methods. Case uses a VM bytecode so it can be done in a few microseconds for example.
I'll include your PROP.java in my lib.zip if you would be kind enough to make those changes.
Thanks.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Attached is the updated version. I have also done small type corrections.
For the switch, I was not sure. I was 2 if in the CPU code, so I just kept the same format.
File has been tested successfully for PORTC. Not yet for PORTD, but I don't see why there will be any issue with it.
@Peter, look like for Spin/PASM baby will grow [noparse];)[/noparse] When Javelin going end of life, I'm sure more people will try Java on Propeller...
JM
I've added the PROP.java to my library and will post a clean version (without .class files) on top post later.
I have an overlay design that compresses the JVM down to 1 COG from 3 COGs, but we lose over half the available Java byte-code storage space (relative to the 3 COG design). I'll devote some time integrating with VMCOG, but it will take a while to get there.
--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.
I still have the same issue with "3f5678901234567890" for the LCD, and I'm not able to see anything on the console.
I tried with sx.start(31,30,0,19200) but it's stillk not working.
Regarding 3 cogs vs 2 cogs vs 1 cogs, can't we target 2 cogs? That will free 1 cog, and keep some place for the byte-code?
I will try the DS1302 to see if it's now working.
JM
JM> I still have the same issue with "3f5678901234567890" for the LCD ...
There has been no change for VP function with pjvm6.zip just the number available since a spin only serial driver is being used.
JM> I tried with sx.start(31,30,0,19200) but it's stillk not working.
It's not clear why you need to do this. The image should "start" the console for you. You can uncomment the debug statement "sx.str(string($d,"JVM Startup"))" in pjvm6_demo.spin main to see if your propeller is talking to a console.
JM> Regarding 3 cogs vs 2 cogs vs 1 cogs, can't we target 2 cogs? That will free 1 cog, and keep some place for the byte-code?
What I'm trying to do now is make an image run where the bytecode is loaded from an external source (EEPROM) and run from within Propeller. This will mean that VMCOG will be used to fetch and save bytecode into its cache in one COG and the interpreter will run in another COG.
The net effect will be running Java programs up to size of excess EEPROM storage capacity with an extra free COG. The main concern with this will be the amount of Propeller RAM available for object references and stack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
As you can see it is comparable to Javelin performance for FiboTest.java (about 2x slower than the 3 COG solution).
The memory available for Java byte code and data is 15KB. This is 5KB less than the 3 COG solution, but it free's up a COG for more VPs and should allow easier integration with VMCOG. Also I'm thinking almost all of the 15KB will be available for objects and stack when the byte code is fetch-able from EEPROM or other devices via VMCOG.
Note for BradC I've hit some interesting differences between BSTC and the Propeller Tool. BSTC is more relaxed than Propeller Tool for some label usage ... I'll post the examples if/when it makes sense. Basically though, the Propeller Tool can not compile the image and because of that I don't think releasing source publicly is a good idea now.
After some testing, I'll post a binary. Meanwhile, I'll look at some optimizations and VMCOG integration.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 know bstc is more relaxed with regard to labels for "res" definitions when accessing them from SPIN blocks. If there are other issues I'll certainly look at them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Meanwhile, with one optimization I was able to shave almost 2 seconds off of FIBO(24) [noparse]:)[/noparse] Basically the INVOKESTATIC (static method call) byte code got moved to the COG from HUB RAM. With that there are only a few longs left for VMCOG though ... wish me luck.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
- It is only 2x slower than the 3 cog interpreter.
- This example enables 8 Virtual Peripherals.
- A SingleSerial.spin is used for console communications.
- Console is limited to 19200 baud.
- Builds with BST/BSTC/Propeller Tool.
The current plan is:- Experiment with EEPROM byte-code fetch/execute (reduces VP to 6). Will require at least 64KB EEPROM.
- Test with more java code examples.
- Get a SerialLCD module and fix the JM's issue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔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.
[noparse];)[/noparse]
I will test this new version and let you know.
For what I'm doing now (The LED display driver), I prefer a very fast JVM and need only one VP...
JM
SerialLCD still display the same thing, so at least, it's responding.
I'm able to see console results. (I uncommented the 2 first lines).
Seems to be an issue with the ports. My leds are not working anymore. I retried with version 0423 and it's not working. I retried with version 0422 and it's working fine. Each time, same jem.bin.
My code is very simple.
protected void init () { for (int i = 0; i < maxDigits; i++) { portA[i] = 0; // 00111110 portB[i] = 115; // 01110011 portC[i] = 1; // 00000001 } } . . . for (int i = 0; i < 2; i++) { // Fast working option for fixed pin assignation. PROP.writePort(PROP.PORTA, portA[i]); // 00000000 PROP.writePort(PROP.PORTB, portB[i]); // 01110011 PROP.writePort(PROP.PORTC, portC[i]); // 00000000 PROP.writePin(digitPin[i], true); PROP.delay(1); } [/i][/i][/i][/i][/i][/i][/i]I will test the DS1302 with the new version.
JM
This code:
public static void main () { System.out.println ("SerialLCDTest.java v2.2"); System.out.println ("\nStarting LCD test..."); System.out.println ("Starting UART"); Uart screenUart = new Uart(Uart.dirTransmit, PROP.pin27, Uart.invert, Uart.speed2400, Uart.stop1); System.out.println ("Sending content"); screenUart.writeString("12345678901234567890"); System.out.println ("Stopping UART"); screenUart.stop(); System.out.println ("End...");produce only that
And crash. Everything after the UART stop is not called.
With 0423 I get
And with 0422 I get up to End... but it's crashing after that.
What's strange is that I don't always receive the same result.
So I will continue to test and give you a feedback when I will found a pattern.
JM
Please attach your .java test files for me so I can reproduce the software conditions.
I'm out of Propeller time for today and will get to this tomorrow morning.
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I removed barely everything from the code:
import stamp.core.PROP; import stamp.core.Uart; public class SerialLCDTest { public static void main () { System.out.println ("SerialLCDTest.java v2.3"); System.out.println ("Waiting 2 second..."); PROP.delay(20); System.out.println ("... Done"); System.out.println ("\nStarting LCD test..."); System.out.println ("Starting UART"); Uart screenUart = new Uart(Uart.dirTransmit, PROP.pin27, Uart.invert, Uart.speed19200, Uart.stop1); System.out.println ("Sending content"); screenUart.writeString("12345678901234567890"); System.out.println ("Stopping UART"); screenUart.stop(); System.out.println ("End..."); System.out.println ("Waiting 2 second..."); PROP.delay(20); System.out.println ("... Done"); } }And here is the output:
PJVM6_DEMO from 0423 is working fine.
PJVM_DEMO from 0422 is working fine.
So I think there is something wrong in this new version.
JM
I just send the code as the same time you replied [noparse];)[/noparse]
I added the while(true) loop, and result is the same.
Good luck.
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.
Do you think there will be a way to write 16bits registers? Instead of calling writeRegister 2 times? Maybe we can add that on the doto list [noparse];)[/noparse]
JM
I believe that adding a 16 bit read/write will require JNI·additions to the Javelin Direct linker. Trying this is a good building block to prove whether or not something more complicated like a QVGA LCD driver is possible (one of my end goals). We should still try to be conservative with native functions since there is a limited number available.
The Javelin Direct package can be built without Borland tools (except for the download serial port stuff which we don't need since we have BST, BSTC, and PropellerTool). If you like, I'll zip you what I have for experiments tomorrow ... I'm away from my office now.
For now I'm building the linker under MS C++, but there is a set of #ifdefs for building with linux ... I just haven't tried to make that work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
If address is a 8 bits register, we use only value LSB. If it's a 16 bits register, we use both LSB and MSB to form a 16 bits value?
Then on java side to keep compatibility:
public static void writeRegister( int address, int value ) { writeRegister(address, value, 0); }On Prop side:
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: outa[noparse][[/noparse]15..0] := value nmPortCD: outa[noparse][[/noparse]31..16] := valueIt's just a draft idea. Maybe it's a very bad one [noparse];)[/noparse] But at least, it's an idea [noparse];)[/noparse]
JM
Add the port definitions to PROP.java, try it in your private JVM copy and let me know.
I found and fixed the bug that caused the program to stop prematurely.
On the RTC front, the return value from shiftIn was not properly shifted for LSB mode.
Try the attached zip with these fixes.
Maybe this is a clue to the SerialLCD problem? Looks like the VP TX Uart is sending a 0
at startup ... not sure why. System.out.println("") also sends 0 before end of line.
Strange. I'll look into this further on Thursday as I have a heavy schedule tomorrow AM.
--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.