Yep. It should be good to go. I also generated a binary distribution this time with the most up-to-date code in nightly, so if you don't want to build it yourself, just download it here.
Suppose I have a device that outputs RS232 and after each transmission, only "LF" (line feed ASCII ~ Decimal 10) is output. Usually, a CR (Carriage Return ~ Decimal 13) is output and I see that the Prop C code expects that CR in order to return from the dscan/readDec functions. Any tips on a quick way to make LF decimal value become equivalent to a CR so my program can register the data after an "LF"?
This application is simply listening for decimal numbers from a device and then using them to direct program flow.
I'm thumbing through the .h files and don't see anything I can tweak just yet.
I've also been fighting with the device to output a binary 13 (%00001101) to force a CR, but so far it just outputs an ASCII string of 0's and 1's.
if it's something you need in PropWare's UART library, let me know and I can add it. i think i moved from UART to cmake right before creating a multi-word receive method, so I can switch gears again if you need.
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 !
Are you sure it is 7bit? The default is 8N1, but it will work sometimes with a terminal setting of 7N2. You may be just have to shift your RealTerm to 8N1 (or 8E1) to get the same or better results.
Post #15 of this thread has a 7 bit test lib from Jazzed.
I solved my I/O problem in "serial7.c". In the first few lines of code under the #include, "int j = 7;" becomes "int j = 8;"
Now I am testing and found that the device isn't sending "CR" and that seems to be a problem. I may also have a signal inversion parameter to regard as well, I'll test in a few hours.
Okay, tested... O-scope shows actual +/- 12v RS232 levels (yeah its an old pc of equipment!) My DB9 serial adapters are not fairing well on the scope. I'm thinking this is a job for the MAX232 chip.
I assume that the printing ASCII strings to the LCD is working properly and proves that the serial output is AOkay. If NOT, you may not have opened the serial port correctly.
Your output to the LCD seems to be a long series of NUL with a few LF-CR instances. NUL is binary 0000_0000 in ASCII, so it seems that the output is all zeros.
Try just outputting a "Hello World /n" to see if ASCII is working.
If that works, it might be the wrong type conversion on input and or output.
The problem is that the Serial input and the Serial output are character based, which is conceptually a string in C.
Whereas storage is in binary with several choices -- char, int, unsigned int, and floating point.
Personally, I have less trouble with the conversion to characters for output than how you convert an input to decimal, especially a floating point decimal input. It seems that only floating point would be actual decimal storage, but I read that in C the actual floating point is a binary floating point. In other words, there seems to be a conversion into a variable of your choice; and a second conversion to a decimal based string for output regardless of which type of storage you choose for transfer to the output.
At the moment, I am having success with the basic stamp getting the serial data from my old RS232 devices. The prop works fine on the PC and functions as intended, but when I interface those same devices that the basic stamp works with, the prop isn't reacting correctly. I'm scratching my head as to why this is going on....
The photo in post #37 of this thread shows data that the BS2 works fine with, using the command "SERIN" with the DEC (decimal formatter). That SERIN command on the BS2 series is what I need to replicate on the prop. I would like to see it work in C code.
Well, I suspect that you are having trouble with figuring out the way the Simpletools and Simpletext libraries use the Serial port.
I think that you need to verify your set up in two steps -- get a basic port open, then get the kind of information you desire through the port.
A. Just output a message to the LCD that doesn't require any numeric data. Getting this running verifies that you have a properly set up serial port services, and the LCD is working right.
B. After that, you can delve deeper into sending numeric data to the the LCD.
+++++++++++++
The situation is that C is a 'more strongly typed' language than PBasic, that requires some attention to outputting the right format and conversion of types. I suspect that is where your output to the LCD is failing.
Whereas PBasic seems pretty straight forward in how numeric and text data are sent.
(NOTE - Someone is very likely to jump in and say that PBasic is not a typed language at all, whereas C is a weakly typed language. It is not really important to figure out how strongly typed C is. The point it that it is TYPED and you have to get the types properly declared or the output may be trashed.)
I can output to the LCD just fine. My program listens for serial data on the debug port, and when it gets a decimal value (ASCII) it outputs that value to the LCD. I basically program the propeller EEPROM then connect it to a PC terminal program running on the proper com port with the proper baud rate settings. The prop works great when connected to a PC this way, but when I connect it to a CNC machine, I get incorrect output displayed on LCD. Output from the CNC machines is proven to work correctly. I can send and receive CNC programs with no trouble, and the BS2 version of my setup is proven to work accurately. !@#$%^
I am only sending integers from the CNC machines. I don't think I have an issue because there is no floating point in the data I am dealing with. I'm not quite sure what the problem could be.
Maybe all the nulls are overflowing the buffer? Any thoughts?
BS2SX - SERIN command with DEC (decimal) modifier works just fine, so my wiring is good....
It does seem a slightly strange stream.
Can you check in a HEX mode Terminal display, and also check how the BS2SX - SERIN command with DEC (decimal) modifier
handles the not-normal chars. (maybe it simply skips them at lowest level)
If you have an O-scope, also check if the CNC is sending any Break or other non std signals.
(Break is a pulse wider than all low )
The prop works great when connected to a PC this way, but when I connect it to a CNC machine, I get incorrect output displayed on LCD. Output from the CNC machines is proven to work correctly. I can send and receive CNC programs with no trouble, and the BS2 version of my setup is proven to work accurately. !@#$%^
Do you mean here that a 'clean' string from the PC, handles ok in the Prop C code ?
For that test, do you type that in (gives gaps), or paste/send (no gaps)
Check on O-Scope that the total char times are the same. (7E2 is 10 bit times ?)
I don't think one needs to turn to an oscilloscope in this instance. He is already using RealTerm that can diagnose just about anything a serial stream with throw out.
Only sending integers, but are you relying on conversitions to Decimal?
My C skills are minimal, but I strongly suspect that the problem lies in how the input buffer on the Propeller is scanned for numerical values.... especially if the values are floating point or demical.
The incoming stream of bytes provides everything represented in ASCII, but -- unlike the BS2 -- C can scan the buffer for numbers and store them away as integers, unsigned integers, characters, signed characters, and floating-point.
Also there is the 'wide character' feature that might mess things up if it is unintentionally deployed.
================
What I am trying to say is that I suspect that either there is a failure of the input to grasp anything (thus you get a string of nulls on the output side), or there is an error in deploying the right type for the input somewhere along the way from input to output.
That is why I suggested that one first verify that output is working right.
++++++++++++++++
I recently became aware of how complex the input buffer can be in C while looking at G-code parsing for CNC.
Coming from a BasicStamp background, I was shocked by how much code and the implications of what the input buffer does in C.
I am still trying to full comprehend how to make it work well when you have a string of serial input that has a combination of letters, integers (unsigned), and floating point. I suspect it requires fully anticipating what the input strings will be on a case-by-case basis. It helps if the received input is some how in packets that are terminated by a /n or /0. Then the input buffer can analize the whole and dump the buffer after the input is resolved.
I suspect that trying to take a character-by-character approach to processing the input buffer in such situation will pretty much ignore use functions available in the the Simpletools and Simpletext libraries... and just make the code more work. But if you goal is merely to provide display services on an LCD, a character-by-character approach might be optimal with a simple FIFO approach to use of the input buffer.
I was under the impression that the inversion was only for full duplex. I've tried about everything, but when I invert on half duplex, the Prop still brings in data either way from the PC, leading me to "assume" the inversion isn't working. Recall this is for the 7 bit lib as well as the 8 bit lib. Thx!
Comments
This application is simply listening for decimal numbers from a device and then using them to direct program flow.
I'm thumbing through the .h files and don't see anything I can tweak just yet.
I've also been fighting with the device to output a binary 13 (%00001101) to force a CR, but so far it just outputs an ASCII string of 0's and 1's.
ugh!
Function documentation:
http://man7.org/linux/man-pages/man3/getline.3.html
if it's something you need in PropWare's UART library, let me know and I can add it. i think i moved from UART to cmake right before creating a multi-word receive method, so I can switch gears again if you need.
Are you sure it is 7bit? The default is 8N1, but it will work sometimes with a terminal setting of 7N2. You may be just have to shift your RealTerm to 8N1 (or 8E1) to get the same or better results.
Post #15 of this thread has a 7 bit test lib from Jazzed.
I solved my I/O problem in "serial7.c". In the first few lines of code under the #include, "int j = 7;" becomes "int j = 8;"
Now I am testing and found that the device isn't sending "CR" and that seems to be a problem. I may also have a signal inversion parameter to regard as well, I'll test in a few hours.
Okay, tested... O-scope shows actual +/- 12v RS232 levels (yeah its an old pc of equipment!) My DB9 serial adapters are not fairing well on the scope. I'm thinking this is a job for the MAX232 chip.
The Prop C program attached works fine on PC when I test, but cannot seem to detect the decimal output from a REAL RS232 device (through a MAX3232).
Signal shows up fine on the o-scope and the prop either outputs the data read incorrectly or not at all on LCD screen.
Maybe all the nulls are overflowing the buffer? Any thoughts?
BS2SX - SERIN command with DEC (decimal) modifier works just fine, so my wiring is good....
#include "simpletools.h" #include "serial7.h" // COMPILE IN LMM MODE !!! #include "simpletext.h" const int ON = 22; const int CLR = 12; const int CRLF = 13; int value; serial7 *text; int main() { while(1) { text = serial7_open(31,30,0,4800); //dprint(text,"Enter a decimal:"); //terminal com input verify value=readDec(text); //pause(100); //dprint(text,"You entered %d\n",value); //terminal com output verify //pause(500); serial *lcd = serial_open(15, 15, 0, 9600); writeChar(lcd, ON);//display on, cursor off, no blinking writeChar(lcd, CLR);//home position pause(5); dprint(lcd, "7E2 4800 baud"); pause(50); writeChar(lcd, CRLF); //next line pause(50); dprint(lcd,"%d",value); } }http://stackoverflow.com/questions/22030336/c-converting-string-char-input-to-floating-point
I assume that the printing ASCII strings to the LCD is working properly and proves that the serial output is AOkay. If NOT, you may not have opened the serial port correctly.
Your output to the LCD seems to be a long series of NUL with a few LF-CR instances. NUL is binary 0000_0000 in ASCII, so it seems that the output is all zeros.
Try just outputting a "Hello World /n" to see if ASCII is working.
If that works, it might be the wrong type conversion on input and or output.
The problem is that the Serial input and the Serial output are character based, which is conceptually a string in C.
Whereas storage is in binary with several choices -- char, int, unsigned int, and floating point.
Personally, I have less trouble with the conversion to characters for output than how you convert an input to decimal, especially a floating point decimal input. It seems that only floating point would be actual decimal storage, but I read that in C the actual floating point is a binary floating point. In other words, there seems to be a conversion into a variable of your choice; and a second conversion to a decimal based string for output regardless of which type of storage you choose for transfer to the output.
The photo in post #37 of this thread shows data that the BS2 works fine with, using the command "SERIN" with the DEC (decimal formatter). That SERIN command on the BS2 series is what I need to replicate on the prop. I would like to see it work in C code.
I think that you need to verify your set up in two steps -- get a basic port open, then get the kind of information you desire through the port.
A. Just output a message to the LCD that doesn't require any numeric data. Getting this running verifies that you have a properly set up serial port services, and the LCD is working right.
B. After that, you can delve deeper into sending numeric data to the the LCD.
+++++++++++++
The situation is that C is a 'more strongly typed' language than PBasic, that requires some attention to outputting the right format and conversion of types. I suspect that is where your output to the LCD is failing.
Whereas PBasic seems pretty straight forward in how numeric and text data are sent.
(NOTE - Someone is very likely to jump in and say that PBasic is not a typed language at all, whereas C is a weakly typed language. It is not really important to figure out how strongly typed C is. The point it that it is TYPED and you have to get the types properly declared or the output may be trashed.)
Can you check in a HEX mode Terminal display, and also check how the
BS2SX - SERIN command with DEC (decimal) modifier
handles the not-normal chars. (maybe it simply skips them at lowest level)
If you have an O-scope, also check if the CNC is sending any Break or other non std signals.
(Break is a pulse wider than all low )
Do you mean here that a 'clean' string from the PC, handles ok in the Prop C code ?
For that test, do you type that in (gives gaps), or paste/send (no gaps)
Check on O-Scope that the total char times are the same. (7E2 is 10 bit times ?)
Only sending integers, but are you relying on conversitions to Decimal?
My C skills are minimal, but I strongly suspect that the problem lies in how the input buffer on the Propeller is scanned for numerical values.... especially if the values are floating point or demical.
The incoming stream of bytes provides everything represented in ASCII, but -- unlike the BS2 -- C can scan the buffer for numbers and store them away as integers, unsigned integers, characters, signed characters, and floating-point.
Also there is the 'wide character' feature that might mess things up if it is unintentionally deployed.
================
What I am trying to say is that I suspect that either there is a failure of the input to grasp anything (thus you get a string of nulls on the output side), or there is an error in deploying the right type for the input somewhere along the way from input to output.
That is why I suggested that one first verify that output is working right.
++++++++++++++++
I recently became aware of how complex the input buffer can be in C while looking at G-code parsing for CNC.
Coming from a BasicStamp background, I was shocked by how much code and the implications of what the input buffer does in C.
I am still trying to full comprehend how to make it work well when you have a string of serial input that has a combination of letters, integers (unsigned), and floating point. I suspect it requires fully anticipating what the input strings will be on a case-by-case basis. It helps if the received input is some how in packets that are terminated by a /n or /0. Then the input buffer can analize the whole and dump the buffer after the input is resolved.
I suspect that trying to take a character-by-character approach to processing the input buffer in such situation will pretty much ignore use functions available in the the Simpletools and Simpletext libraries... and just make the code more work. But if you goal is merely to provide display services on an LCD, a character-by-character approach might be optimal with a simple FIFO approach to use of the input buffer.
@ericpine, did you add driver "start mode" code to invert the serial stream. That's important for TTL->RS232.