SPI Interrupt wird ZU SPÄT ausgelöst nach Sendevorgang

[Siro]

Ich will den Compiler nicht schlecht machen Klebwax,
ich weis aber und das wird sogar angezeigt, dass im "Free" Mode der Code "äußerst" ungünstig wird, so würde ich das mal nennen.

Dies ist meine Standard Meldung bei allen Projekten:

You have compiled in FREE mode.
Using Omniscient Code Generation that is available in PRO mode,
you could have produced up to 60% smaller and 400% faster code.
See http://www.microchip.com/MPLABXCcompilers for more information.

Daher ist es gut möglich, dass hier die "zusätzlichen" Zeiten kommen könnten.
400 Prozent ist doch erheblich.....

[Klebwax]

Daher ist es gut möglich, dass hier die "zusätzlichen" Zeiten kommen könnten.
400 Prozent ist doch erheblich.....

Ich kenne die Meldung. Aber "60% smaler and 400% faster" glaub ich erstmal nicht. Da müsste eher ein "or" stehen. Typisch dealt man zwischen "faster" and "smaler". Loop unroling macht den Code länger, aber schneller. Berechnungen über Tabellen zu machen ebenfalls. Für die Rechnungen mit ints oder longs Inlinecode zu verwenden oder Systemfunktionen zu callen genauso. Und die Spitzenwerte sind, wie bei Benchmarks so üblich, wirklich Spitzenwerte unter idealen Bedingungen. Der Optimizer arbeitet auch sicher im wesentlichen auf C-Ebene, das wird sich auf sowas wie eine Interrupt-Präambel kaum auswirken. Der Optimizer wird nicht plötzlich umschaltbare Registerbänke oder ähnliches entdecken.

Der XC8 ist für Microchip sicher ein Verlustgeschäft. Ohne einen funktionierenden, fehlerfreien Compiler kann man aber keine CPUs für Milliarden von $ an Profis verkaufe, sie müssen sich das also antun. Ich glaube, diese Meldung soll die professionellen Kunden, die mit den "deep pockets", dazu bringen, wenigstens einen Beitrag zur Entwicklung und Wartung des Compilers beizutragen.

MfG Klebwax

[Siro]

Ich finde der Compiler sollte umsonst sein, (logisch aus privaten Interesse natürlich )
Aber eine Verbreitung der Chips geht meiner Meinung nach auch durch Privatanwender voran,
was ich privat nutze, setzte ich dann auch in der Entwicklung in der Firma ein.
Bei mir war es zumindest so.
-----------

Zum Thema Assembler Listing:

Um ein Assembler Listing zu bekommen must Du erst etwas einstellen: ich beziehe mich auf die MPLABX-IDE

Du klickst oben im Menü
File
Project Properties

oder auch rechte Maustaste in dem Projects Fenster links.


Dann gibt es vermutlich 2 Konfigurationen
eventuell aber auch nur eine.
Dort musst Due auf Conf und dann den Unterpunkt "Loading" wählen.
Hier muss rechts in das Kästchen ein Haken rein bei "Load symbols when......

Nun musst das Projekt neu compiliert (Builded) werden.
Erst dann wird auch ein Assembler File erstellt.

Nun gehst Du oben im Menü auf
"Window" --> Debugging --> Output --> Disamply listing file


Nun sollte sich das Assembler Fenster öffnen.


Bei mir heisst die Funktion
void __interrupt isr(void)

Dann kannst Du Dir den erzeugten code anschauen.

Ich hab mal Bildchen angehangen:

[Siro]

Ich habe mal eben ein Project mit deinem PIC erstellt
und dies ist der erzeugte Assembler Code der interrupt Funktion:

unsigned char spi_reg_addr;
18:            
19:            void interrupt isr(void)
20:            {
21:                if (PIR1bits.SSPIF == 1)
0052  A69E     BTFSS PIR1, 3, ACCESS
0054  D006     BRA 0x62
22:                {
23:                    spi_reg_addr=SSPBUF;
0056  CFC9     MOVFF SSPBUF, spi_reg_addr
0058  F018     NOP
24:                    SSPBUF=0x00;
005A  0E00     MOVLW 0x0
005C  6EC9     MOVWF SSPBUF, ACCESS
25:                    RD5=0;
005E  9A83     BCF PORTD, 5, ACCESS
26:                    PIR1bits.SSPIF = 0;
0060  969E     BCF PIR1, 3, ACCESS
27:                }
28:            }
0062  C012     MOVFF 0x12, 0x1C

er sichert keine Register und ein RETFIE vermisse ich auch.
Muss man da noch was einstellen, vermutlich erscheint es nicht im Listingfile ??

[Ceos]

