[En-Nut-Discussion] problem using fflush() (Klaus Kloos)

Klaus Kloos klaus.kloos at gmx.de
Mon Oct 24 09:58:58 CEST 2011


Hello Rob

Thanks for your answer.
If followed your idea, tried around some time and came to another problem.

> Try configuring the Tx-pin of your UART as a normal output pin, generate the
> break and mark-after-break sequence with the use of a timer (exact timing)
> and then (re)configure the pin as UART Tx-pin again (250 kbBaud). For my DMX
> projects I always use this method and it's working fine.
> 
Here is my DMX-packet... (initialization as before)

	    outr(PIOA_OER, _BV(1));			// set Pin to output
	    outr(PIOA_CODR, _BV(1));		// set Pin
	    outr(PIOA_PER, _BV(1));     	// PIO Enable Register
	    NutMicroDelay(100);				// definition is down to  88
	    outr(PIOA_SODR, _BV(1));		// reset Pin
	    NutMicroDelay(30);				// definition is 8, my working 'reference butler' makes 30
	    //outr(PIOA_CODR, _BV(1));		// set Pin, only for findig the start of UART transmission on the scope
	    //NutMicroDelay(1);				// 
	    outr(PIOA_PDR, _BV(1));     	// PIO Disable Register
// here I can see an additional 200us reset pin on the scope
	   zeichen = 0;
	   gesendet = fwrite(&zeichen, 1, 1, dmxOut);			// Startcode=0

	    gesendet = fwrite(buffer, 1, 512, dmxOut);
	    fflush(dmxOut);
	    NutSleep(10);

It seems that the changing from PIO-control to UART-control (or starting the UART transmission) adds an additional 200us.
Ive tried to debug the evernut-code, but I can only see that the UART is started correctly. No delay found..

Am I doing something wrong... does ethernut produce this delay or is it generated by hardware?
... and how do I get the problem solved?

Greetings
Klaus





More information about the En-Nut-Discussion mailing list