Serial I/O with Propeller C code

BTL24

What is the simplest way to send Serial commands with the Prop C system?

I have been attempting to get my Propeller (Activity Board) to transmit and receive simple command / status to/from my Motor Mind B (DC motor controller) at 2400 BAUD... both Parallax products and am having mixed results. Primarily because I don't know which simple serial command to use. I have looked through tutorials and example code.... but nothing is available to provide simple example or reference... other than the libraries.. which sometimes lack the practical example.

So, I tried "fdserial" structure, and then just "serial" structure. The half duplex "serial" function seems to be able to get the Motor Mind to run. When I try and read back status, I get weird results.

I would like to use something very simple like the SX command SEROUT or SERIN, where the pin, baud and value are included in the command. Also, it allows for multiple bytes to be sent with one command string.

Anything in the libraries that would do something similar to the SX or BASIC stamp commands?

Thanks,
Brian (BTL24)

jazzed

Hi.

Try this: http://learn.parallax.com/propeller-c-start-simple

BTL24

jazzed wrote: »

Hi.

Try this: http://learn.parallax.com/propeller-c-start-simple

Thanks, but I have been through that site with fine toothed comb...a few times. Can't find anything on serial interface.

The libraries have quite a group of "text" routines with serial commands. Couldnt find anything that appeared to be a solution to my problem. I do wish they had examples to follow.

I just want to send and receive 2 or 3 bytes at a time from serial interface with sensors, motor controllers....the fundamentals. I just cant figure it out with the prop...I can't find a reference manual geared toward both the prop and C. Lots of places to look, but confusing when you want a simple reference manual with the most basic commands.

Sorry for vent. I spent way too much time searching for answers today. In comparison, I could have finished this task in 30 minutes with SX or Stamp. But, I want to branch out to prop and C....so much of this is my learning curve.

Thanks for the link anyways...

Regards,
BTL24 (Brian)

Dave Hein

Brian,

The C serial interface uses the standard I/O approach, which is great for user input and output, but it's often an overkill for talking to other devices. Using the standard C serial I/O to talk to device requires working around the buffering that is done on the input and output. I think your best bet is to use the FullDuplexSerial object and convert it from Spin/PASM to C using spin2cpp. I create a test program that uses the converted FullDuplexSerial object, and attached it below. It prints "Hello World" to the console, and the reads characters and echos them back. It uses pins 31 and 30 for serial RX and TX at a baud rate of 115200. You can change these to the pins and baudrate that you need to use.

Dave

BTL24

Dave Hein wrote: »

Brian,

The C serial interface uses the standard I/O approach, which is great for user input and output, but it's often an overkill for talking to other devices. Using the standard C serial I/O to talk to device requires working around the buffering that is done on the input and output. I think your best bet is to use the FullDuplexSerial object and convert it from Spin/PASM to C using spin2cpp. I create a test program that uses the converted FullDuplexSerial object, and attached it below. It prints "Hello World" to the console, and the reads characters and echos them back. It uses pins 31 and 30 for serial RX and TX at a baud rate of 115200. You can change these to the pins and baudrate that you need to use.

Dave

Dave,

Thanks for your response and I better understand that prop C may be a tad more burdensome when working with serial I/O. So you think I should go back to full duplex.. Hmmmm. I am having some luck with the half duplex mode using "serial_txchar". It is the "serial_rxchar" that I am getting nonsense answers back. So it could be I have set up the commands wrong... or the Motor Mind B is malfunctioning. I think it is my ignorance with Prop C serial I/O.

If you are interested....I have attached a sample of code with several serial commands to the Motor Mind B (a DC motor controller). As you can see, the code gets cumbersome with all the "serial_txchar" commands.... rather than one command that sends a string of HEX values out to the port, all at once. This is especially worrisome when using the "serial_rxchar" in multiple calls, as I don't know the timing of the port and the sending unit (MMB) may have already finished its transmission before the prop sees it.