Der XC8 ist für Microchip sicher ein Verlustgeschäft. Ohne einen funktionierenden, fehlerfreien Compiler kann man aber keine CPUs für Milliarden von $ an Profis verkaufe, sie müssen sich das also antun. Ich glaube, diese Meldung soll die professionellen Kunden, die mit den "deep pockets", dazu bringen, wenigstens einen Beitrag zur Entwicklung und Wartung des Compilers beizutragen.

Also wenn einer Fragen zum Thema XC Compiler von Microchip hat, her damit, hatte gerade erst vor einer Woche den FAE von microchip zu Besuch bei uns und darüber intensiv unterhalten. Der XC8 ist wohl ein übernommener und ewig weiterentwickelter Compiler (der Ursprung ist mir entfallen weil es bei uns um den XC16 ging) der aber so schnell nicht sterben wird, er nannte ihn den wohl am besten optimierten Compiler.

Microchip ist eine Firma in der keine Querfinanzierung gemacht wird und daher kosten die "Fortgeschrittenen" Feature halt Geld da die Abteilung die u.a. den Compiler pflegt sich damit finanzieren muss.

Deine Behauptung das es nur für die deep-pockets ein Anreiz sein soll ist definitiv falsch. Die Optimierung kann immense Geschwindigkeitsvorteile bringen und 400% sind nicht aus der Luft. Man nehme z.B. einen Switch Case mit 30 Einträgen (ein etwas großer zugegeben aber nicht zwingend ungewöhnlich). Den kann ich mittels gewöhnlicher "If ElseIf" lösen, entsprechend langsam ist das ganze. Ich kann aber auch (Vorausgesetzt alle cases sind wertemäßig ansteigend und haben unterneinander weniger Abstand als 5) einen switch case in eine Sprungtabelle umwandlen. Das ist codemäßig kleiner als die ganzen Bedingungen und ERHEBLICH schneller!

Kommt also mehr oder minder auf die zu optimierende Funktion an, dann sind 400% absolut real!

Viele Funktionen wie "garbage collecting unused methodes" und andere code optimierungen lassen sich aber auch ohne optimierungsstufe realisieren. Schon allein damit methoden in einzelne sektionen packen zu lassen und dann hinterher im linker (hat der XC8 so nicht) dann unreferenzierte sektionen löschen zu lassen kann einen Code schnell viel kleiner machen, vor allem wenn man Softwaremodule einsetzt.
Das ist stnadradmäßig nicht an, beim atmel GCC aber schon.

[Siro]

Jetzt hab ichs, glaube ich:
Der Interrupt Vector liegt ja bei 0x0008 bzw. 0x0018
und dort ist folgender Code zu finden, nämlich der Eintritt in die Interrupt Funktion
Hier werden alle notwendigen Register gerettet, erstmal unabhängig davon ob diese benutzt werden.

0008  821B     BSF btemp, 1, ACCESS
000A  CFFA     MOVFF PCLATH, __pcstackCOMRAM
000C  F001     NOP
000E  CFFB     MOVFF PCLATU, 0x2
0010  F002     NOP
0012  CFE9     MOVFF FSR0, 0x3
0014  F003     NOP
0016  CFEA     MOVFF FSR0H, 0x4
0018  F004     NOP
001A  CFE1     MOVFF FSR1, 0x5
001C  F005     NOP
001E  CFE2     MOVFF FSR1H, 0x6
0020  F006     NOP
0022  CFD9     MOVFF FSR2, 0x7
0024  F007     NOP
0026  CFDA     MOVFF FSR2H, 0x8
0028  F008     NOP
002A  CFF3     MOVFF PROD, 0x9
002C  F009     NOP
002E  CFF4     MOVFF PRODH, 0xA
0030  F00A     NOP
0032  CFF6     MOVFF TBLPTR, 0xB
0034  F00B     NOP
0036  CFF7     MOVFF TBLPTRH, 0xC
0038  F00C     NOP
003A  CFF8     MOVFF TBLPTRU, 0xD
003C  F00D     NOP
003E  CFF5     MOVFF TABLAT, 0xE
0040  F00E     NOP
0042  C01B     MOVFF btemp, 0xF
0044  F00F     NOP
0046  C01C     MOVFF 0x1C, 0x10
0048  F010     NOP
004A  C01D     MOVFF 0x1D, 0x11
004C  F011     NOP
004E  C01E     MOVFF 0x1E, 0x12
0050  F012     NOP
00D8  0012     RETURN 0
54:

!! Die NOP s sind NICHT etwa reingebastelt um Code zu verschwenden, obwohl ich das auch am Anfangs dachte....
das ist Prozessorbedingt so bei einem Befehl MOVFF.

er kommt auch bei einem Interrupt in diesen Code rein, habe ich grad mal simuliert und das dauert dann 40 Cycles für diesen Codeabschnitt

