@Peter: Thanks as usual for your help. This is the version I'm using on the Javelin and which is working fine. But attached is an updated improved one. It's not stopping anymore the UART each time it's sending a char in a string. Do you know if the Javelin is sending #0 on the terminal when we start it?
@BradC: Did not figured that also [noparse];)[/noparse] Just tried, and it's working fine! Thanks! Will safe me some time. Is there a way to call an external build script from BST?
@jazzed: I tried with the updated version, and it's still not working. You can count on me for the testing [noparse];)[/noparse] I'm like a kid with a brand new chrismas toy [noparse];)[/noparse] I will try the screen whitout starting/stopping the UART.
After reset the javelin transmits $50 out of pin SOUT at 28800 baud.
This signals the downloader/IDE that downloading can begin.
Regarding your LCD. If it operates at 5V you need 1k series resistor from
propeller receive pin to LCD transmit pin (if that is used).
Do not use a 1k series resistor from propeller transmit pin to LCD receive pin.
If your LCD receive pin has a pulldown resistor the signal may be weakened
(resistor divider) if you do use a series resistor.
The screen isonly 1wire. I have the ground, the +5, and the receive pin from the propeller. So I think that mean I should not add anything, correct?
But if the propeller send a 3.3V signal to say"1", and the screen is expecting a 5V signal for that is it possible that the screen never receive the signal? On the screen shopping page, there is a link to the documentation and some code www.parallax.com/Portals/0/Downloads/docs/prod/audiovis/27976-7-9-ParallaxSerialLCD-v2.1.pdf and seems that there is nothing specific for the propeller.
I will try with the screen I have on the Javelin (same model) to see if there is anything.
System.out.println ("Starting DS1302 test...");
DS1302 ds1302 = new DS1302 (CPU.pin13, CPU.pin14, CPU.pin0);
for (int i = 0; i < 10; i++)
{
System.out.println (ds1302.readTime(false));
scaledTimer.mark();
for (clock.mark(); !clock.timeout(1000);) ; // wait for one second
} // end for
Seems that the 1st issue always occur at 51. The code is the one already in this thread.
This timing issue can affect the Uarts, no? Which can be which the screen is not working?
Attached is the full code. So far SerialLCD and DS3102 are not working. TickTock seems to be working, with some small issues, and CPU pins are working fine.
I'm not really sure how to do that so I will have to wait for Jazzed to tell me.
I tried by adding jmp #GC_Ret in the first line of PASM GC function, but the issue is still there.
I also tried by commenting the only place when there is a call #gc, with no success. This last update delay the issue, it's not occuring in the first 60 seconds, but I still can see it.
JM
Update: Look like the longer the Prop is running, the more the issue is coming. Will try to run the loop for 1h.
Is there a way to call an external build script from BST?
No, not really. Because bst does not use temporary or intermediate files between the editor and the compiler, it's not really designed to work with external tools.
The whole thing is very tightly coupled, which gives it access to the compilers symbol table and other niceties without the hassle of parsing text files and the associated upkeep as formats drift (plus its *much* faster).
Admittedly PropBasic files must be on-disk to be compiled, but I modified PropBasic to feed the results back to bst through a single pipe rather than multiple generated files.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
For pjvm, we need to create the jem file from the java classes. After that, pjvmInterpreter load it to the propeller.
DAT
jemcode file "jem.bin"
jemcode_end long 0
So today, I need to have an xterm opened to run the build.sh before I go back to BST and press F11.
What will be nice to have is something like F12 which can start a configured file. We don't need this file to get information from BST, we "just" need to run it, and see the result (standard output) if any.
That way, we will be able to build the jem.bin file, push it on the prop and see the result on the console whitout going outised of BST.
I don't know if you will need WD40 or Duct Tape for that, but will be nice to have [noparse];)[/noparse]
JM
PS: Another idea will be to have a PRE-F11 option wich allow to call an external script before compiling the code. Even if this script will not received any info from BST.
jmspaggi said...
... You can count on me for the testing [noparse];)[/noparse] I'm like a kid with a brand new chrismas toy [noparse];)[/noparse] I will try the screen whitout starting/stopping the UART.
[noparse]:)[/noparse]
Good news that the CPU pins work for you.
Since I have an RTC on the PPDB, I can test that soon. I'll check more on the start/stop stuff today.
My budget for Propeller time is limited this morning however.
jmspaggi said...
... It's not stopping anymore the UART each time it's sending a char in a string. Do you know if the Javelin is sending #0 on the terminal when we start it?
There are a few small differences between Javelin and this Propeller JVM console:
1. A 0 is sent to the terminal at startup to clear the terminal screen.
2. no other special characters are sent to/from the serial terminal.
3. the default terminal baud rate is 115200.
The send 0 can be deleted by commenting out sx.tx(0) in pjvm_debug pub main.
I guess sending 0 at startup is a bad idea, but the PST has an option to detect that as clear screen. Not sure what BST does.
jmspaggi said...
Hi Peter,
I'm not really sure how to do that so I will have to wait for Jazzed to tell me.
I trying by adding jmp #GC_Ret in the first line of PASM GC function, but the issue is still there.
I also tried by commenting the only place when there is a call #gc, with no success. This last update delay the issue, it's not occuring in the first 60 seconds, but I still can see it.
JM
I've seen the TickTock anomaly and I'm not sure what's causing it.
The GC is just changing the timing of the event itself and not the root cause.
The Uarts work for me tough regardless without doing any start/stop ... see my test below.
Here is a good way to disable GC:
Find this snippet in pjvm_demo.spin and remove the ' mark before the { do garbage collection ....
'{ do garbage collection before NEW, NEWARRAY, and ANEWARRAY
cmp _mcmd, #$57 wz
if_ne cmp _mcmd, #$59 wz
if_ne cmp _mcmd, #$5b wz
if_e call #GC
'}
Below is my UART test code snippet.
import stamp.core.*;
import stamp.util.text.*;
public class UartTest
{
// Modified Program Listing 4.9 - Modem Test
final static int SERIAL_RX_PIN = CPU.pin1;
final static int SERIAL_TX_PIN = CPU.pin2;
final static int SERIAL_RTS_PIN = CPU.pin3;
final static int SERIAL_CTS_PIN = CPU.pin4;
static Uart rxUart =
new Uart(Uart.dirReceive, SERIAL_RX_PIN, Uart.invert, Uart.speed57600, Uart.stop1);
static Uart txUart =
new Uart(Uart.dirTransmit, SERIAL_TX_PIN, Uart.invert, Uart.speed57600, Uart.stop1);
public static void main() {
txUart.sendString("ATDT19166240160\r");
while (true) {
int val = rxUart.receiveByte();
//txUart.sendByte(0x55); // send UUUUUU ... another char is better for testing
System.out.print((char)val);
//txUart.sendByte(val); // send back received byte
}
}
}
There is an RS232 port on the PPDB that you can connect as a test. Using that will require a Uart.dontInvert object though.
Try the RS232 port and let me know if that works. I'll try it too. Added: I would like to try that, but I have no RS232 port uggh.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
This works for me at 57600, 38400, and 19200. However, it fails at 9600, 4800, and 2400 and lower.
With write((int)c) ... the old start/send/stop function, it fails at 9600 and 4800.
Crank your baud-rate back up to 19200 for now JM.
import stamp.core.*;
import stamp.util.text.*;
public class Junk
{
// Modified Program Listing 4.9 - Modem Test
final static int SERIAL_RX_PIN = CPU.pin1;
final static int SERIAL_TX_PIN = CPU.pin2;
final static int SERIAL_RTS_PIN = CPU.pin3;
final static int SERIAL_CTS_PIN = CPU.pin4;
static Uart rxUart =
new Uart(Uart.dirReceive, SERIAL_RX_PIN, Uart.invert, Uart.speed57600, Uart.stop1);
static Uart txUart =
new Uart(Uart.dirTransmit, SERIAL_TX_PIN, Uart.invert, Uart.speed57600, Uart.stop1);
public static void main() {
boolean testsend = true;
boolean testecho = false;
String s = "ATDT19166240160\r";
//txUart.sendString("ATDT19166240160\r");
while (testsend) {
sendString(s);
}
while (testecho) {
int val = rxUart.receiveByte();
//txUart.sendByte(0x55);
System.out.print((char)val);
//txUart.sendByte(val);
}
}
public static void sendString(String s) {
for(int n = 0; n < s.length(); n++) {
sendChar(s.charAt(n));
}
}
public static void sendChar(char ch) {
// all work just fine
txUart.start(); // ensure txUart is started for sendByte
txUart.sendByte(ch); // fails at 2400 and lower
write(ch);
write((int)ch);
}
public static void write(char c) {
// fails at 2400 and lower
txUart.start();
txUart.sendByte(c);
while (!txUart.sendBufferEmpty()) ; //wait until character transmitted
txUart.stop();
}
public static void write(int c) {
// fails at 9600 and lower
txUart.start();
txUart.sendByte(c);
txUart.stop();
}
}
My problem is that it's working fine with the MAX3232 and external terminal, but it's not working with the screen. The screen is working fine with the Javelin, and with the Propeller Code.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
TX_PIN = 15
BAUD = 19_200
OBJ
LCD : "FullDuplexSerial"
PUB Main
LCD.start(TX_PIN, TX_PIN, %1000, 19_200)
waitcnt(clkfreq / 100 + cnt) ' Pause for FullDuplexSerial.spin to initialize
LCD.str(string("Hello, this text will wrap."))
Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1);
screenUart.writeString("Wow! Its working!");
(I thought it was because of the ' )
result: " working!" is display on the screen.
Even adding a delay does'nt help.
System.out.println ("Starting SerialLCD test...");
Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1);
screenUart.start();
clock.mark();
for (clock.mark(); !clock.timeout(1000);) ; // wait for one second
screenUart.writeString("Wow! It's working!");
I don't know if this information is usefull, but I hope. I also think your Uart is "inverted". Because the screen is working as "dontInvert" usually, but not here.
Interesting ... Did you add Peter's code? ... while (!lcdUart.sendBufferEmpty()) ; //wait until character transmitted
I also had some corrupt/missing char trouble using your test code without that in SerialLCD.write((int)c).
So is the most important conclusion that my Uart is inverted from normal ? Maybe PropPlug inverts the signals ... I'll have to check.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 testing purposes, I got rid of the SerialLCD class to access the Uart directly.
System.out.println ("Starting SerialLCD test...");
Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1);
screenUart.start();
screenUart.writeString("12345678901234567890");
while (!screenUart.sendBufferEmpty()); //wait until character transmitted
screenUart.stop();
This code is displaying "901234567890" on the screen. I will try to see if we are also missing the 8 first chars when the MAX3232. Without Peter's modification, we should have miss the end of the sequence, not the begining.
Also, yes, I think it's inverted from what it should be. But not 100% sure [noparse];)[/noparse]
Ok. I'm able to reproduce and isolate the issue...
If I define only one UART with
Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1);
screenUart.start();
screenUart.writeString("12345678901234567890");
while (!screenUart.sendBufferEmpty()); //wait until character transmitted
screenUart.stop();
[noparse][[/noparse]code]
It's working fine.
But if I add
[noparse][[/noparse]code]
static Uart txUart = new Uart(Uart.dirTransmit, CPU.pin12, Uart.invert, Uart.speed19200, Uart.stop1);
before the main(), it's not working anymore.
So it looks like there is something wrong when there is more than 1 UART at the time.
>> So it looks like there is something wrong when there is more than 1 UART at the time.
Hmm, I added a static txUart to your code on a different pin and had no trouble sending to a PST terminal running on my PC from screenUart.
What happens if you add some CPU.delay in the write method for the LCD?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 both your SerialLCDTest files with a small change to use Propeller P2 for transmit on the LCD and can't get either to fail. I see the leading character problem at lower baud rates.
Also if I remove the stop() calls in SerialLCD.java write() methods, I can use baud rate down to 600 but with some noise. I have an idea to restructure the VP code a little that may get rid of the stop problem and save room for other code simultaneously. But that's for another day. I'm over Propeller Time budget now.
I'm attaching the SerialLCDTest2.java I'm testing for you to examine. At some point tomorrow I'll download the posted JVM and retest just in case there are enhancements in my directory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 tried the version you sent. I have only updated the pin number to match my shema, and I have only "90123456789" displayed on the screen. So there might be someone different in the pjvm version I have.
I also tried to update my schema to use pin2 for the LCD, but result is the same.
But if I replace the LCD by a terminal, then I'm getting all the string.
I tried also with a shorter wire with no success.
Same thing at 2400, BUT it's working fine at 9600.
So I think the screen is more sensitive to the timing than what the computer is, and that's why it's not working very well. Many components are working with a serial link, so it's pretty critical.
I will try to connect the Javelin and the Prop together and have them speaking with an UART to see if it's working too...
Yes, I think it might be timing related and so far looks like the Propeller version is faster than Javelin for complicated call/return paths (correct me on that if necessary). That's why I suggested adding a little delay. For tomorrow I plan to download and retest test that SerialLCDTest2.java file, try a few things that might fix the stop issue, fix initial character corruption at lower baud rates, and will look further into invert. Once I have a better version I will repost it.
This has been a very productive morning.
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, very productive [noparse];)[/noparse] That will be all for me for today. I had a leak over one of my temperature sensor and have to replace it [noparse]:([/noparse]
Just let me know when you will have a new version ready to test and I will try to had few more test cases.
What's strange is that if I move the screenUart creation at the beginning of the main, then it's working fine even at 19200... I still have the "\" at the beginning of the display, but at least, I have all the chars...
Comments
··public·void·write(char·c)
··{
······lcdUart.start();
······lcdUart.sendByte(c);
······lcdUart.stop();
··}
will fail because stop() removes the uart VP immediately.
Use this
··public·void·write(char·c)
··{
······lcdUart.start();
······lcdUart.sendByte(c);
····· while (!lcdUart.sendBufferEmpty()) ; //wait·until character transmitted
······lcdUart.stop();
··}
regards peter
@BradC: Did not figured that also [noparse];)[/noparse] Just tried, and it's working fine! Thanks! Will safe me some time. Is there a way to call an external build script from BST?
@jazzed: I tried with the updated version, and it's still not working. You can count on me for the testing [noparse];)[/noparse] I'm like a kid with a brand new chrismas toy [noparse];)[/noparse] I will try the screen whitout starting/stopping the UART.
JM
I'm at 2400bauds to reduce communication errors.
I have also add some trace on the files to be sure I compiled/linked the correct version [noparse];)[/noparse]
JM
PS: I think the file in the previous post was not the right one...
After reset the javelin transmits $50 out of pin SOUT at 28800 baud.
This signals the downloader/IDE that downloading can begin.
Regarding your LCD. If it operates at 5V you need 1k series resistor from
propeller receive pin to LCD transmit pin (if that is used).
Do not use a 1k series resistor from propeller transmit pin to LCD receive pin.
If your LCD receive pin has a pulldown resistor the signal may be weakened
(resistor divider) if you do use a series resistor.
regards peter
The screen isonly 1wire. I have the ground, the +5, and the receive pin from the propeller. So I think that mean I should not add anything, correct?
But if the propeller send a 3.3V signal to say"1", and the screen is expecting a 5V signal for that is it possible that the screen never receive the signal? On the screen shopping page, there is a link to the documentation and some code www.parallax.com/Portals/0/Downloads/docs/prod/audiovis/27976-7-9-ParallaxSerialLCD-v2.1.pdf and seems that there is nothing specific for the propeller.
I will try with the screen I have on the Javelin (same model) to see if there is anything.
JM
System.out.println ("Starting DS1302 test..."); DS1302 ds1302 = new DS1302 (CPU.pin13, CPU.pin14, CPU.pin0); for (int i = 0; i < 10; i++) { System.out.println (ds1302.readTime(false)); scaledTimer.mark(); for (clock.mark(); !clock.timeout(1000);) ; // wait for one second } // end forIt's the same class I'm using on the Javelin too.
JM
I think there is something wrong with the TickTock.
Ususally, there is about 1814 to to 1821 ticks for 1012 to 1015ms. But sometime, the value is quite different. The first number is an iterator.
And so on...
Seems that the 1st issue always occur at 51. The code is the one already in this thread.
This timing issue can affect the Uarts, no? Which can be which the screen is not working?
Attached is the full code. So far SerialLCD and DS3102 are not working. TickTock seems to be working, with some small issues, and CPU pins are working fine.
JM
Try your code with GC disabled.
regards peter
I'm not really sure how to do that so I will have to wait for Jazzed to tell me.
I tried by adding jmp #GC_Ret in the first line of PASM GC function, but the issue is still there.
I also tried by commenting the only place when there is a call #gc, with no success. This last update delay the issue, it's not occuring in the first 60 seconds, but I still can see it.
JM
Update: Look like the longer the Prop is running, the more the issue is coming. Will try to run the loop for 1h.
Message Edité (jmspaggi) : 4/21/2010 2:49:18 PM GMT
No, not really. Because bst does not use temporary or intermediate files between the editor and the compiler, it's not really designed to work with external tools.
The whole thing is very tightly coupled, which gives it access to the compilers symbol table and other niceties without the hassle of parsing text files and the associated upkeep as formats drift (plus its *much* faster).
Admittedly PropBasic files must be on-disk to be compiled, but I modified PropBasic to feed the results back to bst through a single pipe rather than multiple generated files.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
For pjvm, we need to create the jem file from the java classes. After that, pjvmInterpreter load it to the propeller.
So today, I need to have an xterm opened to run the build.sh before I go back to BST and press F11.
What will be nice to have is something like F12 which can start a configured file. We don't need this file to get information from BST, we "just" need to run it, and see the result (standard output) if any.
That way, we will be able to build the jem.bin file, push it on the prop and see the result on the console whitout going outised of BST.
I don't know if you will need WD40 or Duct Tape for that, but will be nice to have [noparse];)[/noparse]
JM
PS: Another idea will be to have a PRE-F11 option wich allow to call an external script before compiling the code. Even if this script will not received any info from BST.
Good news that the CPU pins work for you.
Since I have an RTC on the PPDB, I can test that soon. I'll check more on the start/stop stuff today.
My budget for Propeller time is limited this morning however.
There are a few small differences between Javelin and this Propeller JVM console:
1. A 0 is sent to the terminal at startup to clear the terminal screen. 2. no other special characters are sent to/from the serial terminal. 3. the default terminal baud rate is 115200.
The send 0 can be deleted by commenting out sx.tx(0) in pjvm_debug pub main.I guess sending 0 at startup is a bad idea, but the PST has an option to detect that as clear screen. Not sure what BST does.
I've seen the TickTock anomaly and I'm not sure what's causing it.
The GC is just changing the timing of the event itself and not the root cause.
The Uarts work for me tough regardless without doing any start/stop ... see my test below.
Here is a good way to disable GC:
Find this snippet in pjvm_demo.spin and remove the ' mark before the { do garbage collection ....
'{ do garbage collection before NEW, NEWARRAY, and ANEWARRAY cmp _mcmd, #$57 wz if_ne cmp _mcmd, #$59 wz if_ne cmp _mcmd, #$5b wz if_e call #GC '}Below is my UART test code snippet.
import stamp.core.*; import stamp.util.text.*; public class UartTest { // Modified Program Listing 4.9 - Modem Test final static int SERIAL_RX_PIN = CPU.pin1; final static int SERIAL_TX_PIN = CPU.pin2; final static int SERIAL_RTS_PIN = CPU.pin3; final static int SERIAL_CTS_PIN = CPU.pin4; static Uart rxUart = new Uart(Uart.dirReceive, SERIAL_RX_PIN, Uart.invert, Uart.speed57600, Uart.stop1); static Uart txUart = new Uart(Uart.dirTransmit, SERIAL_TX_PIN, Uart.invert, Uart.speed57600, Uart.stop1); public static void main() { txUart.sendString("ATDT19166240160\r"); while (true) { int val = rxUart.receiveByte(); //txUart.sendByte(0x55); // send UUUUUU ... another char is better for testing System.out.print((char)val); //txUart.sendByte(val); // send back received byte } } }There is an RS232 port on the PPDB that you can connect as a test. Using that will require a Uart.dontInvert object though.
Try the RS232 port and let me know if that works. I'll try it too. Added: I would like to try that, but I have no RS232 port uggh.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/21/2010 3:08:39 PM GMT
No worries for the time you have to spent on that today. I also have a fulltime job [noparse];)[/noparse] So I can't spend to much too.
Regarding the Garbage, I tried what you asked above, and issue is still occuring.
I tried the UART with a loopback, and it seems to be working fine. I will have to do more robust tests.
I will also try with another computer console to see if data are corrects after the MAX3232E...
JM
With write((int)c) ... the old start/send/stop function, it fails at 9600 and 4800.
Crank your baud-rate back up to 19200 for now JM.
import stamp.core.*; import stamp.util.text.*; public class Junk { // Modified Program Listing 4.9 - Modem Test final static int SERIAL_RX_PIN = CPU.pin1; final static int SERIAL_TX_PIN = CPU.pin2; final static int SERIAL_RTS_PIN = CPU.pin3; final static int SERIAL_CTS_PIN = CPU.pin4; static Uart rxUart = new Uart(Uart.dirReceive, SERIAL_RX_PIN, Uart.invert, Uart.speed57600, Uart.stop1); static Uart txUart = new Uart(Uart.dirTransmit, SERIAL_TX_PIN, Uart.invert, Uart.speed57600, Uart.stop1); public static void main() { boolean testsend = true; boolean testecho = false; String s = "ATDT19166240160\r"; //txUart.sendString("ATDT19166240160\r"); while (testsend) { sendString(s); } while (testecho) { int val = rxUart.receiveByte(); //txUart.sendByte(0x55); System.out.print((char)val); //txUart.sendByte(val); } } public static void sendString(String s) { for(int n = 0; n < s.length(); n++) { sendChar(s.charAt(n)); } } public static void sendChar(char ch) { // all work just fine txUart.start(); // ensure txUart is started for sendByte txUart.sendByte(ch); // fails at 2400 and lower write(ch); write((int)ch); } public static void write(char c) { // fails at 2400 and lower txUart.start(); txUart.sendByte(c); while (!txUart.sendBufferEmpty()) ; //wait until character transmitted txUart.stop(); } public static void write(int c) { // fails at 9600 and lower txUart.start(); txUart.sendByte(c); txUart.stop(); } }Sample output:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/21/2010 3:56:29 PM GMT
But the screen is configured at 19200 and it's still not working.
Strange. Look like only that is not working. I will try the Propeller Demo for the screen to see if it's working...
JM
Also if I use only txUart.sendByte(c) and Peter's version of write(c), it works down to 4800 baud.
I'll have to look at 2400 and 1200 baud.
Added: For some reason, without txUart.start(), txUart.sendByte(c) by itself eventually stops. Does this happen on Javelin?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/21/2010 4:07:29 PM GMT
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 TX_PIN = 15 BAUD = 19_200 OBJ LCD : "FullDuplexSerial" PUB Main LCD.start(TX_PIN, TX_PIN, %1000, 19_200) waitcnt(clkfreq / 100 + cnt) ' Pause for FullDuplexSerial.spin to initialize LCD.str(string("Hello, this text will wrap."))But is not working with my code.
So I tried to play with the parameters.
Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.dontInvert, Uart.speed19200, Uart.stop1); screenUart.writeString("Wow! It's working!");Result: Dummy char on the screen.
Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1); screenUart.writeString("Wow! It's working!");result: "s working!" is display on the screen.
Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1); screenUart.writeString("Wow! Its working!");(I thought it was because of the ' )
result: " working!" is display on the screen.
Even adding a delay does'nt help.
System.out.println ("Starting SerialLCD test..."); Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1); screenUart.start(); clock.mark(); for (clock.mark(); !clock.timeout(1000);) ; // wait for one second screenUart.writeString("Wow! It's working!");I don't know if this information is usefull, but I hope. I also think your Uart is "inverted". Because the screen is working as "dontInvert" usually, but not here.
JM
Only the first chars are missing. After, it seems to be working fine.
System.out.println ("Starting SerialLCD test..."); Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1); screenUart.start(); clock.mark(); for (clock.mark(); !clock.timeout(1000);) ; // wait for one second screenUart.writeString("Wow! It's working!"); SerialLCD screen = new SerialLCD(screenUart); screen.backLightOn(); screen.blinkOff(); screen.cursorOff(); screen.clearScr(); screen.moveTo(SerialLCD.LINE2, 2); screen.write("Wow! It's working!");This code display "s working!", then clear the screen, remove the cursor and so on, and display the full text perfectly.
JM
I also had some corrupt/missing char trouble using your test code without that in SerialLCD.write((int)c).
So is the most important conclusion that my Uart is inverted from normal ? Maybe PropPlug inverts the signals ... I'll have to check.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 testing purposes, I got rid of the SerialLCD class to access the Uart directly.
System.out.println ("Starting SerialLCD test..."); Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1); screenUart.start(); screenUart.writeString("12345678901234567890"); while (!screenUart.sendBufferEmpty()); //wait until character transmitted screenUart.stop();This code is displaying "901234567890" on the screen. I will try to see if we are also missing the 8 first chars when the MAX3232. Without Peter's modification, we should have miss the end of the sequence, not the begining.
Also, yes, I think it's inverted from what it should be. But not 100% sure [noparse];)[/noparse]
JM
If I define only one UART with
Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1); screenUart.start(); screenUart.writeString("12345678901234567890"); while (!screenUart.sendBufferEmpty()); //wait until character transmitted screenUart.stop(); [noparse][[/noparse]code] It's working fine. But if I add [noparse][[/noparse]code] static Uart txUart = new Uart(Uart.dirTransmit, CPU.pin12, Uart.invert, Uart.speed19200, Uart.stop1);before the main(), it's not working anymore.
So it looks like there is something wrong when there is more than 1 UART at the time.
JM
Hmm, I added a static txUart to your code on a different pin and had no trouble sending to a PST terminal running on my PC from screenUart.
What happens if you add some CPU.delay in the write method for the LCD?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Only one very small difference...
When you tried, have you try the 2nd UART you have created? Or the 1st one?
Also, with exemple 2, the output is "\12345678901234567890" like is there was someone remaining in the UART queue after the initialization...
I will try to reduce the code has much as possible to have only the UARTs and see if it's still failing.
JM
Because if you take exemple 1 above, which is not working, and you comment the Timer block above the Uart, then it's working... Timer is another VP.
I will continue to investigate and find the smallest not working code as possible.
JM
The issue seems to be in the 3rd VP.
This is not working:
import stamp.core.CPU; import stamp.core.Timer; import stamp.core.Uart; public class SerialLCDTest { static boolean tick=true; public static void main () { System.out.println ("SerialLCDTest.java v2.0"); Timer clock = new Timer(); Uart txUart = new Uart(Uart.dirTransmit, CPU.pin12, Uart.invert, Uart.speed19200, Uart.stop1); Uart screenUart = new Uart(Uart.dirTransmit, CPU.pin15, Uart.invert, Uart.speed19200, Uart.stop1); screenUart.writeString("12345678901234567890"); } }But just comment the clock or the Uart, and then it's working fine.
I also tried with 2 Uart instead of 1 uart + 1 timer, and same thing.
//Timer clock = new Timer(); Uart txUart1 = new Uart(Uart.dirTransmit, CPU.pin12, Uart.invert, Uart.speed19200, Uart.stop1); //Uart txUart2 = new Uart(Uart.dirTransmit, CPU.pin12, Uart.invert, Uart.speed19200, Uart.stop1);Comment 2 VPs, and it will work. Comment 1 VP, it will fail, which ever VPs you keep.
Not sure I can go deeper. Let me know if there is anything I can do.
JM
I tried both your SerialLCDTest files with a small change to use Propeller P2 for transmit on the LCD and can't get either to fail. I see the leading character problem at lower baud rates.
Also if I remove the stop() calls in SerialLCD.java write() methods, I can use baud rate down to 600 but with some noise. I have an idea to restructure the VP code a little that may get rid of the stop problem and save room for other code simultaneously. But that's for another day. I'm over Propeller Time budget now.
I'm attaching the SerialLCDTest2.java I'm testing for you to examine. At some point tomorrow I'll download the posted JVM and retest just in case there are enhancements in my directory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 tried the version you sent. I have only updated the pin number to match my shema, and I have only "90123456789" displayed on the screen. So there might be someone different in the pjvm version I have.
I also tried to update my schema to use pin2 for the LCD, but result is the same.
But if I replace the LCD by a terminal, then I'm getting all the string.
I tried also with a shorter wire with no success.
Same thing at 2400, BUT it's working fine at 9600.
So I think the screen is more sensitive to the timing than what the computer is, and that's why it's not working very well. Many components are working with a serial link, so it's pretty critical.
I will try to connect the Javelin and the Prop together and have them speaking with an UART to see if it's working too...
JM
Yes, I think it might be timing related and so far looks like the Propeller version is faster than Javelin for complicated call/return paths (correct me on that if necessary). That's why I suggested adding a little delay. For tomorrow I plan to download and retest test that SerialLCDTest2.java file, try a few things that might fix the stop issue, fix initial character corruption at lower baud rates, and will look further into invert. Once I have a better version I will repost it.
This has been a very productive morning.
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, very productive [noparse];)[/noparse] That will be all for me for today. I had a leak over one of my temperature sensor and have to replace it [noparse]:([/noparse]
Just let me know when you will have a new version ready to test and I will try to had few more test cases.
JM
JM