serial vs fdserial

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.

Comments

  • JonnyMacJonnyMac Posts: 6,661
    edited 2020-05-12 - 15:18:49
    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.
  • 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
  • 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
    
  • 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.
  • This is the latest drive I have saved from OBEX.
  • you dont happen to have that in "C" do you?
  • 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
  • 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.
  • ElectrodudeElectrodude Posts: 1,375
    edited 2020-05-13 - 16:52:52
    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.
  • 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 AllenTracy Allen Posts: 6,479
    edited 2020-05-13 - 21:18:59
    @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.
  • 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.
  • 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.
Sign In or Register to comment.