[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