Once you start the prop tool (not propeller IDE) click on file. The dropdown should have as one choice "open from...". Click on that and the next drop down should have "Library" as the first choice. That's where fullduplexserial.spin is located. However, you should not have to do that (unless you want to see how that object is written.) When you compile with the PropTool it looks in its library for objects.
What it is supposed to do is display the values of the four bytes corresponding to the received buffer of FDSERIAL. I dont really know how to set it up.
You've mixed what methods are available with something other than FullDuplexSerial... Your pst.str(...) expects to work like C's printf (it does not). When you specify an object, you need to use the same name for that object throughout your code (serial, pst, ???). You need to be consistent in your use of indention, for ease of reading as well as functionality
This code compiles as a .spin file for P1 (I assume you want to compile for P1?):
longcon
_clkmode = xtal1 + pll2x
_xinfreq = 5_000_000
CLK_FREQ = ((_clkmode - xtal1) >> 6) * _xinfreq
MS_001 = CLK_FREQ / 1_000
US_001 = CLK_FREQ / 1_000_000
con {io pins}
RX1 = 31 {i} ' serial programming
TX1 = 30 {o}
SDA1 = 29 {i/o} 'I2C/eeprom
con {user io}
NS_PLS = 16
NS_Dir = 15
EW_PLS = 17
EW_Dir = 18
BTN_N = 7
BTN_S = 6
BTN_E = 5
BTN_W = 4
con {navigation}
NORTH = %1000
EAST = %0100
SOUTH = %0010
WEST = %0001
#0, GO_NORTH, GO_SOUTH ' direction control
#0, GO_EAST, GO_WEST
CYCLE_TIX = CLK_FREQ / 50 ' set period to 50Hz
MOVE = MS_001 * 15 ' set pulse width
MOVES = US_001 * 1500 ' set pulse width for tracking
STOP = 0
con
#true, on, off
#false, no, yes
var
long nspulse ' timing ticks
long ewpulse
obj
ser : "FullDuplexSerial.spin"
pub main | t, nav
setup
ser.start( 31,30,0,9600) '' <<<<<<____<<<<<< ERROR
t := cnt ' loop timing
repeat
nav := scan_nav_buttons(5)
case nav
NORTH :
nspulse := MOVE
outa[NS_Dir] := GO_NORTH
ewpulse := STOP
EAST :
ewpulse := MOVE
outa[EW_Dir] := GO_EAST
nspulse := STOP
SOUTH :
nspulse := MOVE
outa[NS_Dir] := GO_SOUTH
ewpulse := STOP
WEST :
ewpulse := MOVE
outa[EW_Dir] := GO_WEST
nspulse := STOP
OTHER :
ewpulse := MOVES
outa[EW_Dir] := GO_WEST
nspulse := STOP
phsa := - nspulse
phsb := - ewpulse
waitcnt( t += CYCLE_TIX ) ' loop timing
pub scan_nav_buttons(ms) : nav | t
--nav
t := cnt
repeat ms
waitcnt( t += MS_001 )
nav &= ( ina[BTN_N] << 3) | (ina[BTN_E] <<2 ) | ( ina[BTN_S] <<1 ) | ina[BTN_W]
pub setup
outa := $00000000
dira := $00000000
ctra := %00100 <<26 | NS_PLS ' set for pwm/ nco mode
frqa := 1
phsa := STOP
dira[NS_PLS] := 1
dira[NS_Dir] := 1
ctrb := %00100 <<26 | EW_PLS
frqb := 1
phsb := STOP
dirb := 1
dirb := 1
pub serial
repeat
ser.str( "value1: ")
ser.Dec(EW_PLS)
ser.str( " value2: ")
ser.Dec(EW_Dir)
ser.str( " value3: ")
ser.Dec(NS_PLS)
ser.str( " value4: ")
ser.Dec(NS_Dir)
ser.Tx(13)
My next question ; is there a component in fdserial that is responsible for sending the data in the buffer to the proper outputs or do I need a extra pub to do that like that in the arduino language.
If you make the string corrections it will work. When you start serial it's expecting to communicate with something on the other end. Or if may just sit in hang in that PUB serial, if you add a line that expects to recieve something as in full duplex.
Example if I wire two props together, I might use a variable such as Angle:=ser.Getlong in my serial start PUB. This will wait until it can fetch that variable from the other Prop1. Or if I want to send a variable to the other prop I might say ser.Putlong (Pan) that sends the data in Pan to the other prop. If I want to print it, I might say LCD.dec(Pan) to display the value in Pan to my LCD.
If you just send you should be ok, it will just keep sending bits to those pins. But on the recieving end you need to "syn" with the timing with transmitting prop. Or you'll just see random data. Such as sending a ser.Putlong(777) just as a test number. You could make up four of those ser.Putlong(555) etc.. And see if you can read it on the rec. end. If your serial timing is OK you'll see the number. If you see random numbers reset the transmitter or write a handshake timing routine to "syn" the two.
You could always offer to pay someone on this forum to write your entire routine, that works without glitches. I'm a little busy with my own projects. Just throwing my 2 cents worth out there.
AKA hex 0D/0A. Some terminals need both carriage return and line feed. You may see it elsewhere as CR/LF. On terminals needing CR, if all it gets is LF, terminal will drop a line but keep going from its position on the last line. You will get a sort of barber pole effect if it keeps sending to the terminal. One more thing you must match up with terminal settings.
I may be wrong, but if you are editing a file (for example the savelog for the terminal session) with vim, the line feed codes show up on each line as ^M.
Comments
Tom
C:\Program Files (x86)\Parallax Inc\Propeller Tool v1.3.2\Library
Your object is called "fdserial" but you use "serial".
Add:
Is your intendation in pub serial after repeat as intended?
The way it is written the repeat is just an endless do-nothing loop.
This code compiles as a .spin file for P1 (I assume you want to compile for P1?):
dgately
I may be wrong, but if you are editing a file (for example the savelog for the terminal session) with vim, the line feed codes show up on each line as ^M.