sending an "enter" to the prop through the serial port

realolman1

I am using

sio = parallax serial port    
minutes:=sio.decIn(variable)

in a spin program, to receive info from the serial port.

if I use the parallax serial terminal it works ok.

I would like to send the same info automatically from a VB.net program, but the prop doesn't recognize anything I've been sending as an "enter" ......Chr(10) Chr (13) vbCr vbCrLf

What do I need to send serially to the prop, using VB.net, that the propeller will recognize as an enter keystroke and move past the decIn(variable)?

thank you

Duane Degn

The method "DecIn" in the object "Parallax Serial Terminal.spin" using the ASCII character #13 to identify the end of the number.

There's something else causing the problem.

realolman1

Please find attached the code.
I have LED's that indicate where I'm at in the "if action =="s" "

If I do this by hand, using parallax serial terminal it works OK, but it won't go past the first DecIn by sending the stuff from a VB program.

On the character chart 16 is a triangle... why is 13 not two lines... one at the top and one at the bottom?
How does DecIn tell the difference when it's supposed to be a control code?

realolman1

actually I forgot to attach the code

Duane Degn

I don't know why your program doesn't advance part the first DecIn call. My guess it's an issue with the way the serial port is handled within the VB program.

realolman1 wrote: »

On the character chart 16 is a triangle... why is 13 not two lines... one at the top and one at the bottom?
How does DecIn tell the difference when it's supposed to be a control code?

The character chart isn't the same as ASCII characters. These are the characters stored in the Propeller's ROM.

When character 13 is used as text within a program (such as when using these characters to display schematics), the character isn't stored as an ASCII character, rather it's stored as a Unicode character. A Unicode character uses two bytes per character rather than a single byte used by ASCII characters. I think ASCII characters are actually only 7-bits. I don't understand the exact details of how Unicode works verses the way ASCII works but I am sure the method DecIn uses a carriage return to identify the end of a series of numeric characters.

Are you sure your VB program is sending ASCII characters and not Unicode characters?

I have a couple comments on your program.

PUB main
    'start in new cog

    StackSpaceComms :=20     
    cognew(Communicate,@StackSpaceComms)
    coginit(8,second_timing,@StackSpaceArrayChecker)
    

Rather than starting a new cog for the "Communicate" method, you could instead just call the Communicate method at the end of your main method.

I'd suggest changing your main method to:

PUB main
    'start in new cog
    
  cognew(second_timing, @StackSpaceArrayChecker)
  Communicate
    

The command coginit can get you into trouble. Cogs are numbered from zero to seven. I'm not sure what happens when you try to start cog #8. My guess is the Propeller will attempt to use cog #0. I suggest using cognew when starting a new cog so the Propeller will automatically assign an available cog.

Do you have a USB to serial device you can use as a second serial channel? It may be helpful to use a second serial driver to send debug statements to a separate com port. I frequently use the debugging technique when I work on Android apps which communicate with a Propeller.

realolman1

thank you for all your help. I will look into everything you said . I see that the cogs ARE 0-7. There is indeed no 8 ..So that's a probably a problem right off.

I was hoping that the program was going to get considerably larger, and I was willing to devote 2 cogs to timing and communication. I have been having a heck of a time with this, though

The spin program does advance using the PSTerminal, so it has to be something that is going on with the VB stuff... I see the appropriate number of serial activity on the prop plug, timed way slow enough between. Things that don't require an "enter" work OK ...like the CharIn

I bet what you said about the VB program and Unicode is right though.

I also seem to recall something in the "old days" about using an "escape character" ....Chr(27) comes through the fog. I have been able to find just about nothing re: VB,net and sending an "enter" keystroke serially... I suppose, thinking about a typewriter, that would be a carriage return and a line feed... VB has a vbCrLf ... I wouldn't know why that would be anything but a control character.

thank you

Duane Degn

realolman1 wrote: »

VB has a vbCrLf

The carriage return, line feed pair are frequently used to indicate the end of a message. These are ASCII characters 13 and 10.

I'm pretty sure the extra line feed character (10) just gets ignored by your program.

Duane Degn wrote: »

Do you have a USB to serial device you can use as a second serial channel? It may be helpful to use a second serial driver to send debug statements to a separate com port.

If you have an additional USB to serial device you could monitor the characters coming from the VB program.

I often add a method which will display ASCII control characters as their hex values. I'll post one of these methods you could use if you have an USB to serial device handy.

Duane Degn

Here's an example of a method I used to display ASCII characters.

PRI SafeTx(localCharacter)

  if localCharacter => 32 and localCharacter =< "~"
    Pst.Char(localCharacter)
  elseif localCharacter == 0 ' this may need to be changed if monitoring raw data
                             ' "Parallax Serial Terminal" doesn't catch framing errors
                             ' so without this "elseif" line you can end up with a
                             ' bunch of zeros if a line is inactive. 
    return
  else
    Pst.Char("<") 
    Pst.Char("$")
    Pst.Hex(localCharacter, 2)
    Pst.Char(">")

If the text "Hello World" were received along with a carriage return and a line feed you'd see the following in the terminal window.

Hello World<$0D><$0A>

Normally the received characters would need to be sent to the "SafeTx" method as each were received.

This assumes you have a way of displaying characters in a terminal window. If your main serial line is receiving text from the VB program, you'll need to have a second serial connection to use a terminal window.

realolman1

Good grief , man you certainly are forthcoming with help. I appreciate it very much

I am afraid I don't understand what you are doing, and I don't have anymore USB to serial devices

I am going to try a thing or two (more), and if I can't figure it out, I will post and maybe you will be inclined to take a look at it.

thank you

realolman1

Duane Degn.

Since you were so kind as to try and help me ( rather generously and profusely I might add) I thought that it would only be right to tell you what I discovered.

In my VB program I had to put a delay between the sending of the decimal and the sending of the Chr(13) I had delays between the Chr(13) and the NEXT decimal, but not between the decimal and the "enter"

seems that about 0.1 second delay is about the shortest reliable delay between sending the decimal and sending the "enter" ...0.075 doesn't work

the baud is set at 115200, and OCCASIONALLY the propeller program was moving past the FIRST DecIn .

I guess that would be the framing error you mentioned in your post that the propeller doesn't catch.


Anyway, I think this will cure it... it seems reliable now
thank you very much for your help.

MrBi11

As opposed to needing a separate serial port setup to debug, the one pin TV that would require less hardware.
http://obex.parallax.com/object/438

doubstops102

With no mass storage, one had to load software into the machine by typing it into the "Woz monitor" — this is the program that occupies the 256 bytes of ROM at the top of the machine's memory. It allows the user to program values into the machines memory, read values from the memory, and have the processor jump and start executing at a particular location. So for example, to tell the monitor to program sixteen bytes at memory locations 6000 through 600F (all numbers are expressed in hexadecimal) you would type in:

Duane Degn

I like MrBi11's suggestion of using a video display as a debugging aid.

If you have a second Propeller board with a USB connection, it could be used as a serial bridge. This would allow you to monitor the data sent from the VB program.