[Kinetis]Zu doof für LPSPI

Michael H. Gast #5015635 
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 Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke
W.S. Gast #5016914 
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 Melden Danke
Bernd K. #5016940 
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 Melden Danke
W.S. Gast #5017617 
> 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 Melden Danke
Bernd K. #5018202 
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 Melden Danke
W.S. Gast #5018557 
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 Melden Danke
Bernd K. #5018619 
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 Melden Danke
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 9 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.