I have also tried moving groups of code into functions... but then I had to open a serial port in each function.... that adds a time delay since the function has to keep opening the port every time it is called. It would be great if I could "publicly" open the serial port called MMB and then use it within the function code. I tried using the PUBLIC parameter... with no success (again, due to my inexperience with prop C).

/*
  motor mind B9.c

  11/15/13  BTL- Original Code 
                  
  NOTE:   1) Motor Mind B => MMB; Serial link is 2400 BAUD
*/

#include "simpletools.h"                      // Include simpletools header
#include "servo.h"                            // Include servo header
#include "simpletext.h"

int main(void)                          // main function
{
  serial *MMB;                       //Establish Serial Port called MMB (Motor Mind B controller)
  MMB = serial_open(14,15,0,2400);  // Prop Pin 14 is RX,  Prop Pin 15 is TX, Mode = n/a, BAUD 2400
  
//--------------Clear MMB Modes --------------------------------------
  print("Clear MMB Modes\n");
  low(15);                              //Get MMB out of SPDCON mode
  pause(500);                           //Hold Low for over 250mS to clear SPDCON mode
  high(15);
  pause(1000);

//----------------Send Stop Command ----------------------------------
  print("Send Stop Command\n");
  serial_txChar(MMB,0x55);           //Sync Byte to MMB;  85=0x55 HEX
  serial_txChar(MMB,00);             //Stop Command to MMB
  pause(1000);

//-----------------Status Check --------------------------------------
  int status = 0;                  //Clear Variables for Reading back info from MMB
  int dutycycle = 0;
  serial_txChar(MMB,0x55);         //Sync Byte to MMB; 85=0x55 HEX
  serial_txChar(MMB,05);           //Request Status from MMB
  status = serial_rxChar(MMB);     //Read Status from MMB
  dutycycle = serial_rxChar(MMB);  //Read Dutycycle from MMB
  print("status Byte hex = %x\n", status);        //Display results
  print("dutycycle Byte hex = %x\n", dutycycle);
  print("  \n");

//--------------- Send Speed Commands-----------------------------

  print("Send Speed Command - 255\n");
  serial_txChar(MMB,0x55);             //Sync Byte to MMB; 85=0x55 HEX
  serial_txChar(MMB,03);               //Speed Command to MMB - (0 to 255)
  serial_txChar(MMB,255);              //Speed
  pause(3000);

//-----------SEND STOP COMMAND --------------------------------------------
  print("Send Stop Command \n");
  serial_txChar(MMB,0x55);             //Sync Byte to MMB; 85=0x55 HEX
  serial_txChar(MMB,00);               //Reverse Command to MMB - 01
  pause(1000);

//-----------SEND REVERSE COMMAND --------------------------------------------
  print("Send Reverse Command \n");
  serial_txChar(MMB,0x55);             //Sync Byte to MMB; 85=0x55 HEX
  serial_txChar(MMB,01);               //Reverse Command to MMB - 01
  pause(500);

}

jazzed

Glad you're making progress here. Looks like all your searching is paying dividends.

If you move "serial *MMB;" out of the main function, you can access it from any function.

A SERIN equivalent will require using fdserial instead of serial.

Dave Hein

Brian, I would suggest using full-duplex instead of half-duplex because there's a chance you will drop characters or miss the start bit with half-duplex. From jazzed's comment it sounds like you can use fdserial instead of serial for your application.

jazzed

Here's an example of serin/serout in C.

The semantics of serin(...) are not the same as SERIN for pbasic, because i'm too lazy to implement setjmp at the moment.

/**
 * This is the main serial_inout program file.
 */
#include "simpletools.h"
#include "fdserial.h"

#define NONE 0
#define DEC 1
#define HEX 2
#define BIN 3
#define CHR 4

void serout(text_t *ser, int delay, char* string, int type, int val, int end);
void  serin(text_t *ser, int wait, void (*function)(), int type, void* value);

void fail() {
  print("FAIL\n");
}

