Atmega328p

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

Hi there

I am using 2 Arduino nano boards and want to implement full duplex data transfer between them..by using GPIO pins. Both devices can send or receive data. See diagram. Let the initial I/O configuration be clk - output, tx- output, rx- output.

Scenario- when device 1 wants to send data to device 2 on tx pin, then the tx pin of device 2 should be configured to input.

Now during program execution, if I change the configuration of tx pin of device 2 to input, it does not receive data from device 1.

How to correct this?

There are available protocols that can be used for this but I was just trying to do something own d different.

Attachment(s): 

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

 

 

Helps if you put the image in the post - where we can see it:

 

 

So why not just use SPI? or the USART in sync mode?

 

Why do you need to be changing the direction of pins? why not just keep 1 line for device1 --> device2, and 1 line for device2 --> device1 ?

 

Which is how both SPI and USART do it!

 

 

EDIT

 

Like this:

 

 

So:

  • "Tx" is always device1 --> device2
  • "Rx" is always device2 --> device1

 

(but then you should probably choose better names)

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: Fri. May 22, 2020 - 10:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

seemam wrote:

...to implement full duplex data transfer between them by using GPIO pins...Now during program execution, if I change the configuration of tx pin of device 2 to input,

 

That's not full duplex.

 

In full duplex each device has a dedicated input (RX) pin and a dedicated output pin (TX). And in use you simply cross-connect them.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Ok...it's like I want to write data transfer code d make my own circuit using gpio pins.
There can be more than 2 devices...multi master multi slave configuration.

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

before re-inventing the wheel, it's good to have a solid understanding of how existing wheels work, and how they have addressed the common problems that wheels encounter ...

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

seemam wrote:
Now during program execution, if I change the configuration of tx pin of device 2 to input, it does not receive data from device 1.

you will also have to change the direction of the pin at device 1.

 

and you have to change the functions associated with those pins.

 

how do you know which one of them is not working? or that more than one thing is not working ... ?

 

 

 

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

Just look at "bit bang SPI", "bit bang I2C", "bit bang UART". Each of those is simply making 0/1 transitions on general IO pins to make the desired kind of connection.

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

seemam wrote:

...using gpio pins...multi master multi slave...

 

clawson wrote:

Just look at "bit bang SPI", "bit bang I2C", "bit bang UART"...

 

Bit bang LIN might work better for multi-master multi-slave.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

There are available protocols that can be used for this but I was just trying to do something own [an]d different.

Well if you want to do it using your own method...why aren't you? 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Thanks a lot...browsing along for bit bang gave a lot of insight

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

๐Ÿ‘Ž๐Ÿ‘Ž

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

Well, the protocol was 'different' in that the common ones actually work. The 'must work' requirement got added after implementation.