Recieving a string of data with full duplex serial object

dodger · 2009-03-19 23:58

I am trying to recieve a string of data that has 18 bytes using the full duplex serial object.· I can send a byte through hyper terminal and recieve it on the propeller, but when i try to send a string i am having trouble.· Any suggestions or can someone point me in the right direction.·

thanks

grasshopper · 2009-03-20 00:06

Post some code and i will see if i can find a solution.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit my site -> [url=Http://www.rawcircuits.com]www.rawcircuits.com[/url]

Mike Green · 2009-03-20 00:06

FullDuplexSerial deals only with single bytes on input. There is an object in the Object Exchange that has some additional input routines including some that deal with input strings. Have a look at Extended FullDuplexSerial.

dodger · 2009-03-21 04:25

I have made some good progress with the extended full duplex object. I can loop back my transmit string and display it via my video output. I have sent the string i am expected to recieve from my serial device and i can display it perfectly.

I can connect my serial device through Hyper terminal and i have good communications.

But when i connect my serial device to the propeller i dont recieve anything. I think the problem i am having is a delimiter problem. I have tried (10) for line feed and (13) for Carriage return and still no joy.

Heres a copy of the data stream and my app

RS232 Datastream Format
mmmbsdddddbuuuuucl, where:
m Memory Location
s Sign (space or -) c Carriage Return
d Data with Decimal Point l Line Feed
u Units b Blank

{{ Prop Serial}}

CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

VAR
long MyStr [noparse][[/noparse]64]
long Torque
OBJ
SER : "FullDuplexSerial"
TV : "tv_text"
Num : "Numbers"
Ext : "Extended_FDSerial"
PUB Main

Num.init
TV. start(12)
TV.str(string("Start",13))
TV.out(13)
Ext.start (17,16,0,9600)
{Ext.SetDelimiter (13)}
repeat 30
Ext.rxflush
{Ext.str(string("-0.148 INLB,"))} ' I can transmit this string and recieve it. This is what is expected from my serial device.
Torque := Ext.RxStrTime (200,@MyStr)

TV.str(@MyStr)
TV.out (13)
waitcnt (clkfreq/10 + cnt)
TV.str(string("End",13))
Ext.stop

StefanL38 · 2009-03-21 12:38

Hello Dodger,

as indention is very important to SPIN-soucecode use the Post reply button

and the [noparse][[/noparse] code ] [noparse][[/noparse] / code ] -commands to insert sourcecode into postings
or use the Attachment Manager

I modified your sourcecode that I can easily dbug it just by using
the serial-connection for programming

once the program is downloaded to the propeller or EEPROM
on PINS 31,30 you can use EXACTLY the same pins for whatever you like

Mike Green made a modified version of FullDuplex which has a 64byte buffer
I increased it to 128 bytes

you want to receive a 18 byte long string
the standard FDS-object can only receive 16 bytes
and the ExtendedFDSerial-object can receive only strings with 15 bytes

edited: another bug was your stringvariable was defined as a long it has to be defined as byte
as all string-functions of FDS and Extened_FDS expect strings as a BYTE-sequence NOT as a long-sequence

I attached the democode with included files

Extended_FDSerial_128ByteBuffers.spin
FullDuplexSerial_128ByteBuffers.spin

here is the democode

{{ Prop Serial}}

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

VAR
  Byte MyStr [noparse][[/noparse]64]
  long Torque

OBJ
  'TV : "tv_text"
  Num : "Numbers"
  Ext : "Extended_FDSerial_128ByteBuffers"
  'Ext : "Extended_FDSerial"

PUB Main

  Num.init
  'TV. start(12)
  'TV.str(string("Start",13))
  'TV.out(13)
  'Ext.start (17,16,0,9600)
  Ext.start (31,30,0,9600)
  {Ext.SetDelimiter (13)}
  'repeat 30

  repeat 
    Ext.rxflush
    {Ext.str(string("-0.148 INLB,"))} ' I can transmit this string and recieve it. This is what is expected from my serial device.
    'Torque := Ext.RxStrTime (200,@MyStr)
    Ext.Str(string("R"))
    Ext.RxStrTime (500,@MyStr)
    Ext.Str(@MyStr)
    Ext.Tx(13)
    waitcnt (clkfreq * 1 + cnt)

    {
    TV.str(@MyStr)
    TV.out (13)
    waitcnt (clkfreq/10 + cnt)
    TV.str(string("End",13))
    Ext.stop
    }

{ the lines below are Scripting-code for Br@ys-Terminal-Software
program TestSendingAString;

const STRING1 = 'first test';
const SensorAnswerTemplate = 'mmmbsdddddbuuuuu';

const SensorAnswerExample = 'FF1A -123.4 uuuuu';

var 
  i : longint;

begin
  writeln(STRING1);
  comsendstr(STRING1);
    while not(i=27) do // repeat until ESC
    begin
      while i <> ord('R') do i:=ComReadChr();// wait for char "R" 
      begin
        i:=0;
        writeln('received a R');
        writeln('send back ')
        writeln(SensorAnswerExample);
        
        comsendstr(SensorAnswerExample);
        comsendchr(10);
        comsendchr(13);

        writeln('wait for R');
      end
    end;
end.
}

this democode works together with a terminalsoftware called Bray's Terminal
see attached zipfile
this terminalsoftware has a scripting function

Download the program to the EEPROM. NOT to RAM ! Brays-terminal causes a Reset of the propeller when opening the comport

If you start the demoprogram on the propeller you should get a receiving like that in brays-Terminal

R
R
R
R

simply echoes of the sended "R"

if you start the script you should receive in Brays Terminal something like this

R
RFF1A -123.4 uuuuu
RFF1A -123.4 uuuuu
RFF1A -123.4 uuuuu
RFF1A -123.4 uuuuu
RFF1A -123.4 uuuuu
RFF1A -123.4 uuuuu

from the original FullDuplex you get only 15 bytes like this

RFF1A -123.4 uuu

two "u"s missing

While developing software you should change only ONE thing at a time
and test this change until everything is working properly

here this means
use something to send and receive bytes that is working properly
connecting the propeller to a terminalprogram

then connecting the sensor to a terminal program to test if the sensor receives and sends properly
and first AFTER that connect propeller with sensor

best regards

Stefan

Post Edited (StefanL38) : 3/21/2009 5:08:17 PM GMT

StefanL38 · 2009-03-29 05:20

Hello Dodger,

I personally prefer to use a serial connection to debug things
(as this requires no extra hardware)

I think I have found the bug. The size of the bytearray

  Byte MyStr [noparse][[/noparse]64]

was too small

do the following change to your code


OBJ
  Num : "Numbers"
  Ext : "Extended_FDSerial_128ByteBuffers"

VAR
  'ATTENTION bytearrays used with ExtendedFD_Serial have to have the same size
  'as the constant MaxStrLength in the File Extended_FDSerial_128ByteBuffers !
  'you can access the value of this constant by objectname#constantname
  'in THIS example the objectname is "Ext" so it is "Ext#MaxStrLength"
  'the stringreceive-functions fill up the bytearray with zeros in a length
  'of MaxStrLength !. If the bytearray is smaller than MaxStrLength other
  'things get overwritten by zeros !  

  Byte MyStr [noparse][[/noparse]Ext#MaxStrLength]

there was also a bug in ExtendedFDSerial_128ByteBuffers.spin
at two places the buffersize was still on 16 bytes
I corrected that in the new version

I attached a new archive
As I have no TV-screen laying around I could not test it

please test it yourself
if this change does not help
post a new question in the forum

best regards

Stefan

Recieving a string of data with full duplex serial object

Comments