Wireless Serial App basic questionss

Support Wixel
1

Hi, I’m useing the Wireless Serial App to send bytes one-way from one Wixel to another. Sometimes it just seems to jam up; everything stops.

If the one is sending bytes faster than the other can process them, what happens? Is data just lost? Or worse?

Am I right in thinking there’s no handshaking involved there? The “signal” lines are not actually used by the app are they? There must be some form of handshaking to prevent lost packets but does it do anything with flow control?

I guess I’m trying to understand what I need to do to keep the receiving Wixel from being swamped.

Thanks for you help,
Colin

2

Hello, Colin.

I am sorry you are having trouble with the Wixel.

The wireless serial app has three interfaces for sending and receiving serial data: USB, radio, and UART. The USB and radio interfaces have flow control, so no data should be lost there. The UART interface does not yet have flow control; if the app receives bytes on its RX line faster than it can process them, the buffers will eventually fill up and you will start losing data. It should not jam up or stop though.

All the pins used by the wireless serial app are documented in the “Wireless Serial App” section of the Wixel User’s Guide; the DTR, RTS, CD, and DSR pins are not used for flow control.

If you want more help solving this, I recommend simplifying your system down to the simplest thing that causes the problem and describing it to us. Are you sure the problem is with the Wixel, and not with one of the devices receiving or sending data to it?

–David

3

Thanks David, it’s the radio link I was thinking about. But I can now see that that part’s working. I can send an 8-byte “heatbeat” messsge from one Wixel to the other as fast as I can get space in the radio tx buffer and they’ll do that all day.

I think the problem lies elsewhere. Here’s what I’m trying to do. The sending Wixel is polling my TReX for 2-byte channel values and sending them to the receiving Wixel in the form of an 8-byte message that looks like this: /01234S1.

That’s where it’s jamming up. Problem is, when I enter the TReX polling routine, there’s already a byte sitting in the UART Rx buffer, presumably from the previous poll.

Maybe I’m not waiting long enough for the data from the TReX but I thought I had that covered. I’m using the Pololu protocol so I need to send 4 bytes to poll a channel. The serial link to the TReX is at 19.2K. So, a couple of ms for the commands to transmitt and another for the data to return. Certainly the cycle should complete within 5 ms. wouldn’t you say?

If you can think of anything obvious I should look at, I’d love to hear about it.

Thanks,
Colin

4

I am glad you were able to narrow down your problem, but I don’t have any particular suggestions of things you should check. I’m can look at your code if you can simplify it as much as possible.

–David

5

Hi, I’ve done some more investigation and I’ve narrowed it down some more. Which is to say I’m still confused, but maybe I’m confused on a higher level :slight_smile:

I don’t think it has anything to do with the UART. I think it, somehow, has to do with the delayMs() function. Here’s the working heartbeat routine that gets called every iteration from the main loop. This will run indefinitely.

//putchar() calls radioComTxSendByte();

void heartBeatToRadioService()
{
	static uint8 i=0;
	while( radioComTxAvailable() < 8 ) usbComService();
	printf("/%05dH1", i++ );  //eg: "/00123H1"
	radioComTxService();
}

But if I add a delayMs(5) before the while, it runs for some seconds and then just hangs. Any ideas?

Thanks,
Colin

6

No, I still don’t know what is going wrong for you. If you could simplify your code as much and possible post it here, including the code the for the receiver and the code for the sender, and tell us the expected behavior versus the actual behavior, then maybe I could see what is wrong.

You should be wary of writing blocking code like that while loop. When you write blocking code, it is easy to forget to attend to something that is important, for example calling radioComTxService(). A simple thing for you to try would just be calling radioComTxService inside the while loop.

–David