int main(void)
{
  int inpin = 31;
  int outpin= 30;
  int baud  =115200;
  int value = 0x55;

  text_t *ser = fdserial_open(inpin, outpin, 0, baud);

  /* only used if we want to use print like in the fail function */
  if(inpin == 31 || outpin == 30) {
    extern terminal *dport_ptr;
    dport_ptr = ser;
  }

  pause(500);
  print("SEROUT/SERIN DEMO\n");

  while(1)
  {
    serout(ser, 100, "HELLO", 0, value, CR);
    serout(ser, 1, "DEC VAL ", DEC, value, CR);
    serout(ser, 1, "HEX VAL ", HEX, value, CR);
    serout(ser, 1, "BIN VAL ", BIN, value, CR);
    serout(ser, 1, "CHR VAL ", CHR, value, CR);

    print("Enter DEC: ");
    serin(ser, 5000, fail, DEC, &value);
    print("Got %d\n", value);

    print("Enter HEX: ");
    serin(ser, 5000, fail, HEX, &value);
    print("Got %x\n", value);

    print("Enter BIN: ");
    serin(ser, 5000, fail, BIN, &value);
    print("Got %b\n", value);

    print("Enter CHR: ");
    serin(ser, 5000, fail, CHR, &value);
    print("Got %c\n", value);
  }
  return 0;
}

void serout(text_t *ser, int delay, char* string, int type, int val, int end)
{
  int n = 0;
  int len = strlen(string);

  for(n = 0; n < len; n++) {
    writeChar(ser, string[n]);
    pause(delay);
  }

  if(DEC == type) {
    writeDec(ser, val);
    pause(delay);
    writeChar(ser, end);
  }
  else if(HEX == type) {
    writeHex(ser, val);
    pause(delay);
    writeChar(ser, end);
  }
  else if(BIN == type) {
    writeBin(ser, val);
    pause(delay);
    writeChar(ser, end);
  }
  else if(CHR == type) {
    writeChar(ser, val);
    pause(delay);
    writeChar(ser, end);
  }
  else {
    writeChar(ser, end);
  }
}


void  serin(text_t *ser, int wait, void (*function)(), int type, void* value)
{
  char buf[33]; // big enough for hex, dec, bin, or char

  while(--wait > -1) {
    if(fdserial_rxReady(ser))
      break;
    pause(1);
  }
  if(wait < 0) {
    writeLine(ser, "No input");
    function();
    return;
  }

  readStr(ser, buf, 33);

  if(DEC == type) {
    sscan(buf, "%d", value);
  }
  else if(HEX == type) {
    sscan(buf, "%x", value);
  }
  else if(BIN == type) {
    sscan(buf, "%b", value);
  }
  else if(CHR == type) {
    sscan(buf, "%c", value);
  }
}

Example output.

SEROUT/SERIN DEMO
HELLO
DEC VAL 85
HEX VAL 55
BIN VAL 1010101
CHR VAL U
Enter DEC: 55
Got 55
Enter HEX: 55
Got 55
Enter BIN: 55
Got 1
Enter CHR: k
Got k
HELLO
DEC VAL 107
HEX VAL 6b
BIN VAL 1101011
CHR VAL k
Enter DEC: No input
FAIL
Got 107
Enter HEX: No input
FAIL
Got 6b
Enter BIN: No input
FAIL
Got 1101011
Enter CHR: No input
FAIL
Got k
HELLO
DEC VAL 107
HEX VAL 6b
BIN VAL 1101011
CHR VAL k
Enter DEC: 88
Got 88
Enter HEX: 55
Got 55
Enter BIN: 10101010
Got 10101010
Enter CHR: j
Got j
HELLO
DEC VAL 106
HEX VAL 6a
BIN VAL 1101010
CHR VAL j

SRLM

If you happen to need a C++ serial driver you can find one here. It's based on Lonesock's FFDS1 and includes full unit testing, which you can use to see how it works. Note that it needs the numbers class in order to translate between strings and ints.

BTL24

Dave, Jazzed and SRLM,

Wow! Thanks for all the quick feedback and the examples. I love examples.

So many ways to slice it... but it looks like fdserial is going to be the final answer... Thanks.

