Kinetis vs LPC (NXP kauft Freescale)

Die haben das natürlich extra nach der Embedded erst verkündet, damit 
man auf der Messe die Leute nicht genau auf das Thema anspricht...

Solange bis die sich äußern ob Kinetis oder LPC weiterentwickelt wird, 
würde ich für Neuentwicklungen STM32 (oder was anderes) nehmen.

NXPvsFreescale schrieb:
> Das heisst hier wird langfristig nur
> eine Produktlinie überleben.

Ist nicht der erste Merger. Renesas könnte Anschauungsmaterial bieten, 
angesichts dessen, was an Redundanzen zusammen kam. Hat jemand einen 
Überblick, wie es dort lief und läuft?

Na wunderbar :-/

Jetzt hab ich mich gerade so schön mit den Kinetis-Controllern 
angefreundet daß es anfängt Spaß zu machen und jetzt zieht schon wieder 
eine dunkle Wolke der Ungewissheit auf.

Herrje! Wenn die jetzt subito reinen Wein einschenken, dann sind sie die 
Kundschaft auf der falschen Seite der Waage ebenso subito los. Und 
wahrscheinlich ohne sie mit der anderen Waagschale wieder einzufangewn.

Selbstverständlich werden sie beide Linien weiter pflegen und 
weiterentwickeln. Ganz sicher, versprochen, mit Ehrenwort.

Hi

Natürlich werden sie das nicht tun :-)

Überrascht hat mich die Aktion schon. Mit dem Zusammenschluss hätte ich 
nicht gerechnet.

Ich denke es wird so laufen: Bestehende Produkte werden 
weiterproduziert. Und neue Derivate bekommen das beste aus beiden 
Welten. Und mal ehrlich: Heute sollte es kein Problem sein von einem STM 
auf einen Kinetis oder von einem TI Cortex M4 auf einen Spansion M4 zu 
wechseln wenn die Peripherie einigermaßen passt und die Software sauber 
strukturiert ist.

Matthias

Ist auf Dauer auch eine Frage der adressierten Märkte. NXP ist im Markt 
für "Kleinkram" recht rege. Bei Freescale habe ich nicht unbedingt 
diesen Eindruck.

Stimmt. Mit ein Grund ist da bestimmt schon die Webseite von freescale. 
Ich hab noch keine Seite gefunden bei der ich alle Kinetis nach 
Eigenschaften durchsuchen kann. Bei allen anderen nennenswerten Cortex M 
Kandidaten ist das kein Problem.

Μαtthias W. schrieb:
> Ich denke es wird so laufen: Bestehende Produkte werden
> weiterproduziert.

klar.

> Und neue Derivate bekommen das beste aus beiden
> Welten.

So einfach ist das nicht. Z.B. ein Timer oder ein USB-Interface sind 
spezielle IP-Cores, entweder zugekauft und angepasst oder selbst 
entwickelt. Und da kannst Du halt nur entweder den einen oder den 
anderen nehmen. Die beide zusammenzuführen dürfte mehr Aufwand sein als 
die neu zu entwickeln.

> Und mal ehrlich: Heute sollte es kein Problem sein von einem STM
> auf einen Kinetis oder von einem TI Cortex M4 auf einen Spansion M4 zu
> wechseln wenn die Peripherie einigermaßen passt und die Software sauber
> strukturiert ist.

Das gilt aber nur wenn Du Dich auf die Standardfunktionen der Peripherie 
verlässt. Kaum machst Du Dir die Vorzüge des einen Controllers zu nutze, 
hast Du es schwer zu migrieren.

Hatte gerade so einen Fall: Migration von LPC zu STM32, dort gibt es 
kein GIMA und Event Router. Da mussten wir den Wakeup dann komplett 
anders lösen.

Μαtthias W. schrieb:
> Heute sollte es kein Problem sein von einem STM
> auf einen Kinetis oder von einem TI Cortex M4 auf einen Spansion M4 zu
> wechseln

Das verursacht jedesmal Kosten und Zeit und Ärger und Zeit und Kosten 
und Stress bis das alles wieder fertig ist und getestet und dokumentiert 
und läuft und danach hat man wieder ne neue Hardwareversion und noch nen 
neuen Zweig im Code-Repository und alles was sonst noch mit dranhängt 
das man nicht einfach wegwerfen und vergessen kann (als ob man nicht 
schon genug davon hätte) weil das alte Zeug noch irgendwo bei den Kunden 
draußen rumschwirrt oder sonstwo eingebaut ist etc. Niemand wünscht sich 
das.

Gerd E. schrieb:
>> Und neue Derivate bekommen das beste aus beiden Welten.
>
> So einfach ist das nicht. Z.B. ein Timer oder ein USB-Interface sind
> spezielle IP-Cores, entweder zugekauft und angepasst oder selbst
> entwickelt. Und da kannst Du halt nur entweder den einen oder den
> anderen nehmen. Die beide zusammenzuführen dürfte mehr Aufwand sein als
> die neu zu entwickeln.

