BASCOM Hardware SPI zu langsam!?!

[darxon69]

Hallo Leute.
Ich versuche ein Siemens S65-GLCD anzusteuern. Dies geschieht mit Hardware SPI. Um die Geschwindigkeit zu testen habe ich einfach mal die CLS-Routine die beim Display dabei war (Display3000) umgeschrieben.

Die INitialisierung des SPI schaut so aus.

Config Spi = Hard , Interrupt = Off , Data Order = Msb , Master = Yes , Polarity = Low , Phase = 0 , Clockrate = 4 , Noss = 1
Spiinit                                                     'Initializing of the SPI interface
Set Spsr.spi2x                                              'hidden parameter: doubles the speed of the SPI output

Das Display hat eine Auflösung von 132x176 Pixeln Je Pixel braucht es 2 Byte für die Darstellung, womit man 46464 Bytes zum Löschen des Bildschirms übertragen muss. Ich habe, damit es schneller geht ein ByteArray mit 128byte Länge definiert und dieses mit 255 gefüllt. Dann wird das Ganze per SPIOUT 363 mal an das Display gesendet. Das mache ich 100 mal und messe die Zeit die dafür benötigt wird. Es dauert 19 Sekunden. Das bedeutet, daß pro Bildschirmlöschen 0,19 Sekunden benötigt werden. Mein Controller (Atmega2561) arbeitet mit einer externen Takfrequenz von 14,745600 MHz.
Laut CONFIG SPI sollte der SPI-Takt dann mit 1/4 Teilung und Speedverdopplung 7,372800 MHz betragen. Rechne ich aber die CLS Geschwindigkeit (46464 Bytes in 0,19 sek =371712 bits in 0,19sek = 1956378 Bits /sek)um, sokomme ich auf einen effektiven SPITakt von 1,956378MHz. Wo geht die Geschwindigkeit verloren? Ist Bascom da so ineffektiv?

Die CLS Rountine schaut so aus und wird 100 mal hintereinander mit Call aufgerufen

Sub Lcd_cls                                                 'Clears the screen - basically just writes 132x176x2=46464 times a color value into a full frame box
Local Or_old As Byte , Lcd_h As Word
   Or_old = Orientation                                     'save orientation so we always clear screen in portrait mode
   Orientation = Portrait
   Lcd_x1 = 0
   Lcd_y1 = 0
   Lcd_x2 = 131
   Lcd_y2 = 175
   Gosub Window

   For Lcd_h = 1 To 128                                     'Array Füllen   255= Weiss
    Bigarray(lcd_h) = 255
   Next Lcd_h
                                                            'set up an array with 128 Byte , So These 128 Bytes Can Be Faster Transmitted = Quicker Cls ; More Bytes Would Speed It Up Even More
   For Lcd_h = 1 To 363                                     '132x176 pixel x 2 byte = 46464 byte needs to be transmitted = 363 x 128 bytes from the array
      Spiout Bigarray(1) , 128
   Next Lcd_h
   Set Lcd_port.lcd_cs
   Reset Lcd_port.lcd_cs
   Orientation = Or_old                                     'set back orientation to the former state
End Sub

Die "Gosub Window" routine schickt nur 8 Byte mit der Bereichsdeinition per SPI an das Display, sollte also nicht die Bremse sein.

[roboterheld]

du proggst mit Bascom nicht richtig....

mit der hardware spi kennst du dich nicht aus.

les mal das datenblatt vom atmega und display.

[darxon69]

Vom Diplay habe ich leider kein Datenblatt und an Quellen habe ich auch nur die , die Display3000 mitlieferten. Die sehen genauso aus, wie mein Beispiel, nur daß dort die Daten in 8 Byte Blöcken und nicht wie bei mir mit 128byte-Blöcken gesendet werden. Das ging noch langsamer. Ich habe also nur die anzahl der Bytes die in einem Rutsch übertragen werden erhöht. Sonst sind das die Originalquellen.

Worauf sollte ich denn Stoßen, wenn ich das Datenblatt des ATMEGA lese und wie sollte es deiner Meinung nach in Bascom richtig programmiert sein?

[linux_80]

Hallo,
nur mal so eine Vermutung,
kann es sein, dass das Fusebit CKDIV8 noch aktiv ist, das kommt mit Deiner Berechnung in etwa hin bei der Frequenz ?!

[darxon69]

Nein das ist nicht aktiv. Auf die Idee bin ich ja auch schon gekommen.
Mal davon abgesehen, daß 7372800/1956378= 3,76859 ist und das eine recht krummer Faktor ist. Ich vermute, daß Bascom da irgendwas intern nicht optimal umsetzt und unnütze Befehle macht.
Vielleicht sollte ich doch mal direkte Assemblerimplementierung für die SPI Routinen ausprobieren.

[Hanni]

Ich hab mal nen paar grundlegende Gedanke, wieso die Hardware SPI unter Bascom scheinbar so langsam ist.

Bei dem hier angesprochenen Problem wird die SPI mit halbem µC Takt betrieben. Im Klartext heißt das, dass alle 16 Takte ein Byte rausgeschoben wird.
Bedenkt man des weiteren, dass in diesen 16 Takten ein weiteres Byte bereitgestellt werden muss und die nötige Zeit für das Load / CS Signal kann es durchaus sein, das der effektive Datendurchsatz weitaus geringer ausfällt wie die hier angestrebten 7,xx MBit/s.

Grüße,
Hanni

[darxon69]

Ich hatte angenommen, daß der µC den Hardware SPI so quasi nebenbei macht, dh. die Daten aus dem SPDR raus schreibt während er weiter andere Befehle abarbeitet. Wenn das nicht so wäre und der Transfer vom Rechenkern gemanagt werden muss, wo liegt dann der Vorteil gegenüber Soft-SPI?

[Hanni]

Ich hatte angenommen, daß der µC den Hardware SPI so quasi nebenbei macht, dh. die Daten aus dem SPDR raus schreibt während er weiter andere Befehle abarbeitet.

Ist ja auch so, nur muss man eben auch zum richtigem Zeitpunkt auch neue Daten zur Verfügung stellen und genau dafür dürfte recht wenig Zeit sein.

Übrigens halte ich nicht viel von Bascom weil, mir persönlich, zuviel vor dem User versteckt wird (der "hidden parameter" ist das beste Beispiel dazu) und man nie wirklich weiß was da nun gerade passiert.

Mein Tipp: Schau einfach mal in das Datenblatt des Mikrocontrollers, da ist ein supereinfaches Assemblerbeispiel drin.

Grüße,
Hanni