at89 und avr computer

guuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuut, das war dann wohl noch 
nix
aber ma gucken ob ich antworten bekomme.

noch ne frage:  braucht der at89s52 einen externen oszillator? im 
datenblatt hab ich kene konkrete information bekommen und hier im forum 
hab ich nur unbeendete(zumindest ohne klares ergebnis)  diskussionen 
gefunden.

mfg. mark

Moin,

im Datenblatt ist das schon sehr eindeutig. Beantworte Dir selbst die 
Frage: Gibt es einen internen Oszillator beim 89S52 und wie kann er 
aktiviert werden?

Für eine "Spielkonsole" würde ich mir andere Konzepte mal anschauen, 
z.B. den "Propeller-Chip" oder direkt FPGA verwenden.

Zu Deinen obigen Fragen: Nein, bei SRAM ist die Geschwindigkeit des 
Prozessors egal. Der SRAM gibt die Daten so lange aus, wie die 
Enable-Leitungen aktiv sind.
Für den Zugriff zweier Prozessoren auf einen Speicher gibt es 
verschiedene Modelle. Einmal gibt es RAMs, die zwei getrennte 
Daten/Adressbusse haben, die sind aber schlecht beschaffbar (z.B. 
ausschlachten von Grafik-Karten).
Die einfachere Möglichkeit ist: Über einen gemeinsamen Takt werden die 
Zugriffe gesteuert, beide Prozessoren greifen zeitversetzt auf den RAM 
zu. Wenn die Prozessoren nicht in der Lage sind, den Bus auf Tristate zu 
setzen, verwendet man zum Umschalten Bus-Treiber (74HC244, 74HC245, 
74HC541 o.ä.). Du kannst natürlich auch -zig Transistoren dafür 
verwenden. Es gibt ja so (im positiven Sinne gemeint) verrückte 
Projekte, mit denen CPUs aus TTL-Bausteinen aufgebaut werden, wieso 
keine Bus-Treiber aus Transistoren... g

Nachtrag: Die Geschwidigkeit des Prozessors bei SRAM ist dann egal, wenn 
er langsamere Zugriffszeiten als das SRAM hat ;)

hi,
danke für deine antwort.

das datenblatt hab ich so iunterpretiert, dass er eben einen internen 
oszillator hat, vnur hab ich hier im forum beiträge efunden, die 
besagen, dass der interne oszillator  nicht als clock source verwendet 
werden darf( wenn das doch geht dann wird die oszillator frequenz in der 
clock circuitry doch verdoppelt oder??? und der µC ist dann doch 
standartmässig auf internen oszillator eingestellt oder).

das mit dem propeller ist eigentlich ne gute idee aber ich hab den 
at89s52 unter anderem gewählt wegen der verfügbarkeit bei reichelt. bei 
fpga gehe ich mal von einer längeren einarbeitungszeit aus als bei einem 
at89s52.

das mit dem sram ist schonmal sehrt gut.

über dualport ram hab ich auhc schon nachgedacht, diese schienen aber zu 
teuer und schwerer zu beschaffen zu sein.

der zweck der beiden videopuffer sollte ja sein , dass die beiden 
prozessoren asyynchron arbeiten. der bilderzeugende controller sollte ja 
(theoretisch) beliebig lange für einen frame brauchen, wöhrend der 
signalerzeugende  controller konstant 24(so wie es jetzt aussieht wirds 
ein pal signal über composite video)fps liefert.

aber dein vorschlag mit den bustreibern hat mich auf eine idee gebracht:

ich könnte doch einfach für jeden ram-chip einen eigenen (bzw. 2 für 
beide controller) bustreiber verbauen und um eine verbindung zum 
controller zu trennen lege ich einfach ein ALE bzw. den entsprechenden 
pin über GPIO pins auf high( das ist doch meistens der inaktive zustand 
oder?).
den ALE pin des µC´s kann ich doch mit einer diode vom entsprechendem 
GPIO pin isolieren, sodass der andere bustreiber ganznormal 
funktioniert.
hört sich das machbar an?? (ihr merkt schon mir fehlt die erfährung)

mfg. mark

hi,

noch ne farge: wi siehts asu mit memory mapping? also beim 89s52 gibt es 
fürs externe datenram den movx befehl und wie siehts mit pogrammspeicher 
aus??
wird das programm automatisch ausm externen speicher geholt wenn der pc 
8kb übersteigt??? und welche adresse liegt dann am adressbus an, pc oedr 
pc-8kb????
 wie siehts beim mega8915 aus wird automatish jeder zugriff auf 
adresse>größe des internen ram  an den externen ram geleitet?? und 
welche adrese liegt dann an?



mfg. mark

edit: ihc mein natürich atmega8515