For starters though, I took Jazzed's recommendation and moved "serial MMB" outside of the Main function (still using half duplex) .... and VOILA... it worked. No more build errors and the functions now are very responsive. At least the transmit portion of my problem using functions has a temporary solution. I don't have to keep opening new serial ports in each function. I learned something here.. thanks.

Now I will need to read more on fdserial and study Jazzed examples and C version of SERIN and SEROUT.

NOW if you are wondering what I am using this for... check out my posts on DIYChristmas.org (Christmas lighting forum). I am building a new animated prop... a Candy Cane Factory.

Here is the link....
http://www.diychristmas.org/vb1/showthread.php?1138-Candy-Cane-Factory-Lightman-Version

Thanks again,
BTL24 (Brian)

ericpine

This was a nice litte jump start for me, thanks for posting !

NeilRogers

Is it possible to use this same serial code to transmit/receive from the uLCD TOUCH SCREEN?
I have done the serial setup, per the instructions, but I do not see any C samples, all samples are SPIN based.

jazzed

NeilRogers wrote: »

Is it possible to use this same serial code to transmit/receive from the uLCD TOUCH SCREEN?
I have done the serial setup, per the instructions, but I do not see any C samples, all samples are SPIN based.

It should work as long as it's a serial port device and you have the right baudrate and signal sense.

ericpine

Is there any easy way to read 7E2 data from a device? I am under the impression that serial.h and fdserial.h only work with 8 bits. I need to configure my project to interface 1200-115.2k baud, 7 or 8 data bits. Any tips?

jazzed

Here is a 7 bit serial library. I have no way to test it though. It either works or it doesn't.

A fully specifiable 7 bit or 8 bit library is probably months away considering my schedule.

DavidZemon

As per posts 26-29 of this thread, I'm starting creation of a new serial (UART) library within PropWare that will, at very least, allow for all types of communication outlined by this wiki article. Well... probably all types. I'll start with simplex, then full duplex (unless you explicitly need half-duplex ericpine) and, if those go well, move on to half-duplex. But a 5-9 bit range with variable stop bits and even/odd parity are non-negotiable requirements.

If anyone has any requests as I get started on this, let me know. The interface will likely be very similar to my SPI interface (unless of course someone chimes in with a better idea).

And, as always, this code is public on Github so anyone is free to help!

Look for the beginnings of this code to start showing up in commit logs either tonight or within the next few days. I do not expect anything to be testable, let alone operational, for at least a week.

--Edit--
Perhaps this will go a lot faster with jazzed's post for 7-bit serial. Just need to convert to assembly and add some options now

Dave Hein

7E2 means 7 data bits, 1 even parity bit and 2 stop bits. You should be able to receive that with any of the serial drivers. The parity bit will be in the MSB of the byte. If you need to transmit 7E2 you can generate the even parity bit yourself. The serial drivers normally issue a single stop bit, but your device might be able to accept that. Otherwise, you could write a routine to wait after sending each character to ensure that you have at least two stop bits. Or you could use a modified driver that generates 2 stop bits.

ericpine

Jazzed,

No complaints!

I'm exited to try it out (and pick thru the brains).

Let me know how many man-hours I owe you, I will gladly repay with CNC machine time.

-EP

ericpine

Jazzed, I used "realterm" to interface the test harness at 7bit 115.2k. The output from the prop comes in fine, but I'm having trouble sending input to the prop. I'll keep testing !

DavidZemon

Simplex is fully tested in PropWare. Docs are non-existent for it - I'll add them next before moving on to full-duplex. But, I did add an example program (Examples/PropWare_UART) that should show you everything you need to know to use simplex. I've only pushed this to the nightly branch - find it here or a direct link to uart.h.

Eric, are you looking for simplex, half duplex, or full duplex?

David

ericpine

For my application, half duplex is fine.

-EP

jazzed

ericpine wrote: »

Jazzed, I used "realterm" to interface the test harness at 7bit 115.2k. The output from the prop comes in fine, but I'm having trouble sending input to the prop. I'll keep testing !

Did you try to modify the program to make input work?

ericpine

Jazzed, I am sorting through the files and I note the following:

