2input serial port with 8051

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.

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.

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.
... the customer scanning an object and THEN deciding not to buy it?

is this a school project or an industrial application?

Erik

Thank you for your apllying my request

the best solution is 8051 with 2 uarts ???

yes its a project idea, we decide this idea!!!

this is our system , so we decide if each item send after scaned or the total purcahse sent!!!

what is better each item send or the total purcahse??

by the way, we will assume the cost of each item by using a data base !! is this a good idea , if isn't what is the best???

thank you

yes its a project idea, we decide this idea!!!
...what is better each item send or the total purcahse??
...by the way, we will assume the cost of each item by using a data base !! is this a good idea , if isn't what is the best???

being still a student, you have the privilege to make mistakes. that's fine. but once you get your degree and start working, you will need to plan carefully what you are going to do before starting any kind of implementation. That is called collecting requirements (part of software development cycle), and is of extreme importance when working on almost any software project, let alone embedded systems that often involve moving parts or mission critical code.

thank you for your advice:)

untill now we can cahnge our system in oreder to have a few mistake...

therefore, i asked a prossional people,to have a good planning.

Hi, As both devices are not used simultaneously, you can think of below implementation:

Put 2 number of MAX232 Line Receiver/Drivers (choose an IC with Enable option). Short the both Rx's of MAX232 to Rx of controller and similarly for Tx.
1) Keep MAX232 of Scanner Enabled as default and LCD off.
2) When ever a scan is completed:
a) Disable scanner MAX232, Enable MAX232 of LCD
b) Transmit all the data
3) Diable LCD MAX232 and Enable the Scanner MAX232
4) Repeat the cycle.....
Assumptions are: LCD and scanner use same baudrate. Data Trasmited to LCD is only few bytes, so that Scanner will be ready fast for next scan.

I have a problem only on Rx (bar code reader and RF resivier).
At TX we have only RF transmitter

Thanks

I guess you still need to use 2 MAX232 devices, as RS232 is a point to point type not a multi drop!

Put 2 number of MAX232 Line Receiver/Drivers (choose an IC with Enable option). Short the both Rx's of MAX232 will the smoke be blue or grey? to Rx of controller and similarly for Tx.

I know of no RS232 transciever that does not have push-pull output of the Rx. If you are going to short the RX outputs, you better find one with open collector OP.

Erik

Thanks Eric for your comments! Devices like LTC1387 will do the job. When a channel in high impedance on RS232 side, shoritng RX (at TTL) may not give you chance for smoke. Else it is simple to build a switch to isoalte TTL side, with old style MAX232 device.

Thanks Eric for your comments! Devices like LTC1387 will do the job ... as far as I can see there is no disable of the (TTL level) Rx output and it IS push-pull. Thus parallelling two WILL give smoke.

Erik

continuing:
why not just use an OR gate?

Erik