confusion with select statement

New to XMOS and XCore? Get started here.
User avatar
msar
Member++
Posts: 19
Joined: Wed Sep 08, 2010 11:04 am

confusion with select statement

Post by msar »

Hi everyone,

I'm confused over the behavior of a select statement. I have two threads in my program. One listens for input, while the other processes pre-cached settings. My problem with the select statement is that even when there is no input for the listener to consume, the select statement behaves as though it has had input. The serial link seems to not always return to 1 when it's done sending data. In response to that, I have attempted to read the state of the serial link at the beginning of the loop, and then detect if that changes. This doesn't seem to work - if any value aside from 255 is sent over the serial link, this gets caught in the second case after going once through the process thread, as though input were received.

Can anyone guide me on where this is going wrong?

Code: Select all

void getSettings(chanend out_ch, chanend process_ch){
	unsigned char nSettings;
	timeset settings[255];
	char pDone;
	char STOP=1;
	char GO=0;
	char rxd_tmp;
	while(1)
		{
        // The serial link seems to not always return to 1 when it's done sending data
			rxd :> rxd_tmp;
			select
			{
              // the process thread sends this signal when it finishes its round
				case process_ch :> pDone: // process thread is ready for another round
				{
               // this is a signal to the process thread that it should start 
               // another loop with whatever cached settings it presently has.
					out_ch <: GO;
					break;
				}
				case rxd when pinsneq(rxd_tmp) :> void:  // comm received, incoming data
				{
                                        (get settings functionality omitted for brevity)
                                }



User avatar
msar
Member++
Posts: 19
Joined: Wed Sep 08, 2010 11:04 am

Post by msar »

Hi again,

I haven't been able to figure this one out. Any ideas? I am attaching my full source code, in case the snippet wasn't enough before.

Thanks for any input.
Mike
You do not have the required permissions to view the files attached to this post.
vector
Member
Posts: 11
Joined: Mon Mar 29, 2010 11:39 am

Post by vector »

Hi,
I am not clear on where rxd is coming from. It is not a channel as it is not declared.
If it was declared as a channel then the statement should read
case rxd :> rxdtmp :
// rxd received over channel and inputted to rxdtmp, now process.

This would remove need for the rxd :> rxdtmp outside of the SELECT statement,
This makes it more like an event driven routine. Case only gets triggered when rxd is received over the channel. I maybe have misunderstood what you are trying to do but you need to show your full code
in order to solve this.
User avatar
msar
Member++
Posts: 19
Joined: Wed Sep 08, 2010 11:04 am

Post by msar »

Hi Vector,

Thanks for your reply. rxd is not a channel, it is a port. More specifically, it is the UART receive port. I want to listen for any incoming input over the serial connection. Ideally, this would be a simple "wait until RXD port goes to 0", since 1 should be the quiescent state of the line. However, the line doesn't seem to return to one after transmitting anything aside from 255. I'm inclined to think that my terminal emulator is doing a poor job of sending stop bits. Is the line supposed to stay at 1 after the stop bits until a start bit is received, or can it vary?

More importantly, is there a way to debug on hardware while also recording waveforms? I don't know how to see the value of the RXD port when I'm debugging on hardware. Thus, I can't really see why the select statement isn't behaving properly.

The file I attached in my second post in this thread is the complete source code. If I can clarify anything about it, please let me know.
vector
Member
Posts: 11
Joined: Mon Mar 29, 2010 11:39 am

Post by vector »

The rxd being a port is just 1 bit. Why are you looking at the state of this bit ?
Am I wrong in assuming you want to pass a BYTE to the select statement ?
Normally with comms, the UART gets the whole byte and then channels the character to the thread.
The rxdtmp is a byte but you are comparing with a 1 bit port.
Sorry if I have the wrong end of the stick but lets start here.
Apologies for not seeing your code post earlier, was just skimming the forum when I saw your problem
and no answers.
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am

Post by segher »

msar wrote:Ideally, this would be a simple "wait until RXD port goes to 0", since 1 should be the quiescent state of the line.
It is.
However, the line doesn't seem to return to one after transmitting anything aside from 255.
The stop bit is 1; there does not have to be any extra space after a stop bit, it can be
immediately followed by the next start bit.

The uart_getc() code you use does not check for a stop bit. It should; without that you
have no chance of resynchronising to the stream. And you _will_ desynchronise, the
rest of your code pretty much guarantees it ("if there is a start bit, wait a long time
before doing anything").
I'm inclined to think that my terminal emulator is doing a poor job of sending stop bits. Is the line supposed to stay at 1 after the stop bits until a start bit is received,
Yes.
More importantly, is there a way to debug on hardware while also recording waveforms? I don't know how to see the value of the RXD port when I'm debugging on hardware.
I usually use debug printf()s, where the TX runs on a separate thread, with a memory
buffer inbetween, so that the debugging does not significantly changes the timing. You
probably want to output this on a different serial port ;-)
User avatar
msar
Member++
Posts: 19
Joined: Wed Sep 08, 2010 11:04 am

Post by msar »

Thanks both for your replies. Segher - your advice was perfect, and the code is running quite well now. Thanks again for your help.

I'm attaching my modified code to this post, in case it might help anyone.
You do not have the required permissions to view the files attached to this post.