USART DATA RECEIVE FROM MULTIPLE TRANSMITTER.

Go To Last Post
38 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want to connect GSM module and RFID detector module with ATMEGA16.

Here, the purpose of the RFID detector and GSM module is

When an unauthorized RFID card will be scanned, GSM module will make a call to a certain phone number.

 

But the problem is that,

            When I connect both the transmitter with the RX of the ATMEGA16(as shown in the figure), GSM module does not initiates. And even the RFID module also not detects card value.

 

But individually GSM INITIATES piety well.

 

 

What should be the probable problem? Is this Circuit connection issue? Or Coad Issue?

 

 

 

C Code and USART header file is given below.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's a design issue. You can't use the same serial port with two devices simultaneously. What voltage level are you expecting to see when one of them has TX low and one has TX high?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

A mega164p is very like mega16 but has two UART. Suggest you switch.
.
Alternative is soft UART but receive (rather than transmit) is always fraught.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the_real_seebs wrote:

It's a design issue. You can't use the same serial port with two devices simultaneously. What voltage level are you expecting to see when one of them has TX low and one has TX high?

 

 

 

I tried this connection also. But this is not working.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's easier if you embed the image in the post - so that we can see it:

See Tip #1 for instructions.

 

As  the_real_seebs told you in #2: you just can't do that; it won't work - the two data streams will just "collide" and corrupt each other.

 

As clawson suggets in #3, there is  plenty of choice of microcontrollers with two (and more) UARTs; so, really, don't mess about with this - just choose a chip with sufficient UARTs for your application!

 

Another option could be to add an extra UART connected vie SPI or I2C.

 

To do what you have tried to show, you would have to implement a multiplexer - which is a "switch" to properly select one of the two sources to feed the ATMega's Rx. But this means that you will be "deaf" to anything happening on the non-selected device - any data it sent while you weren't listening will be lost and, possibly, irretrievable.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To clarify,

I wrote:
you just can't do that; it won't work - the two data streams will just "collide" and corrupt each other.  

This has nothing specifically to do with AVR; it is basic electronics - simply shorting two outputs together like that is never[1] going to work.

 

skmdr wrote:
And even the RFID module also not detects card value

Almost certainly, is does still detect the card as normal - the problem is that you have broken the communication of that card value to the AVR.

 

 

[1] There are certain specific types of outputs which are designed to be connected together - but then you also need means to select one or the other, and ensure that both don't try to talk at the same time.

This is the concept of a bus

 

https://en.wikipedia.org/wiki/Bus_(computing)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Diodes won't help. You really, seriously, *can't* make serial inputs work with two of them wired to the same thing. That's not how usart works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apart from the diodes being the wrong way, you expect to decode meaningful comms from two devices that might decide to both talk at the same time. You have two choices - devise a mechanism to stop the other device from talking or simply implement another serial port so both devices can talk freely without interfering with each other. No magic.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Suppose "you" wan to transmit 'A' (GSM wants)  and '0' (TFIF wants) at the same time,  through a wired diode  OR; to make things less horrible, I assume chars are synchronous, and bit duration is exactly the same (with a pen, a sheet of paper and an eraser -very important-, you can figure out some more complicated cases)

 

'A' is 1+64 == 0100 0001 in binary

'0' is  48 == 3*16 == 0011 0000 in binary

'you' -ie avr- will receive 0111 0001 in binary, i.e 'q' (your didodes protect gsm and rfid, and are a logical or)

And you wonot know whence it came....

 

I just tried to describe the terrible way things collide and get corrupted in a simple case)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There is a simple solution:

clawson wrote:
A mega164p is very like mega16 but has two UART. Suggest you switch.

the fact is that if you are going to make a "two UART design" it sort of makes sense to pick a chip with at least 2 UARTs ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
if you are going to make a "two UART design" it sort of makes sense to pick a chip with at least 2 UARTs 

Absolutely!!

 

And, since a UART is an invaluable debug, diagnostic, and management tool, it is folly not to keep a UART free for that purpose!

 

Again, it is not hard to find chips with 3 and more UARTs these days ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"To do what you have tried to show, you would have to implement a multiplexer - which is a "switch" to properly select one of the two sources to feed the ATMega's Rx. But this means that you will be "deaf" to anything happening on the non-selected device - any data it sent while you weren't listening will be lost and, possibly, irretrievable.

"

 

A solution would be the multiplex makes packets out of the data (asy "UART 0 sent this packet" .. "UART x sent this packet", "I want to send this data to UART y") I am afraid it would involve programming an extra avr with a lot of UARTs ... and finding out which packet came from would add complexity on the original avr...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:
I am afraid it would involve programming an extra avr with a lot of UARTs

