Shop Learn
serial communication in Propeller c — Parallax Forums

serial communication in Propeller c

bbrienbbrien Posts: 516

I have searched for more advanced serial protocol than talking to a terminal such as data between two propellers but all I get is "0 results found".

Comments

  • iseriesiseries Posts: 1,268

    Serial is used all over the place, but it may not be called serial. Baud rate might get you more hits.

    Anyway, here is a tutorial on the learn site of Parallax that talks about different protocols and some exercises:
    propeller-c-simple-protocols

    These devices require serial to work:
    parallax-wx-esp8266-wifi-module
    parallax-2-x-16-serial-lcd-with-piezo-speaker-backlit-blue

    The main thing with serial is that the TX pin goes to the RX pin on the other device and they both need the same baud rate.

    Mike

  • RaymanRayman Posts: 12,650

    I need to figure that out too.

    With FlexProp C, you can just use one the .Spin2 serial drivers.

    No idea how to do that with LLVM/Clang yet...

  • iseriesiseries Posts: 1,268

    @Rayman ,

    No need to use spin code. Have written serial drivers for both flexprop and llvm.

    With flexprop you can use the serial driver with fprintf so you can do formatted output to devices if need be.

    With LLVM you can do stdin, stdout.

    Open a new subject with examples of what you want to do.

    Mike

  • RaymanRayman Posts: 12,650

    Oh, does "Propeller C" refer to something specific? Is that SimpleIDE or GCC?

  • iseriesiseries Posts: 1,268

    @Rayman ,

    SimpleIDE is built on top of GCC and is the C compiler for P1 projects.

    Mike

  • RaymanRayman Posts: 12,650

    I've used Catalina for P1 projects in the past.
    Recently used FlexProp C for P1.

    I'm just wondering if "Propeller C" means some specific tool...

  • All of the examples work fine for printing to a terminal or LCD or whatever but I am trying to send binary date to be read and acted upon.

  • RaymanRayman Posts: 12,650

    I usually just send the data a byte at a time as if it were text.

    Sometimes make up a protocol like a few special characters to indicate start of a transmission.

    You may have to typecast data location as char pointer or something like that

  • RaymanRayman Posts: 12,650
    edited 2022-03-11 23:07

    I had flexprop C talking to labview on a pc here:
    https://forums.parallax.com/discussion/173513/labview-2020-nxg-connection-over-serial-port-to-flexprop-c-code

    Might or might not help

  • RaymanRayman Posts: 12,650

    The best example I seem to have uses the regular serial output to talk to LabView on a PC (instead of serial terminal), the dogbot.c file in thread from post #10 here.
    You can use the same idea to talk between propellers though.

    void Loop()
    {
    
        char s1[100] = "SA= 140";
        gets(s);
        int d=100;
        sscanf(s,"%s %d", s1, &d);
        _waitms(5);
        printf("SA= %d\n", d);
        //printf("%s\n", s);
        servo.write(0, d);
    
    }
    

    Looks like I used "gets()" to wait for serial input and then "sscanf()" to parse the message into a string and a digital number.
    So, not sending data as binary here but as plain text.

    Not really using any frame start or end here and you don't really have to with a simple USB connection to PC because it's usually perfect data.
    But, you'd need things like that if there's a chance of corrupted data or the two propellers not being in sync.
    Can add CRC if really worried about bad data...

  • Have a pair of programs that seem to work as far as sending some bytes but the functions aren't to my liking .

  • I also rewrote FDSerial for llvm (currently on a separate branch), so the file-based interface works there. For binary data, however, you’d just use the library functions _uart_putc() and _uart_getc() and write your own packeting system on top of it.

  • GenetixGenetix Posts: 1,669

    bbrien,

    Telescope Driver would be easier to understand if the actions where made individual functions.
    In the While loop of the Main function, after getting the switch inputs, the program transmits the Mode as a Decimal, the Direction as a character, and then a NewLine or CR character, before pausing and looping again.

    In the While of the Main of Orion, the Mode and Direction are retrieved which a Mode of 0 meaning no movement.
    Mode is converted back to a number by subtracting out the ASCII value of the number Zero.
    One big problem is the Switch statement which does not cancel out the other directions.
    If going East/West then North/South need to be canceled, and vice versa when going North/South.

    Normally LEDs and Switches are Active-High meaning they are On when a high voltage is connected, but they can be Active-Low.

    Active-Low is good when something shouldn't happen such as a part contact switch that shows a part is in place.

    Currently the Orion program is treating the Autoguider switches as Active-Low or active/working when their value is low.

  • iseriesiseries Posts: 1,268

    @Genetix ,

    Incorrect on the mode being zero means no movement. Mode is used to reference the speed array which always starts at zero.
    This way the array could be changed to allow for different movement values. Up/down might be faster than left/right.

    Since the direction is controlled by the square_wave function it can only effect one pin at a time and thus only move in one direction. Its only allowed to move in one direction for a half of a second and then stops.

    The motors are controlled by an A4988 type stepper chip that powers the motors at all times to keep it in one place. A step pulse is used to move the motors in one direction one movement at a time. It makes no difference where the pins are left since they only respond to change.

    One issue is that the motor driver is waiting one half second but the hand control is waiting at 50 milliseconds. The motor driver unit could be over driven by step movements since it is buffering the connection. The array storing incoming commands is only 8 long and could be over run by values.

    Mike

  • @Rayman said:
    The best example I seem to have uses the regular serial output to talk to LabView on a PC (instead of serial terminal), the dogbot.c file in thread from post #10 here.
    You can use the same idea to talk between propellers though.

    void Loop()
    {
    
      char s1[100] = "SA= 140";
      gets(s);
      int d=100;
      sscanf(s,"%s %d", s1, &d);
      _waitms(5);
      printf("SA= %d\n", d);
      //printf("%s\n", s);
      servo.write(0, d);
    
    }
    

    Looks like I used "gets()" to wait for serial input and then "sscanf()" to parse the message into a string and a digital number.
    So, not sending data as binary here but as plain text.

    Not really using any frame start or end here and you don't really have to with a simple USB connection to PC because it's usually perfect data.
    But, you'd need things like that if there's a chance of corrupted data or the two propellers not being in sync.
    Can add CRC if really worried about bad data...

    Maybe you could take some time and explain this concept in more detail , I got lost just looking at it , I am a rank amature at this stuff.

  • @Genetix said:
    bbrien,

    Telescope Driver would be easier to understand if the actions where made individual functions.
    In the While loop of the Main function, after getting the switch inputs, the program transmits the Mode as a Decimal, the Direction as a character, and then a NewLine or CR character, before pausing and looping again.

    In the While of the Main of Orion, the Mode and Direction are retrieved which a Mode of 0 meaning no movement.
    Mode is converted back to a number by subtracting out the ASCII value of the number Zero.
    One big problem is the Switch statement which does not cancel out the other directions.
    If going East/West then North/South need to be canceled, and vice versa when going North/South.

    Normally LEDs and Switches are Active-High meaning they are On when a high voltage is connected, but they can be Active-Low.

    Active-Low is good when something shouldn't happen such as a part contact switch that shows a part is in place.

    Currently the Orion program is treating the Autoguider switches as Active-Low or active/working when their value is low.

    Someone done changed the original wording and I dont understand what he wrote but setting i == 0 does present a problem since when the switch( opto-isolators) is depressed a 3.3 volt potential is applied to the io pin.

  • actually, the way this is supposed to function is when any button is depressed whether it is on the handbox or the guider, the motor connected to the depressed switch is supposed to run as long as the switch is depressed and stop when it is released. ( ==0)

  • MicksterMickster Posts: 2,090
    edited 2022-03-25 08:19

    @Rayman said:

    Sometimes make up a protocol like a few special characters to indicate start of a transmission.

    I just use 0xAA (10101010), followed by a slave-address, a few data-bytes and a checksum.

    Currently have Flexbasic+SmartSerial talking to a string of RPi Picos (multi-drop TTL UART with a schottky diode) @ 460KBaud; worked instantly and hasn't missed a beat :+1:

    LOVE this stuff! :smile:

    Craig

  • RaymanRayman Posts: 12,650

    @Mickster What is the function of the zener diodes?

  • iseriesiseries Posts: 1,268

    @Rayman ,

    That's so that the other nodes don't interfere with the others as they leave the TX as plus 3.3 or 5 volts.

    Mike

  • MicksterMickster Posts: 2,090

    @iseries said:
    @Rayman ,

    That's so that the other nodes don't interfere with the others as they leave the TX as plus 3.3 or 5 volts.

    Mike

    Schottky actually.
    Yeah, although it is a strict command response arrangement, it just feels better to provide a bit of protection. The devices are close proximity and it seems silly to use a differential transceiver.

    Craig

  • RaymanRayman Posts: 12,650

    I see something similar here: https://electronics.stackexchange.com/questions/505910/multidrop-rs232-diode-selection-and-doubts

    But, they are using 5V Zener diodes. Looks to me like just a regular diode would work. Not enough voltage here to get Zener breakdown...

  • OK "rayman" I just looked at your FlexProp C talking to labview and I do not understand any of this stuff. My programs are already written in Propeller C and I'll stick with it. My immediate problem is in the serial trans. I just need the command to apply the mode value and direction to the output pins.

  • Mickster ; What is SmartSerial and how does it differ from FDSerial.

  • MicksterMickster Posts: 2,090

    @Rayman said:
    I see something similar here: https://electronics.stackexchange.com/questions/505910/multidrop-rs232-diode-selection-and-doubts

    But, they are using 5V Zener diodes. Looks to me like just a regular diode would work. Not enough voltage here to get Zener breakdown...

    I remember looking-up the differences between regular/Schottky and apart from the lower volt-drop of the Schottky, I figured it would be better to go with its faster switching time. IIRC, even low-power Schottky is something like 14ns.

    Craig

  • MicksterMickster Posts: 2,090

    @bbrien said:
    Mickster ; What is SmartSerial and how does it differ from FDSerial.

    I believe that SmartSerial is derived from FDSerial. In the FlexBasic doc's SmartSerial is intended for Prop-2 whereas FDSerial is Prop-1

    Craig

  • RaymanRayman Posts: 12,650

    Ok, Schottky makes more sense.

  • GenetixGenetix Posts: 1,669
    edited 2022-03-26 20:56

    bbrien,

    I create program constants whenever possible since it makes the program easier to understand and modify.

    Notice the constants at the top of each of these programs:
    https://learn.parallax.com/tutorials/language/propeller-c/propeller-c-simple-protocols/half-duplex-serial
    https://learn.parallax.com/tutorials/language/propeller-c/propeller-c-simple-protocols/spi-example/bit-masks-better-code
    https://learn.parallax.com/tutorials/language/propeller-c/propeller-c-simple-protocols/diy-i2c/more-data-types-and-devices

    if (PushButton[Number] == Pressed) is easier to understand than if (i == 1).

    const int Pressed = 1;     // Button is High when pressed.
    
Sign In or Register to comment.