Anyone worked with the FullDuplexSerial-4port object? - rx question

Joms

I am trying to use the FullDuplexSerial-4port object from the object exchange and having some problems with the receive commands.

I have a serial port monitor program that is hooked to the same pin goin into the propeller so I do know the stamp is actually receiving the correct data.· It is a string of about·22 hex charactors...

I have tried both rxtime and rx.··Below is a sample of the code I am trying to use, I have 22 lines with 22 variables.

· rx1 := Data.rxtime(0,100)
·
··· (lines 2 thru 21 here)
··rx22 := Data.rxtime(0,100)

I actually just ignore the first 18 variables because I am only looking for 19,20,21,22 for this application.

Also, I have had to set the object to invert the tx pin and wondering if that is my problem on the rx pin.· Problem is I can not figure out how to invert the rx and the tx pin at the same time.

Please let me know any ideas on this as this is the first time I have had to receive the the prop, until now I have only had to transmit.· Also please let me know if there is any good documents out there for learning how any serial communication works, other then the manual as I have already looked through that.

Thanks...· Joms

Mike Green

All of the FullDuplexSerial calls receive a single character, not a value. There's an object called Extended FullDuplexSerial that calls FullDuplexSerial and handles various kinds of numeric and string input.

Joms

Thanks Mike...I think I understand that...· I am trying to combine the extended serial object with the 4 port serial object but having problems with that.· I am wondering if·I need to invert the RX.

Do you, or anyone else, know of a way to invert both the receive and the transmit pins at the same time?· I have found how to to just transmit, or just receive, but not both.· Am I missing something here?· (this is on the fullduplexserial-4port object)

Thanks...

StefanL38

Hello Joms,

if you take a close look onto the constants for the different modes you can see that in each constant only ONE bit is set high

  INVERTRX                      = %000001
  INVERTTX                      = %000010
  OCTX                          = %000100
  NOECHO                        = %001000
  INVERTCTS                     = %010000
  INVERTRTS                     = %100000

if you want to combine modes you have to OR the constants of these modes

f.e. INVERTRX combined with INVERTTX means

INVERTRX | INVERTTX

therefore you have to use the BITwise OR-operator
see porpeller manual page 270

INVERTRX | INVERTTX
results in the value %000011

the main differences between FullDuplexSerial (FDS) and FullDuplexSerial-4-port-objects (FDS4P) are

in FDS you call start with parameters

in FDS4P you call
INIT
AddPort 'WITH parameters (there is one more parameter PortNumber than in FDS)
after al ports are added you call
Start 'WITHOUT parameters

to get familiar with this I suggest to program a small testprogram
that just sends SINGLE bytes that you can use FDS4P ALONE (without ExtendedFDSerial)