libfdserial.c (functional test harness of 8 bit full duplex) ~ libserial7.c (Though 7 bit is based on half duplex "serial7.h")
fdserial.c is 8 bit ~ serial7.c (says 7 bit full duplex) is about 30% of the code of fdserial.c (not sure why)
serial.h ~ serial7.h
serial_rxtx.c ~ serial7_rxtx.c
fdserial.h (8 bit) has no 7 bit companion.

Just trying to compare files at this point and find any issues.

The fact that the output from the prop to "Realterm" is fine in 7 bit gives me much hope it will be a small code issue on the input side.

Nearly there!

-EP

jazzed

Hmm. I'm a little lost on all the fdserial stuff.

The zip I posted doesn't have any actual fdserial code in it.

Try this one ... no cog required like before. I verified it works with putty in 7 bit mode.

ericpine wrote: »

Jazzed, I am sorting through the files and I note the following:

libfdserial.c (functional test harness of 8 bit full duplex) ~ libserial7.c (Though 7 bit is based on half duplex "serial7.h")
fdserial.c is 8 bit ~ serial7.c (says 7 bit full duplex) is about 30% of the code of fdserial.c (not sure why)
serial.h ~ serial7.h
serial_rxtx.c ~ serial7_rxtx.c
fdserial.h (8 bit) has no 7 bit companion.

Just trying to compare files at this point and find any issues.

The fact that the output from the prop to "Realterm" is fine in 7 bit gives me much hope it will be a small code issue on the input side.

Nearly there!

-EP

ericpine

Here are two photos, Realterm running at 115.2k 72E. First one shows the output from the prop just fine. Second one, I entered 1 2 3 4 a s d f (seen in red) and the echo Is shown In yellow all jammed together on the
same line.

jazzed

Try no parity.

ericpine

Changing parity doesn't effect the output.

I have a gut feeling that this must be something I'm doing wrong on the compiler end.

Here is my compile debug if it is of any value:

