ATmega als "Ersatz" für MAX7219

Martin Schenk schrieb:
> Kann ich da einfach den ATmega ZUSÄTZLICH mit dranhängen?

Ja, er muss halt ein SPI-Slave sein und SPI so interpretieren, wie es 
der Siebensegmenttreiber auch tut (d.h. Du musst auf Taktpolarität und 
LSB/MSB-Reihenfolge achten).

Beispielcode dürftest Du mit dem Stichwort "SPI-Slave" finden können.

Hängt davon ab, wie schnell das SPI ist.
Das AVR-SPI ist recht geizig gepuffert. Wenn die beiden MAX kaskadiert 
sind, muß er je 4 Bytes am Stück lesen können. Ist der SPI-Takt zu 
schnell, schafft er das nicht.

Martin Schenk schrieb:
> Bin totaler SPI noob :(

Schon mal hier geschaut?
http://www.mikrocontroller.net/articles/Serial_Peripheral_Interface
http://maxembedded.com/2013/11/the-spi-of-the-avr/

Sind es nur Ziffern, müßten 5 Segmente reichen.
Der Multiplextakt (max 1,3kHz) ist ja konstant, es reicht also ein 
Synchronsignal, was man dann mit dem Timerinterrupt unterteilt.
Dann sollten 12 Inputs reichen.

Mit SPI ist eh tricky, da man nicht weiß, ob das Latchsignal nur am Ende 
erfolgt und man für 2 Latchsignale nur einen /SS-Pin hat.

@ MCUA (Gast)

>Da sieht man, wie bekloppt das AVR-SPI ist.

Nobody is perfect. Da der AVR sowieso nix besseres zu tun hat, kann er 
das SPIIF Flag auch pollen, das geht sehr schnell. Dann klappt das auch 
mit einer schnelleren Übertragung. Ausserdem haben die neueren AVRs 
einen UART, der im SPI-Mode laufen kann, man bräuchte hier also einen 
größeren AVR mit 2 UARTs. Oder man sendet die Daten mit einem Soft-UART, 
das ist auch eher unkritisch.

Zusätzlliche Hardware ist zwar möglich, aber eher uncool, zuviel 
Aufwand.
Man kriegt das mit dem AVR in Software hin.

Beitrag "LCD Extender"

Das geht sogar in C ziemlich schnell ;-)

Martin Schenk schrieb:
> Die Leitung die am MAX7219 zu DIN geht muss am ATmega dann an MOSI,
> oder?

Ja.

> Was mache ich mit den LOAD Leitungen?

An einen beliebigen Eingangs-Portpin.
Ebenso CS an einen Eingangs-Portpin.

> Und was ist mit CLK?

An den SCK-Pin.

Falk B. schrieb:
> Man kriegt das mit dem AVR in Software hin.

Besser als Software müsste es sein, wenn man einen Controller hat,
der die SPI per DMA auslesen kann.  Sollte eigentlich schon ein
Xmega können oder ein kleiner ARM halt.

MCUA schrieb:
> Auch der Xmega (mit DMA) hat da kein reibungslosen Ablauf, weil auch
> dort der betr. Buffer fehlt! (DMA ersetzt nicht diesen Buffer)

Bei DMA benutzt du den RAM als Puffer.

Bist du etwa der Meinung, der SPI-Modul dort hätte das Schieberegister
direkt als Datenregister?  Nein, das sind schon zwei getrennte, man
kann also das Datenregister (so gesehen ein einstufiger Puffer) lesen,
während das nächste Byte reingetaktet wird.  Man muss es halt nur
gelesen haben, bevor die nächsten 8 Taktimpulse vom Master durch
sind.

MCUA schrieb:
> nein, es ist eben kein Puffer!

Woran definierst du einen solchen?

MCUA schrieb:
> Nochmal

Nochmal: was ist für dich ein “buffer” in diesem Zusammenhang?

Selbstverständlich hat der SPI-Empfänger im AVR (und Xmega) einen
solchen, ob du das nun wahrhaben willst oder nicht.  Inwiefern man
die Behauptung des Datenblatts:

1

The system is single buffered in the transmit direction and double buffered in the receive direc-

2

tion.

nun teilen mag oder als Marketinggeschwätz abtut, ist Ansichtssache.
Für mich wäre es eher ungepuffert in Senderichtung und einfach
gepuffert in Empfangsrichtung.  Die nächsten Sätze dokumentieren
das dann aber ziemlich klipp und klar:

1

 This means that bytes to be transmitted cannot be written to the SPI Data Register before

2

the entire shift cycle is completed. When receiving data, however, a received character must be

3

