[Kinetis]Zu doof für LPSPI

[Michael H. (Gast)]

Hallo,

ich habe schon viel Erfahrung mit CortexM4, jedoch hänge ich gerade beim 
Kinetis MCU fest.
Ich verwende den MKE14F256 und möchte das SPI in betrieb nehmen. 
Datenblatt / Refence Manuals gibts hier:
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/e-series-5v-robust-m0-plus-m4/kinetis-ke1xf-168mhz-performance-with-can-5v-microcontrollers-based-on-arm-cortex-m4:KE1xF?tab=Documentation_Tab

So jetzt habe ich ein ähnliches Cookbook für einen ähnlichen MCU 
gefunden, der das LPSPI demonstriert.
Seite 40 folgende.
http://www.nxp.com/assets/documents/data/en/application-notes/AN5413.pdf

Das ganze habe ich entsprechend umgesetzt.

  //configure port
  PCC->CLKCFG[PCC_PORTD_INDEX]=PCC_CLKCFG_CGC(1);
  PORTD->PCR[0]=PORT_PCR_MUX(3);
  PORTD->PCR[1]=PORT_PCR_MUX(3);
  PORTD->PCR[2]=PORT_PCR_MUX(3);
  PORTD->PCR[3]=PORT_PCR_MUX(3);

  //Set FIRCDIV2
  //SCG->FIRCDIV=SCG_FIRCDIV_FIRCDIV2(1)|SCG_FIRCDIV_FIRCDIV1(1);
  //configure
  //PCC->CLKCFG[PCC_LPSPI1_INDEX]=0;
  PCC->CLKCFG[PCC_LPSPI1_INDEX]=PCC_CLKCFG_CGC(1);//|PCC_CLKCFG_PCS(3); //Set fast irc clock
  //CLOCK_SetIpSrc(kCLOCK_Lpspi1, kCLOCK_IpSrcFircAsync);

  //PCC->CLKCFG[PCC_LPUART1_INDEX]=PCC_CLKCFG_CGC(1);
  CLOCK_SetIpSrc(kCLOCK_Lpspi1, kCLOCK_IpSrcSysPllAsync);

  LPSPI1->CR=0;
  LPSPI1->IER=0;
  LPSPI1->DER=0;
  LPSPI1->CFGR0=0;
  LPSPI1->CFGR1=LPSPI_CFGR1_MASTER(1); //Master mode
  LPSPI1->TCR=LPSPI_TCR_CPOL(0)|
      LPSPI_TCR_PRESCALE(2)|
      LPSPI_TCR_PCS(0)|
      LPSPI_TCR_LSBF(0)|
      LPSPI_TCR_BYSW(0)|
      LPSPI_TCR_CONT(0)|LPSPI_TCR_CONTC(0)|
      LPSPI_TCR_RXMSK(0)|
      LPSPI_TCR_TXMSK(0)|
      LPSPI_TCR_WIDTH(0)|
      LPSPI_TCR_FRAMESZ(15);
  LPSPI1->CCR= LPSPI_CCR_SCKPCS(0)|
      LPSPI_CCR_PCSSCK(1)|
      LPSPI_CCR_DBT(8);
  LPSPI1->FCR=LPSPI_FCR_RXWATER(0)|
      LPSPI_FCR_TXWATER(3);
  LPSPI1->CR= LPSPI_CR_DBGEN(1)|LPSPI_CR_MEN(1);

}

void LPSPI1_transmit_16bits(uint16_t send) {
  while((LPSPI1->SR & LPSPI_SR_TDF_MASK)>>LPSPI_SR_TDF_SHIFT==0);
  LPSPI1->TDR = send;
  LPSPI1->SR |= LPSPI_SR_TDF_MASK;
}

Fehlerbild: Ich kann ca. 8(?) mal schreiben und dann ist Fifo voll.
Am Ausgang kommt nix an. Mein Verdacht sind irgendwie die CLKs, die 
nicht durchkommen. Sehr ihr was?

[Michael H. (Gast)]

Keiner?

[W.S. (Gast)]

Michael H. schrieb:
> PCC->CLKCFG[PCC_PORTD_INDEX]=PCC_CLKCFG_CGC(1);
>   PORTD->PCR[0]=PORT_PCR_MUX(3);

Schreib das ganze lieber direkt, also ohne irgendwelche blöden Makros 
auf der rechten Seite - sonst kann das ja sowieso keiner lesen und mit 
dem Kapitel 35.6 im Refman vergleichen.

Ansonsten:
- Takte aufsetzen und für die div. Peripherien einschalten
- alle benötigten PORTx_PCRn richtig aufsetzen
Dann sollte die Port-Funktionalität OK sein. Anschließend kannst du dich 
im Aufsetzen des SPI-Moduls tummeln.

Hab ja gestaunt: Erstens, daß diese MKE-Typen tatsächlich wieder die 
_PCRn Register haben, und zweitens, daß es mittlerweile sogar hier und 
da mal eine symbolische Schaltung gibt, damit man ne Chance hat, aus dem 
verquaasten Gelaber der Autoren das herauszulesen, was man wissen will.

W.S.

[Bernd K. (prof7bit)]

Geht das schon wieder los... :-(

[Bernd K. (prof7bit)]

W.S. schrieb:
> Schreib das ganze lieber direkt, also ohne irgendwelche blöden Makros
> auf der rechten Seite - sonst kann das ja sowieso keiner lesen und mit
> dem Kapitel 35.6 im Refman vergleichen.

So ein Bullshit. Die Makros dienen der Lesbarkeit und Wartbarkeit. Die 
sorgen dafür dass man auch ohne nachzuschlagen sofort sieht was man da 
konfiguriert hat.

[AVRler (Gast)]

Bernd K. schrieb:
> So ein Bullshit. Die Makros dienen der Lesbarkeit und Wartbarkeit

Hat ARM auch bitter nötig.
Soviel Komplexität in der Konfiguration ist doch der Wahnsinn.

[W.S. (Gast)]

> Soviel Komplexität in der Konfiguration ist doch der Wahnsinn.

Ach nö, solange man das Ganze im RefMan nachvollziehen kann, ist das 
alles durchaus kein Wahnsinn. Man muß sich bloß ein einigermaßen 
sauberes Treiber-Konzept vornehmen, so daß man treiberinterne Dinge 
direkt erledigen kann und deshalb nur jeweils ein Kapitel des Refman's 
durchzuackern braucht.

Da ist Bernd's Ansicht aber außen vor, denn Dinge wie "PORT_PCR_MUX(3)" 
sind in den Manuals nirgendwo deklariert, weswegen man sie bei Problemen 
erst mal ganz woanders suchen und auf Richtigkeit prüfen müßte. Genau 
deshalb meine allererste Bemerkung dazu.

W.S.

[Bernd K. (prof7bit)]

W.S. schrieb:

> Da ist Bernd's Ansicht aber außen vor, denn Dinge wie "PORT_PCR_MUX(3)"

Aber sicher ist das deklariert, und zwar unter genau dem Namen:

PORT ist der Name der Peripherie
PCR ist der Name des Registers
MUX ist der Name des/der Bits.

Und zwar exakt genau so wie sie im Manual benannt sind. So findet man 
das innerhalb von Sekunden im RM. Und selbst ohne Nachschlagen sieht man 
sofort was man da gesetzt hat.

Setz dich doch endlich mal hin und werf selbst mal einen Blick in das 
gottverdammte fucking Manual und in das Headerfile anstatt hier 
pausenlos Deine bornierte Leseverweigerung zum Besten zu geben! Das ist 
ja nur noch peinlich.

[W.S. (Gast)]

Bernd K. schrieb:
> Aber sicher ist das deklariert

..aber eben NICHT in irgend einem Manual zum Chip, sondern sonstwo. Also 
laß dein ewiges Herumnölen endlich mal sein und lerne, das zu lesen, was 
dasteht.

Abgesehen davon bist du nicht der TO, der wie alle anderen zuvor von 
dir rein garnichts Hilfreiches lesen konnte, dafür aber immer wieder 
eine Flut von "Bullshit" und anderen Pöbelwörtern ertragen muß. Brauchst 
du sowas für dein selbstgefühl?

Also reiß dich endlich mal zusammen! Wenn du was zum Allegmeinwohl 
beitragen möchtest, dann schreib mal ne Einführung in die Programmierung 
der Kinetis - dann haben alle anderen was davon.

W.S.

[Bernd K. (prof7bit)]

W.S. schrieb:
> Bernd K. schrieb:
> Aber sicher ist das deklariert
>
> ..aber eben NICHT in irgend einem Manual zum Chip, sondern sonstwo.

Es ist im offiziellen Headerfile deklariert mit WORTWÖRTLICH den selben 
Namen wie sie im offiziellen Manual stehen.

Und was trägst Du eigentlich hier bei außer irreführende schwachsinnige 
Vorschläge er solle die leserlichen Namen der Konstanten entfernen (und 
durch was eigentlich ersetzen?) und irreführende Behauptungen diese 
Namen stünden nicht im Manual?

Ich hatte überhaupt nicht in diesem Thread geantwortet hättest Du nicht 
wieder Deinen üblichen irreführenden Bockmist abgesondert welcher nicht 
unkommentiert stehenbleiben darf, sonst glaubts am Ende noch irgendein 
unschuldiger Anfänger.