We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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,
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.
Erik
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...?
But a student making a working soft UART would have taken a big leap towards knowledge about timing requirements in embedded systems. absolutely! however I doubt this will be even possible for a beginning student, which the OPs posts show (s)he is.
It definitely is possible to implement a software UART for a beginning student (as long as the baudrate is low). But it requires a beginning student who spends significant time reading datasheets and application notes and searching for information, instead of requesting. Requests/responses gives too low bandwidth.
A number of people on this forum had to start with microcontrollers - or more often generic processors with large amounts of external chips - before web forums or mailing lists, and no really good method for the chip manufacturers to distribute application notes. In the end, it's just a question of will. Doing something wrong and having to backtrack is just as valuable as doing something correct - as long as the problem is identified and the lesson learned.
Each shopping cart will be equipped with a Liquid Cristal Display (LCD) and bar code reader. The Bar code reader allows the customer to enter the value of each expected item and the total bill on the LCD screen. The following is a scenario of how this smart shopping cart is expected to function: Firstly, a customer pulls one smart shopping cart from the shopping cart line. When an item is picked, it is scanned (using the item’s bar code) before placing inside the shopping cart which in turns sends a wireless signals to the main cashier computers informing about the purchasing progress.
This is m y idea of the project? Now what is the the best solution? also I though to connect the two input with or gates!!!
"When an item is picked, it is scanned ... the shopping cart ... sends a wireless signals to the main cashier computers informing about the purchasing progress."
So, are you saying the the barcode reader only ever sends data to the processoer (never needs to receive from the processor), and the RF devices is purely a transmitter, which never needs to receive anything for the processor?
If that's the case, then you simply connect the barcode scanner to the UART's receive line, and the RF transmitter to the UART's transmit line!
I'm still with the consensus here that the best solution has to be to get an 8051-derivative with 2 UARTs!
You might think that you can get away with some kludge, but there is a very high risk that this compromise will come back to bite you later; eg, if you discover that you do, in fact, need to send something to the scanner; or it turns out, in practice, that a transmit-only RF link is not suitable, and you need some kind of acknowledgement to your messages.
It is doubtful that adding extra hardware to a 1-UART device will save you any cost over using a 2-UART device.
It is certain that any sort of messing about with multiplexing will add to the complexity of both the hardware and the software - do your deadlines permit this?
You will also have to add something to the user interface to indicate when it's not ready to scan - again, this will add cost and complexity, and will reduce the "usability" of the device.
Note that none of the above is really specific to the 8051 - and certainly has nothing to do with Keil tools!
For a school project, you can normally get away with a paragraph in the report mentioning known limitations - and why the limitations are there.
In real life, you really do have to have two-way communication for the RF link. RF never has 100% delivery guaratee. Might not matter when you press a button to turn on a lamp - you see if the lamp turns on, and can press again.
In a shopping chart solution, you do not want customers to not have to pay... Besides - without a two-way solution, how do the chart know when to send? Would it send each item immediately after being scanned? Normal would be to report to the cachier when you are done shopping, in which case the system must know where you are - if you are near the other end of the RF link. A work-around for that is to have the customer scan a magic "shopping-done" bar code to activate the RF transfer.