Hallo zusammen, ich bin Hobby-Mikrocontrollerbastler hatte bisher ausschließlich mit midrange core PICs (PIC16) und PIC24 zu tun. Erstere kenne ich sehr gut, letztere ein wenig. Beide verfügen über getrennte Programm- und Datenspeicher. Mein Eindruck ist jedoch der, dass die Trennung von Programm- und Datenspeicher eigentlich nur bei kleinen Mikrocontrollern üblich ist. Um so mächtiger sie werden, um so eher scheint man dazu überzugehen Programm- und Datenspeicher zusammenzulegen. Um meinen Horizont zu erweitern, würde ich mich nun gerne mit einem Mikrocontroller beschäftigen bei dem das der Fall ist. Wie der Betrieb mit gemeinsamen Code-/Datenspeicher funktioneren soll ist mir, muss ich leider gestehen, noch ein Rätsel. Trennung von Code und Daten ist für mich etwas derart fundamentales, dass ich noch Denkblockaden habe etwas anderes wirklich zu verstehen. Welchen µC / welche Architektur könnt ihr mir also für Studienzwecke empfehlen? Ich habe nicht vor, tatsächliche Projekte damit zu realisieren. Wie kompliziert die für den Betrieb notwendige Beschaltung ist, ist also nicht weiter relevant. Sollte ich mir überhaupt den µC zulegen (und mich nicht darauf beschränken das Programmers Reference Manual und den vom Compiler generierten Code zu studieren), würde ich mir wohl eine Demoboard zulegen. Vielen Dank! Manuel
PIC32. Die Tools hast Du schon, die Peripherie ist sehr ähnlich zu PIC24. Was neu für Dich ist, ist der MIPS Prozessorkern. fchk
Wie wäre es mit ARM-Cortex M0/3/4, da wäre z.B. der STM32F4xx. Demoboard gibt es für ca 15€ www.st.com/nucleoF401RE-pr
Manuel W. schrieb: > Ich habe nicht vor, tatsächliche Projekte damit zu realisieren. Und was dann damit tun? Leg dir von Pollin für 3.99 ne Betty Fernbedienung zu, damit kannst du herumspielen so viel du willst und programmieren so viel du willst - und zwar mit Daten und Code im gleichen Flashrom und wenn du willst, dann eben auch beides im RAM. W.S.
Allenfalls ein antiquarisches 8086 Buch zulegen ...
Manuel W. schrieb: > Mein Eindruck ist jedoch der, dass die Trennung von Programm- und > Datenspeicher eigentlich nur bei kleinen Mikrocontrollern üblich ist. Um > so mächtiger sie werden, um so eher scheint man dazu überzugehen > Programm- und Datenspeicher zusammenzulegen. Nein. Es ist lediglich eine Architektur-Entscheidung. http://www.mikrocontroller.net/articles/Prozessorarchitekturen http://de.wikipedia.org/wiki/Harvard-Architektur http://de.wikipedia.org/wiki/Von-Neumann-Architektur >Wie der Betrieb mit gemeinsamen Code-/Datenspeicher >funktioneren soll ist mir, muss ich >leider gestehen, noch ein Rätsel. Es gibt den Flashspeicherbereich und den Rambereich. Die Bereiche sind durch ihre unterschiedliche Adressen getrennt. Für einen 64k Bereich denkbar wären z.B. 48k Flash und 16k Ram. Also z.B. 0x0000-0x3FFF Rambereich und 0x4000-0xFFFF Flashbereich. Gruss
Code und Daten im selben Addressraum zu haben kommt davon her, dass es sich um viel, sehr viel Code handeln kann, der eh von einem Medium geladen werden muss, dh der Code kommt sowieso ins RAM, und die Daten auch. Man kann die Beiden durch einen Adressdecoder wieder trennen.
Siebzehn Zu Fuenfzehn schrieb: > Code und Daten im selben Addressraum zu haben kommt davon her, dass es > sich um viel, sehr viel Code handeln kann Vor allem kommt es daher, dass man so viel flexibler ist, man kann sowohl mit viel Code und wenig Daten als auch umgekehrt arbeiten. Bei getrennten Adressräumen muss man für beide das mögliche Maximum vorsehen. Georg
Vorweg: mir ist schleierhaft, welchen Erkenntnisgewinn sich der TE durch sein Experiment erhofft. Liegt vielleicht daran, daß ich mit von-Neumann Maschinen aufgewachsen bin (Z80, 6502). Aus Sicht des Programmierers ist der einzige Unterschied zwischen von-Neumann und Harvard Architektur, daß bei ersterer jede Art von Speicher über die gleichen Adressierungs- mechanismen zugänglich ist, währed letztere spezielle Adressierungsarten für den Zugriff auf die verschiedenen Speicher erfordert (können ja durchaus auch mehr als nur zwei sein). Spätestens bei Verwendung einer Hochsprache ist auch dieser Unterschied weg. Aus meiner Sicht ist es kein Zufall, daß so viele µC eine Harvard- Architektur verwenden. Von-Neumann ist konzeptionell einfacher und vor allem universeller: die Aufteilung des Adreßraums in Daten und Code kann vom Anwender vorgenommen werden. Bzw. ist gar ganz dynamisch wie etwa beim PC, wo ja letzten Endes alles im RAM liegt. Die von-Neumann Architektur ist typisch für Universalmaschinen und CPU die für solche Maschinen designed wurden. Ein µC hat aber immer RAM und ROM und deren Größe ist vom Hersteller festgelegt. Die Flexibilität der von-Neumann Architektur bringt also keine Vorteile. Statt dessen erlauben getrennte Busse höhere Geschwindigkeiten wenn bspw. Zugriffe verschachtelt werden. Ebenso lassen sich Architekturen mit "krummen" Instruktionswortlängen einfacher implementieren. µC mit von-Neumann Architektur sind entweder Vettern von Universal-CPU (z.B. 6800, 68000) oder verwenden einen IP Core (ARM, MIPS). XL
Falls Manuel wirklich nur eine reine Lernerfahrung möchte (ohne damit notwendigerweise eine geeignetere Basis für Projekte zu bekommen als mit Harvard-Architektur-Controllern!), kann ich die Assembler-Programmierung des Parallax Propellers 1 empfehlen, da self-modifying Code dort zum Alltag gehört. Zudem hat man dann gleich mit einem Multicore-Prozessor zu tun.
Warum er das machen will? Er will halt ein "echter Programmierer" werden, denn "Echte Programmierer schreiben selbstmodifizierende Programme, speziell wenn sie damit in einer kleinen Schleife 20 Nanosekunden einsparen können." http://www.bernd-leitenberger.de/echte-programmierer.shtml Deswegen lege ich auch beim ARM Cortex bei jeder Gelegenheit etwas Assemblercode ins SRAM, damit sich der Code dort selbst modifizieren kann, ohne dass man Flash-Löschzyklen verbraucht (e.g. NVIC-Tabelle verbiegen). Und die neuen STM32F42xer haben nun sogar einen Controller für externes DRAM... und wech
user schrieb: > Wie wäre es mit ARM-Cortex M0/3/4, da wäre z.B. der STM32F4xx. > > Demoboard gibt es für ca 15€ www.st.com/nucleoF401RE-pr Der Preis ist echt ein Wahnsinn. Seltsam, für mein PICDEM 2 Plus Microchip-Demoboard + In-Circuit-Debugger habe ich noch einiges an Kohle hingelegt, und dieses ARM-Demoboard (inkl. Debugger) bekommt quasi für lau hinterhergeschmissen. Vielen Dank für den Link! Das klingt sehr interessant. :-) Axel Schwenke schrieb: > Vorweg: mir ist schleierhaft, welchen Erkenntnisgewinn sich der TE > durch > sein Experiment erhofft. Liegt vielleicht daran, daß ich mit von-Neumann > Maschinen aufgewachsen bin (Z80, 6502). Aus Sicht des Programmierers ist > der einzige Unterschied zwischen von-Neumann und Harvard Architektur, > daß bei ersterer jede Art von Speicher über die gleichen Adressierungs- > mechanismen zugänglich ist, währed letztere spezielle Adressierungsarten > für den Zugriff auf die verschiedenen Speicher erfordert (können ja > durchaus auch mehr als nur zwei sein). Spätestens bei Verwendung einer > Hochsprache ist auch dieser Unterschied weg. > > Aus meiner Sicht ist es kein Zufall, daß so viele µC eine Harvard- > Architektur verwenden. Von-Neumann ist konzeptionell einfacher und vor > allem universeller: die Aufteilung des Adreßraums in Daten und Code kann > vom Anwender vorgenommen werden. Bzw. ist gar ganz dynamisch wie etwa > beim PC, wo ja letzten Endes alles im RAM liegt. Die von-Neumann > Architektur ist typisch für Universalmaschinen und CPU die für solche > Maschinen designed wurden. > > Ein µC hat aber immer RAM und ROM und deren Größe ist vom Hersteller > festgelegt. Die Flexibilität der von-Neumann Architektur bringt also > keine Vorteile. Statt dessen erlauben getrennte Busse höhere > Geschwindigkeiten wenn bspw. Zugriffe verschachtelt werden. Ebenso > lassen sich Architekturen mit "krummen" Instruktionswortlängen einfacher > implementieren. > > µC mit von-Neumann Architektur sind entweder Vettern von Universal-CPU > (z.B. 6800, 68000) oder verwenden einen IP Core (ARM, MIPS). > > XL Dein Post zeigt sehr gut in welch unterschiedlichen Welten wir leben. :-) Du sagst quasi "der Unterschied liegt ohnehin auf der Hand, er besteht in diesem, jenem, und überhaupt." Und all die Sachen die du sagst kann ich nicht nachvollziehen. Um Beispiele zu geben: > Von-Neumann ist konzeptionell einfacher und vor > allem universeller: die Aufteilung des Adreßraums in Daten und Code kann > vom Anwender vorgenommen werden. Ahja? Wie das? Ziehe ich eine imaginäre Linie durch den Adressraum des Prozessors und sage "bis hierhin Code, und nicht weiter! Darüber nur mehr Daten!" oder wie? Wie teile ich das dem Compiler mit? Und überhaupt: Warum muss ich das selbst einteilen? Warum kann Code nicht einfach so viel Speicher belegen wie er benötigt, und den Rest den Daten überlassen? Siebzehn Zu Fuenfzehn schrieb: > Code und Daten im selben Addressraum zu haben kommt davon her, dass es > sich um viel, sehr viel Code handeln kann, der eh von einem Medium > geladen werden muss, dh der Code kommt sowieso ins RAM, und die Daten > auch. Man kann die Beiden durch einen Adressdecoder wieder trennen. Du sagst also, dass viel Code einen zusammenhängenden Code+Datenspeicher begünstigt. Das ist wieder so etwas, das ich nicht verstehe. :-( Aus welchem Grund sollte ich aufgrund eines hohen Bedarfs an Codespeicher an der strikten Trennung von Code und Daten rütteln wollen? (In der heutigen Zeit, wo man in jedem billigen USB-Stick aus der Wühlkiste x Gigabyte hinterhergeschmissen bekommt? Vor allem, wenn ich sie dann durch den Adressdecoder (?!? davon hör ich zum ersten Mal) wieder trennen muss?
Bei Mikrocontrollern geht es eigentlich nicht so sehr um die strikte Trennung zwischen Code und Daten, sondern zwischen den physischen Speicherarten wie Flash, RAM, EEPROM usw.. Der Programmspeicher (Flash) enthält typischerweise nicht nur das Programm, sondern auch konstante Daten wie Strings. Der Nachteil der Harvard-Architektur ist, dass man einer Adresse (z.B. in Form eines Char-Pointers in C) nicht ansieht, auf welchen Speicher sie sich bezieht. Adresse 0x123 gibt es sowohl im RAM als auch im Flash. Je nachdem welcher Speicher gemeint ist, müssen unterschiedliche Maschinenbefehle benutzt werden. Man kann also leider keine universelle Funktion schreiben, die sowohl mit konstanten Strings im Flash als auch mit Strings im RAM funktioniert. Man muss sich mit Krücken wie PROGMEM oder __flash beim AVR behelfen. Andere Compiler missbrauchen gegen den C-Standard sogar das const-Schlüsselwort dafür. Bei der Von-Neumann-Architektur hat man dieses Problem nicht, da es nur einen gemeinsamen Adressraum für alle Speicherarten gibt. Die Adresse 0x123 ist also entweder eine Flash- oder eine RAM-Adresse, aber nicht beides. Für beide Arten von Speicherzugriffen nimmt man den selben Maschinenbefehl. Der Prozessor kann allein anhand der Adresse unterscheiden, auf welchen physischen Speicher er zugreifen muss. Die Von-Neumann-Architektur ist für den Programmierer und Compiler also angenehmer. Bei 32-Bit-Adressierung gibt es auch genug Adressen, um die verschiedenen Speicher alle irgendwo einzublenden. Mit 16 Bit ist man dagegen auf nur 65536 Adressen beschränkt. Dort ist gezwungenermaßen die Harvard-Architektur üblich, weil man so immerhin für jede Speicherart alle 65536 Adressen zur Verfügung hat und nicht nur in Summe für alle.
Marcus H. schrieb: > Warum er das machen will? Er will halt ein "echter Programmierer" > werden, denn > > "Echte Programmierer schreiben selbstmodifizierende Programme, speziell > wenn sie damit in einer kleinen Schleife 20 Nanosekunden einsparen > können." Beim Propeller 1 hat das mit Einsparungen nichts zu tun, denn self-modifying Code ist dort die einzige Möglichkeit zur indirekten Adressierung und für Unterprogramm-Rücksprünge (letzteres wird durch die Assembler-Syntax "CALL" aber teilweise verdeckt, bei "JMPRET" ist es klar).
Hier sieht man wieder deutlich, dass die Beschäftigung mit PIC bleibende "Schäden" hinterlässt. Der PIC entpricht einer Rechnerarchitektur aus den 70er Jahren, die schon seit Generationen (literally) nicht mehr Zeitgemäß ist. Aus der gleichen Ecke entstehen dann Aussagen wie: "C-Compiler sind ineffizient, Profis programmieren in Assembler".
hallo, der MSP430 von Texas Instruments hat von-Neumann-Architektur. Mit dem Launchpad für 12€ und dem bis 16kb kostenlosen Code Composer Studio von TI ideal zum Testen. Gruß wv
Fred S. schrieb: > Beim Propeller 1 hat das mit Einsparungen nichts zu tun, denn > self-modifying Code ist dort die einzige Möglichkeit zur indirekten > Adressierung und für Unterprogramm-Rücksprünge (letzteres wird durch die > Assembler-Syntax "CALL" aber teilweise verdeckt, bei "JMPRET" ist es > klar). Ja Wahnsinn, ich sehe, dass ich mich noch viel zu wenig mit dieser genialen Architektur beschäftigt habe. Nun frage ich mich schon, warum so ein kreatives Konzept noch nicht den Markt aufgerollt hat?
Manuel W. schrieb: > Axel Schwenke schrieb: >> Vorweg: mir ist schleierhaft, welchen Erkenntnisgewinn sich der TE >> durch sein Experiment erhofft. Liegt vielleicht daran, daß ich mit >> von-Neumann Maschinen aufgewachsen bin (Z80, 6502). ... > Dein Post zeigt sehr gut in welch unterschiedlichen Welten wir leben. > :-) > > Du sagst quasi "der Unterschied liegt ohnehin auf der Hand, er besteht > in diesem, jenem, und überhaupt." Und all die Sachen die du sagst kann > ich nicht nachvollziehen. > > Um Beispiele zu geben: >> Von-Neumann ist konzeptionell einfacher und vor >> allem universeller: die Aufteilung des Adreßraums in Daten und Code kann >> vom Anwender vorgenommen werden. > Ahja? Wie das? Ziehe ich eine imaginäre Linie durch den Adressraum des > Prozessors und sage "bis hierhin Code, und nicht weiter! Darüber nur > mehr Daten!" oder wie? Wie teile ich das dem Compiler mit? Und > überhaupt: Warum muss ich das selbst einteilen? Warum kann Code nicht > einfach so viel Speicher belegen wie er benötigt, und den Rest den Daten > überlassen? Bei einem µC muß Code in nichtflüchtigem Speicher liegen. Also ROM, heutzutage meist Flash. Wenn du den extern an die CPU anschließt, dann mußt du selbstverständlich überlegen, wie du den Adreßraum aufteilst und wo du ROM und wo RAM hintust. Wenn der µC das alles intern hat, dann hat natürlich der Hersteller diese Entscheidung schon für dich getroffen. Du hast dann zwar immer noch die Freiheit, Code aus dem Flash ins RAM zu kopieren und dann dort auszuführen. Es ergibt aber nur selten Sinn. Manchmal aber doch: weil RAM nämlich tendenziell schneller ist als Flash. So ab Taktraten jenseits echter 20MHz wirds langsam eng mit "Code direkt aus dem Flash ausführen". Andererseits ergibt es praktisch gar keinen Sinn, Daten (nicht: Konstanten) in den Flash zu tun. Ergo: die Aufteilung in Code und Daten entspricht im wesentlichen der Aufteilung in nichtflüchtigen und flüchtigen Speicher. Sie ist für den typischen von-Neumann µC genauso statisch wie für den typischen Harvard µC. > Siebzehn Zu Fuenfzehn schrieb: >> Code und Daten im selben Addressraum zu haben kommt davon her, dass es >> sich um viel, sehr viel Code handeln kann, der eh von einem Medium >> geladen werden muss, dh der Code kommt sowieso ins RAM, und die Daten >> auch. Man kann die Beiden durch einen Adressdecoder wieder trennen. > > Du sagst also, dass viel Code einen zusammenhängenden Code+Datenspeicher > begünstigt. Das ist wieder so etwas, das ich nicht verstehe. :-( Zum Teil deswegen, weil er das so nicht geschrieben hat. Er meinte, daß eine von-Neumann Architektur dir absolute Flexibilität läßt, welchen Teil des Adreßraums du für Code und welchen du für Daten verwendest. Mit einem µC nützt dir diese Flexibilität aber nicht viel, weil ein µC typischerweise eben nicht den ganzen Adreßraum voll RAM hat. Er hat auch keine Festplatte und keinen Benutzer, der ihm sagt "lade doch bitte mal Programm xyz von der Platte ins RAM und führe es dann aus". > Aus welchem Grund sollte ich aufgrund eines hohen Bedarfs an > Codespeicher an der strikten Trennung von Code und Daten rütteln wollen? Wer sagt daß du das wollen würdest? Andererseits ist die Trennung gar nicht so strikt, wie du das darstellst. Denn konstante Daten liegen ja durchaus im Programmspeicher. Sowohl bei Harvard als auch bei von-Neumann. Auch da ist es schlicht Übereinkunft, wo du als Programmierer Code hinpackst und wo Daten. Man kann sicher auch auf einem PIC z.B. Zeichenketten in den Flash tun und dann per GOTO anspringen. Und sich dann wundern wo das Loch im Fuß auf einmal herkommt ;) XL
Hans schrieb: > Der Programmspeicher (Flash) enthält typischerweise nicht nur das > Programm, sondern auch konstante Daten wie Strings. Der Nachteil der > Harvard-Architektur ist, dass man einer Adresse (z.B. in Form eines > Char-Pointers in C) nicht ansieht, auf welchen Speicher sie sich > bezieht. Das ist kein Naturgesetz. Es gibt durchaus C-Compiler die genau das tun können. AFAIK kann z.B. der Keil Compiler das. gcc kann es aber in der Tat nicht, was im wesentlichen damit zusammenhängt, daß die notwendigen Änderungen zu riskant wären. Schließlich sind Harvard µC nur eines der vielen Targets die der gcc abdeckt. > Bei der Von-Neumann-Architektur hat man dieses Problem nicht, da es nur > einen gemeinsamen Adressraum für alle Speicherarten gibt. Die Adresse > 0x123 ist also entweder eine Flash- oder eine RAM-Adresse, aber nicht > beides. Für beide Arten von Speicherzugriffen nimmt man den selben > Maschinenbefehl. Der Prozessor kann allein anhand der Adresse > unterscheiden, auf welchen physischen Speicher er zugreifen muss. Was ich etwas knapper weiter oben auch geschrieben habe. Was man bei Harvard Architekturen typischerweise auch sieht, ist daß sie für den Datenspeicher mehr und ausgefeiltere Adressierungsarten bereitstellen als für den Programmspeicher. Oft läuft es für letzteren auf das absolute Minimum "indirekt adressiert über genau ein Spezialregister" hinaus. XL
@ Marcus H. (lungfish) >> Beim Propeller 1 hat das mit Einsparungen nichts zu tun, denn >> self-modifying Code ist dort die einzige Möglichkeit zur indirekten >> Adressierung und für Unterprogramm-Rücksprünge (letzteres wird durch die >> Assembler-Syntax "CALL" aber teilweise verdeckt, bei "JMPRET" ist es >> klar). >Ja Wahnsinn, ich sehe, dass ich mich noch viel zu wenig mit dieser >genialen Architektur beschäftigt habe. Nun frage ich mich schon, warum >so ein kreatives Konzept noch nicht den Markt aufgerollt hat? Das Einzige was sich dabei aufrollt sind meine Zehennägel!
Manuel W. schrieb: >> Von-Neumann ist konzeptionell einfacher und vor >> allem universeller: die Aufteilung des Adreßraums in Daten und Code kann >> vom Anwender vorgenommen werden. > Ahja? Wie das? Ziehe ich eine imaginäre Linie durch den Adressraum des > Prozessors und sage "bis hierhin Code, und nicht weiter! Darüber nur > mehr Daten!" oder wie? Wie teile ich das dem Compiler mit? Und > überhaupt: Warum muss ich das selbst einteilen? Warum kann Code nicht > einfach so viel Speicher belegen wie er benötigt, und den Rest den Daten > überlassen? Der compiler übernimmt nicht die Einteilung des Speichers, er legt nur Marken an, die dann vom Linker durch Adressen ersetzt werden. Was du dir also anschauen solltest, sind Linker Scripte. Ich hab mir das mit einem STM32F4Discovery angeeignet, zusammen mit Atollic TrueStudio lite. Geholfen hat mir diese Seite: http://www.delorie.com/gnu/docs/binutils/ld_6.html Ich wollte anschließend auch Linkerscripte für PICs nachvollziehen, bin aber kläglich gescheitert...
Falk Brunner schrieb: > @ Marcus H. (lungfish) > >>> Beim Propeller 1 hat das mit Einsparungen nichts zu tun, denn >>> self-modifying Code ist dort die einzige Möglichkeit zur indirekten >>> Adressierung und für Unterprogramm-Rücksprünge (letzteres wird durch die >>> Assembler-Syntax "CALL" aber teilweise verdeckt, bei "JMPRET" ist es >>> klar). >>Ja Wahnsinn, ich sehe, dass ich mich noch viel zu wenig mit dieser >>genialen Architektur beschäftigt habe. Nun frage ich mich schon, warum >>so ein kreatives Konzept noch nicht den Markt aufgerollt hat? > > Das Einzige was sich dabei aufrollt sind meine Zehennägel! Hi Falk, mir doch auch. Ich hab mir ne Tasse Kaffee geholt und verfolge diesen Fred als Pausenkino... Cheerio, Marcus
Marcus H. schrieb: >> Das Einzige was sich dabei aufrollt sind meine Zehennägel! > > Hi Falk, > mir doch auch. Ich hab mir ne Tasse Kaffee geholt und verfolge diesen > Fred als Pausenkino... > Cheerio, Marcus Eine unheilvolle Kombination aus nicht verstehen wollen und nicht verstehen können. Mit der von Neumann-Architektur bist du offensichtlich völlig überfordert. Georg
Meinst Du mich? Da hast Du wahrscheinlich recht, schon die Frank-Lloyd-Wright-Architektur hat mich total überfordert.
Axel Schwenke schrieb: > gcc kann es aber in der Tat nicht, was im wesentlichen damit > zusammenhängt, daß die notwendigen Änderungen zu riskant wären. Seit wir Johann (Georg Lay) haben, kann auch der (AVR-)GCC “generic pointers”. ;-)
>Frank-Lloyd-Wright-Architektur
:D
Ich habe mir alles was ihr geschrieben habt durchgelesen, und sehe die ganze Sache nun wesentlich klarer. Danke vor allem an Hans (Gast) und Axel Schwenke für eure Erläuterungen! Jetzt im Nachhinein kann ich sagen, dass ich völlig falsche Vorstellungen von dem Prinzip eines alles übergreifenden übergreifenden Adressraums hatte. Meine Vorstellung war, dass die Möglichkeit, ausführbaren Programmcode und Daten mehr oder weniger bunt durcheinander gewürfelt im Adressraum zu verstauen, die dadurch gegeben wäre, irgendeinen Vorteil böte, und bei Einsatz dieser Architektur in jedem Fall genutzt werden würde. Jetzt verstehe ich, dass Code und Daten bei einem zusammenhängenden Adressraum nicht unbedingt weniger separiert sind als bei getrennten Adressräumen. Die Hauptvorteile liegen einfach nur darin, flexibler beim Anschluss von externem ROM und RAM zu sein, auf im ROM abgelegte Konstanten ohne Kunstgriffe zugreifen zu können bzw. zur Laufzeit nachgeladenen Code aus dem RAM ausführen zu können. LG Manuel
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.