If this testprogram worls properly on all four ports you can go on modifying ExtendedFDSerial to 4 ports
you will have to add the portnumber to the commands of ExtendedFDSerial and modify the calls
of the FDS-methods to the calls of FDS4P-methods (wich have the additional parameter "PORT"
to identify WHICH port should be used to send or receive data

and AGAIN
make a small testprogram just to test the modified methods
if you jump into your FULL program you will search for hours and days where the bug is

start modifying the code and come back with CONCRETE questions

best regards

Stefan

Joms

OK, I think I am on the right track but do have a few more questions as to why I think this is not working.

Until now it has always been my understanding that a string is simply several hex characters or digits put together. If the documentation says it can accept a 15 size string that it will be able to accept up to 15 hex digits/characters. Is this correct?

My test program (attached) is actually just called upon by another program, for testing I simply call 'GetSource(31)' from another object.

I can successfully input one character but when I changed over to inputing a string it will bring in random data. My string is actually 40 hex's long. I am only going to be looking at four of them in the middle of the string though, which brings up another question.

1. Can I simply call Data.rxstr(@mystr), then call it again on the next line with a second variable, and it would continue to load bytes into the second var, or doesn't it work that way?

2. If the above does work is it possible to actually use 'Data.hex(variable)' 40 times with 40 different variables and expect the string to load into each one?

3.· Also, what does 'PTR' mean?· I have seen this in several of the serial objects.

I have also been looking at the 128 buffer version posted by Stefan in another post, but I have been waiting to implament that until I get this working right. Sorry if I am beating a dead horse here but I am just having a heck of a time figuring out the serial receive thing. I have been pulling my hair out for two days... Also, sorry for the long posts...

StefanL38

Hello Joms,

edited 26.03.2009 21:32:

found one MAJOR bug

your code does NOT include a proper clock setup this is done by the codelines

CON    
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000 

without these lines the clock is much to much unprecise and from such an unprecise clock you just send and receive rubbish
and this is an example of what I told you
small programs that test every dammed detail STEP by STEP
here: testing send a HARDCODED string like "Hello" from the propeller to a TERMINALsoftware and check if the received character are correct

I didn't saw the lack of these codelines too. I did go back to a program that worked properly in the past and started to compare
this code with your code and voila ! there is the bug!



in my opinion your posting is still quite SHORT.

to analyse what is happening I need more information.

could you please post the datatransfer of a terminalsoftware with your sensor
BOTH what you send to the sensor and what you receive from the sensor
really ORIGINAL cut and paste from the send and receive-window of a terminal software

FullDuplexSerial has a 16byte buffer if you receive more than 16 bytes the oldest bytes get overwritten by the new ones

So this means if you receive more than 16 bytes as continous data there is NO other way than to use a buffer that is BIGGER as your LONGEST datastream (string)

In your main program you have a codeline

  src := mystr

this does NOT work as expected
src is a variable of type long (=4 bytes)
so all the variable can store is the first four bytes of mystr

if you want to do anything with the content of mystr
you have to pass the Pointer of MyStr

MyStr is a bytearray of 64 bytes beginning AT ZERO
first byte is mystr[noparse][[/noparse]0]
these bytes are stored at some RAM-ADRESS in the memory
and strings are handled by most methods by their adress

the codeline

  Data.rxstr(@mystr)

does it f.e.

the "@" in front of the variablename ist the adress-operator
which means start storing the received bytes at the ADRESS of mystr

and "PTR" is a TLA (a T)hree-L)etter-A)cronym) of Pointer which is the word for "adress-of" a variable
the number stored in a pointervariable "points" on the RAM-adress where the content of the variable
is stored

please do me a favor:
make a real LONG posting that describes IN DETAIL what you want to do with the received strings !

Otherways we need 20 more short postings forward and back and run out of time until your program works

My experience from 25 years of programming is:
if it should go superfast the result will be superslow progress

Superfast means here: trying to glue some code together without testing and understanding it STEP BY STEP

It's up to you to believe it now or to make this experience on your own by going on the fast way

best regards

Stefan

Post Edited (StefanL38) : 3/26/2009 8:35:30 PM GMT

StefanL38

Hello Joms,

OK in the attached archive you will find democode that receives a string and echos it back

It uses a modified version of ExtendedFDSerial and FullDuplexSerial with 128byte buffers

best regards

Stefan

Joms

GREAT!... I got your sample program to echo back what I typed. I will now start analyzing your demo code line by line to figure out what is going on and attempt to implement it into a small test program to do what I want. I already see several things I was doing wrong.

I will keep you updated as to how this is working. Thanks so much for all the time you have spent helping me on this...

Joms

Joms

Ok, If I see this correctly I actually had it working right and I was having a different type of a problem...· I was guessing that maybe it was because the rx pin needed to be reversed, but when I try that it just seems to make things worse.

Here is how I physically have this test setup...

Debug (com3) is hooked up to pin30/31.· My data into the propeller is hooked to pin26/27.· I have a serial port monitor watching com1 which is hooked to pin 27 (just to monitor the input to the prop).· I am actually inputing/output through rs422 but using a 75ALS176P chip and a 1k resistor to the stamp...

In the attached screenshot I would input the same string of data each time to the propeller(left window), and on the debug output it would send garbarge, each time adding a few charactors then repeating(left side).

Can anyone just look at the data and see if that looks like inverted data or something simple.· I am beginning to think I have a problem that is not really 'in depth code', but maybe just a hardware or setup problem.

PS.· The test program that Stefan attached work great, even when I implemented it to my spin code.