I've been trying to develope an APP for the CC2650 from TI. Im working with the SimpleBLEperipheral example.
What I want to do is:
read a UART (up to 80 byte length)
Write the message to a characteristic
The messages come once a second. Here is, where the problem begins:
When I send a request to the device, that is connected via UART, I get a short answer, that is mixed with the messages, that are secondly sent.
In my App I read the UART once a second in the SimpleBLEPeripheral_performPeriodicTask of the example.
The answers, that come in between the messages will not be read, because of timing problems. My idea was to create a task only for reading the UART and use a callback, but that doesnt seem to work. When I create another task, the App doesnt work at all. No task gets called and the device doesnt advertise.
HELP!
Related
I am a french student in robotics and I have a project in which I have to connect 3 EPOS and my computer via EPOS 3.
I already wrote a programm in C++ to send bytes but I don't understand what to send and when.
For my project, I want to have the computer in master mode to send data to each controller (has orders) and when they all recieved it, I activate them by sending a global message and put them to sleep when they are finished
I read a lot of documentation and I think I want to initialze the NMT first ?
But I can't find anything such as an example or anything more than abstracts schematics.
I used a programm given by maxon to send bytes directly and the controller respond but never what I expect it to be.
And when I try to initialize it, the led on the controller shows me that it's not initialize.
Anyway thank you for everyone who will take the time to reply !
Two Questions:
1) Is it possible to send a message to the device and receive all the current input values?
I am trying to receive and send data to the KORG nanoKONTROL2. I found an API for real-time input/output called RtMidi. Receiving data is no issue, but I don't have the state where the sliders and knobs are in when the application starts. I presume, if this could be done, you need to send a message to the device.
There is an RtMidiOut class with sendMessage functionality where you can send data (vector<uchar>) to the device, but I don't know what data to send (I did try with some for loops to see if anything happens, but no luck).
2) Is it possible to turn the button lights on/off? If so, how?
To clarify the second question; I am trying to create a toggle where the light of the button on the device will turn on/off according to the state of the toggle.
Additional Information: The received data exists of 3 unsigned char's where the first value is probably an id, I am not quite sure, the second is the button/slider id and the third is its value.
Source code link to GitHub.
Is there some way to be notified when my serial device is ready to receive more data?
I am implementing a program that feeds commands to a servo controller over serial using the asynchronous API of QSerialPort. The program works, but it seems that I am experiencing congestion.
In my application I keep a registry of most updated servo position that I wish to synchronize with the controller with as low latency as possible. My attempt at pushing new data to the serial port as quickly as time lets me leads to what I think is a buildup of data that makes the communication break down altogether.
My question is, can I be notified when the serial interface is ready to receive new data somehow while using QSerialPort in asynchronous mode?
The only other option I see is to use synchronous mode and call waitForBytesWritten() But I really don't want to do that.
NOTE: I have studied the serial port examples in the Qt5 documentation carefully, but the example for asynchronous write does not provide the information I need, as it perform a one-shot send before quitting.
You could listen to the signal bytesWritten and check bytesToWrite to determine if the write buffer is empty. Both are inherited from QIODevice.
I'm experiencing a frustrating behaviour of windows sockets that I cant find any info on, so I thought I'd try here.
My problem is as follows:
I have a C++ application that serves as a device driver, communicating with a serial device connected
through a serial to TCP/IP converter.
The serial protocol requires a lot of single byte messages to be communicated between the device and
my software. I noticed that these small messages are only sent about 3 times after startup, after which they are no longer actually transmitted (checked with wireshark). All the while, the send() method keeps returning > 0, indicating that the message has been copied to it's send buffer.
I'm using blocking sockets.
I discovered this issue because this particular driver eventually has to drop it's connection when the send buffer is completely filled (select() fails due to this after about 5 hours, but it happens much sooner when I reduce SO_SNDBUF size).
I checked, and noticed that when I call send with messages of 2 bytes or larger, transmission never fails.
Any input would be very much appreciated, I am out of ideas how to fix this.
This is a rare case when you should set TCP_NODELAY so that the sends are written individually, not coalesced. But I think you have another problem as well. Are you sure you're reading everything that's being sent back? And acting on it properly? It sounds like an application protocol problem to me.
I am writing a gtk application (in C++) to communicate with motor controller through serial port. I am working with Linux Ubuntu and termios lib.
I need advice on the best solution to do it.
So here are the constraints I have:
1- when i send a request, the controler send me back a message
2- the controler can send me error notification at any time if an error occurs
3- request is ANSII characters string finished with [CR]
4- controller answer is ANSII characters string finished with [CR][NL]
Because of (3) and (4), I thought it was appropriate to configure serial port in CANONICAL mode.
Because of the GUI + (2), I thought about multi-threading: a main thread who write user request on serial port and an other infinite thread to read controller answer. Do you think it is a good idea?
Second question: if I am using multi-threading I want to be able to write data when I need it so I have to find a way to stop/sleep the reading thread during writing maybe with pthread_cond_wait. Am I right? I've seen poll and select functions but I don't really understand them and I am not sure they are compatible with canonical mode.
I am getting started with multi-threading and serial port. I read lots of things on google, forum...but the large amount of information is a little overwhelming for a beginner.
Thank you for your help.
The main thing to consider here for separating the GUI from the serial port is going to be your delays. Are you ever going to be performing any actions that will cause you to need to poll the port for a specific amount of time that would be noticeable to the user? If you are just doing request/reply and the latency of those is really low your user probably wouldn't notice any of those delays. Additionally receiving those asynchronous error messages would also not cause any sort of noticeable delay I would imagine. Unless you know for a fact that there could be numerous seconds of delay after an Init message or something like that gets sent to the controller it will probably make your life much simpler to keep the application single threaded.
On the other hand if there will be those large latencies or you just want to mess around with multi thread I would just start with 1 thread that does all the GUI work and another thread that handles all the serial IO. Use message passing or event notification between those two threads for coordinating your activities and it should be pretty straight forward.