[AVR] Mode2+3 SPI und aktuelle AVRs

[Blubber1 (Gast)]

Guten Abend,

beim ATTiny84 hab ich festgestellt, dass das ehemalige SPI-Interface zur 
USI umgebaut wurde. Dummerweise kann man die Clock-Polarität jetzt nicht 
mehr ändern, weshalb Mode2+3 weg fallen.

Die Frage die sich mir jetzt stellt: Muss man extern den Clock 
invertieren für Mode2+3-Peripherie wie die 128x64 COG-Displays?

Clock per Software stelle ich mehr unangenehm ineffizient vor ...

Viele Grüße
Blubber1

[Blubber1 (Gast)]

Eine Frage, die für die geballte Fachkompetenz des Forums zu schwierig 
ist? xD

[c-hater (Gast)]

Blubber1 schrieb:

> beim ATTiny84 hab ich festgestellt, dass das ehemalige SPI-Interface zur
> USI umgebaut wurde.

Das ist Bullshit, der dich als Mann ohne Überblick outet.

Bei den ollen Tinys gab es noch nie ein Hardware-SPI, sondern immer nur 
USI. Wenn es denn überhaupt irgendeine Hardwareunterstützung für 
seriellen Zauber gab, etliche Devices haben nichtmal das USI...

Bei einigen wenigen neueren Tinys ist das allerdings anders. Z.B. ATtiny 
441/841. Die haben nicht nur das klassische Hardware-SPI, was du (wohl 
von den ATmegas) kennst, sondern auch SPI-Master-fähige USARTs, wie es 
sie ebenfalls bei den (neueren) ATmegas gibt. Damit kann man schon was 
anfangen...

> Dummerweise kann man die Clock-Polarität jetzt nicht
> mehr ändern, weshalb Mode2+3 weg fallen.

Du hast das USI und seine Möglichkeiten ganz offensichtlich nicht 
wirklich verstanden. Lies' am besten nochmal das Datenblatt!

[Pappnase (Gast)]

Besorge Dir mal die AppNote AVR319 und siehe es Dir an. Vielleicht 
klingelts dann.

mfg

[Johnny (Gast)]

c-hater schrieb:
> Bei einigen wenigen neueren Tinys ist das allerdings anders. Z.B. ATtiny
> 441/841. Die haben nicht nur das klassische Hardware-SPI, was du (wohl
> von den ATmegas) kennst, sondern auch SPI-Master-fähige USARTs, wie es
> sie ebenfalls bei den (neueren) ATmegas gibt. Damit kann man schon was
> anfangen...


Naja, sicherlich kann man darüber streiten, was "neuer" heißt, aber ich 
denke, die Mehrheit würde z.B. einen 10 Jahre alten ATmega644P nicht als 
neuer bezeichnen, auch wenn er neuer als ein ATmega8515 ist...

[Blubber1 (Gast)]

c-hater schrieb:
>> Dummerweise kann man die Clock-Polarität jetzt nicht
>> mehr ändern, weshalb Mode2+3 weg fallen.
>
> Du hast das USI und seine Möglichkeiten ganz offensichtlich nicht
> wirklich verstanden. Lies' am besten nochmal das Datenblatt!

Hab ich ... Es gibt keinen Bit, das äquivalent zu CPOL ist, wie es die 
AVRs mit SPI-Peripherie hatten ...

Über Erleuchtung würde ich mich freuen :)

[Blubber1 (Gast)]

Pappnase schrieb:
> AVR319

Das war ein kurzes Lesevergnügen ... Seite 1: "Supports SPI Mode 0 and 
1"

[Blubber1 (Gast)]

Aber zurück zur eigentlichen Frage ... Reicht es den Clock einfach 
extern zu invertieren, wenn ich z.B. ein LCD, das nur Mode2+3 kann, an 
den Tiny anschließen möchte?

[Pappnase (Gast)]

Blubber1 wrote:
> Das war ein kurzes Lesevergnügen ... Seite 1: "Supports SPI Mode 0 and
> 1"

Vielleicht schaffst Du es ja irgendwann einmal bis Seite 5.
Die Datei avr319.zip enthält im Übrigen ein Codebeispiel.

[Blubber1 (Gast)]

Pappnase schrieb:
> Vielleicht schaffst Du es ja irgendwann einmal bis Seite 5.
> Die Datei avr319.zip enthält im Übrigen ein Codebeispiel.

Hör bitte auf, meine Zeit damit zu verschwenden ... Auf Seite 5 stehen 
die SPI-Modes, die allgemein bekannt sind - mir auch.

Die USIs des Tinys HABEN KEIN CPOL BIT!

Von Seite 6:"The USI Three-wire mode is compliant with the Serial 
Peripheral Interface (SPI) Mode 0 and 1, "


Wenn du keine Ahnung hast, dann brauchst du auch nicht antworten ...

[Blubber1 (Gast)]

Auch dein hochgelobtes Code-Beispiel unterstützt nur Mode 0 und 1:

/* Test application for the SPI-via-USI-driver. */

#include "spi_via_usi_driver.c"



#define SPIMODE 0  // Sample on leading _rising_ edge, setup on trailing _falling_ edge.
//#define SPIMODE 1  // Sample on leading _falling_ edge, setup on trailing _rising_ edge.



void main()
{
  unsigned char val = 0;    // Temp value to send.
  DDRB = 0xFF;      // Set PORTB to all output.
//  spiX_initmaster(SPIMODE);  // Init SPI driver as master.
  spiX_initslave(SPIMODE);  // Init SPI driver as slave.
  __enable_interrupt();    // Must do this to make driver work.
  do {
    spiX_put( val++ );  // Send temp value to SPI and increment,
    spiX_wait();    // wait for transmission to finish
    PORTB = spiX_get();  // and finally put result on PORTB.
  } while(1);      // Loop forever...
}