Simple(?) question about SPI on ATmega

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

I am new to the SPI-on-atmega (have been using USI on tiny's before). I have a very simple question, with probably a less simple answer (can't find it...)

I am debugging a SPI problem and it strikes me that MOSI is idle HIGH. I have no pull up resistors on the MOSI line, only a 33k resistor to a transistor to a led (for monitoring, just like some other outputs).

The led goes on as soon as I enable SPE in SPCR, iow as soon as SPI is enabled. I am quite aware that I loose the normal output function of the port, but I don't expect it to be idle HIGH.

I am also aware that the state of the MOSI line is only really valid during clock transition.

I already did a loop-back test (mosi to miso) and that seems to work though.

Still it's strange. Is this expected behaviour?

Thx.

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

I'd say "yes". In the datasheet, the timing diagrams e.g. "Figure 19-3. SPI Transfer Format with CPHA = 0" seem to indicate MOSI "idling high".

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.

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

SPI does not use pull-up resistors (different from TWI/I2C). MOSI is hard-driven by an output pin on the master; after all, MOSI = Master Out Slave In. MISO is hard-driven by an output pin on the selected slave; when no slave is selected, it floats.

When SPE is enabled, then the SPI module takes over the MOSI pin. When it is NOT enabled, it does what ever that port pin is programmed to do.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

ka7ehk wrote:
MISO is hard-driven by an output pin on the selected slave; when no slave is selected, it floats.

And that is not what I see, it's outputting 3.3V.

Anyway, with loopback it does seem to work, so apparantly it's not a problem.

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

It floats IF the port pin is set to be an input. If it is an output, then it will be the state set by that pin.

I would not set the MISO pin as an output. There is no strong technical reason for saying this; its just that I don't like a pin that is supposed to be an input at some times to NOT be an input at other times unless there is a really, really, compelling reason to do otherwise.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Now the next step, which is driving me crazy, maybe some of you can help.

I have a enc28j60 attached. I am only at the very first step interfacing with it and already it's not working. Maybe it's something very simple.

The spi io is simply not returning the data it should from the enc. Reading a very simple register gives illegal bit values. The enc only returns 0xff for dummy values (miso is hi-z) or 0xfa, i've seen no other values.

As said before loopback tests are okay (miso connected to either +, GND or mosi give expected values).

What doesn't help, is that DebugWire doesn't appear to work well in combination with SPI. First you need to disconnect miso/mosi/sck from/to the avrdragon, but leave gnd/vtg/reset in place. It appears the avrdragon doesn't completely release these lines :-(

But more important, this line:

while(!(SPSR & _BV(SPIF)))
(void)0;

(waiting for SPI to complete) works normally, but doesn't work while in DebugWire mode. As soon as you run the program in a debugger this will loop forever. Take it off the debugger and it works.

Unfortunately I only have a very basic oscilloscope. I can see all SPI lines doing things that look like I expect them to do, but that's the limit, it cannot analyze spi.

Anyone have smart ideas to workaround this?

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

ka7ehk wrote:
It floats IF the port pin is set to be an input. If it is an output, then it will be the state set by that pin.

I would not set the MISO pin as an output. There is no strong technical reason for saying this; its just that I don't like a pin that is supposed to be an input at some times to NOT be an input at other times unless there is a really, really, compelling reason to do otherwise.


I was talking about MOSI...

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

Quote:

I would not set the MISO pin as an output.

If you are the master, and intend to stay the master, then it is irrelevant.
Quote:
Table 19-1. SPI Pin Overrides

Quote:
Chicolini: Now I aska you one. What has a trunk, but no key, weighs 2,000 pounds and lives in a circus?

Prosecutor: That's irrelevant.

Chicolini: Irrelephant? Hey, that'sa that answer. There's a whole lot of irrelephants in the circus.

[One could ask why I can remember quotes from 80-year-old movies, but forget where I just set down my coffee cup...]

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.

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

theusch wrote:
[One could ask why I can remember quotes from 80-year-old movies, but forget where I just set down my coffee cup...]
That just means you fit in with the rest of us... ;)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

BTW the real problem has been solved. It was a broken PCB lane on the enc28j60 breakout board (mosi) :-/ The enc never got anything useful from the mcu. It works now!