What is the maximum baud rate for fdserial?

photomankc

I had always thought it was a notch above 115200 but my testing seems to indicate that it is echoing back garbage at 230400. I'm using a very simple loop to grab each character in on the RX line and shove that character back out on the TX line. The other end is BeagleBone Black. The Propeller will be a sub-controller for the BBB and I'd like to speed the transmission time as much as possible. Below is the SimpleIDE code:

#include <stdio.h>
#include "propeller.h"
#include "simpletext.h"

int  main(void)
{
    int ii = 0;    
    int term;
    term = fdserial_open(25,24,0,230400);
  
    while(1) {
        ii = fdserial_rxCheck(term);
        if(ii >= 0)
            fdserial_txChar(term,ii);
    }
    return 0;
}

Here's what the logic analyzer sees:


Some other testing suggests that it is able to transmit correctly at this rate. Static characters transmitted go out and appear correctly in the logic analyzer, it just this echo-loop that seems to generate difficulty at this bit rate. Am I asking too much of the driver? At 115200 it handles the echo loop just fine, but that is a little slow for what I had in mind.

Are there any other bits that make working with strings with fdserial a bit easier? The simpletext driver seems aimed at debug output to the programming serial port. If I have to build some wrappers to handle strings that's not a big deal but if there is something already out there then i'd rather not invent the wheel.

jazzed

Can you do the same experiment with "Propeller Serial Terminal.spin" ? We are using that driver in libfdserial with the buffer set to 64 bytes. I'm not sure if that driver was originally designed to be forwarding or looping as you're doing. We might be able to make it more industrial strength in time.

The simpletext library has many simple text io functions (hence the name).
Here's the on-line simpletext documentation. Source for all libraries is here.

If you don't see what you need in the simpletext list, let me know. Generally put* and write* are for dealing with output; get* and read* are for input. Other convenience functions are print, sprint, scan, and sscan which are similar to printf, sprintf, scanf, and sscanf.

The simpletext library was developed in response to the explosive growth nature of standard printf and scanf when adding format specifiers. The print function without format specifiers is larger than the equivalent printf, but all you have to do is add one format specifier, and printf bloats quickly (scanf is the same). The print and scan functions are always the same size regardless of format specifiers AND they support 32bit floating point. Standard printf or puts can be mixed with simpletext library calls.

One may ask why Tiny Library is not used instead. Well, we had mixed results with that because the "device" is always using a global handle. It is horribly confusing at times to deal with the global device connection. The Tinly Library can be beneficial to those who easily understand it, however there are many caveats.

Did you know that Library simpletext allows easy run-time reassignment or use of multiple devices? You could easily have 14 tx/rx simple serial ports running at 115200 half-duplex on the propeller with libsimpletext. A terminal server application using libfdserial would be limited to 7 ports or less depending on COG usage. One could write a 4-port per COG serial library to get higher port density.

photomankc wrote: »

I had always thought it was a notch above 115200 but my testing seems to indicate that it is echoing back garbage at 230400. I'm using a very simple loop to grab each character in on the RX line and shove that character back out on the TX line. ....

photomankc

Jazzed,

I'm trying not to be stupid here but I'm not having any luck finding a "Propeller Serial Terminal". I did locate a "Parallax Serial Terminal" in the library section on the old propeller tool. I'm guessing that was what you had in mind but I'll confirm before I setup an experiment. Man, going to have to get back into the SPIN days. Or hell, even just... the programming days. Been working on bot mechanicals for so long now I'm sitting here fretting how to start a project again. My syntax memory is so dang perishable.

Here's the begining of Parallax Serial Terminal:

{{
─────────────────────────────────────────────────
File: Parallax Serial Terminal.spin
Version: 1.0
Copyright (c) 2009 Parallax, Inc.
See end of file for terms of use.

Authors: Jeff Martin, Andy Lindsay, Chip Gracey  
─────────────────────────────────────────────────
}}

{
HISTORY:
  This object is made for direct use with the Parallax Serial Terminal; a simple serial communication program
  available with the Propeller Tool installer and also separately via the Parallax website (www.parallax.com).

  This object is heavily based on FullDuplexSerialPlus (by Andy Lindsay), which is itself heavily based on
  FullDuplexSerial (by Chip Gracey).

USAGE:
  • Call Start, or StartRxTx, first.
  • Be sure to set the Parallax Serial Terminal software to the baudrate specified in Start, and the proper COM port.
  • At 80 MHz, this object properly receives/transmits at up to 250 Kbaud, or performs transmit-only at up to 1 Mbaud.
  
}

On simpletext, So if I read this code right when I start up an fdserial cog I get an integer back that I can store and then if I want to use the simpletext functions I give them that integer to indicate which serial terminal I want the function to operate on. Do I have the gist of that correct? I guess I got a little wrapped around the word 'overridden' and my OOP mind kept trying to complicate that. The range of functions is plenty enough for my needs I just wasn't getting how you attached it to a different terminal than the default at first.

jazzed

I'm sorry, but I didn't realize Propeller Serial Terminal.spin is not in common usage. In the fdserial library, i renamed it to pst.spin.

photomankc wrote: »

On simpletext, So if I read this code right when I start up an fdserial cog I get an integer back that I can store and then if I want to use the simpletext functions I give them that integer to indicate which serial terminal I want the function to operate on. Do I have the gist of that correct?

That is essentially correct, except that the integer is a pointer to the fdserial struct which is a type of simpletext terminal.

The simpletext library allows specifying a different port in two different ways. 1) reassign the default port, 2) use any port.


Example of reassigning the default port:

[INDENT]
[/INDENT]
  extern terminal *dport_ptr;
  simpleterm_close();
  dport_ptr = serial_open(1,2,0,115200);[INDENT]
[/INDENT]

Example of using any port:

[INDENT]
[/INDENT]
  /* open a device called "text" */
  text = serial_open(3,4,0,115200);

  /* traditional hello message using buffer */
  sprint(buffer, "Hello, world! Again!\n");
  writeStr(text, buffer);

   /* message using device */
  dprint(text, "July PI day %f\n", 22.0/7.0);


  writeStr(text, "\nEnter dscan float string: ");
  dscan(text, "%f %s", &fval, sval);
  dprint(text, "%f %s\n", fval, sval);
  writeFloat(text, fval);
  writeLine(text, "");
  writeLine(text, sval);[INDENT]
[/INDENT]

photomankc

Ok thanks Steve,

I'll try to whip up a test on this next week at higher baud rates and see if the SPIN/PASM driver can handle the echo program. For now I can drop to 115200 as it it's simple to prove that it's working. It may be capable of going faster when I get to the point that I am pulling in strings and responding vs trying to blast stuff out as more stuff is still coming in. If worse came to worse I think I can get by on 115200 without a ton of problems. The essence of what I will be doing is receiving a request string from the BBBlack and sending a response string back. The sensors that the Propeller will be controlling are low update rate now anyway so it's little matter if the command/response timing is several mSecs I guess.

I'll have to play with my example again but I swear when I tried to declare the term variable as a pointer it griped at me about it. I'll have to mess around with the simpletext driver some more. Looks quite nice.

photomankc

Using the SPIN pst object the results are worse. The echoed characters are further apart and only the first character is echoed correctly. A test that involved grabbing a whole command at 230,400 and then repeating the command back also failed so it obviously was not even properly reading input at that baud rate using the SPIN based object. Slow the baud to 115,200 and it passed both the echo test as well as the full command read-back test. So it appears I might be able to eek out 230,400 on the C version since I only need half-duplex anyway. I'm going to do some more testing with the C version and see if I can get it to capture a command and read it back to me at 230,400.

photomankc

Uggghh,

Ok, I'm not getting this. The following code:

#include <stdio.h>
#include "propeller.h"
#include "simpletext.h"
#include "fdserial.h"

int  main(void)
{
    int ii = -1;    
    fdserial *term;
    term = fdserial_open(25,24,0,230400);

is producing the following errors:

FdSerialTest.c:16:5: error: unknown type name 'fdserial'
FdSerialTest.c:17:10: warning: assignment makes pointer from integer without a cast [enabled by default]

So for some reason, fdserial, which is clearly typedef'd in the header is an unknown type and compiler says that that the return value is an integer that i'm ham-fisting into a pointer when the function prototype clearly says it's returning a pointer. This was why I switched to an integer earlier and the compiler quite complaining to me about it and the build completed. What am I missing?

jazzed

What SimpleIDE version do you have?

Your code works with a recent release.

This is likely a library/problem. Look for "Auto Include Libraries" in Properties -> General Tab. That should be checked for copy/paste code.

We are testing these downloads for the upcoming Education release: https://code.google.com/p/propside/downloads/list

altosack

Hey there, fellow Missouri-ite !

You have the files "propeller.h", "simpletext.h", and "fdserial.h" included using quotation marks instead of angle brackets. This will search your working directory (and maybe more if you're using simpleIDE) before it searches the c compiler header directories. Usually, the only reason that you would want to do that is if you modified the file, and have a local version specifically for your project. It's safer to use <> so you don't do this by mistake.

Anyway, it's a long shot, but you may have an older version of one or more of these files in your working directory that doesn't work the way you expect, and it's picking up that one. This could account for why it works for one person but not another, even if they both have the same version of propgcc.

jazzed

That's a good point.

SimpleIDE will not replace your old Documents\SimpleIDE workspace.

You must remove/rename Documents\SimpleIDE before starting the program to get a new workspace. We will likely automate this later ... it's high on the enhancement list.

SimpleIDE requires the form #include "filename.h" for searching Simple Libraries. SimpleIDE will not search for #include <filename.h> ... that's for the compiler.

photomankc

altosack wrote: »

Hey there, fellow Missouri-ite !

You have the files "propeller.h", "simpletext.h", and "fdserial.h" included using quotation marks instead of angle brackets. This will search your working directory (and maybe more if you're using simpleIDE) before it searches the c compiler header directories. Usually, the only reason that you would want to do that is if you modified the file, and have a local version specifically for your project. It's safer to use <> so you don't do this by mistake.

Anyway, it's a long shot, but you may have an older version of one or more of these files in your working directory that doesn't work the way you expect, and it's picking up that one. This could account for why it works for one person but not another, even if they both have the same version of propgcc.

A good point indeed. That may be it. I'm updating the Mac package to the latest version right now but there was another fdserial.h in my project folder from some earlier playing and it was obviously not the same as the library version. Amazing that any of it worked at all!

photomankc

That was the issue. When you include a simple library item "foo" the editor inserts the directive as:

#include "foo.h"

Seems to work fine unless you have an older version of "foo.h" in your project directory. Then things go bad. Changing to:

#include <foo.h>

Solves the issue.

Is there any reason in particular that the #include is inserted using quotes instead of <>?



ETA: So 115200 seems to be the extent of reliable operation. My code does not reliably catch a qualified command string at 230400 but is 100% at 115200 so I guess that's going to be as fast as they can talk. I'll keep the commands short so I can get them transmitted in under 2ms. Now that I solved the library issue, and stick with the supported baud rate everything is working well.