while (!(hri_sercomspi_read_INTFLAG_reg(SERCOM1) & SERCOM_SPI_INTFLAG_RXC))
15
16
gpio_set_pin_level(DAC_CS,true); // CS wieder auf HIGH setzen
Was ich erwarten würde, was passiert:
- CS-Leitung geht auf LOW
- ich sehe 24 Clock-Pulse auf der SPI-Taktleitung
- CS-Leitung geht auf HIGH
Was statt dessen passiert:
- CS-Leitung geht auf LOW
- für ca 220 nsec passiert nichts
- ich sehe 17 Clock-Pulse auf SCLK
- CS geht auf HIGH
- es kommen die fehlenden 7 Clock-Pulse
Also scheint da mit meiner Synchronisation was nicht zu stimmen? Mit
welchem Registerbit überwache ich denn wirklich, ob alle Datenbits
gesendet wurden? RXC scheint es ja nicht zu sein...
Danke!
TXC macht es nur anders aber nicht besser. Dann ist das Ergebnis
- CS geht auf LOW
- ca 22 nsec nichts
- 8x SCLK
- ca. 550 nsec nichts
- 8x SCLK
- ca 550 nsec nichts
- 6x SCLK
- CS geht auf HIGH
- 2x SCLK
Zwischen den Bytes brauchst du kein TXC benutzen, da genügt DRE.
Ansonsten hat TXC für uns seinerzeit funktioniert (auf einem SAMR21,
aber das ist letztlich ein modifizierter SAMD21 mit einem AT86RF233
drüber gestapelt).
while (!(hri_sercomspi_read_INTFLAG_reg(SERCOM1) & SERCOM_SPI_INTFLAG_TXC))
17
18
gpio_set_pin_level(DAC_CS,true); // CS wieder auf HIGH setzen
19
}
dann wird das Setzen von DAC_CS am Ende nicht ausgeführt. Rufe ich
gpio_set_pin_level(DAC_CS,true) vor dem Verlassen der Funktion aber zwei
mal auf, dann funktioniert es und ich sehe, dass CS auf HIGH geht.
Ähnliches passiert beim Beschreiben der DATA-Register: nur einer der
beiden SERCOMs zeigt mir 24 Clock-Bits, beim anderen werden nur 8
ausgegeben. Verdopple ich die Aufrufe von
hri_sercomspi_write_DATA_reg(), dann sendet auch der andere SPI 24 Bits.
Wenn das Lesen der Statusbits genau so zuverlässig funktioniert, ist es
klar, dass das Timing nicht stimmt.
Erzeugt habe ich den Code mit Atmel START, bauen tue ich im AtmelStudio
unter Windows. Ist das ein Compilerproblem oder habe ich irgend was
anderes blödes übersehen, was dieses Verhalten verursachen könnte?
Danke!
Vielleicht solltest du ja auch, wenn du auf zwei SERCOMs arbeitest, auf
jeder von beiden das DRE-Bit testen?
START / FSF haben wir nie benutzt, irgendwie zu aufgebläht und
obfuscated. Wir haben uns lowlevel-Routinen selbst geschrieben (hat auch
den Vorteil, dass sich bspw. auch ein STM32Fxxx da parallel ganz gut
einbinden lässt).
Keine Ahnung, ob da noch was vergurkt sein könnte – eigentlich haben
sich die Jungs und Mädels da Mühe gegeben, jeden auch noch so obskuren
Fall abzudecken, aber ich habe (als ich mir das mal für irgendeinen
eigenen Code als Vorlage genommen habe) da auch schon Bugs entdeckt. War
allerdings nicht SAMD/SAMR, sondern SAM4E/SAME70.
>gpio_set_pin_level(DAC_CS,true);// CS wieder auf HIGH setzen
6
>
Dürfte an den fehlenden Semikola liegen.
Davon abgesehen: ich würde mich nicht darauf verlassen, dass die beiden
SERCOMs gleichzeitig fertig sind - besser beide testen.