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?
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.
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.
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?
:
Bearbeitet durch User
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
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...
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.
:
Bearbeitet durch User
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.
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.
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.
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 ;-)
Μα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
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.
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.
:
Bearbeitet durch User
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.
>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
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.
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.
:
Bearbeitet durch User
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."
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.
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
:
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.