read from the SPI Data Register before the next character has been completely shifted in. Oth-

4

erwise, the first byte is lost.

Damit kann man im Zusammenhang mit DMA (beim XmegaA) auf jeden Fall
beliebig lange Bytefolgen erstmal in den RAM gelesen bekommen ohne
zu riskieren, dass ein Byte verloren geht.

SPI-Antwortverhalten ist bei einem Software-Slave natürlich immer
noch ein anderes Problem, aber das steht ja in diesem Falle hier
gar nicht.

AVRs ersetzen halt die ehere magere Peripherie durch einen (für 
8-Bitter) ziemlich potenten Prozessor.
Bei dem TO würde ich locker 20€ verwetten, dass ein AVR (zumindest wenn 
der Programmierer kein Idiot ist) das SPI spielend "mitlesen" kann ohne 
eine FIFO oder so einen Kram (allein die mehreren Meter Kabel diktieren 
schon eine langsame Taktrate).

MCUA schrieb:
> Das stand früher so da, was klar falsch ist. Nun haben die es verbessert
> (nur den Satz im DB, aber nicht das Interface!).

Im Datenblatt des ATmega328PB (*) steht das nach wie vor genauso.
Updated: 10/2015.

(*) Einer der neuesten AVRs, schätzungsweise ja auch einer der letzten –
der ATtiny104 ist neuer, hat aber keinen SPI-Slave.

Wie ist es denn deiner Meinung nach?  Womit hast du das getestet?

@ MCUA (Gast)

>bekloppt ist aber mehr als 'nicht perfekt'
>selbst ein STM8 für 0,25eu hat da Buffer!

Bla. Daß der AVR hier eine Schwäche hat ist bekannt. So what!
In diesem Fall ist das durch Knoff Hoff kompensierbar!
Man könnte es auch eine Herausforderung nennen.

>pollen ist norm. die allerschlechteste Lösung.

Hier ist es schlicht ausreichend und voll OK. Siehe mein LCD-Expander.

>Auch der Xmega (mit DMA) hat da kein reibungslosen Ablauf, weil auch
>dort der betr. Buffer fehlt! (DMA ersetzt nicht diesen Buffer)

Quark. Du kannst das SPI vom ATXmega im Slave Modus mit bis zu 1/4 F_CPU 
dauerhaft mit Daten füttern, es wird bei DMA-Nutzung KEINERLEI Daten 
verschlucken. Und das bei 0% CPU-Last. Reicht das?

MCUA schrieb:
> und was nat. die völlige Unzulänglichkeit dieses Interfaces zeigt.

Oben hast du noch stock und steif behauptet, es wäre in
Empfangsrichtung absolut ungepuffert und daher völlig unzulänglich.

Ja, die Aussagen sind wischiwaschi, ich würde sie in Empfangsrichtung
auch als einfach gepuffert bezeichnen.  Das ist aber ein großer
Unterschied zu ungepuffert: Wenn in Empfangsrichtung das Schieberegister
nicht nochmal gepuffert ist, kann man in der Tat nicht garantieren,
dass da kein Datenverlust eintritt.  Es ist aber gepuffert (Schiebe-
und Datenleseregister sind getrennt).  Damit kann man auch
„Rücken-an-Rücken“-Daten lesen, sofern die CPU es schafft, innerhalb
eines Bytes das vorherige abzuspeichern, die Zeiger zu erhöhen und
das Ende der Transaktion zu testen.  (Bei DMA geht dies alles ohne
CPU.)

Dass es in Senderichtung nicht nochmal gepuffert ist, bedeutet
lediglich, dass man keine „Rücken-an-Rücken“-Daten raussenden kann,
da zwischen den Bytes noch eine kleine Denkpause nötig ist (Flag
pollen, danach Senderegister neu laden).  Das ist aber nun alles andere
als „völlig unzulänglich“.

@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite

>und Datenleseregister sind getrennt).  Damit kann man auch
>„Rücken-an-Rücken“-Daten lesen, sofern die CPU es schafft, innerhalb
>eines Bytes das vorherige abzuspeichern, die Zeiger zu erhöhen und
>das Ende der Transaktion zu testen.

Da man so oder so max. 1/4 CPU Takt als SP-Takt verwenden kann (Slave 
mode!), hat die CPU min. 32 Takte dafür Zeit.
Das reicht locker. Zumal sie sinnvollwerweise per Interrupt sofort auf 
eine fallende FLanke des SS Signal reagiert und dann dort in einer 
Polling-Schleife die Daten einliest.

