deprecated chip select?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. use atmega hw-spi
2. have 1-wire bus on PB2

What is the expected output? What do you see instead?
working 1-wire and OLED

At first: I just finished my PCB, so changes in HW are quite a challange :)

Im using an ATmega328p (no Arduino) with a SSD1325 with this constructor:

u8g_InitHWSPI(&display, &u8g_dev_ssd1325_nhd27oled_gr_hw_spi, PN(PORT3, PIND5), 
PN(PORT3, PIND4), PN(PORT3, PIND6));

(PORT3 should be PORTD, right?)

If I comment this line, my 1-wire bus works, but when I use the OLED, the bus 
is pulled high, immediately after the "presence" signal (the slave pulls the 
line down).
So I searched the lib for any pin manipulation on PB2 and found this:
DDRB |= _BV(2);     /* slave select */
(u8g_com_atmega_hw_spi.c, line 100)

Commeting this line does not solve my problem, so there must be some more lines 
like this. Btw, is this just deprecated or is this really neccessary?

Thanks for any idea/help and of course the great lib!

Original issue reported on code.google.com by bad...@gmail.com on 16 Oct 2013 at 4:01

[GoogleCodeExporter]

1-wire means SPI, correct?
PORT3 must be a definition in C. It should evaluate to 3, which would be port D

With the ATMEGA there was an issue with the chip select line. In principle it 
is hard to use the CS for something else.

At least for testing, i also suggest to use SW SPI for a while. It will treat 
the pins as normal IO pins without problems regarding the CS line.

Original comment by olikr...@gmail.com on 16 Oct 2013 at 5:12

[GoogleCodeExporter]

See ATmega328P datasheet, rev. D, page 171 (SS Pin Functionality). In short:

The SS pin can set the AVR's hardware SPI to slave mode IF it's configured as 
an input AND pulled low by an external device or the AVR itself. Your 1-Wire 
device will do that when you communicate with it. So you cannot use 1-wire and 
hardware SPI at the same time (!).

What you can do is: Use the hardware SPI to communicate with the display, do 
1-wire stuff (that will set the hardware SPI to slave mode), set the SPI to 
master mode again. Then you can talk to the display again. If you have the SPI 
interrupt enabled, things will get a bit more complicated.

Using the SS pin for 1-wire was a very unfortunate choice!

Original comment by avrbegin...@googlemail.com on 16 Oct 2013 at 6:44

[GoogleCodeExporter]

@ Oli:
No, 1-Wire is a proprietary protocol from Dallas Semi. You need just one pin 
for the whole communication and sometimes its also for power, too.
So I tought I just map the CS for OLED to any IO of my AVR and the 1-Wire 
pin... Software-SPI is my next try. 

@ AVRbeginer:
Thanks for explanation! Now it seems reasonable that the communication stops 
after the presence signal. So it has nothing to do with this lib - its just my 
stupid fault.

I will try SW-SPI, if this is too slow (need at least 5 FPS), I will try 
avrbeginner's idea or really need to change the HW, what a fun with TQFP :D

Thanks you both a lot!

Original comment by bad...@gmail.com on 16 Oct 2013 at 7:35

[GoogleCodeExporter]

closing this...

Original comment by olikr...@gmail.com on 22 Jan 2014 at 8:04

• Changed state: Done
• Added labels: Milestone-1.15, Type-Other
• Removed labels: Type-Defect