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
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.
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...
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):
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, ...
