FDS vs(and/or) SSER

Rsadeika

I started my next project which uses the Propeller Servo Controller USB(PSCU) and the DNA-RTC boards. I am trying to figure out the best way to setup communication between the two boards, do I use the FDS as in fopen(FDS:..) or fopen(SSER:...)? I looked in my propgcc folder and could not find any information that outlines FDS and SSER, as it pertains to Tx,Rx, and BAUD rates to name a few items. Also maybe a couple of examples as to how to best use these drivers. At the moment I keep forgetting if it is fopen(...:Tx,Rx...) or fopen(...:Rx,Tx...). Also would be nice to know what kind of subcommands are associated with each driver, or is that strictly handled with commands such as printf(), fprintf(), and maybe fgets()?

Ray

jnml

Rsadeika wrote: »

I started my next project which uses the Propeller Servo Controller USB(PSCU) and the DNA-RTC boards. I am trying to figure out the best way to setup communication between the two boards, do I use the FDS as in fopen(FDS:..) or fopen(SSER:...)? I looked in my propgcc folder and could not find any information that outlines FDS and SSER, as it pertains to Tx,Rx, and BAUD rates to name a few items. Also maybe a couple of examples as to how to best use these drivers. At the moment I keep forgetting if it is fopen(...:Tx,Rx...) or fopen(...:Rx,Tx...). Also would be nice to know what kind of subcommands are associated with each driver, or is that strictly handled with commands such as printf(), fprintf(), and maybe fgets()?

Ray

Quoting from the documentation

Drivers Provided in the Library

Simple Serial Driver (Prefix SSER)

The simple serial port driver (_Driver _SimpleSerialDriver) is a half duplex driver for generic serial ports. It defaults to doing I/O at the rate specified in the _baud variable (normally 115200 on most boards), with transmit pin_txpin and receive pin _rxpin. These defaults may be overridden by the string passed to fopen. This string contains the baud rate, optionally followed by a comma and the receive pin number and then another comma and the transmit pin number, all in decimal notation. So for example the default

FILE *f=fopen("SSER:", "r");is equivalent to
FILE *f=fopen("SSER:115200,31,30", "r");on most boards.The simple serial driver does not require any additional cogs to operate.
Note that because the simple serial driver runs completely in the local cog, it shares the cog's DIRA and OUTA register with the calling code. Therefore, avoid overwriting the DIRA/OUTA bits corresponding to the simple serial driver's TX and RX pins. You can do this when setting or clearing bits for other I/O devices by using bit-setting and bit-masking instead of direct assignment (e.g. DIRA |= 3 or DIRA &= ~3 instead of DIRA = 3 or DIRA = 0). This is always a good idea, but failing to do this in any code that uses the simple serial driver will result in unpredictable I/O.

Full Duplex Serial Driver (Prefix FDS)

The full duplex serial driver (_Driver _FullDuplexSerialDriver) takes over a cog in order to provide reliable full duplex communication on a serial line. A separate cog is needed for every set of transmit and receive pins in use. Like the simple serial driver, the full duplex serial driver defaults to the values in the board specific _baud, _txpin, and _rxpin variables, and these may be overridden by passing a string containing baud,rxpin,txpin.

HTH

-j

Rsadeika

Thanks jnml, I just tried to find the citation, and it was not easy to find. Maybe that google site needs some sort of find command, or equivalent, so you could type in SSER and it would give you some links or something.

So now the question is on the proper usage of FDS and SSER, in the examples shown they use:

#include <driver.h>
extern _Driver _SimpleSerialDriver;
extern _Driver _FullDuplexSerialDriver;

_Driver *_driverlist[] = {
&_SimpleSerialDriver,
&_FullDuplexSerialDriver,
NULL
};

I have used some of the code that jazzed provided, and it did not use the above lines of code, and the use of SSER seemed to still work. I figure it is some expert knowledge that jazzed has, that he knows when to use it or not, which I guess does not help me very much.

After reading the documentation for SSER, it seems like this would be the one to use, since it is half duplex, and the communication between the two boards is one way. One board, the DNA-RTC, sends (Tx), while the other board just receives (Rx). I tried using some like this to send:

void *do_job1(void *arg)
{
    pthread_set_affinity_thiscog_np();
    pthread_detach(pthread_self());
        
    cmdout = fopen("SSER:38400,16,16","r+");
    
    waitcnt(CLKFREQ + CNT);
    fprintf(stdout,"Thread Started\n");
    
    while(1)
    {
        fprintf(cmdout,"%c\n",t1cmdout);
        usleep(3000);
    }
}

And something like this to receive:

void DataInThread(void *arg __attribute__((unused)))
{
    int speed = 20;
    int t1datain;
    
    cmdin = fopen("SSER:38400,26,27","r+");
    
    while(1)
    {
        fgets(t1datain, "%c", cmdin);
        
        switch(t1datain){
            case 's':
               botStop(); 
            break;
            case 'f':
                botForward(speed);
            break;
        }
        usleep(3010);
    }
}

It is not working at the moment, but I will try some different things.

Ray

Dave Hein

fgets reads a string into a buffer. The compiler should be generating a warning or errors that the first and second arguments to fgets are not the correct type. It looks like you intended to use fscanf instead. However, the order of the arguments would need to be re-arranged, and you would need to use &t1datain instead of t1datain. There is also the problem that I/O is buffered by default, and you would need to make it unbuffered.

Ray, I suggest you always define -Wall. The compiler is a useful tool for finding common programming mistakes. I use it most of the time. We go one step further at work, where warnings are treated as errors, and our code won't build until we've eliminated all of the warnings.