Attached is a quick and dirty version which uses 3 serial objects, one to the PC for display purposes and two which communicate over pins 0 and 1. The sender method will send(!) data embedded between STX/ETX. As it's displayed as string I picked printable values for the binary part. HTH
I will have to take a peek tomorrow. I am very tired. However, I will definitely get back with you on the results. As always I sincerely appreciate all the help you have given me.
Taking another look at your code, I see that you are receiving data and also transmitting data using the same serial driver. The "transmitted" data is the error messages, so I'm guessing you are talking to a terminal of some sort, eg the propeller terminal?
If so, it can be hard to debug because you can't type in an ascii 2, or 3 into a terminal. You can certainly type a 2 on the keyboard but that is ascii 50.
So it gets really hard to debug. So maybe for the moment stick to characters you can actually type on a keyboard. It doesn't matter what. Start with ~ and finish with ! or whatever.
Also maybe just use the raw .rx method rather than the rxdec (which I am having trouble decoding).
Then if you stick with ascii characters from 32 to 127, they will all display on the terminal, and you can type them. So the first thing you can do for debugging is simply echo the character back. That makes it much easier to debug each step of the process.
Phil: Sometimes you do not have choices where the comms wires run. e.g. the customer wires them, all 40 of them, in the trunks with the power. One other I had to settle for... The one on the airport ran under two roads and part of the tarmack. No opportunity to dig a new trench. It was a large and very old conduit that had underground 240Vac between hangers. It just had to do or else we couldnt locate the terminals there. Anyway, it worked fine.
Your story brings back some memories. Several years ago, I was the the lead electrician on a job being performed at McCarran International Airport in Las Vegas. I believe it was for a subsidiary of Hudson News. That was a very fun, but also very difficult environment to work in. Before they would allow you to drill holes in their concrete, you had to have x-rays taken of the area you wanted to drill in, to avoid hitting their concrete tension cables. Completely understandable, but it definitely slowed the job down immensly. Yea, they didn't like their infra-structure being tampered with. Not to mention the job of hauling all your tools and equipment from the parking lot, through security, to the final job location. But the job also had it's perks, all kinds of beautiful women flowing like water through that airport
I will have to take a peek tomorrow. I am very tired.
Cripes, looking at the post times, you have had less than 7h sleep and you are back to this project!
Albeit, with not quite the focus as before...*grin*
But the job also had it's perks, all kinds of beautiful women flowing like water through that airport
Back to the coding - are you using the prop terminal as the test platform and if so, can you add one line of code after .rx to do a .tx and echo back the byte? If so I think it could make debugging a lot easier.
Sorry I missed your post. I never got a notification for it.
Anyhow, here is the real deal. Thanks to everyone involved in this post, I believe I have a very good idea of how to send data, the problem is the receiption of data, interpeting it, and parsing it. Going back to Jon's sample, he effectively created a sample which would allow you to enter data into the Parallax Serial Terminal, parse it and then display the results. Which I liked a lot.
However, I am trying to do something similar, but yet quite different. Whereas he had one actual input contained within a string, I on other hand want to have 3 or more inputs and still display them. The purpose of this is to create a parser similar to the one described within this post, which would allow me to test and verify operating conditions and variables, before actually installing the software. I believe this will save me a lot of time and headaches down the road. If I can get this to work, I believe I will have or will obtain a more thorough understanding of transmiting and receiving data.
I have attached some new source code and it compiles and runs fine, however there are two items commented out, which really need to be functional. My theory is that if I can find FDS.RxDec as proven in this code, then I should be able to get that byte into the CmdBuffer array, and then display it.
Your code demonstrates why it can be problematic to add parsing into the buffer move. Since you have defined starting and ending bytes it may be wiser -- in my opinion -- to move the message contents to a separate buffer before parsing. The buffer move won't change because you can pass the terminating character (ETX) with the call. I've updated the fill buffer routine just a bit:
pub fillbuf(bufpntr, size, tchar, timeout) | c
bytefill(bufpntr, 0, size) ' clear with zeroes
repeat size
if (timeout > 0)
c := term.rxtime(timeout) ' use timeout
else
c := term.rx ' no timeout
if (c == tchar) or (c == -1) ' if terminator
quit ' exit
else
byte[bufpntr++] := c ' else add to buffer
It's a minor change that lets you pass a timeout value (0 for no timeout).
In your application you might do this:
repeat
c := term.rx
if (c == STX)
fillbuf(@buffer, BUF_SIZE, ETX, 0)
' call parser that matches command format
' do something with parsed elements
<BROKEN RECORD>It's generally best to build your application form small, atomic objects and methods that can be re-used</BROKEN RECORD> *grin*
Once again, thanks for your input. I finally started making some progress in my example, and your modification is the very same problem that I had. I was timing out before making any progress. So I modified your function like this:
pub fillbuf(bufpntr, size, tchar) | c
bytefill(bufpntr, 0, size) ' clear with zeroes
repeat size
c := FDS.rxTime(10_000) ' no timeout
' c := term.rxwait(250) ' use timeout
if (c == tchar) or (c == -1) ' if terminator
quit ' exit
else
byte[bufpntr++] := c ' else add to buffer
Similar to your modified function, but I like your modified function much better, with the timer passed as a parameter. By using the function above, I was able to get some data into the buffer but not all of it. Still have not determined the cause of that. I also further agree that ETX should be passed with the remaining data, and that could be the remaining problem that I am having.
If you look at my fillbuf method you'll see that the buffer is stuffed with zeroes before pulling values from the serial stream. Since the only thing that goes into the buffer are the bytes between STX and ETX the parser can look for a 0 as the end of the buffer (and if the data are ASCII you can use normal string functions as it is zero-terminated).
I agree 100%. One of those live and learn situations. In this case, it was hard way. Thanks for your tips, I truly believe that has been my main stumbling block for the last 36 hours.
Another problem that I am having is that it appears that FullDuplexSerial cannot test for STX and ETX using FullDuplexSerial : Rx. That is why I was using the extended version which has : RxDec. RxDec does have the ability to test and find STX and ETX. I am thinking that I will have to use both of these object to test the character. Something similar to the following might do the trick:
Another problem that I am having is that it appears that FullDuplexSerial cannot test for STX and ETX using FullDuplexSerial : Rx.
Why not? The rx method gives you exactly what you sent down the link on the other end. So if you send STX then you'll get STX. You definitely don't want rxdec for that.
PUB rxDec : Value | place, ptr, x
{{
Accepts and returns serial decimal values, such as "1234" as a number.
String must end in a carriage return (ASCII 13)
x:= Serial.rxDec ' [COLOR="red"]accept string of digits for value[/COLOR]
}}
Spelling it out, in order to get STX from rxdec you'd have to send 50, 13.
First off let me say thank you for the code you provided. I have it stashed it away as a resource and reference to my future endeavors in this matter. If you read some of the previous posts, it will explain why I continue with the current path.
Okay now back to your current post. Since STX and ETX are assigned as constants, they need to be tested as such. I have been playing with this code for a couple of days now, and believe me, I can't get results with just rx but I get them with rxdec.
Another problem that I am having is that it appears that FullDuplexSerial cannot test for STX and ETX using FullDuplexSerial
I'm not surprised, it's just basic serial handling and you should leave it at that.
Char := EFDS.RxDec
You don't appear to be starting this object so I don't expect this to work -- I could be wrong because I've not used the "Extended" version -- being a control freak I like to do that stuff myself.
PS: Please do not include my name in any of your listings unless it's "based on/inspired by code from Jon McPhalen." Sorry, it's a "Hollywood" name protection thing, and I'm dead serious about it. The listing you show above is modified from what I provided.
I don't get it. STX is a single byte ($02) which rx will happily present to you. In order to receive STX with rxdec you'd have to send two bytes (50, 13). Doesn't that strike you as odd?
How do you send your STX? Do you use fds.tx(STX) or do you type something in the connected terminal ("2" + CR by any chance)? If it's the latter then that's not STX.
I don't know, I am still trying to figure this whole thing out.
What you seem to be missing is that the .rxdec method is an ASCII to decimal conversion that is expecting a string of characters and a terminator. As Marko points out, the way you have STX and ETX defined (correctly, by the way), you're just sending a single, non-ASCII byte. Let FDS do reception, do the byte-checking and parsing outside.
Serial comms is not the issue -- custom message creation and parsing is what's going on.
@Bruce: Sometimes the limits of a tool (e.g., PST) force us to take other actions. Since PST cannot send STX and ETX values, why not setup a slave cog to do that? In the attached demo a slave cog sends formatted messages to the master cog. Timing is randomized for fun. This is just a start to show you how you can take advantage of multiple cores to do testing when you don't have all the hardware in place.
Comments
@Dr_Acula - Yeas, hopefully I will get that euphoric feeling soon
Do you have sample code which sends a properly formed message so I/we can test against that? And did you check my changes to the previous post?
LOL I wish I did, it is a work in progress. I am still learning the dec, str, rxcheck, rxbyte, etc.... A whole new world.
But this is what I am trying to achieve:
2, 15.350, 31, CRC_RESULT, 3
Without the commas all in one stream and crc result in numbers
I will have to take a peek tomorrow. I am very tired. However, I will definitely get back with you on the results. As always I sincerely appreciate all the help you have given me.
Bruce
If so, it can be hard to debug because you can't type in an ascii 2, or 3 into a terminal. You can certainly type a 2 on the keyboard but that is ascii 50.
So it gets really hard to debug. So maybe for the moment stick to characters you can actually type on a keyboard. It doesn't matter what. Start with ~ and finish with ! or whatever.
Also maybe just use the raw .rx method rather than the rxdec (which I am having trouble decoding).
Then if you stick with ascii characters from 32 to 127, they will all display on the terminal, and you can type them. So the first thing you can do for debugging is simply echo the character back. That makes it much easier to debug each step of the process.
Your story brings back some memories. Several years ago, I was the the lead electrician on a job being performed at McCarran International Airport in Las Vegas. I believe it was for a subsidiary of Hudson News. That was a very fun, but also very difficult environment to work in. Before they would allow you to drill holes in their concrete, you had to have x-rays taken of the area you wanted to drill in, to avoid hitting their concrete tension cables. Completely understandable, but it definitely slowed the job down immensly. Yea, they didn't like their infra-structure being tampered with. Not to mention the job of hauling all your tools and equipment from the parking lot, through security, to the final job location. But the job also had it's perks, all kinds of beautiful women flowing like water through that airport
Bruce
Cripes, looking at the post times, you have had less than 7h sleep and you are back to this project!
Albeit, with not quite the focus as before...*grin*
Back to the coding - are you using the prop terminal as the test platform and if so, can you add one line of code after .rx to do a .tx and echo back the byte? If so I think it could make debugging a lot easier.
Sorry I missed your post. I never got a notification for it.
Anyhow, here is the real deal. Thanks to everyone involved in this post, I believe I have a very good idea of how to send data, the problem is the receiption of data, interpeting it, and parsing it. Going back to Jon's sample, he effectively created a sample which would allow you to enter data into the Parallax Serial Terminal, parse it and then display the results. Which I liked a lot.
However, I am trying to do something similar, but yet quite different. Whereas he had one actual input contained within a string, I on other hand want to have 3 or more inputs and still display them. The purpose of this is to create a parser similar to the one described within this post, which would allow me to test and verify operating conditions and variables, before actually installing the software. I believe this will save me a lot of time and headaches down the road. If I can get this to work, I believe I will have or will obtain a more thorough understanding of transmiting and receiving data.
I have attached some new source code and it compiles and runs fine, however there are two items commented out, which really need to be functional. My theory is that if I can find FDS.RxDec as proven in this code, then I should be able to get that byte into the CmdBuffer array, and then display it.
Bruce
pub fillbuf(bufpntr, size, tchar, timeout) | c bytefill(bufpntr, 0, size) ' clear with zeroes repeat size if (timeout > 0) c := term.rxtime(timeout) ' use timeout else c := term.rx ' no timeout if (c == tchar) or (c == -1) ' if terminator quit ' exit else byte[bufpntr++] := c ' else add to bufferIt's a minor change that lets you pass a timeout value (0 for no timeout).
In your application you might do this:
repeat c := term.rx if (c == STX) fillbuf(@buffer, BUF_SIZE, ETX, 0) ' call parser that matches command format ' do something with parsed elements<BROKEN RECORD>It's generally best to build your application form small, atomic objects and methods that can be re-used</BROKEN RECORD> *grin*
Once again, thanks for your input. I finally started making some progress in my example, and your modification is the very same problem that I had. I was timing out before making any progress. So I modified your function like this:
pub fillbuf(bufpntr, size, tchar) | c bytefill(bufpntr, 0, size) ' clear with zeroes repeat size c := FDS.rxTime(10_000) ' no timeout ' c := term.rxwait(250) ' use timeout if (c == tchar) or (c == -1) ' if terminator quit ' exit else byte[bufpntr++] := c ' else add to bufferSimilar to your modified function, but I like your modified function much better, with the timer passed as a parameter. By using the function above, I was able to get some data into the buffer but not all of it. Still have not determined the cause of that. I also further agree that ETX should be passed with the remaining data, and that could be the remaining problem that I am having.
Bruce
I agree 100%. One of those live and learn situations. In this case, it was hard way. Thanks for your tips, I truly believe that has been my main stumbling block for the last 36 hours.
Bruce
Another problem that I am having is that it appears that FullDuplexSerial cannot test for STX and ETX using FullDuplexSerial : Rx. That is why I was using the extended version which has : RxDec. RxDec does have the ability to test and find STX and ETX. I am thinking that I will have to use both of these object to test the character. Something similar to the following might do the trick:
Why not? The rx method gives you exactly what you sent down the link on the other end. So if you send STX then you'll get STX. You definitely don't want rxdec for that.
PUB rxDec : Value | place, ptr, x {{ Accepts and returns serial decimal values, such as "1234" as a number. String must end in a carriage return (ASCII 13) x:= Serial.rxDec ' [COLOR="red"]accept string of digits for value[/COLOR] }}Spelling it out, in order to get STX from rxdec you'd have to send 50, 13.First off let me say thank you for the code you provided. I have it stashed it away as a resource and reference to my future endeavors in this matter. If you read some of the previous posts, it will explain why I continue with the current path.
Okay now back to your current post. Since STX and ETX are assigned as constants, they need to be tested as such. I have been playing with this code for a couple of days now, and believe me, I can't get results with just rx but I get them with rxdec.
Bruce
I'm not surprised, it's just basic serial handling and you should leave it at that.
You don't appear to be starting this object so I don't expect this to work -- I could be wrong because I've not used the "Extended" version -- being a control freak I like to do that stuff myself.
PS: Please do not include my name in any of your listings unless it's "based on/inspired by code from Jon McPhalen." Sorry, it's a "Hollywood" name protection thing, and I'm dead serious about it. The listing you show above is modified from what I provided.
@Marko - I don't know, I am still trying to figure this whole thing out.
What you seem to be missing is that the .rxdec method is an ASCII to decimal conversion that is expecting a string of characters and a terminator. As Marko points out, the way you have STX and ETX defined (correctly, by the way), you're just sending a single, non-ASCII byte. Let FDS do reception, do the byte-checking and parsing outside.
Anyhow, I am entering the information into the Parallax Serial Terminal
2 + Enter ( get the buffer ready for filling)
The repeat keeps checking for information
I type more info into the Parallax Serial Terminal + 3 + Enter
The screen displays one valid character from the buffer
Bruce
repeat fds.dec(fds.rx) fds.tx(32)See the difference?A Sounds horrible, I know.
Now I am confused even more. However this looks promising "fds.dec(fds.rx)"
fds.tx(32) is this a space or is this ETXSTX
Bruce
When I first tried to run your loop it didn't work for me, but it works now. Now I see what you mean.
Bruce
Why not use one of these routines?
Some include wiring diagrams.
Serial comms is not the issue -- custom message creation and parsing is what's going on.
@Bruce: Sometimes the limits of a tool (e.g., PST) force us to take other actions. Since PST cannot send STX and ETX values, why not setup a slave cog to do that? In the attached demo a slave cog sends formatted messages to the master cog. Timing is randomized for fun. This is just a start to show you how you can take advantage of multiple cores to do testing when you don't have all the hardware in place.
jm_parser_demo_v3.spin