SimpleIDE fdserial.h
AS
Posts: 149
in Propeller 1
The fdserial_rxChar should wait until until a byte is received?
(https://propsideworkspace.googlecode.com/hg/Learn/Simple Libraries/TextDevices/libfdserial/Documentation fdserial Library.html#details)
With SPIN exist the function "waitstr" with the FullDuplexSerial that works great.
I want to control the cycles, the Propeller only works if receive a "ok" (I´m testing with LabView).
I have here a simple example with RC Time:
Any sugestion?
Thanks!
(https://propsideworkspace.googlecode.com/hg/Learn/Simple Libraries/TextDevices/libfdserial/Documentation fdserial Library.html#details)
With SPIN exist the function "waitstr" with the FullDuplexSerial that works great.
I want to control the cycles, the Propeller only works if receive a "ok" (I´m testing with LabView).
I have here a simple example with RC Time:
#include "simpletools.h" // Include simpletools #include "fdserial.h" fdserial *LabView; int main() // main function { LabView = fdserial_open(31, 30, 0, 115200); pause(500); char c[10]; // array with 10 elements int cont; while(1) // Endless loop { high(0); // Set P0 high pause(1); // Wait for circuit to charge int t = rc_time(0, 1); // Measure decay time on P0 cont=0; if (cont<2) { c[cont] = fdserial_rxChar(LabView); // this should wait?????? cont ++; } // if (c[0]=="o") If this line working I don´t have nothing in serial // I´m sending a "ok," from Labview { dprint(LabView,"%d\n", t*50); // Send serial decay time } pause(50); // Wait 1/10th of a second } }
Any sugestion?
Thanks!
Comments
There are here something that I don´t understand :P
Thanks!
I agree with you the code is wrong with the "if" I need to use a "while" because I want that Propeller do more than one time to fill the array. Thanks!
But to solve this problem that Propeller don´t wait for the next "rxserial" is necessary to write: before the "while", example:
At this moment is solved the control of each cycle.
Now I have other problem, LabView sending a "ok", but I don´t know why "c[0]" never exist a "o". :P
What are you getting instead?
You might be losing data through your "fdserial_rxFlush(LabView);".
Your code above could be written as
What do you think? Are you planning to take advantage of the asynchronous nature of FdSerial later, is that why you started with it?
This is a very understandable assumption, but not correct. You do not have to disable the default serial driver. Like any unused variable, GCC will automatically prune it from your program when it sees that it is unused.
I want have sure that I have a "o" in the array c[0] and this is not happening. Without the "if" everything works ok but I want that the "if" works, in other words, if I have a "o" in the array c[o] the response of Propeller should be the same.
I start using "fdserial.h" because I thought that I need use it, like in Spin with the "FullDuplexSerialPlus".
Thanks a lot for your code, I understand that for this example I only need the "simpletools.h". I think so!
But with the code you post I still can´t use the "if" which guarantees me that I have a "o" in the first position of the array c[0], for some reason this is not working too
(without the "if" everything is working ok, but I want that "if" :P)
Now the problem is similar but without the "fdserial.h".
I hope I have made myself clear.
If you could help me it would be great!
I´m trying to do similar things that I already do with the Spin and I am a beginner with "C" to the Propeller, because I see here a great potential. I really can´t understant why this is not working! :P
In C/C++ (and Java too), there is a big difference between "o" and 'o'. Double quotes are used for strings whereas single quotes are used for individual characters. Also, printi only accepts strings, not single characters. So two lines of that block need to be changed:
Also, knowing that you don't need fdserial (aka, a buffered UART implementation), and based on our previous thread with eFFL and PropWare, you may be interested to hear that you can do this with PropWare's libraries too. Here's what it would look like using PropWare's (unbuffered) UART library:
I switched out getChar and printi for pwOut and pwIn. Notice the simple use of << instead of printi and putChar.
1 - The first code with the "fdserial.h" is working great after write 'o' and not "o" in the line Only one thing is not working, I still can´t send back the 'o' in the line The code I´m talking about is:
2 - But like DavidZemon said I don´t need "fdserial.h" for this especific exercise. With the great help of DavidZemon the solution is:
3 - The third exercise DavidZemon already solve it in the last post, do this with PropWare's libraries. Only one detail, here I can´t send back the c[0].
Malfunction summary:
1 - Can´t send back the c[0];
2 - Send back too many c[0]. Maybe it needs a TxFlush??;
3 - Can´t send back the c[0];
The first exercise is not important (for now) solve it. (But any sugestion is welcome)
The second it would be interesting solve it.
The third exercise, DavidZemon please help me!
Electrodude, thanks for your sugestion. I had already thought of something like that, because we never know what is in the serial until see it, is something like the Schrödinger's cat. :P
Strange behavior :S
LEARN the printf format. This page is a fantastic reference in English, but printf is such a popular function, that you can probably find someone that wrote equivalent documentation in your primary language as well.
Okay, familiar with printf now? No? Go read some more. Go practice it.
Done now?
Great, so as you can see, the first argument to printf is a string. So if you wanted to print a single character, like you have with c[o], then you would write printf("%c", c[0]). Simple right? You could expand on that and make it more human-readable (if you care) and write printf("The first character is: %c\n", c[0]).
Now, printf is so popular that it has been copied over and over and over again. FdSerial uses a similar function called dprint. The only difference between printf and dprint is that you have to add an extra argument: dprint(LabView, "%c", c[0]).
If you're using the default serial routines, like print or printi, then it's exactly the same as printf: print("%c", c[0]) and printi("%c", c[0]).
As for PropWare, on top of the option I showed above with the fancy <<, there's another printf mimic: pwOut.printf("%c", c[0]).
So, printf is great. It's used all over the place, and if you understand how to use it in one place, you'll know how to use it everywhere. The only fortunate thing about printf (and all of the similar functions like pwOut.printf, print, printi, dprint, etc, etc, etc) is that they take a lot of memory. But don't worry about that until it becomes a problem.
Okay, so that should answer your first problem right? It might also answer your second issue as well... not sure.
As for #3.... that's just weird. I'll check in on this again in a bit, but I tried that code for myself and it was working well for me.
Thanks a lot
Thanks! this is everything great
I need to go back to here because I was testing again these experiences and I detect strange things :P.
I use always the same LabView program for the 3 experiences.
To test the bytes received from the LabView I decided change only one line, the idea is, instead of sending back the 'o', sending back the 'k', and the "if" continue looking for the 'o'.
The LabView is sending 'ok,'
1 - The first code with the "fdserial.h" is working great, I only changed and now I receive which was expected. (see 1st.jpg)
The code is:
2nd experience, it was working fine, until I changed this line to receive the "k" (in the LabView). Now LabView is received something not expected. (see 2nd.jpg)
The code is:
In the 3rd experience using PropWare I was doing a bad procedure because I conected the Propeller to the Raspberry and to the PC, and I turn off the Propeller each time.
When I write in the Raspberry "make debug" I don´t put the code in the EEPROM, for that I need write "make run"? (I think you already told me that)
The results obtained were not true.
So, with the code you send me I have these results (see 3rd_1.jpg). I don´t understand why I receive before the number "o,". Is not o big problem because I say to the LabView to don´t see it. The rest seems to be all right.
I change your code to send back the "c[1]" and not the "c[0]" I wrote this "pwOut << c[1];", now I have these results (see 3rd_2.jpg). Labview continue receive "o," before the number (not a big problem) but now Propeller is sending a "," and not a "k".
I hoje you can help me.
Thanks a lot.
Everything was working ok, Labview receive back the first letter from the string that it is sending, Labview sending "ok," and receive back the "o". But to test it, I changed to the Propeller send the 2nd letter back, the "k", and this is not happening.
In the last comment I have here with code, the 1st experience with "fdserial.h" is working great, the "1st.jpg" is what I expect, the 2nd experience is with the "getchar()" and the result obtained is the "2nd.jpg", as can be seen Labview not receive back the "k".
Thanks
With fdserial is everything working good.