Das ist schon klar. Auch ein UART wird sicher nicht zusammengefummelt. 
Da nimmt man dann halt die NXP IP und beim Ethernet die Freescale IP. 
Fertig. Ist beim neuen Derivat dann halt so und der kleine Entwickler 
hat sich anzupassen. Der Automobiler wird denen einfach sagen welche IP 
er will.

Gerd E. schrieb:
> Das gilt aber nur wenn Du Dich auf die Standardfunktionen der Peripherie
> verlässt. Kaum machst Du Dir die Vorzüge des einen Controllers zu nutze,
> hast Du es schwer zu migrieren.

Auch klar. Das Problem stellt sich bei einem neuen Derivat aus der 
gleichen Reihe aber unter Umständen auch wenn der Hersteller was an der 
Peripherie geändert hat. Hatten wir auch mal. Neues Derivat -> neuer CAN 
Controller. Macht halt immer Arbeit geht aber wenn die Abhängigkeit 
ordentlich gekapselt ist.

Μαtthias W. schrieb:
> Stimmt. Mit ein Grund ist da bestimmt schon die Webseite von freescale.
> Ich hab noch keine Seite gefunden bei der ich alle Kinetis nach
> Eigenschaften durchsuchen kann. Bei allen anderen nennenswerten Cortex M
> Kandidaten ist das kein Problem.

Aber wenn man die findet, will man keine anderen mehr...
www.freescale.com/kinetis und dort auf Kinetis Product Selector gehen 
oder direkt zu 
http://www.freescale.com/webapp/sps/site/overview.jsp?code=KINETIS-PRODUCT-SELECTOR 
da ist nach allem selektierbar von Familie, Core, mit/ohne FPU bis zu 
Pin-Abstand etc. ;)

Arc Net schrieb:
> da ist nach allem selektierbar von Familie, Core, mit/ohne FPU bis zu
> Pin-Abstand etc. ;)

aber weder einfaches multiselect, noch min/max für die parameter.

wenigstens brauchen sie kein flash dafür

W.S. schrieb:
> A. K. schrieb:
>> Ist nicht der erste Merger. Renesas könnte Anschauungsmaterial bieten,
>> angesichts dessen, was an Redundanzen zusammen kam. Hat jemand einen
>> Überblick, wie es dort lief und läuft?
>
> Naja, guck mal nach Fujitsu: Die hatten mit der FR-Reihe auch einen
> schnuckligen 32 Bitter. Nun haben sie die ganze Sparte an Spansion
> verkauft und der ganze Kram wird Stück für Stück abserviert.

Der Tod der FR Reihe war schon zum Zeitpunkt der CortexM Einführung von 
Fujitsu absehbar. Von Spansion war da noch nix zu hören.

Matthias

W.S. schrieb:
> Dann kannst du mir mal auf die Sprünge helfen.
> Die Dokus von Freescale (Datasheet's und Refman's) finde ich zum Kotzen.

Also im Moment kann ich mich nur zur L-Serie äußern.

Ich finde mich eigentlich ganz gut zurecht, ich finde alles mehr oder 
weniger auf Anhieb und ich empfinde es als klar und strukturiert:

Jedes Peripheriegerät hat ein eigenes Kapitel, jedes dieser Kapitel hat 
die exakt selbe Struktur. Die meiste Zeit verbringe ich in dem "Memory 
map / Register definitions" des jeweiligen Peripheriegerätes. Hinzu 
kommt dann noch jeweils SIM und PORT.

Also mal ein Beispiel: Ich will bei einem MKL05Zxxyyyy mittels des 
Timers an mehreren Pins PWM-Signale erzeugen. Dann nehm ich mir das 
Reference manual: 
http://cache.freescale.com/files/32bit/doc/ref_manual/KL05P48M48SF1RM.pdf 
und dann schlag ich die folgenden Seiten auf:

* Signal-Multiplexing (Pinout Tabelle und Pinout-Bild ausgedruckt, 
Alternate-Funktionen noch ins Bild reingemalt zwecks Übersicht und an 
die Wand genagelt)

* SIM (um die Takte für den Timer einzuschalten, Bustakt für Timer und 
Portpins und Zähltakt für den Timer [OK, letzteres hat ein bisschen 
länger gedauert, musste erst suchen, ersteres ist jedoch bei allen 
Peripherals immer gleich])

