Problem while trying to read using the Full-Duplex Serial Driver v1.0

mpholmes

I have being using the Full-Duplex Serial to send information to a VB application that I wrote via the serial port/USB driver.· It seems to be working as planned, and I’m finally ready to add the ability for the VB app to also send data back to the Hydra.
·
I have been running into some problems.· At first, the VB app would get stuck waiting for room in the buffer to send data.
·
So after doing some more digging, it looks like something is filling the buffer and I can’t figure out what.
·
In attempt to get to closer look I created this little spin program

CON 
  _clkmode = xtal2 + pll4x ' enable external clock and pll times 4 
  _xinfreq = 10_000_000 + 0000 ' set frequency to 10 MHZ plus some error 
  KEYCODE_ENTER = $0D 

OBJ 
  serial: "mph_FullDuplex_serial_drv_0101.spin" ' The Driver for the serial port 
  key : "keyboard_iso_010.spin" ' instantiate a keyboard object 

VAR 
  long rxbufferbefore[noparse][[/noparse]4] 
  long rxbufferafter[noparse][[/noparse]4] 

PUB start | i 

  DIRA[noparse][[/noparse]0] := 1 

  key.start(3) 
  serial.start(31, 30, 9600) 
  longmove(@rxbufferbefore, serial.bufferptr, 4) 


  OUTA[noparse][[/noparse]0] := 1 
  repeat 
    if (key.gotkey == true) 
      if (key.getkey == KEYCODE_ENTER) 
        quit 
     'End If 
   'End If 
   waitcnt(cnt+6_666_666) 
   OUTA[noparse][[/noparse]0] := !OUTA[noparse][[/noparse]0] 
 'End Repeat 

  OUTA[noparse][[/noparse]0] := 0 

  longmove(@rxbufferafter, serial.bufferptr, 4) 

  repeat i From 0 to 3 
    if !(rxbufferbefore[noparse][[/noparse]i]==rxbufferafter[noparse][[/noparse]i]) 
      OUTA[noparse][[/noparse]0] := 1 
    'End If 
  'End repeat 

  repeat 
    if (key.gotkey == true) 
      if (key.getkey == KEYCODE_ENTER) 
        quit 
      'End If 
    'End If 
    waitcnt(cnt+6_666_666) 
  'End Repeat 

  key.stop 
  serial.stop 

· ·mph_FullDuplex_serial_drv_0101.spin is simply the regular FullDuplex_serial_drv_010.spin. I added this function to allow the main program to examine its’ inbound buffer directly.

PUB bufferptr : x 
  x:=buffer_ptr

When I run the program this part seems to work as planned

DIRA[noparse][[/noparse]0] := 1 

key.start(3) 
serial.start(31, 30, 9600) 
longmove(@rxbufferbefore, serial.bufferptr, 4) 


OUTA[noparse][[/noparse]0] := 1 
repeat 
  if (key.gotkey == true) 
    if (key.getkey == KEYCODE_ENTER) 
      quit 
    'End If 
  'End If 
  waitcnt(cnt+6_666_666) 
  OUTA[noparse][[/noparse]0] := !OUTA[noparse][[/noparse]0] 
'End Repeat

This is setting the Debug LED so that it can be turned on/off and fires up the keyboard driver and the serial driver.· It then copies the 4 longs that make up the rx buffer’s 16 bytes, and begins a loop (where it simply flashes the debug LED and waits for the enter key to be pressed).
·
This part also seems to work

OUTA[noparse][[/noparse]0] := 0 

longmove(@rxbufferafter, serial.bufferptr, 4)

·
It turns off the LED, and again copies the 4 longs.
·
This is where it gets weird.

repeat i From 0 to 3 
  if !(rxbufferbefore[noparse][[/noparse]i]==rxbufferafter[noparse][[/noparse]i]) 
    OUTA[noparse][[/noparse]0] := 1 
  'End If 
'End repeat

It simply loops over the 4 longs collected at the beginning and the end to see if they are the same.· Since nothing has been sent to the serial port it should be the same, but the LED is turned on. ·(It is true that even if the buffer was unchanged it could still be possible for serial port to have processed data, if it was receiving data that was identical to what was already in the buffer.)
·
Then it just waits for enter to be pressed again before it clean ups.

repeat 
  if (key.gotkey == true) 
    if (key.getkey == KEYCODE_ENTER) 
      quit 
    'End If 
  'End If 
  waitcnt(cnt+6_666_666) 
'End Repeat 

key.stop 
serial.stop

More debugging is showing that the buffer is being filled with “-1”.
·
At this point I’m unsure how to proceed so help would be appreciated .

Thanks!

Mike Green

When you say that the buffer is being filled with "-1", do you mean that all 16 bytes are set to $FF?

The only way that would happen would be if the serial port was receiving that information.
That's strange because the start bit of a character is zero and this would have to be a zero bit followed
by at least 8 bit times of one bits. It couldn't happen just with a bad connection and I assume that
downloading from the Propeller Tool works, so it might be something in the VB program.

Have you tried just sending and receiving data using a terminal emulator like HyperTerm?

mpholmes

Thanks for the quick response Mike,
·
Yes all 16 bytes are being filled with $FF.· I don't think its the VB app (however that was also my first thought).· When running this program the VB app is not running.· I have only played with HyperTerm a little bit.
·
I think my next step will be to load the simple program onto the hydra’s onboard memory.· This should allow me to run without having the hydra connected to the PC.
·
Thanks again!

Mike Green

If I were in your position, I'd switch to using the version of FullDuplexSerial that comes with the Propeller Tool. It's a later version, has an additional parameter (for mode information), but more important, I know it works reliably.

I've used a Hydra with a version of FemtoBasic that uses pins 31/30 for console I/O. It works fine with HyperTerm and other terminal emulators. You could take DongleBasic from the Object Exchange and just change _XINFREQ and _CLKMODE and it should work fine.

AndreL

Try talking to a PC with your application, not the HYDRA to make sure that your protocal is working, simulate the HYDRA with a PC app, take the HYDRA out of the loop, so you cann debug your serial 100%, you can even use the SAME pc and run one serial cable right back into the other serial port! This way you can see what's going on, THEN once you know its working, get the HYDRA end to work.

Serial over the COM port with the VXD driver and VB can be tricky. VB has some issues with a few things I can't remember off the top of my head, but there are issues with character translation you have to watch for, etc.

But, like mike said $FF means 0 with all 1's, which really means 1, with all 0's due to the inversion of serial for mark and space.

Andre'

mpholmes

Thank you again

I have thought about doing that as well.· In the long run I think I will write my own so that I strip it down to the bar essentials to maximize performance and space usage for my particular needs.· And getting to know a new version/its differences will help with that.
I'll send updates if I learn anything new.

mpholmes

Again thanks for the help today.

Simply swapping out v1.0 for v1.1 seamed to have fixed by problem.· It looks like finding the exact problem will need to wait for another day.