UART & timing

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

UART & timing

Postby msar » Tue Sep 14, 2010 2:22 pm

Hi everyone,

I have hacked out a rough start for a shutter control project. There's some details here:
http://xcore.com/projects/xmos-fast-shutter-control

I have a couple of questions that I hope you might enlighten me on.

From the openShutter function in the code block below, a couple of questions:
  • * For an unsigned int, clock counters are limited to maximum lengths of ~42 seconds, right? How can I get timers longer than that?
    * What is the difference between waiting for a clock value using

    Code: Select all

    tmr when timerafter ( time ) :> void ;
    shutter <: 1;
    and telling an operation to occur at a particular clock value using

    Code: Select all

    shutter @ time <: 1
It seems like they should be equivalent, but the output signals in the simulation don't make sense using the latter method.

Code: Select all

void openShutter(out port shutter, in port notscan, unsigned int stime)
{
	timer tmr;
	// an unsigned int for the time should allow for exposure times up to
	// 42.94 seconds - 4,294,967,295 cycles * 10 ns/cycle
	unsigned int time;
	//notscan when pinseq(1) :> void;
	tmr :> time;
	// sleep for preset delay
	time += SETUP_DELAY;
	// open shutter for setting.stime by turning on shutter port
	tmr when timerafter ( time ) :> void ;
	shutter <: 1;
	time += stime;
	tmr when timerafter ( time ) :> void ;
	shutter <: 0;
	//
}
Since I am only passing integers around, I altered the rxByte function from the UART demo to receive 32 bits rather than 8. Is this a bad idea? Is there a better way to do it?

Code: Select all

unsigned int rxInt(in port rxd)
{
	unsigned int rlt, time;

	// Wait for start bit
	rxd when pinseq (0) :> void @ time;
	time += BIT_TIME / 2;

	// Input data bits
	for (int i = 0; i < 32; i++) {
		time += BIT_TIME;
		rxd @ time :> >> rlt;
	}

	// Input stop bit
	time += BIT_TIME;
	rxd @ time :> void;

	return rlt;
}
Finally, I am unfamiliar with UART and embedded programming in general (if that isn't already obvious from the above code). The code examples have shown me how to get the XS1 to receive data, but how do I tell the PC to send information over COM ports? Is there a good tutorial website or textbook that anyone can point me to?
User avatar
msar
Member++
Posts: 19
Joined: Wed Sep 08, 2010 11:04 am

Postby msar » Wed Sep 15, 2010 4:40 pm

In case any other newbies come here looking for similar answers, here's an update:

You can experiment with sending data over UART using a terminal emulator that connects to serial ports. Another user, leon_heller, made a simple XC program to listen for values and return them to your computer. It was helpful to me.

http://www.xcore.com/projects/simple-uart-demo

The terminal emulator I found for Windows was 232Analyzer, which can be obtained free here:
http://www.232analyzer.com/232default.htm

I assume that I'll have to implement the equivalent of the XC UART code for any application on my PC that I want to use for sending data to my XC-1A.

For counting long periods of time, I do iterative waits, like this:

Code: Select all

case 115: //seconds, lower-case s
			if (time > 20) {
				carry=time/20;
				for (int cnt = 0; cnt < carry; cnt += 1){
					delay(2000000000);
				}
				delay(time%20);
			}
			break;
		case 109: //milliseconds, lower-case m (no need for longer times)
			delay(100000*time);
			break;
Is that a reasonable approach?
User avatar
paul
XCore Addict
Posts: 169
Joined: Fri Jan 08, 2010 12:13 am

Postby paul » Fri Sep 17, 2010 7:42 am

Multiple delays is the only way to get a longer delay than the timer permits.

The port time stamp (the @ time) syntax is different to normal timers. The timer for a port timer is clocked from the port clock (default is the reference clock). The port timer is also only 16 bit so will wrap a lot quicker!

Regarding your UART... you need to be careful how your transmitter works. I haven't come across anything that sends 32bit values all at once. The transmitter might split up the value into 4x8 bit values with the relevant start and stop bits at the beginning and end of the 8 bit value. Your function assumes the start and stop bit surround a 32bit value.

Hope that helps!
Paul

On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
User avatar
msar
Member++
Posts: 19
Joined: Wed Sep 08, 2010 11:04 am

Postby msar » Fri Sep 17, 2010 4:20 pm

Thanks Paul, that clarifies things a lot. The 16-bit port timer explains the behavior I saw perfectly.

I guess if I wrote my own transmitter, I could have it send the 32 bits all at once. I think it's probably better to stick with tradition, though.
Dominik.vettel
New User
Posts: 3
Joined: Wed Nov 28, 2018 9:31 am

Postby Dominik.vettel » Tue Feb 25, 2020 4:22 pm

Hi there,
The simple UART demo link isn't working. can I get the new link?
Thanks

Who is online

Users browsing this forum: No registered users and 3 guests