[Kinetis]Zu doof für LPSPI

Michael H. Gast #5015635
Lesenswert?
• ▲
▼ 
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.

1
  //configure port

2
  PCC->CLKCFG[PCC_PORTD_INDEX]=PCC_CLKCFG_CGC(1);

3
  PORTD->PCR[0]=PORT_PCR_MUX(3);

4
  PORTD->PCR[1]=PORT_PCR_MUX(3);

5
  PORTD->PCR[2]=PORT_PCR_MUX(3);

6
  PORTD->PCR[3]=PORT_PCR_MUX(3);

7


8
  //Set FIRCDIV2

9
  //SCG->FIRCDIV=SCG_FIRCDIV_FIRCDIV2(1)|SCG_FIRCDIV_FIRCDIV1(1);

10
  //configure

11
  //PCC->CLKCFG[PCC_LPSPI1_INDEX]=0;

12
  PCC->CLKCFG[PCC_LPSPI1_INDEX]=PCC_CLKCFG_CGC(1);//|PCC_CLKCFG_PCS(3); //Set fast irc clock

13
  //CLOCK_SetIpSrc(kCLOCK_Lpspi1, kCLOCK_IpSrcFircAsync);

14


15
  //PCC->CLKCFG[PCC_LPUART1_INDEX]=PCC_CLKCFG_CGC(1);

16
  CLOCK_SetIpSrc(kCLOCK_Lpspi1, kCLOCK_IpSrcSysPllAsync);

17


18
  LPSPI1->CR=0;

19
  LPSPI1->IER=0;

20
  LPSPI1->DER=0;

21
  LPSPI1->CFGR0=0;

22
  LPSPI1->CFGR1=LPSPI_CFGR1_MASTER(1); //Master mode

23
  LPSPI1->TCR=LPSPI_TCR_CPOL(0)|

24
      LPSPI_TCR_PRESCALE(2)|

25
      LPSPI_TCR_PCS(0)|

26
      LPSPI_TCR_LSBF(0)|

27
      LPSPI_TCR_BYSW(0)|

28
      LPSPI_TCR_CONT(0)|LPSPI_TCR_CONTC(0)|

29
      LPSPI_TCR_RXMSK(0)|

30
      LPSPI_TCR_TXMSK(0)|

31
      LPSPI_TCR_WIDTH(0)|

32
      LPSPI_TCR_FRAMESZ(15);

33
  LPSPI1->CCR= LPSPI_CCR_SCKPCS(0)|

34
      LPSPI_CCR_PCSSCK(1)|

35
      LPSPI_CCR_DBT(8);

36
  LPSPI1->FCR=LPSPI_FCR_RXWATER(0)|

37
      LPSPI_FCR_TXWATER(3);

38
  LPSPI1->CR= LPSPI_CR_DBGEN(1)|LPSPI_CR_MEN(1);

39


40
}

41


42
void LPSPI1_transmit_16bits(uint16_t send) {

43
  while((LPSPI1->SR & LPSPI_SR_TDF_MASK)>>LPSPI_SR_TDF_SHIFT==0);

44
  LPSPI1->TDR = send;

45
  LPSPI1->SR |= LPSPI_SR_TDF_MASK;

46
}


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?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
W.S. Gast #5016914
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernd K. #5016940
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
W.S. Gast #5017617
Lesenswert?
• ▲
▼ 
> 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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernd K. #5018202
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
W.S. Gast #5018557
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernd K. #5018619
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren