Forum: Mikrocontroller und Digitale Elektronik Kinetis vs LPC (NXP kauft Freescale)


von NXPvsFreescale (Gast)


Lesenswert?

NXP übernimmt Freescale:

http://www.nxp.com/news/press-releases/2015/03/nxp-and-freescale-announce-40-billion-merger.html

Der größte Überlapp zwischen den beiden Firmen scheint das 
Mikrocontrollergeschäft zu sein. Das heisst hier wird langfristig nur 
eine Produktlinie überleben. Kinetis oder LPC?

Mit scheint, dass die Freescale-Linie doch etwas besser etabliert ist. 
Oder liege ich hier falsch?

von NXPvsFreescale (Gast)


Lesenswert?

Strategische Themen interessieren hier natürlich keinen.

Wenn Ihr die NXP-Aktie zum Zeitpunkt meines Posts gekauft hättet, hättet 
Ihr jetzt 16% Gewinn.

von nfet (Gast)


Lesenswert?

Doch mich interessiert es.
Bin auch der Meinung, dass die Freescale Controller etwas etablierter 
sind. Allerdings wurde eben Freescale von NXP gekauft...

Denke auch es wird weitere Konsolidierungen in diesem Bereich geben.
Wenn man bedenkt, dass die Übernahme gerade mal 11,8 Milliarden Dollar 
gekostet hat. Samsung baut für den Preis mal eben ne neue Fab.

von Gerd E. (robberknight)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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?

: Bearbeitet durch User
von Bernd K. (prof7bit)


Lesenswert?

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.

: Bearbeitet durch User
von Lutz (Gast)


Lesenswert?

Na das nenne ich doch mal einen Kracher!

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

Genau das läßt meine Hoffnung steigen, daß die sich bald dazu äußern 
werden. Wenn wegen der Ungewißheit im professionellen Umfeld kaum einer 
sich für einen der beiden entscheiden wird, da man mit beiden hinten 
runterfallen kann...

von (prx) A. K. (prx)


Lesenswert?

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.

von Lutz (Gast)


Lesenswert?

Hast den Smiley vergessen ... ;-)

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

Μα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.

von Bernd K. (prof7bit)


Lesenswert?

Μα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.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

NXPvsFreescale schrieb:
> Wenn Ihr die NXP-Aktie zum Zeitpunkt meines Posts gekauft hättet, hättet
> Ihr jetzt 16% Gewinn.

Hättest du HochTief gekauft, hättest du 35% Gewinn.

Glücksspiel ist Scheisse.

Hinterher weiss man es immer besser.

von NXPvsFreescale (Gast)


Lesenswert?

MaWin schrieb:
> Hättest du HochTief gekauft, hättest du 35% Gewinn.
>
> Glücksspiel ist Scheisse.
>
> Hinterher weiss man es immer besser.

Ich hatte erheblich mehr als 16% Gewinn, da ich NXP schon lange halte.

Der Vorteil des Deals ist recht offentsichtlich:

1) Aktientausch - damit sind FSL und NXPI effektiv gekoppelt.

2) Die Steuerbelastung des Unternehmens sinkt durch den Wechsel der 
Firmenzentrale von den USA in die Niederlande von ~35% auf 25%.

Das konnte man schon heute Morgen um 7:00 nachlesen. Ich bin erstaunt, 
dass der Kurs in D so langsam gestiegen ist.

von gg (Gast)


Lesenswert?

NXPvsFreescale schrieb:
> da ich NXP schon lange halte.
> ...
> Das konnte man schon heute Morgen um 7:00 nachlesen. Ich bin erstaunt,
> dass der Kurs in D so langsam gestiegen ist.


Also eigentlich haste das hier nur gepostet um den Kurs zu pushen.
Soso ;-)

von Arc N. (arc)


Lesenswert?

Μα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. ;)

von Gerd E. (robberknight)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

Bernd K. schrieb:
> 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.

Dann kannst du mir mal auf die Sprünge helfen.
Die Dokus von Freescale (Datasheet's und Refman's) finde ich zum Kotzen. 
Es ist alles auseinandergezerrt, viel Gelaber ohne erkennbare Zuordnung, 
selbst dort, wo die mal ein Schema zeichnen (z.B. Taktversorgung), 
schaffen sie es nicht, dranzuschreiben, welches Bit in welchem Register 
für welche Weichenstellung von Signalen denn nun zuständig ist. Und im 
gleichen Kapitel wird das Ganze garantiert nicht erklärt, da ist man 
ständig am Suchen, an welcher Stelle man die nötigen Zusatzinfos findet. 
Wo schaltet man den Oszillator ein? Im Kapitel über den Oszillator 
steht's nicht. Wo stellt man die Port-Optionen ein? (was für ne 
Funktionalität OPT0..7 an welchem Pin einen angrinst) Im Kapitel über 
die Ports (PORT) steht's nicht - jedenfalls bei der MKE06Z Reihe.