* PORT (um die Pin-Multiplexing-Zuordnung eintzustellen, unter 
Zuhilfenahme der Tabelle die an der Wand hängt stellt man die 
gewünschten Alternate-Funktion am gewünschten Pin ein so daß der Pin auf 
einen der TPMx_CHx gemappt wird.

* TPM um den Timer zu konfigurieren, hier schau ich also wieder in der 
Registermap welche Bits in welchem Channel ich setzen muss damit er tut 
was ich will. Die Register sind sehr gut dokumentiert.

Fertig.

In allen drei letzteren Kapiteln ist es jeweils das Unterkapitel "Memory 
map / Register definitions" in dem Du die meiste Zeit verbringen wirst, 
dort steht wirklich alles drin, jedes einzelne Bit ist ausreichend(!) 
erklärt (nachdem Du einmal den Rest des betreffenden Kapitels gelesen 
und verstanden hast)

Schwierig ist es nur erstmal zu Beginn den Gesamtzusammenhang zu 
erblicken, aber das brauchst Du nur einmal.

Du wirst dann später immer wieder nur jeweils die oben genannten wenigen 
Register aus den Kapiteln SIM, PORT und dem des jeweiligen Peripherals 
brauchen: SIM zum Einschalten, PORT und zum Mappen der Pin-Funktionen 
(zusammen mit dem Bild an der Wand) und zuletzt das Kapitel des 
jeweiligen Peripherals selbst. Und dort meist wirklich jeweils nur die 
Registerbeschreibungen, der Rest ergibt sich aus dem einmal gewonnenen 
Verständnis. Die ersten paar Tage sind schwierig, dann wirds rapide 
einfacher.

Aber jeder hat halt seine eigene Art Dokumente zu lesen oder Information 
aufzunehmen oder zu verarbeiten, deshalb bevorzugt jeder ein anderes 
Format oder mancher empfindet etwas als übersichtlich was ein anderer 
als unstrukturiert empfindet oder umgekehrt. Bei mir war es jedenfalls 
so dass das Freescale-Manual und mein Gehirn sofort kompatibel waren, es 
spricht anscheinend genau meine Sprache, YMMV.

Wo wird denn bei Neuentwicklungen PowerPC verwendet?

W.S. schrieb:
> Das gilt übrigens auch für die MKxxx.h Files von Freescale. Herrje, was
> werden dort für Makro-Affentänze zelebriert und tausende von
> Namensdefinitionen kreiert, die man sich nie merken kann und die m.E.
> auch völlig überflüssig sind. Hier mal ein Beispiel:
> #define ADC_SC2_ACFGT_MASK     0x10u
> #define ADC_SC2_ACFGT_SHIFT    4

Find ich nicht Überflüssig, ganz im Gegenteil, das empfinde ich als 
einen wahren Segen und es ist wirklich konsequent umgesetzt. Wie 
würdest Du die Bits stattdessen benennen?

Stell Dir vor Du willst das ADCFGT Bit im ADC0->SC2 Register setzen, wie 
sollte das denn anders benannt sein? Bei der schieren Anzahl an 
Registern und deren Bits braucht man ein striktes und konsequentes 
Namensschema und da muss der Name des Registers ein Teil des Namens des 
Bits sein.

Das kann auch helfen Fehler zu vermeiden. Es kann sogar helfen nicht so 
oft im Handbuch nachschlagen zu müssen: Zum Beispiel weißt Du daß um das 
clock gating für Port B einzuschalten muss irgendein Bit in irgendeinem 
der SIM->SCGCx Register gesetzt werden (SCGC4 oder 5 oder 6 oder 7) aber 
Du hast vergessen in welchem. Du schreibst einfach SIM_SCGC_ und drückst 
Shift-Leertaste und dann siehst Du eine Liste aller clock gating bits, 
eins davon heißt SIM_SCGC5_PORTB. Jetzt weißt Du daß es ins 
SCGC5-Register gehört (und nicht etwa ins SCGC4 oder SCGC6) und wie das 
Bit heißt weißt Du auch ohne im Handbuch nachschauen zu müssen.

Kannst Du Dich noch erinnern wie es damals war bei AVR? Da gabs zum 
Beispiel für den Timer ein WGM02 bit und ein WGM01 und ein WGM00 aber 
für welche Register? Oder gar für welches Gerät? Und zu allem Überdruss 
hat man da nur den shift definiert, die Maske hat man sich dann noch 
jedesmal selber zusammenstoppeln müssen mit endlosen Orgien von (1 << 
WHATEVER). Kannst Du Dich noch erinnern wie das war?

Es hat schon seinen Charme, nur die Bits zu benennen. Ob man die Maske 
daraus mit explizitem 1<< gewinnt, oder per Makro, ist sekundär. Der Weg 
jedenfalls ist trivial.

Doof allerdings ist es, in den Includes nur die Maske anzugeben (STM32). 
Denn ab und zu braucht man die Bits zur Maske, und der Weg in diese 
Richtung ist nicht direkt trivial.

W.S. schrieb:
> Entweder exakt so, wie sie im RefMan benannt sind

Sind sie doch! Exakt so wie im Refman!

> oder ersatzeshalber
> GARNICHT!

Das geht ja mal gar nicht. Wie sollen die Leute die sich mit dem 
Schreiben der Treiber vergnügen die Register benutzen wenn keine Defines 
mit vernünftigen Namen für selbige existieren, wie soll der Treibercode 
denn aussehen?

Mir ist heute etwas aufgefallen: Für ein neues Produkt bin ich auf der 
Suche nach einem Cortex M0 und die von Freescale sind bei Mouser 
unheimlich günstig. War das schon immer so? Ich kann das leider nicht 
beurteilen, da ich in dem Bereich zu wenig Erfahrung habe. Kla, 8kB 
Flash ist sehr wenig aber für 68 Cent das Stück (Stückpreis)?

Hier die Herstellernummer: MKL03Z8VFG4