PB4 for ENC28J60 ?

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

Guys,

Why can't I use PB4 for CS on ENC28J60 ?
It's working only with PB0 even I change to PB4.

Code :

#define ENC28J60_CONTROL_PORT	PORTB
#define ENC28J60_CONTROL_DDR	DDRB
#define ENC28J60_CONTROL_CS		4
#define ENC28J60_CONTROL_CS_L 	ENC28J60_CONTROL_PORT&=~(1<<ENC28J60_CONTROL_CS)
#define ENC28J60_CONTROL_CS_H 	ENC28J60_CONTROL_PORT|=(1<<ENC28J60_CONTROL_CS)

Does anyone have the same experience ?
How to rectify it ?

Thanks

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

Pb4 on what avr?
What other pins have you tried? Is there a pattern?

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

I've tried PB5 too...ATMEGA128....is there a restriction ?

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

PB0 is slave select. What does the datasheet in the spi section say specifically about the state of SS when a master?

Quote:

If SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the SS pin of the SPI slave.
If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid bus contention, the SPI system takes the following actions:

Basically - read the datasheet.

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

I set as master, but I don't want to use SS....
I'm abit confused?? because last time it was working between SDcard and VS1003.....

SDcard using PB0 and VS1003 CS using PortF

SPCR = (1<<SPE)|(1<<MSTR);
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got strange response on the browser :

ETPGETPGEC86 sal< rf""LNh>b>ETht:/w.m-tdocmh>b>ETht:/w.m-tdocm

is it because of SPI speed ? thanks

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

You need to set PB0 as an output as per the datasheet otherwise you will have problems.

The enc chip has a few defects. It can be sensitive to spi speed , but it think the problem is elsewhere. I would think if spi speed was an issue you would be lucky to send a packet.

In future read the datasheet first and do some investigation first. Pretend this forum doesn't exist and work harder to solve your problems. What do you think i do when i have a problem? For me, asking on a forum is a last resort.

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

ok, I don't understand why can't I change PB0 to elsewhere??...for example PB4, since I want to use PB0 as a chip select for SDcard and the other one for ENC28J60...

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

How can i answer such a question? You have given next to no information and done zero debugging. You havent told us at which point it goes wrong. You have a logic analyser - use it and a bit of thought to narrow down the problem. Have you even tried a debugger or simulator? If i wirked like you do, i would've been sacked years ago.

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

Quote:

ok, I don't understand why can't I change PB0 to elsewhere??..

Did you or did you not understand this point?:
Quote:
If the SS pin is driven low by peripheral circuitry when the SPI is configured as a master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it.

It is there VITAL that PB0 (or whatever SS is) must not be allowed to go low as an input. If it does the SPI in the AVR stops being a master and becomes a slave.

You also said:

Quote:
but I don't want to use SS....

That is madness - if you don't want to use SS then forget about using SPI - it's fairly vital.

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

Don't worry Cliff, he'll have another question on something different next week. I don't think he has his DHT11 working yet.

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

It's a bit like Christmas isn't it? You open all the shiny new boxes then don't know what to play with first. So you have a bit of a go with this but then get kind of bored so move to that instead... etc.

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

Kartman wrote:
Don't worry Cliff, he'll have another question on something different next week. I don't think he has his DHT11 working yet.

my DHT11 has worked already...don't worry about it mate..

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

Quote:

my DHT11 has worked already...don't worry about it mate..

No YOU should worry about it. SPI is a synchronous serial link. Each chip effectively has a state machine that (generally) clocks through 8 states as the master pulses the SCK pin. The two ends are in synchronisation so that as clock pulse 5 is pulsed the master Tx's bit 5 of that to be sent and the slave Rx's it while at the same time Tx'ing his bit 5 which the master receives. Consider now what happens if there's some electrical noise and one chip mistakenly detects what really isn't an SCK pulse. Say the slave "sees" it. It has now clocked to state 6 when the master is still back at state 5. The master will make 3 more state transitions to clock the last 3 bits but the slave already thinks it has bit 6 so will only be looking for 2.

So how do you recover form this mess?

I'll tell you how you recover. You recover by the deassertion and reassertion of slave select. It is the master's opportunity to say "I just got back to state 0 from state 7". The slave - even if he's mis-counted - can now say "oh, right, in that case I'll skip to state 0 too so we're back in sync".

Ignore SS at your peril.

Alright mate?