>Dass es in Senderichtung nicht nochmal gepuffert ist, bedeutet
>lediglich, dass man keine „Rücken-an-Rücken“-Daten raussenden kann,
>da zwischen den Bytes noch eine kleine Denkpause nötig ist (Flag
>pollen, danach Senderegister neu laden).

Und selbst das hat keinen davon abgehalten, ein Videoterminal in 
Software mit dem AVR zu generieren. Wahnsinn!!
Und die GANZ GROßEN Könner haben sogar richtig gute Animationen + 
Midi-Sound generiert.
Oder die diversen Mini-Spielkonsolen.

Das andere Ende des Leistungsspektrums verlegt sich halt auf seine 
Kernkompetenz des Jammerns und Meckerns.
Auch Fußpilz hat seine göttliche Daseinsberechtigung ;-)

Ist jetzt mal gut mit dem Atmel Bashing? Du widerholst Dich. Wer Double 
Buffer für seine Anwendung braucht, nimmt das UART im SPI-Modus und 
fertig. Damit kann man ebenfalls lückenlos senden und empfangen.

MCUA schrieb:
>>Oben hast du noch stock und steif behauptet, es wäre in
>>Empfangsrichtung absolut ungepuffert und daher völlig unzulänglich.
> Nein, hab ich nicht.
> Ich sagte, es hat keinen Buffer. Nicht, es hat keinen RX-Buffer.

Den TS interessiert aber nun mal nur eine Bufferung in RX-Richtung. 
Können wir uns darauf einigen, dass seine Anwendung mit dem ATmega-SPI 
problemlos möglich ist?

Gruß, Stefan

Stefan K. schrieb:
> Können wir uns darauf einigen, dass seine Anwendung mit dem ATmega-SPI
> problemlos möglich ist?

Nein.
Wir kennen das Timing nicht und ob überhaupt das notwendige /SS anliegt.
Oft wird für das LOAD nur eine kurzer 0-1-0 Puls erzeugt.

Und da es 2 nicht kaskadierte MAX7219 sind, müßte er die beiden LOADs 
noch irgendwie verwursten.
Man könnte die beiden LOADs auf Interrupts legen und der AVR erzeugt 
dann sein /SS selber über einen Output-Pin.
In der Hoffnung, daß nach jedem LOAD genügend lange gewartet wird, um in 
den Interrupt zu springen.

Wenn ich mir aber mal meinen MAX7221 Code ansehe, sende ich immer alle 8 
Digits am Stück ohne Pause.
Z.B. 3 MAX7221 kaskadiert:

1

void max7221_update()                           // need about 220µs @ 4MHz SPI clock 

2

{

3

  max7221_init();

4

  for( uint8_t i = 1; i < 9; i++ ){             // Digit 1 .. 8

5

    xMAX7221 = 0;

6

    max7221_out( i );

7

    max7221_out( display_data[i-1] );           // 1. MAX2771

8

    max7221_out( i );

9

    max7221_out( display_data[i+7] );           // 2. MAX2771

10

    max7221_out( i );

11

    max7221_last_out( display_data[i+15] );     // 3. MAX2771

12

    xMAX7221 = 1;

13

  }

14

}

Peter D. schrieb:
> Wir kennen das Timing nicht und ob überhaupt das notwendige /SS anliegt.

Das ist allerdings ein völlig anderes Paar Schuhe dann.  Damit
wird man mit so ziemlich jeder MCU als Slave Probleme bekommen,
denn die wollen alle ein slave select haben, bevor die SPU unit
lostickt.  Ist halt nicht einfach nur ein Schieberegister.

Nur so als Schnapsidee: Einen Xmega nehmen, /SS ständig auf low,
Einlesen per DMA, mit dem Ladeimpuls ein Event generieren, welches
das zuletzt eingelesene SPI-Byte dann weiterverarbeiten lässt.

Wieder mal einen "schöne" akademische Diskussion. Sollte man nicht erst 
einemal die REALEN Verhältnisse am Gerät MESSEN? Ein Oszi oder Logic 
Analyzer bringt in Minuten Klarheit. Danach kann man weiter 
philosopieren.

Falk B. schrieb:
> Sollte man nicht erst
> einemal die REALEN Verhältnisse am Gerät MESSEN?

Ich vermute mal, der TE hat nichts dafür geeignetes an Messgeräten.

Sonst hätte er ja schon vor dem Thread mal messen können. ;-)

m.n. schrieb:
> Er hat doch einen ATmega, mit dem er auch hinreichend genau messen und
> per UART den Wert ausgeben kann.

Den von Peter genannten kurzen Spike zur Übernahme der Daten in ein
Schieberegister findest du damit nicht.

Nein, ein ATmega taugt für manches, aber nicht als LA-Ersatz. ;-)