I have a problem with interfacing two serial port with 8051 microcontroller. I have to use bar code reader and RF reciver and transmitter which both of them interfaced serially. I am thinking to add an ic to controller these to serial ports, but I don't know which type of IC I should used!! could any one help me, please?
Thanks,
As i under stand urs problem u want to connect the serial port of 8051 withtwo peripherals. The solution is Multiplexer IC.With its select lines u can select the peripheral with which the controller will communicate at particular instance.
The solution is Multiplexer IC NO, absolutely not! The solution might be a Multiplexer IC, but based on a statement above VERY unlikely.
if you can fully and totally GUARANTEE that the two serials never transmit at the same time, you may try multiplexing (and then find out that they DO send concurrently sometimes :( ). Based on previous posts in this thread: how do you control that nobody swipes a card when the other trasmission is active????
but which type of IC muliplexing I should used if you can not figure that out yourself, the go to NXP and click on 'logic'
you will need one multiplexer and two transcievers.
but again how do you control that nobody swipes a card when the other trasmission is active????
The solution you need is a derivative with 2 UARTS, and if that is not possible, you need to verify that one of the serials is a very low baudrate which I asked and you did not bother to answer.
Erik
One not so nice solution is to have a mux, but let the serial data from the two serial ports be sent to interrupt pin of the processor. If you listen to the RF receiver when someone uses the bar code reader, then you will know that you just lost data, so you can give proper feedback - an error sound or similar to request that they read the bar code again.
With a little bit of luck, the RF link will send all data multiple times (if it is one-way, it can never know if there are radio interference blocking one transmission) and then you may have time to switch back from the bar code reader to the RF receiver and still pick up one or more of the transmissions.
Yes, it is a kludge. I would definitely have selected a processor with more than one UART.
Can hardware flow control be used to ensure that one device doesn't transmit while the processor is listening to the other...?
But two UARTs would still be better
... why not just add an external UART?!
If you're short of pins, UARTs are available with I2C and SPI connections...
Why not choose a device with two UARTS.
Job jobbed.
One not so nice solution..... Yes, it is a kludge. Why do you not just do the right thing and get a derivative with 2 UARTS.
Why use a "not so nice solution"? why use a "kludge"? why make gigantic efforts not to do the right thing?
With a 2 UART derivative you should be able to code it in 1/2 hour without you will have to buy a bottle of aspirin which will cost you more than the proper derivative.
Sounds more like you are arguing with me instead of the OP.
I definitely recommend a two-UART solution. I just note that it _may_ be possible to do a multiplexed kludge.
I have used multiplexing when requiring output to two devices but only input from one. The processor had two UART (and didn't exist with more) and I needed to send to three devices. But multiplexing transmission is so very much easier, since the multiplexing can be synchronized with the transmissions.
you are right, of course, but if this is a school assignment the OP can learn a lot more from it doing it the "wrong" way - either by realizing he chose a wrong solution or by acquiring a deeper understanding of the entire subject. either way - he wins.
to Per: Sounds more like you are arguing with me instead of the OP. not arguing, emphasizing
To tamir:the OP can learn a lot more from it doing it the "wrong" way I have seen ever so many getting stuck making the wrong way "work". Yea, the OP can learn how to eat aspirin, if that is what he need learn.
The amazing thing about "the wrong way" is that it is an advanced method, not "beginners goof".
I guess every seasoned developer has been in situations where the only solution was "the wrong way" and implemented it; however "the wrong way" is not kid stuff.
I would hate to guide a blatant novice through a soft UART.
But a student making a working soft UART would have taken a big leap towards knowledge about timing requirements in embedded systems.
Similarly, a student who successfully interfaced an external UART would have taken a big leap towards knowledge about all kinds of interfacing!
Perhaps the OP should more clearly explain what are the actual objectives, requirements, and constraints of this particular exercise...?
View all questions in Keil forum