Serial Rx problem, Evolving post...

Joms · 2009-03-27 22:43

Can you set an entire string = to 0 just with this line?· Or is there a different command to clear the var?· I didn't see anything that does that other then := in the manual...

VAR
· Byte· MyStr[noparse][[/noparse]Data#MaxStrLength]·

mystr := 0

This is just one line of my code...· The string is about 22 bytes long...

Thanks...

Post Edited (Joms) : 4/1/2009 9:08:03 PM GMT

mctrivia · 2009-03-27 22:46

no you can't.

You need to do

Byte[noparse][[/noparse]MyStr]:=0

strings are pointers. so Byte:=0 sets the string to start at the begining of your code. Byte[noparse][[/noparse]MyStr]:=0 sets the first byte of the string found at MyStr to 0

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

Mike Green · 2009-03-27 22:52

Do you want to initialize the string to empty or to a single zero character? To initialize it to empty, you need to set the first byte to a zero with MyStr[noparse][[/noparse] 0 ] := 0.

If you want to set it to a single zero character, you can use BYTEMOVE(@MyStr,string("0"),2). This copies the zero character, then a zero byte to terminate the string.

Joms · 2009-03-27 22:59

I think I want to initialize the string to empty... I am trying to use your extendedFDS object to input a string of data. It will work correctly one time, then each time I repeat, it just gives me junk. If I reset the prop it will give me one good line of code again.

So my thinking is that I need to clear it each time before I resave it.

EDIT:

I have tried both 'Byte[noparse][[/noparse]MyStr]:=0' and 'MyStr[noparse][[/noparse] 0 ] := 0'. Neither seem to work the way I want. I am going to try moving them to a few different places and look the commands up in the manual to see how they actually work.

Thanks for the help. Please let me know if you have any other ideas...

Post Edited (Joms) : 3/27/2009 11:06:35 PM GMT

Mike Green · 2009-03-27 23:06

There may be something else you're doing wrong. Extended FDS provides the address of a work area within the object and that work area is reused every time you call Extended FDS and it returns a string address. Post your code (as an attachment) and maybe one of us can tell you what's wrong.

Joms · 2009-03-27 23:13

Sorry for the messy code.

This is a test code that Stefan helped me start.

Basically it outputs a command to a piece of equipment to get the equipment to send a string of data out.· Then it will display the string on the Debug output.

The problem is the code works 1 time, then it seems to keeps shifting the·newly inputed·string·left about 8 spaces everytime the program repeats.

I think that I need to try to clear that MyStr variable out before I try to input new data...

I also put a screenshot on real quick that better shows what I am getting out...

Post Edited (Joms) : 3/27/2009 11:30:11 PM GMT

mpark · 2009-03-28 00:48

mctrivia said...
no you can't.

You need to do

Byte[noparse][[/noparse]MyStr]:=0

strings are pointers. so Byte:=0 sets the string to start at the begining of your code. Byte[noparse][[/noparse]MyStr]:=0 sets the first byte of the string found at MyStr to 0

Actually that's incorrect. MyStr is not a pointer, it's an array of bytes (MyStr[noparse][[/noparse] 0], MyStr[noparse][[/noparse] 1], etc.)

And MyStr by itself is the same as Mystr[noparse][[/noparse] 0]. Byte[noparse][[/noparse]Mystr] is not the first byte of MyStr; Byte[noparse][[/noparse]@MyStr] is.

Post Edited (mpark) : 3/28/2009 12:57:15 AM GMT

Joms · 2009-03-28 01:08

I thought adding the '@' symbol address operator just made it a global between multiple objects?

Joms · 2009-03-28 01:25

OK, I am even more confused now...

I have a short pause line 'waitcnt(clkfreq * 2 + cnt)' in my code. If I change the number to a 3 (ie, delay 3 seconds), it doesn't input. Why in the world would this have any affect on inputing the string!?!?

Greg LaPolla · 2009-03-28 03:56

Joms,

In reviewing your code I see this:

Var
  'ATTENTION !!!
  'to avoid datacrashing you have to use the value of the constant MaxStrLength
  'of the object Extended_FDSerial_128ByteBuffers !
  'For the bytearrays that are used for received strings. 
  'The value of this constant can be accessed by writing objectname#constantname 
  Byte  MyStr[noparse][[/noparse]Data#MaxStrLength]

I am not familiar with the object Extended_FDSerial_128ByteBuffers

but I don't see where MaxStrLength is defined.

Greg

Mike Green · 2009-03-28 04:02

Greg,
MaxStrLength is defined in Extended_FDSerial_128ByteBuffers. The "Data#" notation shows that it's defined in the object declared as "Data".

Joms,
I don't see why you'd get the behavior you describe using Extended_FDS and you're using a modified version of that. Maybe there's an error in the modification. How about posting the modified version?

Post Edited (Mike Green) : 3/28/2009 4:12:34 AM GMT

Joms · 2009-03-28 04:02

It is defined in the Extended_FDSerial_128ByteBuffer object. From what I can tell it is supposed to automatically make the array the same length as the string I am trying to input. I did try changing the byte to MyStr[noparse][[/noparse]32], which is the length of the string I am attempting to load. That actually makes the problem worse because I can not make it work at all.

Something very strang is going on because if I change the waitcnt the program will stop working. I will admit I don't completely understand the serial communications, but when I did this on a stamp it work perfectly... I am just trying to move my program to a propeller so I can do a lot more including video out, and parrallel processing...

Mike Green · 2009-03-28 04:17

Regarding the WAITCNT ... The only thing that makes sense for the program not working with a 3 second delay is that the other end of the connection (the "equipment") may have a timeout that gets triggered past 2 seconds. I don't see anything in the Spin code that would account for what's happening. Again, I don't know what the modified Extended FDS does. I assume that the serial I/O buffers are larger, but nothing else hopefully.

StefanL38 · 2009-03-29 06:07

Hello Joms,

from looking at your attached screenshot I see several things
the string that you receive has a lot of blanks in between
the string is estimated more than 60 characters long with all the blanks (and not 22 characters as you wrote)

the second receive seems to be the right end of a correct received string

For analysing this I suggest: make an serial Y-cable that makes it possible to connect a PCs COM-Port AND the prop to the device at the SAME TIME
This will make it possible to see everything on the PC what the prop receives.

As brays terminal is known to work properly - did you make a test using brays terminal as the partner of the device?
sending out the request string from brays terminal several times and see what you receive ?

Another approach is to simulate the device with the Script-function of the terminalsoftware Br@ys terminal
you send out your ORIGINAL request string to brays terminal and if braysterminal has received this string
it sends out the SAME answer as the device

to get the ORIGINAL answer use the copy and paste function when having received a string from the device
(NOT anything type by yourself)

In the meantime attach your actual code to a posting using the attachment-manager of the forumm software that we can take a close look at it

One thing I did see. In another posting you wrote the device is connected to Pins 27/26
in the code in the screenshot pins 26/25 are assigned is this correct ?

best regards

Stefan

Joms · 2009-03-30 16:01

The blanks are actually tabs (09) that the device is sending out.· It does send more then 22 but I only care about the first 22.· I think it sends around 30ish.

I have a y cable hooked up and when I look at the data directly into the computer it looks fine everytime.· Mike Green thought that maybe it was because the device I am interfacing to was timing out, I did the Y cable to check that theory.

In another post Stefan helped put together a test file for me that would let me loop back the data that I output.· I spent about a day playing with it and learning how the rx functions work.· I found that they are not much different then the basic stamp.

As for the pins 26/27, 25/26.· I did move the pins down a number.· I am trying about everything I can think of to get to the buttom of this problem.· I thought maybe, just maybe I had damaged the pin I was using to rx.· That is why I moved them down.

When I get home in awhile I will post my actually code that I am using.· It is basically the exact same as I posted earlier in this post.

Question - It appears that the PUB rxstr function works like serin command of the stamp.· Is this true?· Will it wait at that line of code until it does receive the string?· If I use the rxstrtime, then it would timeout automatically after the set ms that the string does not output?· I assume this is how it is working?· If not, is there a way to make it wait, because I am thinking that maybe the device I am connected to is not outputing the string fast enough and the prop goes right past, or just catches the second half of my input data...

Mike Green · 2009-03-30 16:08

One of the advantages of having source code for included object is that you can examine it.

rxstr uses the rx function which does wait for a character indefinitely. rxstrtime uses rxtime which waits the specified amount of time for a character and quits when a timeout occurs. One way to see if that's causing a problem is to set a large timeout, on the order of several seconds, and see what happens and when.

Joms · 2009-04-01 21:04

Thanks Mike and Stefan...·· I have been going through the code and serial drivers and this is the conclusion I come to on how they work...

When using PUB rxstr it will wait until any byte is received, then receive the string until 1 of 3 things happens.· Either it gets a hex 13 (carriage return), gets to the delimiter, or reaches the max number of bits...

Question - Really for my program I would like to set the delimiter to 04, which is EOT or end of transmittion.· When I change the delimiter for the default (",") to (04) I can not make it work at all.· I did not completely understand the delimiter so I looked it up on·wikipedia and I believe I should be able to change it from a "," to an EOT, is that correct?, should it still work that way?

Basically after hours of analyzing this problem it appears that it brings in the string complete like I want it to, then the next time it only brings in the last 4 charactors, and repeats that same pattern with the exception of bringing in some junk every so often (about every 10 lines).

I did post my complete test code.· The SerialOut-Test128ByteBuffer is my top object...· If someone could please give me something else to try it would help a lot.· I think I am missing something pretty simple here because when I do a loop back I can make it work.

PS. When I monitor what is going into the prop with a y cable going to the serial port, I see the string I am trying to input, perfect everytime...

StefanL38 · 2009-04-02 00:11

Hello Joms,

all I can do by the infos provided by you YET
is to test your code with bray's terminal software but with strings created BY ME

What I found out you should do call

Data.rxflush DIRECT before Data.rxstr(@mystr)

comment out the WaitCnt
also ACTIVATE the MyStr[noparse][[/noparse]0] := 0

I wrote I script for brays terminal that simulates your sensor.
As long as the scripts really WAITS for the "EOT" it is working.
I even commented out the "wait for CR as delimiter of a string inside PUB str of Extended_FDSerial_128Bytebuffers)

As soon as the script does send strings ALL the time the received strings are different. (without leading characters)

And that's clear:
while you're waiting - more and more bytes come in fill up the 128bytebuffer and if this buffer is FULL
the oldest bytes get overwritten and then you have a messed up string

This is only a SIMULATION to get closer to reality I need MORE information from YOU

best thing would be to have a protocol of what your sensor is sending with timestamps of each string even with milliseconds when the were sended

As I have no second COM-Port laying around here I modified your code to use pins 31,30 for everything
You have to change the debugoutput BACK to the debug-object otherwise your sensor will get confused by the addional bytes send for debugoutput

The best way to post code is to use the archive-function of the Proptool
just go into your topobjectfile in the proptool and click in the main-menu of proptool

File - Archive - Project -
the created ZIP-file will include ALL files needed to compile the whole project automatically

If this version does not work with the sensor the detailed information above is needed to analyse it more

HAVE a REALLY close look at the REALLY LAST byte that is send by the sensor
You should analyse this by looking at the HEX-code of the received string with a terminalsoftware
As my simulation works with delimiter 04 I guess the sensor does NOT send a 04

From 25 years experience in programming I can tell:
you have to analyse EVERY DAMMED DETAIL to find the bug !
Even things that you think of "this is common and well done" CHECK it in DETAIL

best regards

Stefan

Joms · 2009-04-02 01:09

OK, Thanks again for the help.· Here is the string I am trying to input, hopefully this will help...

06· 01· 4E· 30· 4A· 51· 09· 30· 30· 30· 30· 09· 30· 31· 09· 4E· 09· 4E· 09· 30· 30· 31· 46· 09· 30· 30· 30· 30· 30· 30· 30· 33· 09· 09· 09· 37· 46· 04

This is the string EXACTLY as it is output from the device I am connecting to.· I used "free serial port monitor" to monitor the serial port.· It takes .0901 seconds to respond with this data after my string of data is sent out of the prop.

My end goal is to input the 4 hex characters that are in bold and use them somewhere else in the program.

The file you modified for me did not work at all, as far as it does not seem to record the string to the variable.· However, I do think the string is being inputed as it does debug all the steps on the debug output.· (I did set the program up for debug and data again for this test, but I was extreamly careful)...

I can not seem to figure out where I am going wrong...

Post Edited (Joms) : 4/2/2009 1:17:29 AM GMT

StefanL38 · 2009-04-02 11:26

Hello Joms,

so now I took the efoort of setting up my PPDB for two serial connections to brays terminal
and a scriptfile that sends your sensorstring to the propeller.

in the attached archive you find the code that IS RUNNING
EVEN if the simulated sensor sends his string every 96 milliseconds WITHOUT ANY requests

if you do the rxflush not RIGHT before the rxstr or if you have a codeline waitcnt inside PUB Getsource
I receive wrong strings

If this code is running in yout setup too I guess your sensor is doing something else than you think until now

My suggestion is:

start with sending only the FIRST request-byte and see what is happening
YES i mean send NOT the complete request-sequence but JUST ONE BYTE

see what is happening

add the second request byte see what is happening
add the third request byte see what is happening etc. etc.

to find out WHEN is the snesor answering

another question:
what is the reason to send a 06 AFTER receiving the string from the sensor ?
(end of PUB GetSource)

best regards

Stefan

Joms · 2009-04-02 20:39

I think I am starting to understand this problem...· First off Stefan, I would like to express my sincere thanks for all of the extra effort your have put forth on this long problem I have been having, and for all the help you have been learning the prop.

I did the tests you explained.· It does not respond until I send the '04' meaning End Of Transmission.· The reason I added the '06' after the receive is to send an acknowledge command to the sensor.· If I do not do this the sensor keeps sending the same string of data every 1 second until is receives another response.

So here is what I think is going on and why I have a problem...·· I send the transmission correctly but the propeller does not switch to the receive command fast enough after sending the 'end of transmission' byte.· Thus it has to wait until the second time the sensor sends the command and puts that 'on-top' of what is already stored in the buffer.

So basically, does this mean that the stamp is not fast enough to switch from transmitting bytes to receiving the input string?· If so, is it possible to speed this process up on the prop?

---EDIT---
OK, I tried the PreTest file you attached.· It is doing the same thing as basically every code I have tried.· When I run the code with my sensor hooked up it will show all of the proper debug information except where the string is supposed to go.· It just displays <>.· The string should be between it.· Here is the interesting part though... I know it is receiving the string, because if I unhook my sensor the program will just sit waiting for the string to be inputed.·· Hmmmm....Any ideas?

Post Edited (Joms) : 4/2/2009 9:21:02 PM GMT

StefanL38 · 2009-04-03 06:10

Helo Joms,

did you test the Pre-Test-Program with a terminalsoftware to make sure it receives properly at all ?
I want to make sure it is an software-issue and not a hardware issue that can't be solved by software

Explicit question and I woud like to have an explicit answer:
Did you test the Pre-Test-Program with Bray's terminal and the SCRIPT below PUB GetSource ?

the Propeller IS fast enough.
The FullDuplexSerialdriver and derivates can handle up to 115200 bauds and FullDuplex means send AND receive at the SAME time.

If your sensor stops sending the command after receiving the acknoledge-code "06" I would do the following

Do I remember right that you have received ANY bytes I mean more than just an empty string < > ?

take the pre-Test-program and

- comment out the acknowledgebyte "06" so the sensors keeps on sending

- comment out the call of

  Data.rxflush

see what is happening

change the call of

  Data.rxstr(@mystr)                                       'Store string from equipment

to a call of

  Data.rxstrTime(,500@mystr)                                       'Store string from equipment

and watch if you receive something different

and vary the Timeout-length from 1 millisecond up to 1000 miliseconds using the "add/substract the half"

start at timeout 1000
if you receive more than nescessary
reduce to 500
if you receive too less take 750
if you receive too much take 250
etc. etc.

I have attached a version of Pre-Test... that does ONE request to the sensor
and then repeats receiving a string with debugoutput in ASCII-Code AND in Hexcode

ATTENTION here ! I changed the baudrate of the debugoutput from 9600 to 115200 to make it faster

Post Edited (StefanL38) : 4/3/2009 6:19:15 AM GMT

Serial Rx problem, Evolving post...

Comments