Also, Freescale hat einen Riesensack von Familien, Unterfamilien, 
Varianten und Untervarianten von Cortexen, aber die Chips scheinen mir 
nicht wirklich durchdacht zu sein, sondern eher von Freaks 
zusammengeschustert, wo keiner mit dem anderen geredet hat und ein jeder 
nur sein engeres Feld gesehen hat.

Und die Doku ist grottenschlecht.

Also ich wäre dafür, die µC von Freescale in die Tonne zu drücken und 
mit den LPC weiterzumachen. Das ist ja bei Philips nicht das erte Mal. 
Von Sharp hatten sie die BlueStreaks eingekauft und nach ner Weile auf's 
Abstellgleis geschoben. Aber wie man ein benutzbares TFT-Interface in 
die Chips einbaut, das hat NXP bei dieser Gelegenheit gelernt. 
Vielleicht läuft das jetzt ähnlich.


W.S.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

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.

: Bearbeitet durch User
von Bege (Gast)


Lesenswert?

Freescale macht nicht nur in ARMs sondern ist auch ganz groß im PowerPC 
Geschäft. Interessant daran ist, dass FSL zusammen mit STM, die auch 
PPCs im Portfolio haben, Peripheriemodule entwickelt haben. Ich kenne 
Manuals von beiden Unternehmen in denen es bis auf's Wort gleiche 
Beschreibungen gibt.

Bleibt die Frage was der Zusammenschluß von FSL mit NXP für STM zu 
bedeuten hat? Muss STM jetzt seine PPC Peripheriemodule alleine 
entwickeln... ?

