Is it possible to re-use MISO as GPIO with hardware SPI enabled? tinyAVR®1-Series

Log in or register to post comments
Go To Last Post
8 posts / 0 new
Author
Message
baxsie
baxsie's picture
Level: Rookie
Joined: Sun. Mar 23, 2003
Posts: 24 View posts
#1
Posted by baxsie: Thu. Aug 30, 2018 - 06:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a ATtiny412 that I am using to talk to a "listen only" SPI device. Tthe ATtiny412 is the SPI master, and I need it to control SCK and MOSI, but I do not want to use MISO for SPI.

 

I got the hardware SPI working by using the thread here: https://www.avrfreaks.net/forum/...

 

However, that code takes over the PA2 pin to dedicate it to MISO and I it does not appear that I can regain control of it.

 

Is that just a fact of life or is there a clever way to regain control of that pin?

 

I have software SPI written and working, it just seems a shame to not be able to use the hardware SPI :-(

 

Thanks for any help you can offer.

 

ATtiny212 ATtiny214
ATtiny412 ATtiny414 ATtiny416 ATtiny417
ATtiny814 ATtiny816 ATtiny817
ATtiny1614 ATtiny1616 ATtiny1617

This topic has a solution.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, #SPI #MISO, solved, #ATtiny212 #ATtiny214 #ATtiny412 #ATtiny414 #ATtiny416 #ATtiny417 #ATtiny814 #ATtiny816 #ATtiny817 #ATtiny1614 #ATtiny1616 #ATtiny1617
Last Edited: Thu. Aug 30, 2018 - 11:16 PM
Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40129 View posts
Location: Wisconsin USA
Posted by theusch: Thu. Aug 30, 2018 - 07:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

baxsie wrote:
but I do not want to use MISO for SPI.

I think you are stuck; the datasheet says it twice (once in the table).

 

When the SPI module is enabled, the data direction of the MOSI, MISO, SCK, and SS pins is overridden
according to Table 25-1.
The data direction of the pins with "User defined" pin configuration is not controlled by the SPI: The data
direction is controlled by the application software configuring the Port peripheral. If these pins are
configured with data direction as input, they can be used as regular I/O pin inputs. If these pins are
configured with data direction as output, their output value is controlled by the SPI. The MISO pin has a
special behavior: When the SPI is in slave mode and the MISO pin is configured as an output, the SS pin
controls the output buffer of the pin: If SS is low, the output buffer drives the pin, if SS is high, the pin is
tristated.
The data direction of the pins with "Input" pin configuration is controlled by the SPI hardware.
 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
Greg_Muth
Greg_Muth's picture
Level: Posting Freak
Joined: Sat. Dec 13, 2014
Posts: 1209 View posts
Location: Portland, OR, US
Posted by Greg_Muth: Thu. Aug 30, 2018 - 07:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

With the USART in MSPI mode, the Rx and Tx are individually enabled/disabled, so you should be able to use Rx (MISO) for whatever. 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

Top
baxsie
baxsie's picture
Level: Rookie
Joined: Sun. Mar 23, 2003
Posts: 24 View posts
Posted by baxsie: Thu. Aug 30, 2018 - 09:31 PM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

Thanks for the replies.

 

theusch: That was the way I was reading it. Just hoping I was missing something.

 

Greg_Muth: OK, that is an interesting idea. Unfortunately, I can't get it USART in MSPI going. Here is my init so far:

 

   //All pins set to output above

   USART0.CTRLA =  0x00;
   USART0.CTRLB =  USART_TXEN_bm;
   USART0.CTRLC = USART_CMODE_MSPI_gc;
   //0x0100 = 2.5MHZ
   //0x0080 = 5MHZ 
   //0x0040 = 10MHZ (apparently the max)
   USART0.BAUD = 0x0100;

 

When I send data:

 

_delay_us(1);
USART0.TXDATAL=data;
_delay_us(4);

 

The XCK acts predictably, pumping out blocks of 8 clocks, but the MOSI remains at 0.

 

1) Is there some " tinyAVR®1-Series" USART in MSPI sample code that I am missing?

 

2) Is there something obvious / stupid in that code fragment?

 

Thanks for any help or suggestions you can offer.

Top
balisong42
balisong42's picture
Level: Hangaround
Joined: Fri. Mar 20, 2009
Posts: 299 View posts
Location: Seattle, WA, USA
Posted by balisong42: Thu. Aug 30, 2018 - 09:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's pretty subtle, but looking at the IO chart in the datasheet, the USART signals are in a different font, indicating alternate pins. Try setting the USART0 bit in PORTMUX.CTRLB to select the alternate pinout. Although, this wouldn't explain why the clock signal already work.

Top
baxsie
baxsie's picture
Level: Rookie
Joined: Sun. Mar 23, 2003
Posts: 24 View posts
This reply has been marked as the solution. 
Posted by baxsie: Thu. Aug 30, 2018 - 09:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

balisong42: You nailed it!

 

  //Enable the port mux to allow the USART to talk
  PORTMUX.CTRLB=PORTMUX_USART0_ALTERNATE_gc;
  USART0.CTRLA =  0x00;
  USART0.CTRLB =  USART_TXEN_bm ; //| USART_RXEN_bm;
  USART0.CTRLC = USART_CMODE_MSPI_gc;
  //0x0100 = 2.5MHZ
  //0x0080 = 5MHZ
  //0x0040 = 10MHZ (apparently the max)
  USART0.BAUD = 0x0040;

 

This appears to give me 10MHz SPI output on MOSI and still have GPIO control of MISO.

 

Thanks folks. I really appreciate the help.

Last Edited: Thu. Aug 30, 2018 - 09:58 PM
Top
Simonetta
Simonetta's picture
Level: Raving Lunatic
Joined: Wed. Mar 12, 2003
Posts: 3079 View posts
Location: Portland, Oregon USA
Posted by Simonetta: Fri. Aug 31, 2018 - 01:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SPI interface receives a serial byte on the MISO line every time that a serial byte is output on the MOSI line.  So every write to SPI  is going to have the SPI external device toggling its MISO line.  If you use MISO as GPIO, then the external SPI device might have an electrical logic contention (one side pulls high, the other side pulls low, the resulting signal often is Vcc/2) if it is connected.  If the external device's MISO is not connected to the AVR MISO, then with each byte sent by the SPI, the SPI data input register will have eight bits of the logic level on the GPIO pin that is using MISO.

Top
baxsie
baxsie's picture
Level: Rookie
Joined: Sun. Mar 23, 2003
Posts: 24 View posts
Posted by baxsie: Fri. Aug 31, 2018 - 05:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta: Thank you for your reply. In this case, the device can only be talked to.  There is no MISO line on the device. So even though the SPI subsystem is clocking _something_ into the receive buffer, I do not care what it is and do not read it.

 

My issue was that I intended to (and have a PCB with taces to back up that intention) use the AVRTiny's MISO pin to do some other work on the board. So I need control or the MISO pin as a GPIO.

 

Using the hardware SPI, this is impossible. By using the USART in MSPI mode (as Greg_Muth suggested), I can control the otherwise unused MISO pin as GPIO.  

Top