Hallo Leute, Ich möchte gerne mit dem programmieren vom uC anfangen. Kann mich nicht entscheiden, welches von dem beiden toolkits ich mir anschaffen soll. PSoC mit Display habe ich zu Hause. Oder reicht es erst mal aus um uC programmieren zu lernen. Gruß
In wenigen Stunden kommt mein PsoC 5 LP Kit per Post:) Damit wede ich meine Reise in die Welt der µC anfangen. Ich habe eben wenig Ahnung von µC, aber ich würde sagen PsoC ist um einiges aktueller und vielseitiger als diese veraltete 8-Bit µC Ich denke wenn man schon programmieren lernt, dann mal an den modernen µC
Wilder Kater mit Schwanz schrieb: > Ich habe eben wenig Ahnung von µC Dann würde ich lieber auf etwas einfaches, bewährtes, erprobtes, zuverlässiges und gut bekanntes setzen. Wilder Kater mit Schwanz schrieb: > als diese veraltete 8-Bit µC Da lehnst Du Dich aber sehr weit aus dem Fenster. Wie kommst Du darauf, daß länger am Markt = veraltet bedeutet? Veraltet ist etwas erst, wenn es nicht mehr den Markt dominiert. Ich bin schon gespannt, wieviele Dir hier helfen können, wenn die ersten Probleme auftauchen.
Peter Dannegger schrieb: > Wilder Kater mit Schwanz schrieb: >> Ich habe eben wenig Ahnung von µC > > Dann würde ich lieber auf etwas einfaches, bewährtes, erprobtes, > zuverlässiges und gut bekanntes setzen. Nein, ich persönlich habe keine Lust mich monatelang mit 8 Bit AVR/PIC zu beschäftigen, um später herauszufinden, dass die richtige (sprich. moderne und industrierelevante) µC ganz anders ticken und ich muss alles von vorne anfangen. > Wilder Kater mit Schwanz schrieb: >> als diese veraltete 8-Bit µC > > Da lehnst Du Dich aber sehr weit aus dem Fenster. > Wie kommst Du darauf, daß länger am Markt = veraltet bedeutet? > Veraltet ist etwas erst, wenn es nicht mehr den Markt dominiert. Veraltet im sinne, dass es schon seit Ewigkeit 32 bit µC gibt, die fast genau so viel kosten, aber deutlich mehr lesitzen.
Wilder Kater mit Schwanz schrieb: > Peter Dannegger schrieb: >> Wilder Kater mit Schwanz schrieb: >>> Ich habe eben wenig Ahnung von µC >> >> Dann würde ich lieber auf etwas einfaches, bewährtes, erprobtes, >> zuverlässiges und gut bekanntes setzen. > > Nein, ich persönlich habe keine Lust mich monatelang mit 8 Bit AVR/PIC > zu beschäftigen, um später herauszufinden, dass die richtige (sprich. > moderne und industrierelevante) µC ganz anders ticken und ich muss alles > von vorne anfangen. Das ist bei den meisten µC eh nicht der Fall... Wenn du einmal wirklich gelernt hast mit einem Typ umzugehen, wirst du mit anderen Controllern genauso zurecht kommen. Natürlich braucht es etwas einarbeitungszeit, aber wenn es dir nur darum geht mit µC warm zu werden, ist es egal mit welchen. Wenn du es für einen zukünftigen Job machst, dann weißt du jetzt eh noch nicht, was da genutzt wird - vielleicht auch noch 8051, und dann kommst du und kennst nur die "modernen" IDEs, die Treibergeneratoren uvm. haben.
Wilder Kater mit Schwanz schrieb: > Nein, ich persönlich habe keine Lust mich monatelang mit 8 Bit AVR/PIC > zu beschäftigen, um später herauszufinden, dass die richtige (sprich. > moderne und industrierelevante) µC ganz anders ticken und ich muss alles > von vorne anfangen. Aha. Und dafür suchst du dir dann ausgerechnet Nischenprodukte wie einen PSOC aus? Naja, musst du selbst wissen. Das Einzige, was ich noch verstehen würde wäre, sich als Alternative irgendeinen Cortex-Mdingsda ARM zu nehmen. Ansonsten kannst du vergessen, dass es irgendeinen Hersteller gäbe, der Produkte für etwas längere Zeit verkauft, die nicht „indunstrierelevant“ wären. Der wäre nämlich pleite, von den paar Bastlerhanseln finanziert keiner eine Controller-Chipentwicklung.
Wilder Kater mit Schwanz schrieb: > dass die richtige (sprich. > moderne und industrierelevante) µC ganz anders ticken und ich muss alles > von vorne anfangen. Wie kommst Du bloß auf diese schmale Brett? Ein C-Programm auf einem AVR läuft in der Regel auch auf einem Cortex-M3. Nur die IO-Zugriffe muß man entprechend kapseln, um sie dann leicht anpassen zu können. Und ein umständliches Programm, was auf dem AVR CPU-Leistung vergeudet, vergeudet sie umso mehr auf dem ARM. Die auf einem kleinen MC gesammelten Erfahrungen sind niemals nutzlos, sondern im Gegenteil äußerst hilfreich. Wilder Kater mit Schwanz schrieb: > die fast > genau so viel kosten, aber deutlich mehr lesitzen. Jaja, typisch Geiz ist geil Mentalität. Hauptsache möglichts viel fürs Geld, auch wenn ich 90% davon garnicht benötige. Die Frage ist natürlich, was Du überhaupt machen willst. Wenn Du eh nichts mit echter Hardware (Sensoren, Motoren, LEDs, Relais usw.) am Hut hast, sondern nur GUIs, Spiele, Video, Audio programmieren willst, dann ist ein 8Bitter wirklich nichts für Dich.
eigentlich hatte michi die Frage gestellt: Entweder psoc oder stk500 und daß er das Controller-programmieren lernen möchte. Da kann ich nur dringend empfehlen, mit dem 8-Bit-System stk500 anzufangen. Das ist ein erweiterbares Entwicklungsboard mir Programmiermöglichkeit, das für den Anfänger und den Fortgeschrittenen alle Möglichkeiten zum Einstieg bietet und die Atmel-Palette ist riesengroß. Wenn Du das drinhast, kannst Du - ohne den Faden zu verlieren - immer noch dickere Bretter bohren. Das Forum bietet für den Einsteiger hervorragende Tutorials und gute Hilfe. Lerne C oder Bascom oder auch Assembler und es wird Dir später eine wesentliche Hilfe sein, 8-Bit-Systeme zu verstehen. Im Übrigen gibt es auch noch preiswertere Entwicklungsumgebungen als stk500: Z.B. Pollin Ev-Board, Test- und Programmierboards von Radig und Rowalt und, und und. Ich möchte mein stk500 nicht missen. Gruß wilials
Hallo Michi, vielleicht verrätst Du uns etwas über Deine Voraussetzungen (Kenntnisse, Programmiersprachen?) Obwohl ich die PSoC3 und 5 sehr schätze, würde ich einem Anfänger davon abraten, vor allem weil es keine aktuelle deutsche Literatur, keine deutsche Community und z. B. in diesem Forum kaum Resonanz gibt, wenn man tiefer gehende Fragen hat. Mir haben C- Kenntnisse und Englisch geholfen, trotzdem einigermaßen zurecht zu kommen. Für ARM, AVR und viele andere Familien findest Du wenigstens Tutorials und Beispielprogramme und ein Forum. Das trifft übrigens auch für Arduino, Pinguino usw. zu... Gruß Wolfgang
Peter Dannegger schrieb im Beitrag #3202172 > Jaja, typisch Geiz ist geil Mentalität. Hauptsache möglichts viel fürs > Geld, auch wenn ich 90% davon garnicht benötige. > > Die Frage ist natürlich, was Du überhaupt machen willst. > Wenn Du eh nichts mit echter Hardware (Sensoren, Motoren, LEDs, Relais > usw.) am Hut hast, sondern nur GUIs, Spiele, Video, Audio programmieren > willst, dann ist ein 8Bitter wirklich nichts für Dich. Geiz hat damit nichts zu tun. Man muss sich einfach auf dem aktuellsten Stand halten. Wozu 8 bit, wenn es schon seit Ewigkeit 32 gibt?
Peter Dannegger schrieb: > Ein C-Programm auf einem AVR läuft in der Regel auch auf einem > Cortex-M3. Nur die IO-Zugriffe muß man... Peter, also erstmal eines: Ich befürchte, daß es wenig Zweck hat, wilden Tieren die höhere Mathematik erklären zu wollen. Da ist einfach keine Basis da. Wer meint, daß er sich immer nur mit dem größten und dicksten gizmo befassen will, hat mental nicht die richtige Voraussetzung für einen Entwickler in der Industrie. Soll sich nen Manta(-Nachfolger) kaufen. Und zu deiner obigen Bemerkung: Das ist natürlich zu 90% Quatsch, weil bei der uC-Programmierung ja gerade die Hardware, vor allem Board und Peripherie völlig anders ist und nix außer solchen Sachen wie Ein- und Ausgabekonvertierungen von einem uC auf nen anderen übernommen werden kann. Naja, und wie jemand auf die Idee kommt, grad nen PSOC als Einstieg zu wählen, ist mit unverständlich. Die Hauptattraktion bei diesen PSOC's ist ja grad, daß sie ein bissel programmierbare Logik enthalten, mit der man (eventuell) was tolles anstellen kann. Aber dazu sollte man nicht 2 Lern-Baustellen offen haben, sondern bereits sowohl mit dem uC auf dem Chip umgehen können als auch wenigstens mit CPLD's umgehen können. Die Dinger sind also das komplette Gegenteil eines Einstiegs-Kit's. In diesem Lichte halte ich das ganze Gebrüste hier für reines Angebertum. W.S.
W.S. schrieb: > Und zu deiner obigen Bemerkung: Das ist natürlich zu 90% Quatsch Im Gegensatz zu dir haben wir allerdings von Peter schon hinreichend guten Code gesehen, dass er mit seinen Aussagen deutlich glaubwürdiger rüberkommt als du. Selbstverständlich kann man immer auch unportabel programmieren, aber man muss es nicht. Mit ein wenig Abstraktion bekommt man Projekte gebacken, bei denen man ausreichend große Teile des Codes auch über viele verschiedene Plattformen gemeinsam nutzen kann. Betriebssysteme wie NetBSD zeigen das übrigens schon seit Jahren sehr eindrücklich.
Böser Kommunist schrieb: > Wozu 8 bit, wenn es schon seit Ewigkeit 32 gibt? Weil ich 0,4/0,5 Pitch nicht mehr selber löten kann. Ein ATtiny25 im SO-8 ist einfach viel besser handhabbar. Ich hab größtenteils komplexe Abläufe zu steuern, da ist ein ATiny25/24/261 (je nach benötigten IOs) einfach ideal geeignet. Die 32Bit würden mir bei dem ganzen Pingewackel genau soviel nützen, wie ein Kropf.
Peter Dannegger schrieb: > Böser Kommunist schrieb: >> Wozu 8 bit, wenn es schon seit Ewigkeit 32 gibt? > > Weil ich 0,4/0,5 Pitch nicht mehr selber löten kann. Ein ATtiny25 im > SO-8 ist einfach viel besser handhabbar. > > Ich hab größtenteils komplexe Abläufe zu steuern, da ist ein > ATiny25/24/261 (je nach benötigten IOs) einfach ideal geeignet. > > Die 32Bit würden mir bei dem ganzen Pingewackel genau soviel nützen, wie > ein Kropf. Pff, 0.4 Pitch kann man problemlos löten. Habe ich schon selber mehrmals getan. Hauptsache man trinkt nicht zu viel..;)
Jörg Wunsch schrieb: > Betriebssysteme wie NetBSD zeigen das übrigens schon seit Jahren sehr > eindrücklich. Abstraktion? Jörg, denk mal an NetBSD auf nem PIC16Fxxx.. Wie dick müßte der sein, um dort sinnvoll abstrahieren zu können? Eigentlich ist es schon zu spät, um heute noch zu stänkern, aber gerade bei kleinen 8 Bit Systemen wird wenig abstrahiert, sondern ne möglichst schlanke Firmware gemacht, die genau dort das tut, was sie soll und nicht mehr. Ach, gut Nacht für heute. W.S.
So wie es hier aussieht, handelt es sich wieder um die Menschen, die nur 8- Bit können. Diese Menschen verteidigen ihre 8 Bit Familie , weil die einfach nicht zugeben wollen, dass ihre kenntnisse schon seit ca.10 Jahren veraltet sind;) Halt:"Waaas, ich brauche keine 32, man kann sowieso mit 8 bit alles machen. 8 bit sind sogar oft besser...*weil ich nur das kann:(((*" Ähnlich wie die Menschen, die ihr ganzes Leben den harten Weg mit Assembler programmiert haben Diese sind immer noch der Meinung, assembler ist besser als C. Und raten tatsächlich jedem mit assembler anzufangen. In der Tat wollen sie nicht zugeben, dass ASM schon zur Vergangenheit gehört..;)
W.S. schrieb: > Jörg, denk mal an NetBSD auf nem PIC16Fxxx.. Darum ging es nicht. Es ging darum, dass man die Hardware selbst abstrahieren kann. Das kann man auch bei Controllern, natürlich muss man in der gleichen Größenordnung bleiben. Böser Kommunist schrieb: > handelt es sich wieder um die Menschen, die nur 8- Bit können. Du bist ein Troll. plonk
W.S. schrieb: > bei kleinen 8 Bit Systemen wird wenig abstrahiert Nur weil Du es nicht machst, heißt das noch lange nicht, daß es alle anderen auch so machen. Ich hab z.B. in einer Steuerung eine Task, die den Druckgradient überwachen soll. Und die ruft dazu eben get_adc() und get_tick() auf. Diese IO-Funktionen müßte ich dann beim Umstieg auf ARM anpassen. Die eigentlichen Steuerungs- und Überwachungs-Tasks kann ich aber zu 100% übernehmen. W.S. schrieb: > sondern ne möglichst > schlanke Firmware gemacht Nun genau das erreiche ich damit, daß ich alles in möglichst kleine Module aufteile. Sobald etwas mehrmals benötigt wird oder eine abgeschlossene Einheit bildet, wird eine Funktion daraus. Was man bei Anfängern aber leider oft sieht, sind riesige Copy&Paste Monster. Man hat eine riesen Wust an Code, wo alles miteinander verwoben ist und keiner mehr durchsieht. Sowas läßt sich natürlich nicht portieren. Und solche Copy&Paste Monster brauchen auch erheblich mehr Flash, als modulare Programme. Ich wundere mich immer wieder, wenn manche selbst bei völlig einfachen Aufgaben über zu kleinen Flash klagen. Bei Copy&Paste Code kann selbst der beste Compiler nichts optimieren, Common subexpression elimination kann ja nicht zaubern.
Böser Kommunist schrieb: > Wozu 8 bit, wenn es schon seit Ewigkeit 32 gibt? Ich stelle mir gerade eine moderne Zahnbürste mit 32Bit vor. g
Jemand schrieb: > Böser Kommunist schrieb: >> Wozu 8 bit, wenn es schon seit Ewigkeit 32 gibt? > > Ich stelle mir gerade eine moderne Zahnbürste mit 32Bit vor. *g* Na, vor 20 J könnte man auch sowas schreiben "ich stelle mir gerade eine Zahnbürste mit einem mikrocontroller vor.haha" :-P
hallo, erst mal, vielen dank an alle für die Ratschläge. ich habe bisschen Grundkenntisse in C (ich denke,ich werde auch bei C bleiben), ob die gut sind werden wir sehen ;) Kenntnisse in uC habe ich noch keine. > Im Übrigen gibt es auch noch preiswertere Entwicklungsumgebungen als > stk500: Z.B. Pollin Ev-Board, Test- und Programmierboards von Radig und > Rowalt und, und und. Danke für den Tip. Es reicht ja eigentlich auch aus, wenn ich mir eine günstige Entwicklungsumgebung kaufe? würde das auch für den Anfang erst mal reichen? http://www.pollin.de/shop/dt/MTY5OTgxOTk-/Bausaetze_Module/Bausaetze/ATMEL_Evaluations_Board_Version_2_0_1_Bausatz.html oder sollte ich mir sofort ein anständiges Board kaufen? Wie sieht es aus mit einem Buch oder reichen erst mal hier die Tutorial etc.? gruß michi
moin ich würde dir zum Anfang schlicht und einfach zu einem Steckbrett + 2 ATmega 8 (168) und dem original Atmel AVR ISP2 raten. Damit hast du ein auch in zukunft zu benutzendes prog. Gerät das ohne Kopfstand und wahnsinnig machenden Treibern auf nahezu allen Plattformen zuverlässig funktioniert.Das ISP2 kostet ca.39,95€. mfg
>Nein, ich persönlich habe keine Lust mich monatelang mit 8 Bit AVR/PIC >zu beschäftigen, um später herauszufinden, dass die richtige (sprich. >moderne und industrierelevante) µC ganz anders ticken und ich muss alles >von vorne anfangen. Auf Nummer sicher geht man mit dem 8051.
Auf eienm PSoC 5 arbeitet doch ein irgendein arm m0, m3, m4? Warum dann nicht ein einfaches m0, m3, oder m4 board von nxp, st & co?
Dann hast Du zumindest einen Core aus der "Verwandschaft".
Ja, PsoC 5 hat M3 in sich. Was es noch interessanter macht, ist die integrierte programmierbare digitale/analoge Schaltung. So hat PsoC auch Komparatoren, Opamps etc, die man beliebig verbinden kann.
Jörg Wunsch schrieb: > Darum ging es nicht. Es ging darum, dass man die Hardware selbst > abstrahieren kann. Das kann man auch bei Controllern, natürlich > muss man in der gleichen Größenordnung bleiben. Na siehste. OK, mit dem NetBSD hast du angefangen.. Aber mit deinem 3. Satz sagst du im Grunde genau das Gleiche, wie ich es gesagt habe. Programme, die für einen 8 Bitter entworfen wurden, sind in den aller-aller-allermeisten Fällen inhaltlich so veschieden von dem, was auf nem 32 Bitter en vogue ist, daß Peter sich mit seiner Behauptung schlichtweg zu weit aus dem Fenster gelehnt hat. Wenn man hingegen in der gleichen Liga bleibt (ARM versus MIPS versus SH versus Altera-dingsbums), dann sieht das anders aus. Peter Dannegger schrieb: > Ich hab z.B. in einer Steuerung eine Task, die... Ja Peter, ich will dir das ja garnicht ausreden. Ich mach sowas (auf 32 Bittern) ja ähnlich. Vergleiche mal die Boop-Software mit meiner Lernbetty, da siehst du den Unterschied. Aber das Argument deiner Antwort auf die kühnen Bemerkungen des wild gewordenen Katerli war daneben. Der Junge träumt von allumfassender Großartigkeit obwohl es nach meiner Einschätzung (quod licet jovi non licet bovi) dazu bei ihm keine Veranlassung gibt. Wer nicht erkennen kann oder will, daß es im Berufsleben eben auch triftige Gründe gibt, gelegentlich ganz kleine uC zu benutzen und diese eben wegen ihrer Kleinheit in Assembler zu programmieren, der ist eben auf dem Holzwege. W.S.
W.S. schrieb: > Aber mit deinem 3. Satz sagst du im Grunde genau das Gleiche, wie ich es > gesagt habe. Programme, die für einen 8 Bitter entworfen wurden, sind in > den aller-aller-allermeisten Fällen inhaltlich so veschieden von dem, > was auf nem 32 Bitter en vogue ist, daß Peter sich mit seiner Behauptung > schlichtweg zu weit aus dem Fenster gelehnt hat. Ich arbeite beruflich an einer Software, die problemlos zwischen MegaAVR, AVR32, XmegaAVR, ARM7, Cortex-M3 und nun Cortex-M4 portabel gehalten worden ist. Sind halt alles klassischen Controller, und das ist, was ich mit „einer Klasse“ meinte. Allerdings hat sich natürlich für die Abstraktionsebenen seinerzeit jemand Gedanken gemacht. Trotzdem ist das nicht per se ineffektiv, auch nicht auf 8-Bittern, denn man kann durchaus mit heutigen Compilern Abstraktionen schreiben, die die Compiler trotzdem noch effektiv umsetzen können. NetBSD wiederum abstrahiert problemlos zwischen diversen Computern auf Basis vieler verschiedener Universal-CPUs, angefangen von M68k bis zu den heutigen 64-Bittern. Auch wieder eine Klasse für sich, wenn auch eine sehr große. Der Gag ist bei solchen Systemen, dass du beispielsweise einen Treiber für eine PCI-Karte einmal auf einem i386-PC schreibst und testest, ihn damit aber danach 1:1 auf Sun UltraSPARC-Systemen nutzbar gemacht hast (wenn du den Job ordentlich getan hast), die halt ebenfalls einen PCI-Bus aber auf völlig anderer Basishardware implementieren. > … der ist eben auf dem Holzwege. Wie ich weiter oben bereits schrieb: kein Mensch glaubt dir deine vollmundig hingeworfenen Aussagen, solange wir noch nie was anderes als große Worte von dir hier gesehen haben. Von Peter jedenfalls haben wir schon ausreichend Code gesehen.
Jörg Wunsch schrieb: > Von Peter jedenfalls > haben wir schon ausreichend Code gesehen. z.B. die geradezu geniale Entprellroutine, die vermutlich mit minimalen Anpassungen auch auf dickeren Schifen als AVR benutzt werden kann. asdfg
W.S. schrieb: > gelegentlich ganz kleine uC zu benutzen und diese eben wegen ihrer > Kleinheit in Assembler zu programmieren Da muß ich Dir widersprechen, Kleinheit ist definitiv kein Grund für Assembler. Auch einen kleinen ATtiny13 (1kB Flash) programmiere ich in C. Zu 99% dürfte der Hauptgrund für Assembler sein, daß derjenige mit C noch auf Kriegsfuß steht oder erst noch MC-Anfänger ist. Nur für sehr sehr wenige Spezialanwendungen kann Assembler auf 8Bittern vielleicht nötig sein. Und für einen mit wenig C-Erfahrung mal etwas öfter.
Peter Dannegger schrieb: > Da muß ich Dir widersprechen.. Das Thema hatten wir schon früher mal und meine Meinung zu diesem Thema ist gänzlich anders als deine. Deine Meinung zeigt eigentlich nur, daß du "noch auf Kriegsfuß" stehst mit Assembler und daß du dieses kühn verallgemeinerst. Mich ärgert es, daß dir an Bescheidenheit fehlt. Anstatt zu sagen "Ich, der Peter mag/verstehe Assembler nicht und schreibe deshalb lieber C" versuchst du, das was dir nicht schmeckt verächtlich zu machen, als ob andere Assembler nur deshalb schreiben, weil sie zu doof für C wären. Kein guter Stil. Und auch nicht sachgerecht. W.S.
W.S. schrieb: > Deine Meinung zeigt eigentlich nur, daß > du "noch auf Kriegsfuß" stehst mit Assembler und daß du dieses kühn > verallgemeinerst. Ich habe früher auch lange Jahre Assembler programmiert (8051) und stand mit C auf Kriegsfuß. Dann mußte ich aber ein bestehendes C-Projekt weiter entwickeln und habe dabei gemerkt, daß C um Längen produktiver und übersichtlicher ist. Ich habe also genau wie Du viele Jahre lang gedacht, Assembler wäre das einzig wahre. Ich habe aber erkennen müssen, daß ich falsch lag und gebe das auch unumwunden zu. Und auch den WINAVR gab es 1997 noch nicht, daher habe ich die AVRs auch erst in Assembler programmiert. Es sind nur noch 2 ältere Geräte in Produktion, wo ich MCs noch in Assembler programmiert habe, aber deren Ablösung steht kurz bevor. In den älteren Beiträgen findest Du auch reichlich Assemblercode von mir. Und die 64Bit Erweiterung (mul, div) des AVR-GCC beruht auf meinem Assemblercode. In 8051/AVR Assembler bin ich immer noch topfit. Ich mache nur nichts neues in Assembler mehr. Du kannst mir also ruhig glauben, daß ich ganz genau weiß, wovon ich rede.
Peter Dannegger schrieb: > Du kannst mir also ruhig glauben, daß ich ganz genau weiß, wovon ich > rede. Hör auf Peter. W. S. weiß schon immer alles besser, ist dir das noch nicht aufgefallen? Nur seine Meinung gilt, aber außer großen Worten hat man von ihm noch nichts gesehen. Keine hilfreichen Codeschnipsel, kein Opensource-Projekt, kein kommerzielles Projekt, bei dem er behauptet, der wesentliche Ausführende zu sein. Mit solchen Leuten hast du es nicht nötig weiterzudiskutieren.
Wäre mal ne interessante Frage, in welchem Simpelstgerät ein 32bitter tickt. Zumindest ist bei den Cypress PSoCs der Zielmarkt z.B. Waagen, bei denen alles wesentliche auf dem PSoC integriert wurde, inkl. LCD-Ansteuerung. Und NXP bewirbt ja gerade 32Bit in 8Bit-Gehäuse. Aus der Sicht der Halbleiterhersteller ist der 32 genauso teuer wie der 8 Bit. Copy&Paste von Masken und Prüfapparaturen einfach billiger als ne zweite (8-Bit) Linie parallel zu fahren. Und so wird es auch bei 64Bit werden!!
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.