Serial objects question

max72

I have used the various serial objects with no big issues in the past, but this time I cannot figure what is not working.
I set up a serial mirror, and I mirror my data to the serial terminal. The other serial thing is a SIM900 GSM module.
When I use the full duplex serial on the GSM side everything works.
If I use the 4 ports full duplex serial (traditional or with extended buffer) I only get back garbage. Probably missing something obvious, but cannot get it. Any suggestion is appreciated.

Using Saleae Logic analyzer I get corret readings setting 115200 bits/sec, 8 bits per trasnfert, 1 stop bit, no parity bit, LSB first, non inverted.

Thanks in advance,
Massimo

test code:

OBJ

  Debug   : "Fullduplexserial"       
  Comm    : "FullDuplexSerial"
  comm2   : "pcFullDuplexSerial4FC"
  
Pub Start  
    debug.start(31,30,0,57600)
    'comm.start(18,17,0,115200)
    comm2.AddPort(0,18,17,-1,-1,0,%0,115200)
    comm2.start
    
    repeat
       char:=comm2.rxcheck(0)
         if char == -1

         else
            debug.tx(char)
            waitcnt(clkfreq/1000+cnt)


       char:=debug.rxcheck
         if char == -1

         else
            Comm2.tx(0,char)
            waitcnt(clkfreq/1000+cnt)

Ray0665

I went thru a similar problem, it turned out that I did not set the clock frequency in the main module.
The good news is that after several hours of frustration, I'll never do that again.

max72

Thanks for the suggestion.
The clock frequency is set. Moreover if I read the data bask with fullduplezserial it works, and at 115200 it cannot be just luck. Same thing when I send data to the module. The logic analyzer says the data is sent reasonably shaped.
I'm breadboarding, so there are connections 10cm/5" long, but I assume fullduplexserial and pcFullDuplexSerial4FC are equivalently picky?
Massimo

ratronic

Massimo I not sure if this is the source of your problem but in the code you posted above the debug port is started at 57600 baud and the comm2 port is started at 115200 baud.

max72

Ratronic, this is meant to be. I have the serial terminal at 57600, while the GSM is working at 115200. I'm, sending and receiving a small amount of data, so I assume the buffer is never overstressed.
Anyway I tried also with 115200 on both serial ports, with the same result.

Massimo

ratronic