Indeed it would!

 

So we're back to same conclusion: @skmdr - You Need An AVR With At Least 2 UARTs !

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also agree that an AVR with (at least) 2 hardware UsART's is probably the best solution, but there are alternatives:

 

The trick with the diodes as mentioned in post #5 can work (if an extra pullup or pull down resistor is added) if some synchronisation method can be added

For example (from the picture in post #5. If the RFID sends data at regular intervals, but the GSM module only responsd when talked to, you can wait untill an empty window for the RFID node to talk to (and get a response) from the GSM module.

 

If it can be tolerated that collisions occur, then with the diode trick you can receive messages from both nodes, for the messages without collisions.

 

Some digitial glue logic or even an analog multiplexer can be used to prevent the collisions from occuring, (But data will still be lost).

 

With a lot of these devices the baudrate is low, and a software uart can be used for one of them.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think we're just going in circles here - time to wait for the OP to come back ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Kartman wrote:

Apart from the diodes being the wrong way...

+1.  Asynchronous, serial communication leave the Tx signal high when idle.  This means your diodes need to pull down, not up.  While the internal pullup on the ATmega16 RX line may be adequate, I would try an external pullup of 10k or so.  As others have ponted out, you will still have the collision issue if one device tries TXing while the other is TXing.

 

edit: removed image

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

Last Edited: Tue. Apr 24, 2018 - 03:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you Experts.....

The issue is clear to me.

 

awneil wrote:

 

Another option could be to add an extra UART connected vie SPI or I2C.

 

 

Dear awneil, Can you give me some knowledge about the process of making an USART communication using SPI and I2C.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UART <-> other AVR <->SPI (or TWI)  <-> first avr...

 

Drowabcks : you have to develop/ find SPI code, master on one side, slave on the other (same thing with TWI/I2C : I am sure avrs can become I2C slaves, not sure for SPI); code for one UART can be adapted to another, if you use a multi UART avr...

Compexity would be greater than a multi UART avr (both software and hardware complexity)

 

Edited : avr s can be SPI slaves (confirms complexity)

Last Edited: Wed. Apr 25, 2018 - 06:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skmdr wrote:
Can you give me some knowledge about the process of making an USART communication using SPI and I2C.

What I actually said was:

an extra UART connected vie SPI or I2C

ie, an external UART chip which is connected to your AVR by means of an SPI or I2C link; eg,

     AVR                   UART
   +------+              +------+
   |      |              |      |
   |      |  I2C or SPI  |    RX+<---------
   |      +<============>+      |            GSM
   |      |              |    TX+--------->
   |      |              |      |
   |      |              +------+
   |      |
   |    RX+<--------------------------------
   |      |                                   RFID
   |    TX+-------------------------------->
   |      |
   +------+

 

But, as dbrion0606 said, why on earth would you want to do that??

 

It would be so much simpler to Just Get An AVR With At Least 2 UARTs !

 

dbrion0606 wrote:
Comlplexity would be greater than a multi UART avr (both software and hardware complexity)

Probably cost, too.

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Apr 24, 2018 - 09:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:
UART <-> other AVR <->SPI (or TWI)  <-> first avr...

I was actually thinking of off-the-shelf chips; eg,

 

https://www.nxp.com/docs/en/data-sheet/SC16IS741.pdf

 

https://www.maximintegrated.com/en/products/interface/controllers-expanders/MAX3107.html

 

but one could, of course, implement the functionality in another microcontroller.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, as several people have pointed out, the OP's project could be completed with a single USART, and he almost has it right.

 

The diodes are to form the equivalent of an "open collector" output, the OP should Goggle that.

 

As mentioned the diodes are place in the wrong direction, and need to be reversed.

 

As mentioned, one needs a 10K (roughly) pull up resistor on the micro side of the diodes, to hold the line high when the transmitters are not actively pulling it low.

 

AS a User could swipe a card at any time, it would be best to use another of the micro's I/O lines to turn on / off the RFID reader if it has a control line, or turn on/off its power with a PFet, or add an AND gate to its output to allow the micro to control when it can transmit data on the (single) data line into the micro.

 

As the micro controls the GMS modem, perhaps no additional control signal is required for that device's data transmission line.

 

One still has to guarantee that both devices can not transmit data at the same time.  With the diodes reversed and a pull-up resistor there would not be any physical harm to the chips, but there would be corruption of the transmitted data.

 

At the end of the day, however, it would be MUCH easier just to pick a micro with two hardware USARTs.

 

JC

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
One still has to guarantee that both devices can not transmit data at the same time. 

That is the fundamental flaw.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps someone should suggest that skmdr just use an AVR with (at least) two UARTs ... ? 

 

It's the obvious and simple answer ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

I was actually thinking of off-the-shelf chips; eg,

NXP 16Cxxx seems very interesting (has a 64 byte buffer, low power, idle current mode, can work with I2C -it is nxp- and SPI : all of this could be implemented in an avr but the extra software is half ). A little drawback : I bet, according to Murphys laws,  OP's transmitters are 5v, and this circuit is 3v (adaptation adds other complexity)

 

w/r dual UART : extra software, an extra circuit, at least 2 extra wires. .,; can one find this circuit in India -for a long time?-

OTOH dual UART avr (Clawson idea)  needs only 2 extra wires (anyway, SPI needs 4 extra wires, I2C needs two)  and adapting working -according to OP- software (perhaps receiving upon interrupts?).

Last Edited: Wed. Apr 25, 2018 - 11:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think this dead horse has probably been resurrected and beaten again to death enough by now ... ?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In case you dont want to change MCU, you can also use couple of optocouplers whit enable pin(or some other on/off throughput component) and then just "open" the serial connection that you need and close the second one. Just make sure that on/off component is bidirectional for your GSM module.

Last Edited: Wed. Apr 25, 2018 - 11:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you can also use couple of optocouplers whit enable pin

you are likely to loose characters... (interrupt receiving with dual UART avoids this character loss). This si a kind of multiplexing (very safe one) ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:
you are likely to loose characters

Indeed!

 

Again, that is the fundamental flaw - which has been pointed out before when basically the same approach was suggested before!

 

How many lives does a dead horse have??

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But klemko idea makes a very safe multiplexer .... (the safest that was suggested) and can be used .... for dual UARTs avrs (if one changes RFID GSM  with strange "ground" characteristics).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If i understood it correctly, the system works by making a call over GSM module, if unatuhorised RFID card is used. In this case only the RFID connection is opened and once the unauthorized RFID is detected, the MCU switcher to GSM connection, closes RFID and once the Call via GSM is finished, open the RFID again. It is simple, but it only works of it is acceptable that RFID reader is inactive, while the GSM module is making its call/sms sending.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Klemko wrote:
it only works of it is acceptable that RFID reader is inactive

There, again, is the fundamental flaw!

 

As already noted, a  user could come along at any time and swipe a card. The user is not going to be happy if the reader appears to have stopped working - because it's busy on the GSM.

 

#UXfail

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ye, but if the RFID reader has output buffer that keeps the last scanned data memorised until it is read, and if the GSM will only be active for couple hundred  ms, it could still work good. Maybe the OP already has PCB developed and doesnt wanna change the MCU. There are many IFs, it is up to OP to either give more data or select viable solution form all that were suggested in the post on his own :D  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or just buy a UART to I2C adapter from sparkfun or some other site for couple of euros, and you are finished :D 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

All this to save replacing a $3 mega16 with a $3 mega164 ??

 

Just get the specification / design sorted first then pick the chip that delivers what the design needs.

 

The worst way to design is to say "OK I have an ABC123 here in my hand, now how can I shoe-horn everything I need into this chip?". You could spend weeks/months messing about with soft UARTs or "diode sharing" or whatever and all you really needed to do was design THEN pick the chip and you could have spent all that time/effort making the product better instead.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

again, you're just repeating stuff that has been suggested already!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Or just buy a UART to I2C adapter from sparkfun or some other site for couple of euros, and you are finished :D "

 

But you have to begin writing I2C software (assuming OP's card does not have LCD screen, which eats I2C hardware pins) instead of adapting (partly) tested UART software -the only remaining effort if OP changes 1 UART avr to 2UART avr... maybe he needs to read tutorial on UART+ interruptions...).

The easiest (and cheapest) solution, if one does not bet GSM and RFID never emit simultaneously -according to Murphy's law, this hypotheses is false- is to use dual UART... (and hope no UART pins are used by extra hardware such as screens....)

 

Edited :  a couple of euros? that might make things more expensive than a dual UART (from Clawson 's prices) ... and do euros exist in India -from OP's profile and some notions of geography-

Last Edited: Wed. Apr 25, 2018 - 01:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The RFID has essentially zero data rate (maybe 10 bytes every hour), you could set up an IRQ based bit-bang uart on some free pins.

But I agree, a dual UART is better...try the mega328PB.

 

When in the dark remember-the future looks brighter than ever.