Hi team,
I've noticed that in http://leaflabs.com/docs/hardware/maple-mini.html it notes that for Serial2 pins 10 and 11 are RTS / CTS respectively. Is there any harward flow control built into maple? Does it need to be initiated somehow?
I'm looking into hardware flow control for a WiFly RN131 module which seems to be either dropping or doubling up data, even on lower baud rates.
Here is my sketch. Does it appear I'm using CTS correctly to control data being recieved?
#include <stdlib.h>
#define NumLEDs 24
#define RTS_PIN 10 // RTS PIN
#define CTS_PIN 11 // CTS PIN
uint8 LEDChannels[NumLEDs][3] = {0};
void setup()
{
pinMode(RTS_PIN, OUTPUT);
pinMode(CTS_PIN, INPUT);
USART3->regs->CR3 = (USART_CR3_CTSE | USART_CR3_RTSE); // IS THIS RIGHT IF IM USING SERIAL 2??
Serial2.begin(921600);
for (int h = 0; h < NumLEDs; h++)
{
LEDChannels[h][0] = 10;
LEDChannels[h][1] = 10;
LEDChannels[h][2] = 255;
}
}
void loop()
{
digitalWrite(CTS_PIN,LOW); // turn CTS on to open UART data
if (Serial2.available() > 0 )
{
someByte = Serial2.read();
if (someByte == 'V')
{
for (int i=0; i < 8; i++)
{
int num = Serial2.read();
num -= 10;
LEDChannels[num][0] = getByte();
LEDChannels[num][1] = getByte();
LEDChannels[num][2] = getByte();
}
digitalWrite(CTS_PIN, HIGH); // tell CTS to turn off
} // if N
} // Serial Available
}
int getByte()
{
return Serial2.read();
}
gbulmer
Moderator
asterix - could you give a bit more information?
As far as I can tell from the example code, in post 2, you've only tried receiving data. Is that true? Is the doubling up or lost bytes always when receiving, or transmitting data, or are both directions effected in either way?
How do you detect that the data is lost or doubled up? The code in post 2 doesn't seem to have anyway to detect or signal that.
How many bytes get through before the errors? Are the some number of bytes which get through?
If you use a very low baud rate (e.g. 1200 baud), is the problem as common as a high baud rate (e.g. 921600)?
Are the byte values sent/received always correct, or are they sometimes wrong too?
In general, you have two choices with hardware handshaking, either program the USART to do it, or do it yourself in software. That code looks like it is trying a bit of both.
What happens on low-speed comms with no flow control? AFAICT from the RN131 datasheet, it doesn't need flow control. Can you 'throttle' the software sending data so that it is very slow, so flow-control can't possibly have an effect?
Hi gbulmer, sorry busy week!
I've only posted an edited down version of the sketch as there was alot of other stuff that isnt relevant.
I basically just added an else clause to my if (someByte == 'V') to check whether it was in time or not. If its not a V that I'm recieving before my loop then I've either lost or gained a char. I send it back to processing to notify me. The odd thing is that if one packet in the series (as I'll explain below) is out of synch, then I should be receiving at least several responses on every scan sent through. Not just one bad char every second scan or so.
I'm basically sending a series of 5 bytes: V int char char char (without spaces of course). I am doing this 26 times per send, each of the 26 times is basically captured by maple and the last three chars are fed into an array but stored as an int value. int r= Serial2.read();
V - to verify that the order of the bytes is correct.
int - Introduced after this post was originally written. An integer identifying what number in the array the chars should be assigned to (i could use a counter but I want to be certain the array is assigned correctly. This is sent from processing as a char by using char(i) in a loop. I add 10 to avoid any problems with char(0) through to 10 (char(0) is NULL which sounds bodgy to me!!).
char char char - I read these as ints although they are sent out as chars. Chars are just a convenient way for me to send values between 0 and 255. I'm basically sending an RGB value in for each array item.
I send this format through 26 times per ip frame. Doesn't seem to matter if I send each of the 26 seperatly or in one ip packet frame as a String.
At the trailing end I send another char ('Q') which, when added to the if (someByte = 'V') clause will trigger another char ? to be sent back to processing to tell it to send the next line. I've ended up ditching this now and just flushing the Serial buffer entirely which seems to have improved data speeds. Q also triggers another function that shifts the array out into my shiftbrite leds (which you've helped me with before).
What I really don't understand with WiFly is how it talks through UART. Before I had to send my string through twice before recieving a '?' response back from maple, which means either:
- WiFly isn't sending the data through the UART until the buffer is full
- My data has corrupted and 'Q' never made it through.
I've reduced the flush size to around 150 and I only need to send the string once to get processing to automatically resend each 26 lines.
Anyway, RTS/CTS is a little confusing and their documentation doesn't help. Its confusing as I'm not sure what side of the wifly I am controlling:
- Is it controlling when to send / receive from serial uart to wifly
- Is it telling when wifly should send / receive to the host connection (my laptop running processing in this case).
Hope this makes sense. perhaps I should just post up my code...
gbulmer
Moderator
asterix - I am not a WiFly guru.
In my experience, either the person with the bug spots the error when they explain it, or it becomes clear to someone who has had a similar bug before what is happening, so I asked for a bit more detail.
I would do my best to avoid using RTS & CTS, if I could. It is even more complexity to get right. I can imagine that the WiFly might resend a character if RTS/CTS are wiggled. Otherwise I would expect the WiFly to only deliver each character once.
I notice that the code doesn't check for a 'V' on each byte, so once it loses synchronisation, it might be a long time before it gets it back. It might be worth checking every byte for 'V', and now 'Q'.
It might also be worth sending a smaller packet. Try making every packet unique (in some simple way). For example, use a 16 bit into to count the packets, and convert that int to 4 hexadecimal ASCII characters ('0' to '9' and 'A' to 'F'). Then wait, don't send anything more for a big chunk of a second.
How are you opening the connection to the WiFly on the host? Is it a TCP/IP socket connection, or UDP?
TCP/IP should not pass the packet on until it is sure that the packets are correct and in the correct order. So losing packets sounds very strange if TCP/IP is being used.
TCP/IP will balance the size of a packet with a time out, so a small packet may take longer to deliver, and several might arrive in one chunk.
UDP will do best efforts only.
I am sending via TCP / IP so I'm expecting 100% accuracy. An external antenna I hacked out of an old laptop seems to have helped rather than relying on the chip antenna.
I believe I've nutted out a reasonable send rate but can always be improved by the higher baud rates offered by SPI. I'm curious to find out more about RTS / CTS as roving networks point out that it is generally a good idea for large packet streams or constant packet streams.
gbulmer
Moderator
asterix
I believe I've nutted out a reasonable send rate ...
So, let me make sure I understand.
If the transfer is slow enough, everything transfers with 100% accuracy over the USART in either direction?
Have you looked at http://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS
Depending on how Rover Networks implement things, that seems to explain what might be happening on the wireless side, but I have not read the WiFly documentation enough to know, so I may be misleading you.
I have managed to solve the problem (I believe) and I may need to submit a bug report (how do I do this??). But actually it was a two part problem, which probably doesn't need to be covered here.
Serial.available bug //////////
The Serial library must only store up to 64 bytes into its memory buffer, as the maximum number of bytes I can read is always 63 (I'm assuming its reading off an array).
When there are no bytes available, Serial.available returns innacurately, as 63. You can test this by a simple sketch:
void loop()
{
int numberOfBytes = Serial2.available();
Serial2.write (numberOfBytes);
}
Somewhere along the line, I am still getting a double sent variable. Still trying to figure out why exactly but I know its double sent because otherwise the array of data I'm recieving wouldn't be perfectly formed and all of my shiftbrites wouldn't be lighting up!!!
mbolivar
LeafLabs
void loop()
{
int numberOfBytes = Serial2.available();
Serial2.write (numberOfBytes);
}
I can't reproduce this issue using the following program:
void setup() {
Serial2.begin(115200);
}
void loop() {
int available = Serial2.available();
Serial2.println(available);
}When I connect to Serial2, I see 0 printed, which is what I expect. Each time I send a character, the printed number increases by 1 until it hits 63, which is the size of the ring buffer the serial ports use. At that point, it stays 63 no matter how many characters I send. Things seem to work for me.
Can you please send a short, complete program that exhibits the bug? Along with the program, please explain what you expect to happen, and what happens instead.
You must log in to post.