hi alle mal, ich will eine art spielekonsole bauen mit dem at89s52 als cpu(weil er ein programm asu eienm externem speicher ausführen kann) und noch weiteren avr controllern (weil die leistungsfähiger sind und die dann immer wieder das gleiche machen werden und kein externes programm mbrauchen, wie das audio und video signal zu erzeugen und so) google und dieses forum haben bisher gut geholfen, nun bleiben noch paar fragen offen: 1. worauf muss ich achten wenn ich ein sram ausscueh? die zugriffszeiten dürfen ja nciht zu lang sein, aber kann auch der prozessor zu langsam sein?? so wie ich das bis jetzt verstehe können die zugriffszeiten nciht zu kurz sein 2.ich hab mir das bisher so gedacht , dass ein controller in einen von zwie videopuffern schreibt , und ein anderer controller den anderen puffer ausliest und den inhalt als vga signal ausgibt. kann ich nun als puffer zwei srams benutzen und diese irgendwie immer von jeweils einem controller memory interface abkoppeln?? ich hab mir überlegt das mit transistoren zu machen aber sind sie "dicht" und schnell genug?? und ist ihre kapazität nicht zu groß??? fragen werden mit sicherheit kommen. mfg mark
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
Bitte 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.