I ran into a problem using the pcfullduplexserial4c object when talking to the parallax laser range finder (I'm sure it was my use of it) but lately I have had real good luck using the parallax serial terminal for debug and fullduplexserial for serial communications to whatever I'm talking to (keeping baud rates so as not to over flow the buffer). I'm sure if anybody can figure this out you will.

Ray0665

Try this

  comm2.init                                                        'Always call init before adding ports
  comm2.AddPort(0,18,17,-1,-1,0,%0,115200)
  comm2.start

Init does pretty much nothing except call stop
but STOP initializes buffers and pointers???

max72

Thanks for the suggestion Ray, I'll try it tomorrow and I'll post the effect.
Massimo

kuroneko

I'm wondering if it' s connected to signal quality (code looks fine). Can you split the serial link between prop and GSM module and

1. use FDS for tx and FDS_4FC for rx
2. use FDS_4FC for tx and FDS for rx (FDS: temporarily set txpin to an unused pin)

max72

I tried both solutions (init method and mixing the two objects). I have the same (consistent) results.
I also tested the prop in pin with a scope, and the signals are sharp and well shaped.

Mike G

max72, your code snippet does not define the clock or the variable "char". Please post all of your test code.

What is the HEX value of the "garbage" char?

  debug.hex(char)

What value are you expecting?

How about comparing the logic analyzer results with the garbage char. Are the values equal?

kuroneko

max72 wrote: »

I tried both solutions (init method and mixing the two objects). I have the same (consistent) results.

What are those results, i.e. is any 4FC involvement causing garbage or for rx/tx only?

rx   tx  result
FDS  FDS    OK
FDS  4FC    ??
4FC  4FC    NG
4FC  FDS    ??

Dr_Acula

I found this in the 4 ports serial code

''* Optimization perf *
''* 1 port up to 750kbps *
''* 2 port up to 230kbps *
''* 3 port up to 140kbps *
''* 4 port up to 100kbps

I've never been entirely confident that 115200 is a super reliable comms speed. Back in the olden days (1984) my dad and I ran a cable from upstairs to downstairs to link two computers. The cable was 5 wires and about 30 metres long and we struggled to get anything reliable over 9600 baud. My old 1985 computer even struggled with a 3 metre lead and 19200 baud.

Can you retest with slower baud rates? Could it work with a really slow speed like 1200 baud (I have run 400 metres of unshielded cable at 1200 baud and it works). Or does it have to be 115200?

max72

@kuroneko: it looks I have a problem in receiving from 4FC, as long as the lisetner is FDS everyting is ok.
it could well be related to the fact that I'm close to the rate limits...

@Dr_Acula: the 115200 is the factory setting from the unit. I was trying to leave it alone..

@Mike G: please find full source code and hex readings.

Thanks for you time and the suggestions.

I attached the full source of a new simplyfied version.
It constatly sends "AT" to the serial and reads back the data.
I expect an echo of the data and "OK"

from FDS the hex code is consistent and I get the following:

41 54 0D 0D 0A 4F 4B 0D 0A
A  T  CR CR LF O  K  CR LF

switching the comments on the comm objects I get not constant readings:

41 54 86 0D 84 A7 A9 48 F8
41 D0 86 0D 86 A7 A9 48 FC
41 D0 86 0D 0A A7 A5 48 E1
41 92 86 0D 86 A7 A9 48 F8

and so on....

CON

    _clkmode = xtal1 + pll16x      '80MHz operating frequency.
    _xinfreq = 5_000_000                      

VAR   '' Global Variables and Cog Stack Space

  long  char
  
OBJ

  Debug   : "parallax serial terminal" ' "Fullduplexserial"       
  Comm    : "FullDuplexSerial"
  comm2   : "pcFullDuplexSerial4FC"
  
Pub Start  
    'debug.start(31,30,0,57600)
    debug.start(57600)
    comm.start(18,17,0,115200) '18 17
    'comm2.init
    'comm2.AddPort(0,18,17,-1,-1,0,%0,115200) '18 17
    'comm2.start
    

    
    repeat
       'comm2.str(0,string("AT",13))
       comm.str(string("AT",13))
       waitcnt(clkfreq/2+cnt)
       'repeat while (char:=comm2.rxcheck(0)) > -1
       repeat while (char:=comm.rxcheck) > -1
            debug.hex(char,2)
            debug.char(" ")
            waitcnt(clkfreq/1000+cnt)          
       debug.char(13)
              

max72

@Dr_Acula: I tested setting the module to 57600 and it works.

Massimo

Dave Hein

The problem may be that the unit you are interfacing with is on the lower or upper range of the RS-232 frequency tolerance. I think it allows for +/- 10 percent, or maybe it's +/- 5 percent. The 4FC serial driver is going to have more jitter than FDS, though I think with only a single port 4FC should be the same as FDS, but I haven't looked at it in detail.

Is there a way you can measure the bit-widths of the unit you're interfacing to?

Tracy Allen

I posted results of jitter measurements in this thread, the one where PhiPi came up with his jitter-free PBNJ serial driver.

Dave Hein

1 uart enabled, 115200 baud, no flow control.
bit=$ff: 8.884 µs mean, variation 6.186 to 11.201, sigma 1.2631, 57.8% max bit width variation.
byte=$00: 77.880 µs mean, variation 77.158 to 80.005, sigma 0.958, 3.6% max byte width variation.

At 115200 the bit time should be 8.68 us. A worse case value of 11.2 is too long by 29%. Of course, this is on the transmit side, we don't know what the timing on the receive side looks like.

max72

I forgot the jitter thread.
Using the results and the fact that more ports are causing less jitter, I added 3 empty UARTS and it now works..