James,
Thanks for the suggestion.
A pair of questions:
1- The jumpers you are mentioning are not phisically present on the board.
There are just two pairs of tiny tin “dots” labeled as J1 and J2 (see attached picture).
Does it means the board doesn’t support RTS and CTS ?
Is it safe to solder them togeher anyway, even if there are not the connectors ?
2- Are you suggesting this solution because there are no other methods to safely go over 100 chars/second only by software ?
Is this a known limitation of the board ? ( < 100 chars/sec without CTS/RTS, and > 100 chars/sec with CTS/RTS)
Yes, these are the jumpers themselves. The connector is only used when the pads that are jumped do not need a permanent connection.
No, this is a limitation of the protocol. No matter what mainboard or platform you use, RTS and CTS are highly recommended. The only difference is that they are recommended for larger packets, but in setups where communication generally flows in one direction.
Ok, thankyou, I’ll try your suggestion and I’ll let you know.
I’m curious: since as you say, RTS/CTS are highly recommended, why does the jumpers are not bridged by default ?
Hi,
first a question: what is the transmission rate you need?
Secondly: If you want to be fast, you should avoid string manipulation as you do in the eventhandler. You should work with byte arrays where ever possible as byte array operations are done in native code in NETMF. You can for example use the SerialBuffer.cs Class as I suggested in my first post of this thread (see the links).
Then: The Debug.Print command is very slow, you should leave it away in the eventhandler. The eventhandler will not finish before Debug.Print is executed.
Edit: The Name of the Class is not SerialPort but SerialBuffer. I corrected it in the text.
@ NinjaCross - The reason these are not connected by default is the fact that the socket type is U. Connection of the CTS/RTS pins would make the module code-wise incompatible with U type sockets. We placed the jumpers here in the event that a user would need handshaking, which would change the socket requirement to K.
@ RoSchmi - I’ld like to reach at least 4 Kbytes/sec. Since the baud rate is set to 115200, I expect a total of about 10Kbytes/sec. Having bidirectional communication, 4KBytes/sec per “direction” should be feasible (right ?)
@ James - so if I bridge those jumpers, the needed socket begin K, but the module only support U, so the designer would break (and probably the module code too, since the socket compatibility is verified at startup). Am I right, or am I misunderstanding something ?
I think the info the guys have given you is valuable for you in understanding what you can achieve purely from a serial port perspective. As with all challenges like this, the real issue will come when you then use the data you have… if you have to go to string manipulation, as you have been warned, you blow out the time taken to deal with the data; if you need to do heavy maths or anything else computationally intensive, the data rate may need to be lower to keep up. But if you’re not doing much with the data then that kind of rate is probably fine. At the moment you haven’t told us more background so we can’t suggest more relevant hints, which is fine, you’re going to have to use trial-and-error a bit more.
@ Brett - You are right, I didn’t give any context detail since I initially though it would be easiers to solve the problem.
Essentially I’m building a remote controlled stepper motor (using L6470 module) and I need to:
frequently (10 times per second) and continuously acquire the state flags of the motor (warnings, errors, position, speed, and so on)
send commands to the motor to change its speed, position, etc.
That’s all.
It’s apparently simple, but this communication problem is giving me a big headache, since it’s the only flawed piece of the project that block me to deploy to my customer.
I’ll try to remove Debug.Print and convert the string protocol to a binary protocol, maybe everything will go better.
Anyway, if you have suggestions to solve the problem without doing this, they would be greatly appreciated.
[quote]@ RoSchmi - I’ld like to reach at least 4 Kbytes/sec. Since the baud rate is set to 115200, I expect a total of about 10Kbytes/sec. Having bidirectional communication, 4KBytes/sec per “direction” should be feasible (right ?)
[/quote]
Hard to say right. As Brett already mentioned, there are other more important things that have influence. Here are some considerations of a hobby-programmer: The data come with a rate of around 10 kbytes/sec in the internal buffer of the serial port. When you use the SerialLine_DataReceived Event the serial port generates an interrupt after an ankown amount of bytes arrived in this buffer. This generates the call of the eventhandler and this special call of the eventhandler can handle just this amount of bytes. So the first thing you should find out is how many bytes are processed by one call of the eventhandler. The next point is, with which frequency is the eventhandler executed. So the real maximal rate of data that can be processed is count of eventhandler calls/sec multiplied with count of bytes in one eventhandler action.
When you want a real-time control, besides average data rate in NETMF you must consider the action of the garbage collector.
So I would say, what you want to do is rather ambitious.
Maybe it would be better to do more of the controlling in the spider and to communicate with the PC in a much lower frequency?
@ RoSchmi - Your analisys is flawless, probably I’ll change approach to minimize the calls frequency.
Just a question: If i decide to aggregate more information on a single message to minimize calls frequency, what is the max message length I could build ? Is it in some way related to the internal buffer size ?
Let’s say that at the moment I send 10 messages (one message is a chars string ended by ‘\n’) of 100 bytes per second (10*100 = 1000 bytes/sec).
Can I assume I can safely and robustly unify them in a single message of 1000 bytes, so I can send just one message per second ?
Thankyou all so much for your efforts in helping me.
@ NinjaCross - Also, I would avoid gathering the information in the event handler. I would set up variables for the data that you want to retrieve, and have a separate thread updating these variables. That way, you can grab the data without blocking the event handler. The data would have the possibility of being one update behind, but at 10 samples per second, this should not be a problem.
You could also use the event handler to only append the new data to a buffer, and have another thread parse the results on a terminating char(s) like CRLF etc.
@ James - I was avoiding multithreading techinques on the Spider because i feared to load too much its processor resources, but if you suggest to do so, I’ll make it for sure !
I don’t know if I am right, but your post makes me think, that you assume that always a whole string arrives with one call of the eventhandler. This is only true in few cases. Normally the data arrive in chunks and it may be, that a string of 100 characters arrives in several calls of the eventhandler. In your application the buffer size should not be critical, important is how fast you can empty the internal serial port buffer. As James already mentioned, if possible, in the eventhandler you should only, as fast as possible, store the data away and return. The processing of the data can be done in another thread.
These are the following buffers for EMX (Spider), G120 (Cobra II), and G400 (Raptor):
4 KiB for the TX on all;
4 KiB for RX on G400
and 16 KiB for RX on EMX and G120.
Would be nice if we could see the code for controlling the stepper motor on Code Share when it is ready.
@ RoSchmi - Using your suggestions, yesterday I modified my code to use a SerialBufferm and so get the single lines one by one once they arrives.
Anyway, I’ll try to implement your suggestions and James advices and I’ll let you know.
If the result will be a valuable and reusable code, I’ll be happy to insert it into Code Share !