read two input via usart without losing anything

"The design only has a single holding register for each of the transmit and receive paths, so no FIFO."

I haven't seen any CPU mentioned.

With FIFO you would often manage maybe one interrupt per 10 characters - it's quite common with around 16 character long FIFO. Without, you need to pick up every character one-by-one one and has less margin to overrun where a character is lost.

With DMA, it's the buffer size that decides how often you need to react and chain in a new buffer. A traditional DMA implementation runs doublebuffered so you get an interrupt when the DMA channel switched to the second buffer. Then you can pick up the data from the first buffer and relink it as third buffer.

"The design only has a single holding register for each of the transmit and receive paths, so no FIFO."

I haven't seen any CPU mentioned.

With FIFO you would often manage maybe one interrupt per 10 characters - it's quite common with around 16 character long FIFO. Without, you need to pick up every character one-by-one one and has less margin to overrun where a character is lost.

With DMA, it's the buffer size that decides how often you need to react and chain in a new buffer. A traditional DMA implementation runs doublebuffered so you get an interrupt when the DMA channel switched to the second buffer. Then you can pick up the data from the first buffer and relink it as third buffer.

"In addition it gets too complex"

Having one protocol thread per channel doesn't complicate things. It helps to keep the logic simple. You need to sleep before sending a response? Just sleep. The other threads will manage their own tasks.

"I haven't seen any CPU mentioned."

"is it possible to increase FIFO of usart of stm32f10x MCU?"

Ah. I missed that.

Thanks for your help
I started DMA with USART successfully.
I was wondering if I set input buffer to(for example a packet)100 chars and I receive 50 chars instead of 100 chars (because of any disconnection).After that it will add the new packet with the old one and the arise an interrupt.(half from the old connection and half from new connection)

