-         

Ergebnis 1 bis 8 von 8

Thema: BASCOM Hardware SPI zu langsam!?!

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    09.11.2005
    Ort
    Ichtershausen
    Alter
    48
    Beiträge
    148

    BASCOM Hardware SPI zu langsam!?!

    Anzeige

    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.

    Code:
    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
    Code:
    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.

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    29.07.2007
    Beiträge
    386
    du proggst mit Bascom nicht richtig....

    mit der hardware spi kennst du dich nicht aus.

    les mal das datenblatt vom atmega und display.

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    09.11.2005
    Ort
    Ichtershausen
    Alter
    48
    Beiträge
    148
    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?

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    22.05.2005
    Ort
    12°29´ O, 48°38´ N
    Alter
    48
    Beiträge
    2.731
    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 ?!

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    09.11.2005
    Ort
    Ichtershausen
    Alter
    48
    Beiträge
    148
    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.

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    30.07.2005
    Beiträge
    569
    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
    Grundregeln des Forenpostings:
    1. Nutze niemals die Suchfunktion!
    2. Überprüfe niemals die Topics nach Ähnlichkeiten!
    3. Schreibe alles in hellgelb!

  7. #7
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    09.11.2005
    Ort
    Ichtershausen
    Alter
    48
    Beiträge
    148
    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?

  8. #8
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    30.07.2005
    Beiträge
    569
    Zitat Zitat von 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.
    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
    Grundregeln des Forenpostings:
    1. Nutze niemals die Suchfunktion!
    2. Überprüfe niemals die Topics nach Ähnlichkeiten!
    3. Schreibe alles in hellgelb!

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •