Ich habe noch die Frage, ich möchte auch NXP LPC2148 programmieren lernen, ist die Programmierungsumgebung kostenlos oder? Keil kostet Geld, für mich erst kommt nicht in Frage. Danke.
Jük P. schrieb: > ist die Programmierungsumgebung kostenlos oder? https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE Kannst du Englisch? sieht so aus. Wäre auch irgendwie dämlich, wenn es nicht so wäre. Keil hat noch gantz andere "Vorzüge".
Dann noch den MCU-Link Pro dazu (nicht kostenlos, aber günstig) und Du hast neben den Debuggger auch eine dynamische Strommessung bis in den uA Bereich.
:
Bearbeitet durch User
Jük P. schrieb: > Ich habe noch die Frage, ich möchte auch NXP LPC2148 programmieren > lernen, ist die Programmierungsumgebung kostenlos oder? LPC2142 ist ARM7TDMI und damit seit 20 Jahren veraltet. Willst Du nicht mehr. Beschäftige Dich besser mit CortexM, davon gibts genug, sei es Raspberry Pi 2040/2350, STM32, PIC32C/ATSAM,..., und ist auch angenehmer. Wenn Du das kannst, dann kannst Du gerne Altertumsforschung betreiben. fchk
Frank K. schrieb: > Jük P. schrieb: >> Ich habe noch die Frage, ich möchte auch NXP LPC2148 programmieren >> lernen, ist die Programmierungsumgebung kostenlos oder? > > LPC2142 ist ARM7TDMI und damit seit 20 Jahren veraltet. Willst Du nicht > mehr. Beschäftige Dich besser mit CortexM, davon gibts genug, sei es > Raspberry Pi 2040/2350, STM32, PIC32C/ATSAM,..., und ist auch > angenehmer. > > Wenn Du das kannst, dann kannst Du gerne Altertumsforschung betreiben. > > fchk Wenn es unbedingt NXP sein muss, würde ich noch den LPC1768 und den LPC4370 erwähnen. Letzterer ist allerdings BGA-only, und schon etwas komplexer.
Moin, Mein Vorschlag wäre dahingehend auch auf ST umzusteigen und mit einer STM32 nucleo Board mit angebauten JTAG Debugger und ST freie Entwicklung SW mit JDB Debugger anzufangen. Da hast Du alles was Du brauchst. Bei den Nucleo Bords werden praktisch keine Pins verschwendet und eignen sich gut für Prototypenversuche. Das JTAg Debug Teil lässt sich auch extern benutzen. Allerdings ist ein ST-JLINK-V2/3 oder Minnie doch angenehm in unabhängigen Projekten. Das IDE verwendet die Eclipse Plattform und ist ein Nachfolger der Atollic SW. https://www.st.com/en/development-tools/stlink-v3minie.html https://www.st.com/en/evaluation-tools/stm32-nucleo-boards.html https://www.st.com/en/development-tools/stm32cubeide.html Mit den erwähnten Sachen hast Du eine solide Basis mit minimalen Frustfaktor. Ich bin der Meinung, dass es am Anfang am Besten ist, mit firmeneigener HW und SW anzufangen. Das funktioniert dann sozusagen aus der Schachtel heraus. Mein "Liebling" ist seit ein paar Jahren der STM32L496. Angefangen habe ich mit dem F103 und F407 unter Coocox und Atollic. Obwohl der F103 nach heutigen Maßstäben veraltet ist, war er ziemlich gutmütig und relativ einfach zu verstehen. Allerdings litt er unter diversion Bugs im Silizium (Errata) . Aber man konnte damit einigermassen leben. Mir machten sie bei Firmenprojekten damals in 2013+ keine Umstände. Die HAL Unterstützung ist allerdings auch umstritten. Manche hassen sie, andere kommen damit zurecht. Auch werden ab und zu Fehler bemängelt. Dann gibt es noch die LL-Peripheral Library die aus der früheren SPL (Standard Peripheral Library) entstanden ist. Mit der cubeMX SW kann man ein komplettes Framework graphisch zusammenklicken und es schreibt Dir dann ein minimal lauffähiges Skelett mit HAL Treibern für die gewünschten Peripheriefunktionen. Man braucht dann nur noch den eigenen Code hinzufügen. Mit cubeMX kannst Du alle on board Peripherie und CPU Funktionen einstellen. Auch Treiber für USB und File Funktions Bibliotheken werden bereit gestellt. Mit dem LPC2103 arbeitete ich anfangs auch mit dem Imagecraft Compiler. https://elmicro.com/de/iccarm.html Eine frühere Version von Coocox unterstütze den auch. Allerdings war dieses Package kontrovers je nachdem wen man fragte. Ich hatte aber keine Probleme und funktionierte auch ohne Mutterschiff tadellos. Auch eine frühere freie Version von Atollic unterstützte den LPC2xxx. Gruß, Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Mit den erwähnten Sachen hast Du eine solide Basis mit minimalen > Frustfaktor. Ich bin der Meinung, dass es am Anfang am Besten ist, mit > firmeneigener HW und SW anzufangen. Das funktioniert dann sozusagen aus > der Schachtel heraus. Genauso geht es eben mit NXP auch. Es gibt also keinen Grund, umzusteigen. Allerdings würde ich auch, wie schon erwähnt, auf einen aktuellen uC gehen. Die LPC176* gibt es alle in LQFP100. Der LPC4370 dürfte allerdings etwas Overkill sein, wenn man vom LPC2148 ausgeht.
Andreas B. schrieb: > Gerhard O. schrieb: >> Mit den erwähnten Sachen hast Du eine solide Basis mit minimalen >> Frustfaktor. Ich bin der Meinung, dass es am Anfang am Besten ist, mit >> firmeneigener HW und SW anzufangen. Das funktioniert dann sozusagen aus >> der Schachtel heraus. > > Genauso geht es eben mit NXP auch. Es gibt also keinen Grund, > umzusteigen. Allerdings würde ich auch, wie schon erwähnt, auf einen > aktuellen uC gehen. Die LPC176* gibt es alle in LQFP100. Der LPC4370 > dürfte allerdings etwas Overkill sein, wenn man vom LPC2148 ausgeht. Danke für den Tip. Ich habe mich für die LPC schon lange nicht mehr interessiert. Mein letztes Projekt in der Arbeit war anfangs mit LPC3468 und spaeter mit dem verbesserten LPC1788, aber da benutzten wir durchgehend den IAR-Compiler. Neugierig auf Deinem Hinweis hier, sah ich mir gerade an, was NXP zu bieten hat. Das MCUXpresso Toolset sieht vielversprechend aus und vielleicht lohnt es sich da wieder mal reinzuschauen. Aber sehr motiviert bin ich da eigentlich nicht, weil wir uns zu sehr auf ST fokussiert haben. Man baut sich über die Jahre halt ein Nest aus dem später nur schwer in die Welt hinauszublicken ist;-)
> den LPC4370 erwähnen. Letzterer ist allerdings BGA-only, und schon > etwas komplexer. Lohnt sich aber! Alleine der ADC ist wohl absolut konkurrenzlos. Vanye
Gerhard O. schrieb: > Man baut sich über die Jahre halt ein Nest aus dem > später nur schwer in die Welt hinauszublicken ist;-) Für Dich gibt es also auch keinen Grund, umzusteigen. ;-)
Vanye R. schrieb: >> den LPC4370 erwähnen. Letzterer ist allerdings BGA-only, und schon >> etwas komplexer. > > Lohnt sich aber! Alleine der ADC ist wohl absolut konkurrenzlos. > > Vanye Wenn man sein WLAN nicht braucht, hat ein Rabbit 5000 auch AD-Wandler mit 10 bit und 50 Msps. Wenn man ihn noch bekommt... Und ist gegenüber dem LPC4370 recht einfach gestrickt. Das richtige Zitieren musst du aber wohl noch üben.
Gerhard O. schrieb: > hast Du eine solide Basis mit minimalen > Frustfaktor Hallo Gerhard, der war gut! Nein ehrlich, ich habe auch vor Jahren mit Keil und NXP angefangen, und die IDE in einer sehr guten Erinnerung. Durch AG-Wechsel stieg ich dann auf ST um und kann alles unterstreichen, was Du sagst. Aber wenn DAS der minimale Frustfaktor ist, dann bin ich überglücklich, die anderen nicht zu kennen! Doch heutzutage funtioniert das ganz gut. Üble Bugs in der CubeIDE 1.17.0 haben mich viel Zeit und Nerven gekostet, aber okay, das ist bei anderen sicher auch mal der Fall. Was mich permanent nervt, ist dieser riesige Flickenteppich an Informationsquellen. Okay, Datenblatt und RefMan (>3.000 Seiten!), aber dann geht es los: viele AppNotes, Quellen in den Sourcen der HAL, die mitgelieferten CHM in der HAL sind den Speicherplatz nicht wert. Weil nie jemals einer für nötig gehalten hat, ausführlich zu erläutern, was das macht und wie man es einsetzt. Tolle Webinare, aber leider von Leuten, die kein Wort Englisch rausbringen. Okay, die Einleitung ist oft in fließendem Amerikanisch, aber labert nur dünnes Zeug. Und die Zusammenhänge von den in CubeMX verwendeten Begriffen, den Infos auf Registerebene in den RefMans und denjenigen in der HAL aufzudröseln, ist auch extrem spaßig. (für mich zumindest). Ach ja, das Doxygen-generierte HAL-Manual ist ebenso für die Füße. Zu jeder neuen Cube-Firmware liefern sie hunderte Beispiele mit. KEINS davon ist ausführlich dokumentiert. Viele sind noch auf dem veralteten Stand von anno.... Viele funktionieren dann auch nicht, aber es gibt ja die Community und das Wiki... Und ChatGPT... Ich schlage mich gerade schon seit vielen Stunden mit dem F429Disc1 samt LCD und Framebuffer herum. Beispiele funktionieren nicht, schon erwähnt. Aus den Projektstrukturen, die in Eclipse übel gemappt werden durchzublicken, wenn BSP und Device-Treiber im Spiel sind, treibt mich regelmäßig an meine Grenze. Bei der Zusammenarbeit von FMC und LTDC finde ich immer noch nicht den Grund, warum das LCD falsch konfiguriert und nur flimmernde Zeilen zeigt. Naja, der geprügelte Hund bleibt bei seinem Herrchen und ich werde weiter STM einsetzen. Jetzt fühle ich mich immerhin etwas erleichtert! ;-)
> Wenn man sein WLAN nicht braucht, hat ein Rabbit 5000 auch > AD-Wandler mit 10 bit und 50 Msps. Ist aber wesentlich weniger wie 12Bit und 80Msps oder? Vanye
Vanye R. schrieb: >> Wenn man sein WLAN nicht braucht, hat ein Rabbit 5000 auch >> AD-Wandler mit 10 bit und 50 Msps. > > Ist aber wesentlich weniger wie 12Bit und 80Msps oder? > > Vanye 12 bit und 80 Msps in BGA sind nicht einfach zu händeln. Gut macht es TI im Pinlayout seiner TMS320F28xyx. Da sitzen GNDA, über die Analogeingänge, bis zu VCCA wie die Spatzen auf einem Ast nebeneinander. Die 10 bit und 50 Msps sind auch praxisbewährt, benutzt der Rabbit die doch normalerweise um sein WLAN zu demodulieren. Farblich dazu passende DAs hat er ja auch. Von wesentlich würde ich bei Unterschieden, die grösser als eine binäre Grössenordnung sind, sprechen.
:
Bearbeitet durch User
> 12 bit und 80 Msps in BGA sind nicht einfach zu händeln. Habs laufen, funktioniert gut. > Von wesentlich würde ich bei Unterschieden, die grösser als eine > binäre Grössenordnung sind, sprechen. Ich schon etwas frueher. :) Vanye
Der Threadstarter scheint gerne in altem Kram herumzugraben; anderswo will er ein Flash-ROM in einem SAT-Reciever auslesen, das an einem obskuren Controller mit MIPS-Kern hängt, der vor 25 Jahren mal aktuell war.
Angehängte Dateien:
-
20260328_122407.jpg
200 KB
LPC4337JBD144 von NXP gut genug?) Den NXP LPC2148 werde vielleicht auch paar Stück besorgen, kostet paar Dollar. Also eine Programmierungsumgebung umsonst? Ich möchte möglichst effizient und hardwaregebunden lernen, ohne Kosten zu verursachen. Danke.
:
Bearbeitet durch User
Jük P. schrieb: > Also eine Programmierungsumgebung umsonst? Die gibt es für praktisch jeden µC umsonst, auch für solche Fossilien. Jük P. schrieb: > NXP LPC2148 Magst Du es besonders alt? Warum tust Du Dir das an? Auch das ist ein ARM7TDMI. Der RP2040 kostet bei Reichelt nur 77 Cent. Gut, dem musst Du noch ein SPI-Flash beischnallen, aber das ist's dann auch. https://www.reichelt.de/de/de/shop/produkt/raspberry_pi_-_rp2040_arm_cortex-m0_-306486 Und eine fertige, bastelfreundliche Platine gibt es auch, das ist der Raspberry Pi Pico https://www.reichelt.de/de/de/shop/produkt/raspberry_pi_pico_rp2040_cortex-m0_microusb-295706
Jük P. schrieb: > Also eine Programmierungsumgebung umsonst? Du bist also echt zu faul, in den oben angegebenen Link mal nachzuschauen?
Andreas B. schrieb: > angegebenen Link mal nachzuschauen Doch ich habe es mir kurz angesehen. Ich könnte auf die schnelle da nichts zu den Kosten finden. Wenn es die umsonst in vollen Umfang steht, ist perfekt. Ich muss dann nur noch Platinen malen und mal ran gehen. Mit Keil stand da auch nicht sofort erkennbar das es eine bezahlte Umgebung ist... Danke.
Hallo Gunnar, "Hallo Gerhard, der war gut! Nein ehrlich, ich habe auch vor Jahren mit Keil und NXP angefangen, und die IDE in einer sehr guten Erinnerung." ... ( kann leider beim iPad nicht Text markieren im üblichen Sinn) Das ist ja leider eine einzige lange Horror Story bei Dir und bin fast schockiert. Du hattest also offensichtlich maximalen Frustfaktor! Uns ging es wesentlich besser. Wie unterschiedlich es einem doch gehen kann. Aber durch einige Deiner Schwierigkeiten mussten auch wir uns hindurchbeissen. Aber wie gesagt, es ist nun schon lange Geschichte. Wir fingen vor vier Jahren ein großes Design mit dem L496 an. Ja, es gab damals in der Tat hin und wieder Probleme mit der HAL und setzten teilweise auch die LL SPL ein oder händische Krücken. Aber nach den anfänglichen Wehwehchen pegelte sich alles ein. Wir teilten die SW Architektur in ein Application Layer Bereich und einen sogenannten Commonlib Bereich ein. Die CL enthält den ganzen HAL Kram und die AL die eigentliche Anwendung. Da muß man sich kaum noch um den CL Bereich kümmern und es arbeitet sich so ziemlich intuitiv. Die CL Einteilung setzte damals ein Kollege durch. Ein OLED Graphik Display wird über DMA (CL-Bereich) regelmässig frisch gehalten. Allerdings schrieb man damals auch im CL Bereich viel händischen Code. Der Display Treiber ist sviw. handgemacht. Aber da musste ich mich nie darum kümmern. Funktioniert so alles bestens. DOxygen verwenden wir nicht - Keiner mag es. Findet man auch nur im HAL Bereich von ST produziert. Wir verwenden übrigens eine etwas ältere und bestimmte Version (1.191) des IDEs im Team und halten sie nicht auf den neuesten Stand - Der Feind den man kennt, ist besser einsehbar. Wie gesagt, im Anwendungsentwicklungsstadium läuft das Ganze absolut gut und gleichmässig. Alles funktioniert wie es soll. Es kommt extrem recht selten vor im CL Bereich kleine Änderungen machen zu müssen. An Deiner restlichen Kritik ist schon viel Wahres. Die Seminare haben wir uns eigentlich deswegen auch kaum zu Gemüte geführt. Ich muß zugeben, daß die NXP Unterlagen wesentlich freundlicher und lesbarer im Umgang und Detail sind. In meiner Firma hat man sich aber nun auf ST festgelegt. Mit dem LPC1788 ließ sich gut arbeiten. Ab da kenne ich nur den IAR Compiler und Micrium. Am Rande vermerkt, mit einem alten Keil MC52 Compiler arbeite ich übrigens an alten Projekten auch noch sehr gerne. Wunderschön schlank ist der und intuitiv. Da bleibt mir nur Dir alles Beste zu wünschen und hast mein ehrliches Mitgefühl. Ich hatte das Glück erst etwas später mitzumachen, wo die Kollegen im Team die schwierigere Vorarbeit leisteten. Aber geflucht hat damals niemand. Mir scheint, daß Du auch Dich alleine gestellt bist. Da steht man dann ab und zu wirklich vor der Wand. Manchmal helfen die Synergien einer Team Atmosphäre bei kniffeligen Problemen. Gruß, Gerhard
:
Bearbeitet durch User
Harald K. schrieb: > Der Threadstarter scheint gerne in altem Kram herumzugraben Vielleicht ein Zweitaccount des alten Knackers?! Andreas B. schrieb: > Du bist also echt zu faul, in den oben angegebenen Link mal > nachzuschauen? Mir fällt statt "faul" noch ein anderes Wort ein...
:
Bearbeitet durch User
Gerhard O. schrieb: > Das ist ja leider eine einzige lange Horror Story bei Dir und bin fast > schockiert. Du hattest also offensichtlich maximalen Frustfaktor! Hallo Gerhard, nein, so schlimm ist es auch wieder nicht. Wenn ich ein recht simples Projekt mit ADC, DMA,SPI und USB "from scratch" aufbaue, dann klappt das für gewöhnlich ziemlich schnell. Die besagte 1.17. hatte Bugs, die den DMA nicht richtig konfigurierte, aber das waren nur mal ein paar Stunden Frust. Die Probleme habe ich primär mit deren vielen Beispielprojekten. Kaufte mir aus Neugier das besagte Disco Board, weil ich erwartete, damit schnell in die embedded GUI-Programmierung einsteigen zu können. Erste Enttäuschung: Das mitgelieferte Beispielprojekt funktioniert nicht! Touch spiegelverkehrt. Aber ich möchte nicht weiter den Fred kapern. Wenn ich mich von den vergangenen 3 Stunden Frust mit der FMC-Konfiguration wieder erholt habe, könnte ich ja mal einen neuen aufmachen, mit meinem konkreten Problem. Beste Grüße Gunnar
Rahul D. schrieb: > Vielleicht ein Zweitaccount des alten Knackers?! Nee, das ganz sicher nicht. Einerseits wären für den ARMe noch viel zu neumodisches Zeugs, andererseits kann der Threadstarter --zumindest laut seiner Selbstdarstellung in anderen Threads-- durchaus mit modernen Fertigungstechniken umgehen und z.B. BGAs "reballen". Wie eine Lötstelle Deines Verdachts aussieht, wollen wir ganz schnell wieder vergessen.
Harald K. schrieb: > Jük P. schrieb: >> Also eine Programmierungsumgebung umsonst? > > Die gibt es für praktisch jeden µC umsonst, auch für solche Fossilien. > > Jük P. schrieb: >> NXP LPC2148 > > Magst Du es besonders alt? Warum tust Du Dir das an? Auch das ist ein > ARM7TDMI. Wenn er den ARM7TDMI im Griff hat, wird er neuere ARMe als wohltuend einfacher erkennen. Zumindest die Kleineren. ☺ @TO: Such mal nach der Betty hier im Forum. In der steckt ein LPC2220. Das ist auch ein ARM7TDMI. Da gibt es auch Links zu Programmierhilfen. Vielleicht würde sogar ein Mitforist noch Betties in deine Richtung entsorgen wollen. ☺ > ... Pico-S.P.A.M. gelöscht ...
Cartman E. schrieb: > Wenn er den ARM7TDMI im Griff hat, wird er neuere ARMe als wohltuend > einfacher erkennen. Rätst Du ihm auch, mit Assembler anzufangen? Cartman E. schrieb: > Such mal nach der Betty hier im Forum. Ah, die "Lernbetty". Ein Paradebeispiel für einen hässlichen C-Stil. Cartman E. schrieb: >> ... Pico-S.P.A.M. gelöscht ... Klar, ein typischer und universell hilfreicher Cartman.
Harald K. schrieb: > Cartman E. schrieb: >> Wenn er den ARM7TDMI im Griff hat, wird er neuere ARMe als wohltuend >> einfacher erkennen. > > Rätst Du ihm auch, mit Assembler anzufangen? Wenn man beim ARM7TDMI die Betriebsmodi auseinanderhalten will, führt daran kaum ein Weg vorbei. Ob er damit nun anfängt, oder erst später hineinstolpert. ☺ > Cartman E. schrieb: >>> ... Pico-S.P.A.M. gelöscht ... > > Klar, ein typischer und universell hilfreicher Cartman. Ja, gerne doch. Immerhin, ein: > Vielen dank)
Moin, Also wenn ich wirklich µController programmieren lernen wollte und nicht nur hier die alten Oppas auf Trab halten, wuerde ich irgendwas weit verbreitetes, halbwegs Aktuelles hernehmen, wo man von freundlichen Chi-, Polli- oder Sande- nesen fuer einen Appel und ein Ei mit Evalboards zugeballert werden kann und einem die im www erhaeltlichen Tools zusagen. Erst wenn das Evalboard dann froehlich genau so vor sich hinblinkt, etc. wie man sich das gedacht und programmiert hat, dann ggf. mal selbst designte Hardware in Angriff nehmen. Ist erheblich erfolgversprechender, als irgendwelche ollen Kamellen aus dem Hut zaubern zu wollen oder mit Beweisfotos von irgendwelchen 1000fuesslern anzukommen. Gruss WK
Moin, Jük P. schrieb: > Ich weiß, was und wo ich hin will) Was natuerlich jedem, der deine Beitraege liest, voellig klar ist. scnr, WK
Beitrag #8029291 wurde von einem Moderator gelöscht.
Beitrag #8029293 wurde von einem Moderator gelöscht.
Jük P. schrieb: > 1 Stück NXP LPC2148 nun auch bestellt. > > Ich weiß, was und wo ich hin will) Warum ARM7TDI, wenn Cortex viel weniger Platz braucht und schlanker im Code ist und viele andere Vorteile hat? Das verstehe ich nicht ganz. Ich habe auch noch eine alte Olimex Bord mit dem LPC2103 herumliegen, aber Neues möchte ich damit eigentlich nicht mehr machen wollen. Es ist halt einige Zeit vergangen. Aber zum Lernen damals war es gut. Naja, Du hast schon Deine Gründe, diesen Weg einzuschlagen - "more power to you" - wie man bei uns sagen würde. Gerhard
Gerhard O. schrieb: > > Warum ARM7TDI, wenn Cortex viel weniger Platz braucht und schlanker im > Code ist und viele andere Vorteile hat? Der ARM7TDMI kann den Thumb Instruction Set.
:
Bearbeitet durch User
@TO: Es könnte trotzdem schlau sein, sich hier im Markt mal nach einer Betty umzusehen. Der JTAG-Anschluss ist auf einer Stiftleiste herausgeführt, und man hat ein betriebsbereites Testsystem für einen ARM7TDMI.
Dieter S. schrieb: > Gerhard O. schrieb: >> >> Warum ARM7TDI, wenn Cortex viel weniger Platz braucht und schlanker im >> Code ist und viele andere Vorteile hat? > > Der ARM7TDMI kann den Thumb Instruction Set. Das ist schon wahr; aber das ist nicht einmal das wichtigste Argument, weil Cortex uC Architektur und die der LPC2103 grundverschiedenste "Biester" sind; also eher ein Äpfel und Orangen Vergleich sind und deshalb meiner Meinung nach ein Tauziehen wenig sinnvoll ist - zum Spielen sind beide nett.
:
Bearbeitet durch User
Cartman E. schrieb: > @TO: > Es könnte trotzdem schlau sein, sich hier im Markt mal nach einer > Betty umzusehen. Der JTAG-Anschluss ist auf einer Stiftleiste > herausgeführt, und man hat ein betriebsbereites Testsystem für einen > ARM7TDMI. Was ist ein Betty? Gibt es hier bei uns in Canada nicht. Google meint es sei ein Robotstaubsauger.
Gerhard O. schrieb: > Cartman E. schrieb: > Was ist ein Betty? Gibt es hier bei uns in Canada nicht. Google meint es > sei ein Robotstaubsauger. Betty ist weiblich, und war mal als Universalfernbedienung mit Schnittstelle zur Aussenwelt gedacht. Dafür gab es dann eine Modembox und eine Scartbox. Da sich das System wohl nicht richtig am Markt durschsetzen konnte, haben die Entwickler als finalen Endzustand, auf alle Zusatzcimmicks verzichtet, und daraus "nur" eine lernfähige Fernbedienung gemacht. Und die konnte man in D zu sehr günstigen Preisen kaufen. Such einfach noch mal. ☻
Gerhard O. schrieb: > Warum ARM7TDI, wenn Cortex viel weniger Platz braucht und schlanker im > Code ist und viele andere Vorteile hat? Altersstarrsinn.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.