Hello,
I'm trying to send from my arduino uno temperature values to my PC through the serial port, then getting the values in CVI and printing them to a text box/numeric box.
I got really confused about what I should send and how, and what I'm receiving and how.
The temperature (and also humidity and heat index) on the DHT11 are saved with this function:
float t = dht.readTemperature();
as a float.
Next, I want to send that float value, t, through the serial port.
On CVI I should receive a buffer from type char[ ], and then print it.
I thought about casting the float as a byte, but I'm not sure what will be sent, the entire value or just a part of it?
Also when receiving, the data arriving is the float value but written like a string?
I wish arduino had debugging so I could see the values in real time.
Thanks
If you do Serial.println(t); then the Arduino will send the value of t as a series of characters representing the value of t to 2 decimal places by default. By adding a second parameter like this Serial.println(t, 4); you can change the number of decimal places sent, in this case 4
It is the responsibility of the program receiving the characters to interpret them
I have no idea what CVI is that you refer to
Thank you for the answer.
LabWindows CVI is basically a way to create a GUI using C.
So when I'm sending the temperature value, I should just write Serial.write(t, 4)?
I just don't understand the type of data being sent, because in CVI I should put it in buffer of type char[ ], so I guess I should just create a variable char buffer[4] for the 4 places sent?
Use Serial.println(t, 4); if you want 4 decimal places and you will get a character for each digit in the value of t plus the decimal point. The receive buffer in CVI, assuming that it has such a thing, will need to be large enough to hold the characters before the decimal point, the decimal point, the number of decimal places that you specify in the print command and quite possibly a terminating zero for the string. So, if you specify 4 decimal places to be printed a buffer of size 4 will not be large enough
As I have said previously, the data being sent is a series of chars, ie the ASCII value of each digit and the decimal point
Thank you, it works great now that I understand the Serial.println() doesn't only work as printing to the screen, but also a writing to the serial port.
Now, if I may, I need to do 2 things simultaneously:
- Whenever I type something in the GUI, it will print to the LCD screen - works
- Every 10 seconds, the arduino will send the temperature, humidity and heat index data to the GUI
Now, of course they can cross eachother, especially when the DHT11 takes a long time to respond.
I thought about doing a thread for the temperature part, using a timer on CVI (so every 10 seconds a command to fetch data is sent to the arduino, and the data will be sent), with a lock, so if I'm not mistaken, the part of the temperature will do it stuff (send command - receive data) and then the LCD part can take place.
Is there a better way of doing such a thing?
You can program the Arduino to send data periodically if that suits you or you could program it to respond to a request for data via a serial link. Which would you prefer ?
Which Arduino board are you using ?
I'm using the arduino uno.
Basically the temperature part should just update the text boxes in the GUI in the background, just as information displayed, but because I also send data to the LCD, I think it's possible that the data to the LCD will interrupt the data recieved from the arduino. I think it makes sense for the arduino to send data periodically, probablt with the interrupt timer.
Is it possible for them to happen in parallel? They use the same COM port.
Two way communication should be possible, but there is no need to get into the complications of using a timer to periodically send data. Just use the value of millis() to determine whether the required period has elapsed and if so send the data
I see from your change to post #7 that you maybe having second thoughts on the Arduino sending the data periodically but you still have the option of requesting it from the PC and that would allow you to synchronise the communications
One thing that bothers me is that from what you have said you are using the hardware serial port of the Uno to communicate with the PC. This may not be such a good idea as the Tx and Rx pins are also used when uploading to the Arduino and also you cannot sensibly use the Serial monitor for debugging
I would suggest that you consider using a SoftwareSerial port for data transfer both ways but that would require an external serial adapter to be used
I'm using the USB port for the communication, and yes I had probelms with the serial monitor as the port cannot be opened for both the program and the IDE. I read about the SoftwareSerial but didn't quite understand the usage, but if you say I need an adapter then it makes more sense.
The timer I talked about is the timer in CVI, which will send a command for the arduino to fetch data from the DHT sensor, but the problem is that if I'm send a line to the LCD, this can interrupt each other (and that's why I thought about threading, but I'm not sure this will solve this problem).
The other option, which makes more sense, is for the arduino itself to send the data periodically, but I think it can cause problems if the arduino tries to send DHT data and the PC tries to send data as well (text to write on the LCD).
If you use the option to have CVI request the data when required then you can guarantee that there will be no conflict between sending to the LCD and requesting and receiving data from the DHT11. Just don't send LCD data whilst data request/receipt is in progress
I hope that it goes without saying that the messages to the Arduino will need some kind of identification header so that it can differentiate between the two and act accordingly
Yes I already made this part, I send a starting char which is the command, and then the string, and I have a switch case in the arduino.
The only problem with sending a request with a timer through CVI is how can I know it is sending data so I know now to send data to the LCD?
I mean, I can dim the text boxes and all for that period, using the timer itself, but there must be a more elegant way, no? That's why I thought about threading
With CVI in control of the process I don't see the problem. Send a request for data and until it is received don't send anything else
Well in general the user can send text to the LCD in the moment the timer sends a request for the temperature data. Also the DHT is a very slow component, so it takes time, so I'm trying to avoid these happening together.
What does the user do to send text to the LCD ?
Presumably they enter some data then signal the end of input and the program sends it to the Arduino. If that is correct then don't send it if an unsatisfied request for DHT11 data is in progress, hold on to it until the DHT11 data is received or a timeout occurs.
The DHT11 sampling rate is, I believe, 1 sample per second, so the maximum delay in displaying the user entered data on the LCD would be one second
You could speed this up by using a DHT22 whose sample rate is twice that of the DHT11 or for a faster response have the Arduino continually reading the DHT11 as fast as possible and have it send back the most recent reading when one is requested rather than waiting for a new reading
The user writes something in a text box and hit enter. The function sends a it as a char array.
So I guess I can create a global variable as 'flag' and then in the function which sends the text, write to the com port if the flag is 0 (for example).
I'll try this, thank you very much for the help!
That sounds OK
Just as a matter of interest how long is the text that is entered by the user to be displayed on the LCD ?
I limited the text box to contain up to 16 characters for each line.
So what is the maximum number of characters that could be sent at the same time ?
I determined the char buffer size to be 18, for a command char + 16 LCD chars + \n.
In that case there should be no problem with the shared serial link
Worst case :
You send a request for a DHT11 reading and before a reply is received a user enters and sends data to the LCD. The Arduino is busy waiting for the DHT11 but Serial comms is interrupt driven, so the Arduino will buffer the incoming message bytes and deal with them as soon as the DHT11 has finished doing its stuff and the results have been sent back