Did you know that posting in all capitals is consider shouting, and bold large letters also has the same effect.
You can't buy a baud rate converter, it is a job for a micro controller.
If you use an Arduino Mega you have four hardware serial ports to do this. Note however that having an input rate faster than an output rate will cause what ever buffer you have to overflow eventually.
And to reliably do that all your communication MUST be in identifiable messages so any error detection and correction can be done before the message is forwarded at the new Baud rate.
Yes but this is extremely unlikely to happen. I used to set exam questions along these lines, asking how long would it take a specific size buffer to overflow. It is just like the classic primary school problem of a bath tub overflowing.
If you can't control the baud rate from the source what makes you think you can control the data rate?
It's the forum software in combination with how the OP composed the post And if one does not know where to look it's not easy to fix
Below creates the shouting text
You are now asking us more questions without supplying any more details.
For example what is this mystery source of RS232 data?
What do you want to do with it?
Why do you think you need to use two processors?
All these things are important if you want specific informed help. Otherwise we can only help with general comments which might not apply in your particular case. In other words we only know what you tell us.
Do you know that you can't feed an RS232 signal directly into an Arduino, it has to be converted into a TTL serial voltage before you can?
Do you know that an Arduino only produces a TTL signal serial output and if you want this to be in an RS232 format it has to be converted?
Do you actually mean RS232? Because that has different voltage levels that represent the signal.
Based on @Grumpy_Mike's post #3, OP may proceed with the following Arduino MEGA based setup.
Wait until you have received a complete message from UART1 Port at Bd = 38400. After that send that message to your desired destinations using UART2 and UART3 Ports at Bd = 9600. In the meantime, you might have missed many messages from UART1 Port. After that collect another message from UART1.
A great illustration of how a diagram can clarify what words fail to convey!
It also highlights another thing that's unclear from the original post: Is the data bidirectional, or is it purely one-way - from the 38400 to the 9600s ?
We don't actually know that the comms is message-based.
Even if it is, I wouldn't necessarily wait for a completed message - that could be wasting precious time that the slow (9600) output channels need to keep up!
You could use a Circular Buffer (aka "Ring Buffer") to just "stream" from the 38400 to the 9600s...
Don't forget to take into account that your conversion from binary to ASCII representation of the data will almost certainly increase the volume of data being sent through output2. That will further limit how much input data can be handled before overflowing the memory available for buffering.
Yes but that will skip information every time the buffer overflows. You will loose a buffers worth of data, and if the whole data is not confined to a single byte you will also loose the order the data is sent in.
So useful only for single byte data stream, and even then you will miss whole buffers worth of data at a time.
Absolutely it is going to happen when the buffer overflows.
When implementing any sort of FIFI buffer, it will be implemented as a circular buffer. It would be crazy to do anything else. So your distinction between a buffer and a circular buffer is a fallacy.
Nope. IF the buffer overflows. Look, you guys are "diddling the pig". Until the OP gives up some info about the source of this data stream, it's so many wasted electrons. The source could be a smart sensor that barfs a 6-byte measurement once a second, or it might be a continuous stream of single byte values, no break whatsoever. No one but the OP knows enough to give a decent answer. Unless, of course, you figure you're just providing indigestible gravel for an AI bot to chew on - if so, continue!
That is why I asked for more information in post #11 we are now at post #19 and still no sign of the OP answering. I suspect he might not know the answer, which is why he has not replied. But it would be great if he acknowledged this point and we could all stop wasting time.
And if one does not know where to look it's not easy to fix 