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

[Klaus Kloos]

Hello Hendrik, hello Harald

>> 	    #define blockgroesse 1	// 2^n, works up to 4, 8 generates delays
>> 	    for(lauf=0; lauf<512/blockgroesse; lauf++){
>> 			gesendet = fwrite(&buffer[lauf*blockgroesse], 1, blockgroesse, dmxOut);
>> 	    }
>> 	    fflush(dmxOut);
> 
> This is highly ineffective.
I  know :-)

> Better decrease the high water mark. You may
> also increase the total buffer size to 512, so fwrite will return
> immediately.
> 

> http://www.ethernut.de/nutwiki/Advanced_UART_Functions
> 

Interesting...
I have tried to increase the buffersize, but it has no effect on my problem. blocks of 8 bytes (and more i think) will cause the additional output.

> Considering hardware timer, GPIO and UART, I think that it would be a
> bad idea to integrate this into the existing UART driver.
> 
> I'd do it with native code. You'll probably find an interrupt driven
> UART example in the Internet, which is more easy to follow than the
> Nut/OS driver. Same is true for the timer, Nut/OS doesn't provide any
> except the system timer, which is special.
> 
The break and the MAB are not so critical, even differences in ms are covered by the spec.
Ive got it working with the ineffective sending of single bytes.

> If you think, that a Nut/OS driver is an advantage (because you want
> stdio), then create a dedicated DMX driver. In fact, this is quite easy.
> Fortunately I just created a new document, which may be helpful:
> 
> http://www.ethernut.de/en/firmware/porting.html
> 
> It explains, how to port Nut/OS to a new platform, but also contains
> informations about Nut/OS drivers. Note, that it refers to Nut/OS 5.0.
> I'd recommend to stick with 4.10. You can get the new sources, which the
> document refers to, at
> 
> http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/
> 
> If you need help, please asks here.

I will look at this. But at the moment my project is pushing me and I have to be satisfied with the ineffective working workaround.

Am 25.10.2011 um 14:59 schrieb Henrik Maier:

> On 25/10/2011 6:26 PM, Harald Kipp wrote:
>> break signal will last for at least a full character length. DMX512
>> requires a minimum time of 92us. If I understood it right, this have to
>> be followed by 12us "inverted break". Hummmm! AFAIK, the UART can't to
>> this. Thus we have to use GPIO.
> 
> One dirty trick to use the UART rather GPIO with DMX512 is switching the 
> baudrate form 250kbit/s to 57600 and then to send a nul (0x00) character 
> to simulate the break and then back to 250kbit/s. The 88 us length 
> requirement is a minimum, so it can be longer.
> 
Like Harald said, this will lead to the original problem, that when switching the baudrate the UART does not send its pending data with the old baudrate.
 
Many thanks for your help.

Greetings Klaus