serial vs fdserial

bnikkel

hello again, so i have a working program that uses fdserial at 9600baud, but im wondering if it wouldn't be better to switch to serial?
I only send in one direction at a time so half duplex, I believe fdserial uses another Cog does serial do the same? also are there and speed differences? or other issues? thanks for any help.

JonnyMac

If you can be waiting when the other side is going to transmit and you're running 9600 baud, then yes, you can get away without using a cog.

FDS uses assembly for speed so it can transmit at higher baud rates. Simple Serial is able to send and receive bytes using Spin, so it's not as fast. 9600 is fine. I have done 19.2K by trimming the fat out of the Simple Serial TX and RX routines.

iseries

If your receiving data there could be issues. If your not receiving data the data is lost which is what fdserial does in the other cog is buffer the data so you can receive it at a later time.

Serial is good if you have a process that only sends data with no response or very few. It can also be used if you are creating your own cog process that will process the data on it's own.

In most cases I find myself using fdserial as I don't want to be waiting for data and hold up my main process.

Mike

bnikkel

this is the beginning of my code, am i only using one cog for fdserial or is this starting three cogs for it?

#include "simpletext.h"
#include "simpletools.h"                      // Include simple tools
#include "fdserial.h" 
//#include "servo.h"                            // Include servo header
//added "-std=c99 " in SimpleIDE's "Other Compiler Options" field.

fdserial *transceiver; //HS-LC12S transceiver
fdserial *lcd;  //nextion 4.3" screen
fdserial *JDY40; //JDY-40 chip

localroger

That's going to use a cog for each instance of fdserial. There is another driver that supports up to four ports with one cog at modest baud rates, but with the obex gone I'm not sure how to steer you to it.

Publison

This is the latest drive I have saved from OBEX.

bnikkel

you dont happen to have that in "C" do you?

iseries

Even though this is written in spin it really is mostly assembly language. It could be ported to C with a little work.

The driver checks each pin for a start bit and if it sees one it triggers the serial read function for that pin.

There are 7 cogs and you are only using 3 so I don't see the problem here.

I have that Nextion display, is it only displaying results or do you have buttons defined as well. You could switch it to serial to save a cog then.

Mike

bnikkel

i have several other cogs that start later, running an 8 channel ADC and other functions. yes the screen constantly sends and receives from the prop. and unfortunatly i have no idea how to port things into C.

Electrodude

The one or two times I used propgcc, I used @ersmith's spin2cpp to automatically convert some version of the Spin four-port serial driver to C. I think it just worked without any problems.

iseries

It's more complicated than that. They need to be C functions that can be called by his programs and not just converted programs to assembly language.

Spin2cpp generates ugly looking C code that nobody would write that way but because it's coming from spin turn out that way.

There still may be an issue with this as lets say both serial interfaces start sending data at the same time. The program will likely miss one or the others data as it is single thread and monitoring multiple pins. Once the start bit is received that's it. It has to process that byte of data before looking at the other pin. There is no way for the process to tell one serial interface to not send until now otherwise the code needs to be changed such that it sends out a start code before the other starts sending it's data.

The ADC should be able to be poled by one cog as the values are held in registers until you read them unless your using interrupts.

Mike

Tracy Allen

@iseries, actually, the 4-port object can receive from two or more ports at the same time. The pasm loop checks between bits and doesn't have to wait for a complete byte per port.

Ariba

https://forums.parallax.com/discussion/comment/1394730/#Comment_1394730

Tracy Allen

That’s great that It's converted for c. The flight controller firmware is here,
https://www.parallax.com/downloads/elev-8-flight-controller-firmware. In the archive find
Serial_4x.h
Serial_4x.cpp
Serial_4x_driver

Interesting to me is that Jason converted Wayne Meretsky’s versión, which is quite different from Tim Moore’s original that Jim linked to above or from the versions modified by myself and others that are referenced in the credits. Wayne did a complete rewrite that is plainly more amenable to c, in the way it defines the buffers externally and avoids a lot of the initialization patches.

localroger

iseries wrote: »

The program will likely miss one or the others data as it is single thread and monitoring multiple pins. Once the start bit is received that's it. It has to process that byte of data before looking at the other pin. There is no way for the process to tell one serial interface to not send until now otherwise the code needs to be changed such that it sends out a start code before the other starts sending it's data.

This is incorrect. The four-port object PASM module monitors the status of its eight pins, four inputs and four outputs, in a round robin and uses CNT to determine when to clock the next bit in or out for each pin. At 80 MHz the P1 is fast enough to do this at 115K baud for all four ports. The data are clocked into and out of Hub RAM buffers, where slower C or Spin code can deal with things in a less timely fashion.