Von den Geschäftsfeldern passt der Merger recht gut. NXP ist eher im 
Low-Performnce Segment aktiv, während FSL schon recht potente 
Multicore-Rechenkisten hat. Vom Bauchgefühl her würde ich sagen FSL hat 
mehr Know-How im Bereich der 
Mikroprozessor-/Mikrocontroller-Entwicklung. Man denke an so legendäre 
Kisten wie die 68000er Familie oder (Entwicklungs-Beteiligung im 
PPC-Segment. Soweit ich weiß hat NXP nie wirklich einen Prozessor selbst 
entwickelt. Philips hat den 8051 von Intel gekauft nun setzten sie auf 
ARM (also auch zugekauft).
Von daher denke ich die beiden passen recht gut zusammen. Sicherlich 
wird man das ein oder andere Produkt vom Markt nehmen um sich keine 
Konkurrenz im eigenen Haus zu schaffen aber im Großen und Ganzen denke 
ich nicht dass es große Änderungen am Portfolio geben wird.

von Gerd E. (robberknight)


Lesenswert?

Wo wird denn bei Neuentwicklungen PowerPC verwendet?

von Bege (Gast)


Lesenswert?

>Wo wird denn bei Neuentwicklungen PowerPC verwendet?
Zum Beispiel im Automotive Bereich wo ASICs auf PPC-Basis verwendet 
werden.

FSL gehört da u.a. zu den ganz Großen im PPC Geschäft. Und obwohl heute 
in vielen Consumer-Produkten ARM-Cores zu finden sind, gibt es doch noch 
genügend Gerätschaften mit PPCs nicht nur im Consumer-Bereich (Router, 
Receiver, Drucker, ...) sondern auch in Avionik-, Raumfahrt-, 
Rüstungs-Systemen.

siehe z.B. Portfolio auf der FSL-Webseite:
http://www.freescale.com/webapp/sps/site/homepage.jsp?code=POWER-ARCHITECTURE

von W.S. (Gast)


Lesenswert?

Bernd K. schrieb:
> Schwierig ist es nur erstmal zu Beginn den Gesamtzusammenhang zu
> erblicken, aber das brauchst Du nur einmal.

Erstmal besten Dank für deinen Beitrag.

Aber meine ersten Erfahrungen sind eher, daß man sich totblättert. 
Jedenfalls für den Anfang. In den RefMan's werden tonnenweise 
Abkürzungen verwendet, die man sich erstens nicht merken kann und die 
man zweitens grundsätzlich nur ganz wo anders mal ausgeschrieben findet 
als dort, wo sie verwendet werden.

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
#define ADC_SC2_ACFE_MASK      0x20u
#define ADC_SC2_ACFE_SHIFT     5
#define ADC_SC2_ADTRG_MASK     0x40u
#define ADC_SC2_ADTRG_SHIFT    6
#define ADC_SC2_ADACT_MASK     0x80u
Wer den ADC einrichten will und sich seinen Treiber dafür baut, muß 
sowieso die Nase ins RefMan stecken und da sind solche define's einfach 
nur überflüssiger Ballast. Konsequenterweise mache ich mir deshalb meine 
*.h zum konkreten µC selber und bringe dort nur das hinein, was im 
RefMan definiert ist.

Ich hatte zu allererst mal das Refman der MKL46 gelesen, wegen eines 
Eval-Boardes von der letzten Embedded. Die Festlegung der Pinfunktionen 
(ALT0..7) ist dort mit jeweils einem Register pro Pin (PORTx_PCRy) 
richtig gut gelöst. Dafür ist die Taktversorgung ein Chaos.

Aber das hab ich erstmal beiseite gelegt, um mir die mich eigentlich 
interessierende MKE04 und MKE06 Reihe anzusehen.

Bescheuerterweise gibt es dort die PORTx_PCRy Register überhaupt nicht. 
Kommentar vom Freescale-Kundendienst: Das geht automatisch, je nachdem 
welche Peripherie gerade aktiviert ist. Mit den PINSEL0 und PINSEL1 
Registern kann man lediglich Belegungs-Alternativen wählen, aber NICHT 
zwischen den ALT0..7. Klasse, jetzt muß man also zum Zurücksetzen des 
Chips nach Faults o.ä. alle peripheren Cores abklappern..  Ich hoffen 
nur, daß das Takt Ein/Ausschalten gleichbedeutend ist mit dem Aktivieren 
des betreffenden Peripherie-Cores. Wenn nicht, geht die Suche nach den 
diversen E/A-Schaltern nochmal los.

Es hat auch ne Weile gedauert, bis ich für den Takt den Hinweis gefunden 
habe, daß deren FLL sowohl einen festen Multiplikator von 1280 als auch 
einen zulässigen Eingangsfrequenzbereich von nur 32..39 kHz hat. Geht 
ja, aber man muß es erstmal herauskriegen.

Eigentlich müßte man sich deren RefMan's komplett ausdrucken und dann 
von einem Aha-Moment zum anderen mit roter Tinte die gewonnenen 
Erkenntnisse als Randbemerkungen eintragen. Aber bei rund 1000 Seiten 
tun mir die sibirischen Wälder leid.

Naja, ich ackere mich da durch. Wenn erstmal Pinzuweisungen, Oszillator 
und Taktversorgung so stehen wie gewünscht, dann geht's flotter weiter. 
Es wäre nicht der erste µC, bei dem ich die Firmware noch vor der ersten 
Leiterplatte fertig habe.

Aber eines muß man sagen: Die Dokus von NXP sind deutlich lesbarer und 
informativer.

W.S.

von Bernd K. (prof7bit)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Soul E. (Gast)


Lesenswert?

Offizielle Aussage von FSC zu o.g. Thema

"The two companies' portfolios overlap primarily in only one area, RF 
power products. In this case, NXP has decided to sell their RF power 
portfolio and keep the industry-leading Freescale RF portfolio. All 
other product families are expected to complement each other very 
nicely. For instance, the Freescale Kinetis MCU combination with NXP's 
leadership in connectivity and security is an easy and obvious fit. The 
same is true for NXP's FM tuners and Freescale's i.MX and Infotainment 
systems. Another is NXP's leadership in secure ID and Freescale's secure 
Digital Networking processors. We see these natural junctions in each 
product group and we look forward to exploring more with you.

Once the merger is complete, our plan is to keep the NXP Semiconductors 
name and operate as one company under the NXP brand. We are committed to 
our growth product lines and look forward to becoming the largest 
automotive semiconductor company on the planet and the fourth largest 
semiconductor supplier in the world. The focus of both companies has 
always been high-growth markets and focusing on our customers' needs and 
this will not change."

von W.S. (Gast)


Lesenswert?

Bernd K. schrieb:
> 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?

Entweder exakt so, wie sie im RefMan benannt sind oder ersatzeshalber 
GARNICHT! Es ist nach meinem Verständnis für die meisten 
Peripherie-Cores besser, dafür geeignete Peripherie-Treiber zu schreiben 
und selbige ordentlich zu kapseln, als 1000 eigene Namen und nochmal 
1000 eigene Masken-Namen zu erfinde, damit jeder in der 
Applikations-Ebene seiner Firmware darin herumdaddeln darf.

Sieh dir mal meine CDC-USB-Treiber an. Deren Schnittstelle zur App-Ebene 
ist völlig frei von hardwarespezifischen Details - das schafft nebenher 
eine gute Portabilität. Für sowas braucht man im "dieser_prozessor.h" 
lediglich die Register-Definitionen, aber keinerlei aufgedunsene 
Bitgruppen-Pfriemelei.

W.S.

von Bernd K. (prof7bit)


Lesenswert?

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?

von Jonathan W. (anoj_ettiw)


Lesenswert?

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

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.