Bei 16 MHz / 4 wegen der Pipeline Struktur = 4 MHz =250ns pro Cycle
Bei 40 Cycles also 40*250ns sind 10 us und das entspricht deinem Fehler.

Vermutlich kommt hier dann die "Optimierung" zur Geltung, wenn man eine Pro Version hat.Ich kann das leider nicht testen, habe nur die Freie VersionIch glaube man kann sich aber auch eine Pro Version Testweise runterladenIdee: Du könntest noch die PLL im Chip einschalten und die Zeit damit vierteln.
Also den internen Takt vervierfachen. Must deine SPI Einstellung vermutlich noch ändern.

[NRicola]

Hallo zusammen,

interessante Diskussion, die hier losgebrochen ist.
Aber zum Thema: Danke Siro für die Aufklärung. Den ASM-Code habe ich nun auch ausgeben und so halbwegs nachvollziehen können. Im nächsten Schritt wollte ich mich natürlich daran machen, einige Zeilen auszusparen, um zu schauen, auf welche er womöglich sogar verzichten könnte. So hatte ich versucht, Teile des C-Codes durch asm("...") zu ersetzen. Allerdings klappte das nicht so, da ich versucht hatte, es genauso anzuordnen, wie in der listing.disasm. Das bedeutet aber, dass Befehle zwischen void interrupt isr(void) und der "geschweiften Klammer auf" stehen. Das hat dem Compiler erstmal nicht so gefallen.
Aber ich habe festgestellt, wenn die Befehle dann nach der geschweiften Klammer eingefügt sind, nimmt mein Zeitverzug (immernoch der provisorische INT0-Auslöser) von 11µs auf 25µs zu. Das scheint also schon alles Hand und Fuß zu haben.

Das bringt mich natürlich dazu, das erstmal so zu akzeptieren und ich muss mal drüber nachdenken, wie ich es schaffe, damit umzugehen.
Ursprünglich war mein Ziel, dass ich ein Address-Byte über SPI übertrage und der gleich anschließend eine Antwort (z.B. Wert einer Variable) übersendet. Bei einem SCLK-Takt von 1MHz und diesem verspäteten Interrupt, wo dann SSPBUF gleich den zu übertragenden Wert der Variable hätte rein bekommen sollen, klappt das natürlich nicht. Jetzt muss ich womöglich mehrere Variablen-Anfragen verschachteln. Also so in etwa:

1. SS & SCLK aktiv, 1Byte-Adresse1 MOSI; MISO nichts
<mehr oder weniger pause>
2. SS & SCLK aktiv, 1Byte-Adresse2 MOSI; MISO Variable von Adresse 1
<mehr oder weniger pause>
3. SS & SCLK aktiv, 1Byte-Adresse3 MOSI; MISO Variable von Adresse 2
<mehr oder weniger pause>
...
<mehr oder weniger pause>
N. SS & SCLK aktiv, 1Byte-AdresseN MOSI; MISO Variable von Adresse N-1
<mehr oder weniger pause>
N+1. SS & SCLK aktiv, 1Byte Dummy MOSI; MISO Variable von Adresse N

Dieses Vorgehen wäre zwar möglich, ist aber genau dann unschön, wenn der Master auf Adressen schreiben möchte. Dann würde der µC es nicht schaffen nach der Bekanntgabe der Adresse rechtzeitig den SSPBUF leer zu machen, ehe dann auch gleich das Schreibbyte übertragen wird.

Vielleicht wäre es hier geschickter, den Master anzufassen und (bei der Kommunikation mit dem PIC18 ) eine definierte Pause zwischen dem Adress-Byte und dem Read- oder Write-Byte zu machen.

Grüß,
NRicola

[Siro]

Ich muß gestehen dass ich auch noch keine Erfahrung mit dem "Slave Mode" habe.
und stelle mir das auch etwas problematisch vor mit Bidirektionalen Betrieb.
Wenn ich ein Kommando sende und unmittelbar eine Antwort haben möchte,
bleibt dem Slave meiner Meinung nach ja keien Zeit das Kommando auszuwerten,
bzw. müste das ja dann innerhalb eines Clockzyklus erledigt sein.
Empfang auslesen auswerten und Ergenis Byte schnell genug ins Register zum Ausschieben packen.
Hier würde ich, sofern das überhaupt möglich ist, nach dem Senden eines Kommandobytes
entweder eine Pause einfügen oder einfach 1 oder mehr Dummy Bytes senden.
Dann weis der Master, z.B. dass die ersten n Rückgabebytes ignoriert werden müssen.

Vielleicht haben hier schon andere Erfahrungen mit gemacht
und können dazu etwas Info geben. Wäre für mich auch mal interessant.