Hallo, die hier so beliebten AVRs haben ja bekanntlich eine Harvard Architektur und können keinen Programmcode aus dem RAM ausführen. Ich würd mir aber gerne zu Lernzwecken so ne Art "Minimal-PC" basteln. Problem ist hier das Software nachladen. Natürlich kriegt man auf nen Mega128 auch nen einfachen Texteditor und nochn kleines Spiel drauf. Aber irgendwie wurmt mich, dass es eben doch kein "richtiger" PC ist. Gibt es denn einen uC der als Bastler noch bewältigt werden kann? Damit meine ich sowohl in Bezug aufs Gehäuse als auch den Aufwand der Prozessorinitialisierung. Oder sind Von-Neumann Architekturen generell ne andere Liga und für nen Bastler ne Nummer zu groß? Viele Grüße, Rudi
Du kannst auf dem AVR z.B. auch einen Interpreter laufen lassen, für Basic gibts hier etwas in der Artikelsammlung.
Es gibt auch Java VM's für AVR Mikrocontroller. Dann kannst Du Deine Programme mit dem normalen Java Compiler von Oracle erstellen. Suche mal nach TinyVM oder Lejos. Wenn Du die Funktion eines PC einigermaßen nachbilden/erfoschen willst, dann würde ich allerdings einen Prozessor mit zumiondestb ähnlicher Srchitektur wählen. Zum Beispiel den guten alten 80186 + RAM + ROM. Das ROM würde ich allerdings mit Hilfe eines statischen RAM + Batterie simulieren, denn dann brauchst Du kein Equipment zum Brennen und Löschen von Eproms. ARM Controller können meines Wissens nach auch Code aus dem RAM ausführen, nur etwas langsamer. Vielleicht ist ein ARM für Dich interessant. Such mal nach STM32 Discovery oder Mbed.
80186 ist für einen Anfänger zu gross. Ohne Eprom wird es auch nicht gehen. Irgendwie muss er ja die ersten Bytes hineinbekommen. Ein MCS51 Derivat kann sehr einfach (ein Oder-Gatter) auf die "normale" Architektur gebracht werden. Werkzeuge sind gratis reichlich vorhanden. Die Hardware ist übersichtlich. Und es gibt reichlich Code Beispiele.
Danke euch schon mal. Das STM32 Board klingt interessant, werde ich mir mal anschauen. Ein Interpreter ist eigentlich nicht das, was ich suche. Als Anfänger würde ich mich btw nicht bezeichnen. Neben den AVR hatte ich beruflich auch schon mit einigen 32 Bit Architekturen, allerdings immer Harvard, zu tun.
Rudi schrieb: > Oder sind Von-Neumann Architekturen generell ne andere Liga und für nen > Bastler ne Nummer zu groß? Nö. Die MSP430 sind in der gleichen Liga wie die AVRs.
Stefan schrieb: > ARM Controller können meines Wissens nach auch Code aus dem RAM > ausführen, nur etwas langsamer. Eher etwas schneller. Auf Flash kann zwar parallel zu RAM zugegriffen werden, aber gelegentlich machen sich Waitstates bemerkbar. Manche ARM7 können überhaupt nur im RAM ARM-Code ohne Handbremse ausführen, weil der Flash-Durchsatz für Thumb-Code optimiert ist.
Rudi schrieb: > Als Anfänger würde ich mich btw nicht bezeichnen. Neben den AVR hatte > ich beruflich auch schon mit einigen 32 Bit Architekturen, allerdings > immer Harvard, zu tun. Welche 32-Bit Architekturen haben denn - was die Adressräume angeht - eine Harvard-Architektur? Ob die internen Zugriffspfade auf einen einheitlichen Adressraum getrennt sind oder nicht ist für die hier betrachtete Frage irrelevant.
"Anfänger" war als "Anfänger mit x86" gemeint. Da gibt es n+1 Stolperfallen, die einen "Anfänger" ganz schön demotivieren können.
A. K. schrieb: > Welche 32-Bit Architekturen haben denn - was die Adressräume angeht - > eine Harvard-Architektur? Theoretisch: AVR32, Cortex M3, Renesas RX, aber da > Ob die internen Zugriffspfade auf einen > einheitlichen Adressraum getrennt sind oder nicht ist für die hier > betrachtete Frage irrelevant. spielt dies keine Rolle. Wenn ehe schon Atmel-Tools vorhanden sind, wäre hier ein AVR32 keine schlechte Wahl.
A. K. schrieb: > Die MSP430 sind in der gleichen Liga wie die AVRs. Genau, der MSP430 hat einen gemeinsamen Adresseraum für RAM und Flash. Mein geliebter PIC24 kann's leider nicht...
Arc Net schrieb: > A. K. schrieb: >> Welche 32-Bit Architekturen haben denn - was die Adressräume angeht - >> eine Harvard-Architektur? > > Theoretisch: AVR32, Cortex M3, Renesas RX, aber da > >> Ob die internen Zugriffspfade auf einen >> einheitlichen Adressraum getrennt sind oder nicht ist für die hier >> betrachtete Frage irrelevant. > > spielt dies keine Rolle. Aufgrund ebendieser Verwirrung mag ich die Begriffe Harvard- und von-Neumann-Architektur nicht sonderlich, weil sie meist implizit auf heute interne Busse statt auf Adressräume angewendet werden und dementsprechend sinnlos geworden sind. Siehe "Kritik" in Prozessorarchitekturen.
Du willst dein eigenes Board erstellen? Dann würde ich den 8051er nehmen. Das ist die einfachste und am schnellsten aufzubauende Variante (du brauchst nur die CPU, ein Latch (74HC573) und ein SRAM). Es gibt einen schönes Monitorprogramm dafür, damit kann man komfortabel Programme über RS232 hochladen, es ist ein Assembler drin, ein Hexeditor, alles was man so braucht: http://www.pjrc.com/tech/8051/#paulmon Der Vorteil gegenüber einer "richtigen" 8-bit CPU (6502, Z80) ist, dass der 8051 schon jede Menge nützliche Peripherie drin hat (Timer, UART, I/O Ports). Die müsstest du sonst als separate Chips mit draufpacken. Gleichzeitig hast du aber die Flexibilität eines Datenbusses. Es hindert dich nichts daran, z.B. acht 82C55 I/O Chips anzuschließen wenn du 192 I/O Pins brauchst ...
Hallo, der Hauptvorteil des 8051 ist, dass er zwar harvardmässig getrennte Adressräume hat, beide aber 8 bit breit sind und den gleichen Bus benutzen - unterschieden nur durch Read/Prog Enable. Man kann also Rom und Ram beliebig in beiden Adressräumen verwenden und extern einen Schalter einbauen, der die Zugriffe verodert, dann hat man ein System, das zwischen Harvard und von Neumann umschaltbar ist. Gruss Reinhard
Du könntest Dich in die Z80-Welt begeben - aber mit modernen Mitteln. Der alte Z80 war in den 80'er Jahren beliebt und wurde in CP/M-Maschinen genutzt, im ZX Spectrum und vielen anderen Rechnern. Üblicherweise lief der Prozessor damals mit 4 MHz. Den originalen Chip lässt Du besser sein. Heutzutage gibts viel was besseres: eZ80F91. Schau hier: http://www.zilog.com/index.php?option=com_product&Itemid=26&task=parts&BL=1&familyId=119&productId=EZ80F91 Die moderne Version ist ein Mikrocontroller im Gegensatz zu einem Mikroprozessor, hat einiges an Peripherie drin (auch Ethernet!), hat 16MB linearen Adressraum(!), 256k Flash und läuft mit 50 MHz. Da klemmst Du dann beispielsweise ein 512k*8 SRAM an (z.B. AS7C34096A) und los gehts. Der eZ80 ist LQFP144, das kann man auch noch selber löten. fchk
Reinhard Kern schrieb: > Hallo, > > der Hauptvorteil des 8051 ist, dass er zwar harvardmässig getrennte > Adressräume hat, beide aber 8 bit breit sind und den gleichen Bus > benutzen - unterschieden nur durch Read/Prog Enable. Man kann also Rom > und Ram beliebig in beiden Adressräumen verwenden und extern einen > Schalter einbauen, der die Zugriffe verodert, dann hat man ein System, > das zwischen Harvard und von Neumann umschaltbar ist. > > Gruss Reinhard Meine 8051-Boards haben das fast alle, über Jumper auch konfigurierbar. Damit kann ich an meinen besten Boards 32k RAM als ROM nutzen, wie Flash. Und das ist beim 8051 schon was. Zum Programmtest ohne Stromabschaltung nur, aber das reicht so gut wie immer. Im Augenblick mache ich mir Gedanken zum Reset, wenn es der Watchdog war, daß er im Bootloader wieder an die Zieladresse im RAM springt. Also, das ist im Detail auch kniffliger, als gedacht...
> RAM als ROM nutzen
Sehr fortschrittlich ;) Besser ist eigentlich nur noch das WOM...
aber auch die 6502 Welt hat (noch) Mikrocontroller zu bieten Western Design Center zum Beispiel: http://westerndesigncenter.com/wdc/documentation.cfm Oder von ehemals NECnunReneseas schon EOL aber noch zu kaufen: http://www.renesas.eu/products/mpumcu/740/38000_740/3803h/index.jsp
Edson schrieb: > Besser ist eigentlich nur noch das WOM... Wenn man keine Ahnung hat, sollte man, ..............
Hi, @Rudi: Aus Deinen Postings folgt leider nicht, welche Werkzeuge Du zur Verfügung hast. Was Du vorhast, war in den frühen 80ern als Heimcomputer-Bau durchaus populär, ist aber inzwischen ziemlich ausgestorben. Du könntest ein Problem bekommen: Für einen "Minimal-PC" nimmt man üblicherweise einen µP, keinen µC. Dem musst Du aber irgendwie ein erstes Programm anbringen, mit dem er Dein eigentliches Programm nachlädt (Bootstrap oder Urlader). Dafür gibt es mindestens drei Wege: 1. EPROM oder Flash-Chip. Kann teuer werden, wenn das Werkzeug nicht ohnehin schon da ist. 2. Programmspeicher als Dual-Port-RAM auslegen und auf der zweiten Seite mit einem herkömmlichen µC befüllen. Nicht wirklich sinnvoll. 3. Einen 8052AH verwenden. Bringt ein internes BASIC mit. Inzwischen schwierig zu bekommen. Nach meiner Erfahrung ist ein Mikrocomputersystem nicht schwerer zu bauen als eine normale µC-Anwendung - nur zeitaufwendiger: Die Kombination CPU+RAM+ROM(+Adresslatch)(+UART) bedingt einen ganzen Haufen zu verdrahtender Chips, die eine Eurokarte schon füllen kann. Im Forum wird ein solcher Aufbau auch leicht abfällig "Kuchenblech" genannt. Aus eigener Erfahrung drei Tipps: 1. Der Empfehlung von Malignes Melanom kann ich mich nur anschliessen. Für ein sehr brauchbares System brauchst Du nur 80C31+74HC573+62256+27C256(programmiert)+MAX232+Kleinteile. Alles* problemlos zu beschaffen, nicht teuer und bastlerfreundlich im DIL-Gehäuse. 2. Nimm Dir für den Aufbau ein langes und verregnetes Wochenende - und alle Chips sockeln! 3. Mach eine Steckverbindung zwischen gemultiplextem Adress/Datenbus und Latch/Speichern. Ermöglicht a) verschiedene CPUs auszuprobieren und b) zusätzliche Peripherie einzubinden. @Jobst M.: Das mit dem 68k war wohl ein Scherz oder? Zugegeben, sieht im DIL64 beeindruckend aus, aber die Initialisierung ist nicht ganz so trivial. (*bis auf das programmierte EPROM...) Grüssli
keinLichtAufGing schrieb: > 1. Der Empfehlung von Malignes Melanom kann ich mich nur anschliessen. > Für ein sehr brauchbares System brauchst Du nur > 80C31+74HC573+62256+27C256(programmiert)+MAX232+Kleinteile. > Alles* problemlos zu beschaffen, nicht teuer und bastlerfreundlich > im DIL-Gehäuse. Nee. Kein UV-EPROM mehr. Nimm statt dessen einen EEPROM oder Flash. z.B. 28C256 oder 29C256/29F256. Wahrscheinlich bekommst Du solch kleine Bausteine gar nicht mehr und musst auf ein 29F010 oder so ausweichen. > @Jobst M.: Das mit dem 68k war wohl ein Scherz oder? Zugegeben, sieht > im DIL64 beeindruckend aus, aber die Initialisierung ist nicht ganz > so trivial. Da hätte ich eher einen 68C332 vorgeschlagen. Der hat Peripherie drin und einen BDM-Port zum Debuggen und zum initialen Programmieren. Man muss es sich ja nicht unbedingt schwerer machen als nötig, sondern darf durchaus zeitgemäß arbeiten. Auch der von mir erwähnte eZ80 hat JTAG und Debug-Port, so dass es kein Huhn-Ei-Problem geben kann und man einfacher arbeiten kann. fchk
keinLichtAufGing schrieb: > @Jobst M.: Das mit dem 68k war wohl ein Scherz oder? Zugegeben, sieht > im DIL64 beeindruckend aus, aber die Initialisierung ist nicht ganz > so trivial. Nein, das war eigentlich kein Scherz. Welche Initialisierung? Als 16-jähriger habe ich auf dem Dings damals einfach drauflos programmiert. Gibt es im übrigen auch in kleineren Gehäusen, z.B. PLCC68. Und wenn man lieber einen 8-Bit-Bus haben möchte, reicht auch der 68008 im DIP 48 - wenn man ihn noch bekommt. Frank K. schrieb: > Da hätte ich eher einen 68C332 vorgeschlagen. Ich meinte eigentlich 68k als Familie. Ob das nun der 68000, 68008, 68332, 68020, ColdFire oder DragonBall ist, ist doch egal. Gruß Jobst
programmcode aus ram ausführen auf avr? nichts neues! gibts schon laaange ;) hier: Beitrag "Linux on AVR" find ich immer noch herb diese idee, nem avr einen simm riegel spendieren und dann einen arm emulieren.
Wilhelm Ferkes schrieb: > Edson schrieb: > >> Besser ist eigentlich nur noch das WOM... > > Wenn man keine Ahnung hat, sollte man, .............. Wenn man keinen Humor hat, sollte man das manchmal auch. Ach ja, ASM-Beispiel lädt einen (hartcodierten) Code ins RAM eines STM32F100RB (aktiviert LED an PC9):
1 | ldr r2, = 0x20000401 ;r2 zeigt auf RAM |
2 | |
3 | mov32 r1, #0xF0216901 |
4 | str r1, [r2, #-1] |
5 | mov32 r1, #0xF4417100 |
6 | str r1, [r2, #3] |
7 | mov32 r1, #0x61017100 |
8 | str r1, [r2, #7] |
9 | mov32 r1, #0x69014770 |
10 | str r1, [r2, #11] |
11 | |
12 | blx r2 |
Hi @Frank K.: "Nee. Kein UV-EPROM mehr." Das war genau der Punkt, den ich mit "Werkzeug da" meinte. Da ich ohnehin Brenner und Mäusesolarium habe, stellt sich das Huhn-Ei-Problem für mich nicht. Für die µPs, die ich häufiger nutze, habe ich ohnehin immer ein EPROM mit Urlader in der Schublade. Soweit ich sehe, gibt es den 68C332 nur in SMD-Form. Das finde ich nicht mehr so bastlerfreundlich, auch wenn es zur Not Adapterplatinen gibt. @Jobst M.: Ich dachte daran, dass der 68000 beim Start zuerst zwei Datenworte einliest, dann dann den Einsprungvektor setzt und... Grüssli
Jobst M. schrieb: > Frank K. schrieb: >> Da hätte ich eher einen 68C332 vorgeschlagen. > > Ich meinte eigentlich 68k als Familie. Ob das nun der 68000, 68008, > 68332, 68020, ColdFire oder DragonBall ist, ist doch egal. Eben nicht! Du unterschätzt die Nützlichkeit des BDM-Ports. Wenn man das kennen gelernt hat, will man nicht mehr darauf verzichten. fchk
keinLichtAufGing schrieb: > @Jobst M.: Ich dachte daran, dass der 68000 beim Start > zuerst zwei Datenworte einliest, dann dann den Einsprungvektor > setzt und... Wie das genau war, kann ich mich gerade gar nicht mehr erinnern, aber auch das war machbar. Frank K. schrieb: > Eben nicht! Du unterschätzt die Nützlichkeit des BDM-Ports. Wenn man das > kennen gelernt hat, will man nicht mehr darauf verzichten. Doch! Meinte ich trotzdem so! Und ich hasse Nabelschnüre in laufende Systeme. Gruß Jobst
keinLichtAufGing schrieb: > (Bootstrap oder Urlader). Dafür gibt es mindestens drei > Wege: Das ist ja alles schon richtig modern. Bei den ersten PDPs ging das meiner Erinnerung nach noch so: mit einem Schalterfeld auf der Frontplatte konnte man die ersten 256 Byte Bit für Bit beschreiben, mit diesem Progrämmchen konnte man dann einen leistungsfähigeren Urlader auf Lochstreifen einlesen, und dann gings richtig los... Für die Lochstreifen gab es kleine Handstanzen aus einer Platte mit 8 Löchern und einem bleistiftähnlichen Werkzeug, um die Löcher durchzustossen. Ein Eprom einzusetzen geht da schon wesentlich schneller. Monitorprogramme für serielle Schnittstelle gabs auch fast für alles, manche findet man sicher noch in alten Unterlagen. Gruss Reinhard
mal ne blöde Frage ... was macht denn die PC-Ähnlichkeit aus? PC hat n BIOS für den Start, der Rest wird aus der Peripherie nachgeladen, was spricht dagegen nen AVR zu nehmen, Bootloader drauf und einfach per UART oder meinetwegen von ner SD-Karte die jeweilige Anwendung zu flashen?
> was spricht dagegen nen AVR zu nehmen, Bootloader drauf und einfach per > UART oder meinetwegen von ner SD-Karte die jeweilige Anwendung zu > flashen? Zum Beispiel, dass die Speicherzellen nicht unendlich oft beschreibbar sind. Teilweise sind es nur 10k Schreibzyklen, die garantiert werden. Die Lösung würde also maximal einem "PC" mit ner fast gestorbenen SSD entsprechen, da wird die Akzeptanz nicht allzu hoch sein.
@Rudi Nimm irgendeinen ARM, die können alle Code aus dem RAM ausführen, solange er reinpasst. Die Sachen mit 8051, 68k usw sind zwar alle gut gemeint, aber bei einem Cortex hast du einfach auf dauer mehr davon, als wenn du einen fast ausgestorbenen Prozessor nimmst. Es gibt vor allem auch günstige, fertig aufgebaute Boards, wo man bei der Hardware nicht mehr falsch machen kann. - jgdo -
Naja, wenn man was fertiges kauft, dann kann man ja gleich ein altes Laptop nehmen ... Die Hardware beim 8051 ist jedenfalls unschlagbar simpel, das kann man auch auf dem Steckbrett aufbauen: http://www.pjrc.com/tech/8051/pm2_docs/hardware.html Vor allem haben viele 8051 einen seriellen Bootloader, so dass man nicht mal einen Programmer braucht. Einfach an die RS232 vom PC anschliessen und los gehts.
Ein weiterer Aspekt ist noch, dass der 8051er mit PAULMON autark ist, d.h. mann kann die Programme in Assembler direkt auf dem Controller schreiben, der PC dient nur als Terminal. Das würde auch am ehesten der Anforderung als "minimaler PC" entsprechen.
Könntest dir auch mal den Propeller anschaun. Evt den Hive zum selberbaun, da sind 3 Propeller drauf. Der Propeller läd, falls vorhanden beim Start aus einem externen Eeprom sein Programm oder über die serielle. http://hive-project.de/board/index.php
Mikel M. schrieb: > Könntest dir auch mal den Propeller anschaun. Sicher kein Fehler, der Propeller ist ein interessanter Chip, aber ob der Propeller die passende Antwort zur threadgewordenen Aufgabenstellung ist, benötigt nochmal genaueres Hinschauen. Der Propeller kann nativen Code nur in den 8 Cogs (à 2kBytes RAM) ausführen. Was scheinbar in Hub-RAM (32kBytes, nicht erweiterbar) oder externem Speicher (von EEPROM, SRAM bis SD-Karte) ausgeführt wird, basiert auf kleinen VMs, die dann Instruktionen aus dem Hub-RAM holen und interpretieren (LMM) oder aus extern angedrahtetem Medium (XMM). Wenn es nicht zwingend notwendig ist, daß der aus dem RAM auszuführende Code der mit voller Geschwindigkeit auszuführende native Maschinencode des Propellers ist, dann eignet er sich prima für Soetwas. Mit "normalen" CPUs statt MCUs kommt man aber hier meiner Meinung nach deutlich weiter... MCUs können dabei gut diverse Subaufgaben übernehmen, z.B. der Propeller als Terminal oder Graphikkarte, ...
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.