propeller-elf-gcc.exe -v GCC 4.6.1 (propellergcc_v1_0_0_2162)
propeller-elf-gcc.exe -I . -L . -I ./library/libsimpletext -L ./library/libsimpletext/cmm/ -I C:/Users/Eric/Documents/SimpleIDE/My Projects/libserial7/library/libsimpletext -L C:/Users/Eric/Documents/SimpleIDE/My Projects/libserial7/library/libsimpletext/cmm/ -Os -mcmm -Wall -m32bit-doubles -fno-exceptions -std=c99 -c serial7.c -o cmm/serial7.o
serial7.c: In function 'serial7_open':
serial7.c:29:10: warning: assignment from incompatible pointer type [enabled by default]
propeller-elf-gcc.exe -I . -L . -I ./library/libsimpletext -L ./library/libsimpletext/cmm/ -I C:/Users/Eric/Documents/SimpleIDE/My Projects/libserial7/library/libsimpletext -L C:/Users/Eric/Documents/SimpleIDE/My Projects/libserial7/library/libsimpletext/cmm/ -Os -mcmm -Wall -m32bit-doubles -fno-exceptions -std=c99 -c serial7_rxtx.c -o cmm/serial7_rxtx.o
propeller-elf-ar.exe rs cmm/libserial7.a cmm/serial7.o cmm/serial7_rxtx.o
propeller-elf-ar.exe: creating cmm/libserial7.a
propeller-elf-gcc.exe -I . -L . -I ./library/libsimpletext -L ./library/libsimpletext/cmm/ -I C:/Users/Eric/Documents/SimpleIDE/My Projects/libserial7/library/libsimpletext -L C:/Users/Eric/Documents/SimpleIDE/My Projects/libserial7/library/libsimpletext/cmm/ -o cmm/libserial7.elf -Os -mcmm -Wall -m32bit-doubles -fno-exceptions -std=c99 libserial7.c cmm/libserial7.a -lm -lsimpletext -lm -lsimpletext -lm -lsimpletext -lm -lm -lsimpletext -lm
libserial7.c: In function 'main':
libserial7.c:44:3: warning: unknown conversion type character 'b' in format [-Wformat]
libserial7.c:44:3: warning: unknown conversion type character 'b' in format [-Wformat]
libserial7.c:44:3: warning: unknown conversion type character 'b' in format [-Wformat]
libserial7.c:44:3: warning: unknown conversion type character 'b' in format [-Wformat]
libserial7.c:44:3: warning: unknown conversion type character 'b' in format [-Wformat]
libserial7.c:44:3: warning: unknown conversion type character 'b' in format [-Wformat]
libserial7.c:44:3: warning: too many arguments for format [-Wformat-extra-args]
libserial7.c:47:3: warning: format '%f' expects argument of type 'double', but argument 3 has type 'float' [-Wformat]
libserial7.c:47:3: warning: format '%f' expects argument of type 'double', but argument 4 has type 'float' [-Wformat]
libserial7.c:47:3: warning: format '%f' expects argument of type 'double', but argument 5 has type 'float' [-Wformat]
libserial7.c:47:3: warning: format '%f' expects argument of type 'double', but argument 6 has type 'float' [-Wformat]
libserial7.c:47:3: warning: format '%f' expects argument of type 'double', but argument 7 has type 'float' [-Wformat]
libserial7.c:47:3: warning: format '%f' expects argument of type 'double', but argument 8 has type 'float' [-Wformat]
libserial7.c:58:5: warning: format '%f' expects argument of type 'double', but argument 3 has type 'float *' [-Wformat]
libserial7.c:58:5: warning: format '%f' expects argument of type 'double', but argument 4 has type 'float *' [-Wformat]
libserial7.c:119:3: warning: format '%d' expects argument of type 'int', but argument 3 has type 'int *' [-Wformat]
libserial7.c:119:3: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'int *' [-Wformat]
libserial7.c:119:3: warning: format '%f' expects argument of type 'double', but argument 5 has type 'float *' [-Wformat]
libserial7.c:119:3: warning: format '%f' expects argument of type 'double', but argument 6 has type 'float *' [-Wformat]
libserial7.c:120:3: warning: format '%f' expects argument of type 'double', but argument 6 has type 'float' [-Wformat]
libserial7.c:120:3: warning: format '%f' expects argument of type 'double', but argument 7 has type 'float' [-Wformat]
propeller-load -s cmm/libserial7.elf
propeller-elf-objdump -h cmm/libserial7.elf
Done. Build Succeeded!

jazzed

I don't see any difference in the build status (congrats on figuring that out btw).

How many bytes get loaded?

I tested with putty using N17 (71N) and everything worked fine. Didn't realize you need E72 ....

Guess I'll make a E72 version when I'm not dead tired.

ericpine

11792 bytes, 12048 total in the build.

I really just need the prop to have full serial flexibility like the BS2 serin/out commands.

I didn't want to design around the BS2sx/px or BS2p for obvious reasons, but if I have to for a while, I guess that is a no-brainer.

Take a break, Jazzed !

Thanks so much for getting propeller 7 bit I/O this far!

-EP

DavidZemon

Thanks to PropGCC, that got done a lot faster than expected. There's clearly some speed improvements that can be made - either on the receiving or sending end, I haven't checked yet. I ran successful tests sending and receiving data at up to 122000 baud with lots of different configurations (varying data width, parity and stop bits), but any faster and my example project started printing incorrect data.

Code is still only in the nightly branch - I'll merge with the main 2.0 release branch tomorrow night after I finish up the documentation. Again, the example project should provide all the info you need, but let me know if you have questions.

ericpine

SwimDude0614 wrote: »

Thanks to PropGCC, that got done a lot faster than expected. There's clearly some speed improvements that can be made - either on the receiving or sending end, I haven't checked yet. I ran successful tests sending and receiving data at up to 122000 baud with lots of different configurations (varying data width, parity and stop bits), but any faster and my example project started printing incorrect data.

Code is still only in the nightly branch - I'll merge with the main 2.0 release branch tomorrow night after I finish up the documentation. Again, the example project should provide all the info you need, but let me know if you have questions.

David, you are speaking of PropWare?