Shop OBEX P1 Docs P2 Docs Learn Events
C LMM, Serial? — Parallax Forums

C LMM, Serial?

davidsaundersdavidsaunders Posts: 1,559
edited 2015-04-18 17:45 in Propeller 1
As I am attempting to get the 3D printer firmware done completely in C in LMM code for the first version:

I still need to implement serial to get the G-Code from the host system, and send the OK's back to the host system.

So what are the limits of pseudo RS232 (to the FTDI prop loader) in LMM GCC, and is there any sample code for this???

Comments

  • pmrobertpmrobert Posts: 675
    edited 2015-04-18 05:57
    There are a couple of ways to do serial comms with PropGCC. Searching on terms "gcc fdserial" on here and "propgcc fdserial on Google will return a myriad of prior discussions, wiki and git links as well as relevant forum messages. I'm away from my development site for a couple of days otherwise I would have attached some code that does 350K comms all day long without issues both on selected pin pairs and through P30/31 and the FTDI USB port. There are a lot of ways to implement serial comms with widely varying amounts of code size and fdserial does take up a cog as it uses the Spin Full Duplex object's PASM section as it's engine. I'm rather interested in your project and desire to do it in C and PropBasic, than you for sharing!
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-04-18 06:40
    As I am attempting to get the 3D printer firmware done completely in C in LMM code for the first version:

    I still need to implement serial to get the G-Code from the host system, and send the OK's back to the host system.

    So what are the limits of pseudo RS232 (to the FTDI prop loader) in LMM GCC, and is there any sample code for this???

    For the sake of comparing code size I created this Hello World example. It also shows you almost all the different ways to say "Hello world" in C/C++ on the Propeller.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-18 06:45
    Ok so where do I get the C version of FDSerial?? I have been looking since the first response, and I find nothing.

    I have found a lot of examples of the usage of FDSerial though without FDSerial it does no good.

    I do thank you both.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-04-18 07:13
    Ok so where do I get the C version of FDSerial?? I have been looking since the first response, and I find nothing.

    I have found a lot of examples of the usage of FDSerial though without FDSerial it does no good.

    I do thank you both.

    It's assumed that you know how to write your own version :D

    It should be in the simple libraries
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-18 07:35
    PropGCC does have support for full-duplex-serial. Put the following code at the start of your program.
    #include <driver.h>
    
    /* list of drivers we can use */
    extern _Driver _FullDuplexSerialDriver;
    
    _Driver *_driverlist[] = {
        &_FullDuplexSerialDriver,
        NULL
    };
    
    The first driver in the list will be used for console I/O.
  • ersmithersmith Posts: 6,054
    edited 2015-04-18 07:36
    Ok so where do I get the C version of FDSerial?? I have been looking since the first response, and I find nothing.

    There's a version of FDSerial in the standard libraries. doc/Library.html in the propgcc repository has a discussion of how to install drivers and how to force the use of FDSerial instead of simple serial. However, if your communication is half-duplex (you mentioned you receive the code, and send back an OK, so half duplex may be sufficient) then you can save a COG by using the simple serial driver. That's the default for the C library. You can open multiple channels by doing fopen("SSER:parameters", "r+") or the like; again, Library.doc has the details.
  • twm47099twm47099 Posts: 867
    edited 2015-04-18 07:36
    Ok so where do I get the C version of FDSerial?? I have been looking since the first response, and I find nothing.

    I have found a lot of examples of the usage of FDSerial though without FDSerial it does no good.

    I do thank you both.

    The full duplex serial code can be found in the Simple Libraries download from the C Learning tutorials. The link to the (very simple) fds tutorial with the link to the download can be found here:
    http://learn.parallax.com/propeller-c-simple-protocols

    Tom
  • idbruceidbruce Posts: 6,197
    edited 2015-04-18 08:00
    It is located here: C:\Program Files\SimpleIDE\Workspace\Learn\Simple Libraries\TextDevices\libfdserial\fdserial.h

    #include "fdserial.h"

    Within that same directory....

    C:\Program Files\SimpleIDE\Workspace\Learn\Simple Libraries\TextDevices\libfdserial

    You will also find fdserial.c
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-04-18 08:52
    Well this isn't confusing at all. Duplicate versions of the same code? Can it be removed from Simple since it's already in PropGCC? Or, refactor Simple to use the existing code in PropGCC (since it looks like Simple provides a different interface - which shouldn't be removed for compatibility's sake)
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-18 11:38
    Well this isn't confusing at all. Duplicate versions of the same code? Can it be removed from Simple since it's already in PropGCC? Or, refactor Simple to use the existing code in PropGCC (since it looks like Simple provides a different interface - which shouldn't be removed for compatibility's sake)
    The authors of Simple Library believed that the library code that comes with PropGCC was too complicated to use and/or too large so they wrote their own.
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-04-18 12:04
    The advantage to using the standard library is that the code can be ported to other platforms. However, the problem with using the standard library on the Prop is that it doesn't do unbuffered single character I/O as easily as it's done with FDS in Spin. With standard I/O you would have to explicitly disable the blocking and buffering that's used by default. You also have to switch from using the default SimpleSerial driver to the FullDuplexSerial driver as shown in post #6. And then if you want to do the equivalent of the FDS RxCheck function you would have to do a bit more work. So given all of that, it's easier for a less experience programmer (or even an experienced programmer) to just use the FDS routines from the Simple Library.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-18 13:43
    Thank you all, I found it hiding in the Simple libraries.

    So that is another problem solved.
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-18 14:35
    Dave Hein wrote: »
    The advantage to using the standard library is that the code can be ported to other platforms. However, the problem with using the standard library on the Prop is that it doesn't do unbuffered single character I/O as easily as it's done with FDS in Spin. With standard I/O you would have to explicitly disable the blocking and buffering that's used by default. You also have to switch from using the default SimpleSerial driver to the FullDuplexSerial driver as shown in post #6. And then if you want to do the equivalent of the FDS RxCheck function you would have to do a bit more work. So given all of that, it's easier for a less experience programmer (or even an experienced programmer) to just use the FDS routines from the Simple Library.
    An attempt could have been made to provide simpler interfaces to the standard driver at least as an option rather than providing a completely separate API.
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-04-18 17:45
    Yes, that is a good idea. The file FdSerial.c that is part of the library contains an _FdSerial_rxcheck routine, and the header file contains function prototypes for _FdSerial_rx and _FdSerial_tx even though they're not in the .c file. These could be fleshed out and provided as an API to the programmer. That way the serial port could be accessed either through the stdio functions or through functions similar to the Spin FDS methods.
Sign In or Register to comment.