I think to use an interrupt to detect the start bit of USART communication and then initialize DMA but as I see my CPU should check each input byte and active dma (it's too boring)

what's your idea to save DMA's advantages and prevent the above problem?

        DMAStruc.DMA_PeripheralBaseAddr=(uint32_t) &USART1->DR;
        DMAStruc.DMA_MemoryBaseAddr=(uint32_t) buffer;
        DMAStruc.DMA_DIR=DMA_DIR_PeripheralSRC;
        DMAStruc.DMA_BufferSize=sizeof(buffer)-1;
        DMAStruc.DMA_PeripheralInc=DMA_PeripheralInc_Disable;
        DMAStruc.DMA_MemoryInc = DMA_MemoryInc_Enable;
        DMAStruc.DMA_PeripheralDataSize=DMA_PeripheralDataSize_Byte;
        DMAStruc.DMA_MemoryDataSize=DMA_MemoryDataSize_Byte;
        DMAStruc.DMA_Mode=DMA_Mode_Circular;
        DMAStruc.DMA_Priority=DMA_Priority_High;
        DMAStruc.DMA_M2M = DMA_M2M_Disable;
        DMA_Init(DMA1_Channel5,&DMAStruc);
        USART_DMACmd(USART1, USART_DMAReq_Rx, ENABLE);
        DMA_ITConfig(DMA1_Channel5, DMA_IT_TC | DMA_IT_TE, ENABLE);
        DMA_Cmd(DMA1_Channel5, ENABLE);

Hello
You assume I connect to board to each other with a long wire and under usart communication.

Now you assume we send a string with this format

[Start char][98 chars , don't contain start and stop char][Stop char]

and we can rely on our buffer value by checking start and stop chars.
Now we suppose In receiver we lost one char from 98 chars therefore we get DMA interrupt when it fill up the buffer variable such as this new string
[Start char][97 chars , don't contain start and stop char][Stop char][Start char]
so we check start and stop chars and finally we ignore this packet and other packets ( because their first and end chars position have changed in all strings)
if we don't use DMA we can fill up the buffer with incoming chars and check start and stop chars and also string length and ignore fault string without any effect on other input strings.

Do not assume that your messages will be aligned with the DMA buffers - you can't simply count characters since the user may connect the cable in the middle of a transfer or one side may reboot. So your receiving side must always be self-synchronizing. That should be a minimum requirement of a communications software.

Your program needs to either respond to transfer timeouts - i.e. transfer pauses after the end of one message and the start of a new - and to also be able to split the data depending on the actual data formattting (magical start and/or stop characters or other markup in the data).

So what was your view after having read this document?
www.st.com/.../CD00256689.pdf

I have to assume that you have spent time digging through the processor documentation and also available application notes.

www.keil.com/.../
http://www.keil.com/forum/17145/

Not directly related to this thread, but maybe the OP would be interested.

--
It have been a long time, I did not become an excellent programmer. The discussion of the second URL is still too difficult to me. I am still far behind the skill level of our experts. I am a good programmer (I hope), just not excellent. The world is changing, I got another laid-off on this May, now I am working on the PIC16F platform.

Failed to post some sentences.

[ Problems were detected with the information submitted. Please correct these issues and re-submit the form.

Messages cannot contain the spam word "". ]

There are designs of mine mentioned, my designs are not good but as a reference. (Passed the censor.)

I am still far behind the skill level of our experts.

Please don't put yourself down. Of the many posters here, your posts are ones I do look at. They frequently include interesting concepts and ideas. And you post in a positive way.

I wish you good luck for the future.

Thanks a zillion Per Westermark for your help and good explanation
I have tried to use USART IDLE interrupt to detect the end of transmission and by resetting DMA section to improve my system, instead of using timer to define a timeout(that it has mentioned in CD00256689.pdf document). So is it enough for any discontinuity during transmission or I don't consider some states with this approach?

Thanks John linq for your links and help
As I was checking your comments and links I find out you use checksum,some handshakings and acknowledgement that was interesting for a strong protocol. But here I'm trying to align my data in DMA buffer and after that maybe I want to use some checksum.
I will happy to use your good knowledge about safe communication

"But here I'm trying to align my data in DMA buffer [...]"

Time to stop doing that, since it doesn't help you - it just makes your life complicated. If you want the packets aligned in a buffer, scan the input data for packet breaks and copy to a separate buffer.

Resynchronization and recovery are not things I'd try to manage with large DMA buffers, especially for data streams which are periodic rather than continuous.

Very simple buffering, and synchronization, can be handled in a USART IRQ with a state machine. Actual processing can be deferred to other tasks if it is complicated or is likely to interfere with the expeditious handling of the IRQ.

Receive DMA would work well if the data stream is continuous, and the buffers were smaller, allowing for decimation of interrupt loading, and managing the sync and dispatch of larger packet buffers.

The size of the DMA buffers should relate to the allowed latency of the communication.

If the maximum allowed latency to react to a complete message is 1ms, then it wouldn't be good to try a large DMA buffer big enough to hold 10ms or 100ms of data. The application note I linked to, described how to simulate a FIFO using DMA, and how to control how quickly the main program should be informed that data has been received - or how quickly the program should be informed that there is a pause in the transfer.

Make use of that functionality, and scan the data in the ring buffer produced by that code, to extract your individual messages. If the data doesn't contain any markup allowing you to see the end of one packet and/or the start of a new packet, then you really do need to make sure you detect pauses in the reception, so you can use the pause as packet separator.

Don't start a 100 byte DMA receive operation, just because you assume the received message is 100 bytes large and you assume that you will be able to start the DMA operation in the pause between two messages. When testing, it may seem to work. But it can fail rather badly, in case you do start the DMA operation some microseconds too late, having already missed the first character of the next message. So any use of DMA buffers to receive data must be self-synchronizing. And that also means you can't depend on the DMA receive buffer itself to always store one full and perfectly aligned message. See the DMA as a way to receive a data stream. Just as a FIFO or the single-character receive register represents a way to receive a data stream.

With more advanced transfers - like CAN or ethernet communication - the hardware itself can synchronize on packets. But with a standard UART, it's you who should do the conversion from stream to packets, after the processor hardware have supplied you with the individual characters.