Hi! Ich wollte den sourcecode des yampp3, der eigentlich für den at90s8515 geschrieben ist, für den atmega8515 umschreiben. Bis jetzt leider mit nicht allzuviel Erfolg. Spi und Uart funktionieren weiterhin herrvorragend, nur bekomme ich die festplatte und das ram nicht zum laufen. Nach einem Blick ins datenblatt habe ich bei den einstellungen zwar einige neue register festgestellt, allerdings sind die alten immer noch vorhanden und auch an der selben adresse. Da steht auch noch was von einem schnelleren Timing, könnte ich dieses evtl. wieder langsamer bekommen? Zudem wird beim yampp3 die festplatte ganz normal über die ports a und c angesteuert, also ohne das sram interface. Somit sollte dieses eigentlich funktionieren, tut es aber auch nicht. Gibt es denn beim mega8515 so etwas wie ein Jtag interface, oder irgendwas das ich über lock / fuse bits abschalten muss? Denn die Register die benutzt werden, sind allesamt dieselben, ich kann mir das nicht wirklich erklären was es sonst sein könnte. Die Probleme habe ich im normal modus als auch im compatibility mode. Hardwarefehler kann ich ausschliessen, ich habe alles mehrfach auf lötbrücken überprüft und die verbindungen durchegemessen... mfg Nik
-das timing kanns übrigens auch kaum sein, denn ich verwende für den atmega nur einen 7.372mhz quarz
Hast du auch beachtet das die mega8515 mit internem RC-Osc bei 1MHz ausgeliefert werden? Check mal die fuse-bits.
danke für den tipp, aber das ist es leider nicht. Ich hab die fusebits gesetzt und der externe quarz geht garantiert auch auf jeden fall, denn der uart funktioniert korrekt. ach was kann das nur sein :(
Ich meine mich zu erinnern, daß das Xmem interface des mega8515 im default ein anderes timing bzw. zustand hat als beim 90s8515. Solltest mal die Appnote AN085 ansehn. Möglich daß dies hilft.
oo vielen Dank, das könnte es wohl wirklich sein, da steht nämlich: >Improvements to External Memory Interface: >The combined Address/Data port in ATmega8515 outputs data >until a new address is set up. >Refer to the ATmega8515 data sheet for details on the changed timing. Ich habe mir also mal das Datenblatt vom atmega8515 ein wenig genauer angesehen und dabei herausgefunden, dass der uc ein neues Register bekommen hat, ein sogenanntes Emcucr (extended mcucr). Darin kann man, sofern man das möchte, den Speicher in zwei sektoren aufteilen. Was aber warscheinlich wichtiger ist, ist dass man dort auch noch zwei waitstate bits zur verfügugund hat, um den Zugriff zu verlangsamen. Ich denke mir mal, dass das der Grund ist, dann muss ich wohl im Yampp code mal gründlich etwas untersuchen. Dazu müsste ich jedoch etwas wissen; Das erste was der Compiler ausführt ist main(), oder werden da vorher noch irgendwelche codeschnipsel ausgeführt? mfg Nik
Vor main wird u.a. manchmal der RAM gelöscht, oder Daten ins RAM kopiert. Das ist jedoch Compilerabhängig.
Der Compiler führt gar nichts aus, der kann nur was in Maschinencode übersetzen. Zuerst führt der Controller den Startup-Code aus. D.h. ggf wird vor dem main noch etwas anderes gemacht. Schau dir den assemblierten Quelltext an und Du wirst sehen was dein Controller nach dem reset machen soll...
>Der Compiler führt gar nichts aus, der kann nur was in Maschinencode >übersetzen lol ich meinte ja den controller, sry :P >Zuerst führt der Controller den Startup-Code aus. D.h. ggf wird vor dem >main noch etwas anderes gemacht. Schau dir den assemblierten Quelltext >an und Du wirst sehen was dein Controller nach dem reset machen soll... ok, dann sollte das aber so funktionieren wie ich das programmiert habe. Ich habe noch einen etwas älteren gcc und habe desshalb einfach sbi benuzt, um die Register zu beschreiben. Waitstate ist nun auf dem höchsten, was ich überhaupt einstellen kann, aber das funktioniert immer noch nicht, wie es soll-langsam gehen mir echt die ideen aus. Kann es denn sein, das im bezug auf extMem ausser den Timings noch etwas anderes geändert wurde, wovon dann im Datenblatt allerdings nichts erwähnt wäre? Als Latch habe ich ein sn74hc573 verwendet-ist dieses evtl. zu langsam?
http://www.nongnu.org/avr-libc/user-manual/index.html FAQ -> How to use external RAM? Da is nen kleines Beispiel angeführt wie man es anstellt, das das SRAM wirklich ganz zu Anfang initialisiert wird (noch vor dem restlichen Start Up Code) Ein normaler hc573 sollte schon schnell genug sein, bei mir funktioniert er jedenfalls auch mit 18,432MHz ohne zusätzliche Waitstates problemlos.
danke für den Link, den werde ich mir merken - da hats ja ziemlich viel über den Gcc, oder besser gesacr die libc, da kann ich wies aussieht noch ne riesen Menge lernen. Doch im Code von dem yampp3 ist mir aufgefallen, das das Ram auch erst im main initialisiert wird. Und zwar mit der Zeile outp(MCUCR, 0xC0); //aktiviert Sram und waitstate die zusätzlichen wait state bits im extended mcucr habe ich aber mit sbi gesezt. Nun, der Compiler compiliert das brav, aber dennoch steht im Datenblatt das man die Register nur bis adresse 0x1f bitweise beschreiben kann. Mcucr und emcucr sind aber adresse 0x35. Ich werde nun mal ausprobieren auch die weiteren waitstates mit outp zu setzen. Liege ich total falsch und der gcc macht aus sbi sowiso etwas anderes oder könnte dies die Lösung meines Problems sein?
oho, das hat schon mal etwas gebracht, ich krieg das busy flag der hdd richtig ausgelesen :) Nun gehts aber mit Fat noch nicht richtig weiter, ich denke mal das ist ein Problem mit dem Ram-da dort die Fat tabelle sector buffer usw. Liegen. Nun, vielleicht liegt es grundsätzlich an meinem Ram, es handelt sich um ein "BS62LV256". Nach datenblatt ist dies ein Very Low Power/voltage CMOS sram. Und cmos brauch immer einen definierten Pegel an den Eingängen, wenn ich mich da nicht täusche... Stellt das irgendein Problem dar? Ich habe leider nicht gerade ein anderes ram zur hand womit ich das testen könnte...
naja ich hab nun auch noch ein anderes standard sram ausprobiert, wieder nichts :( was kann das denn noch sein, ausser das timing und die register?(verkabelung ist es ja auch nicht-alles durchgemessen)
Okay, ich denke, dass ich wieder mal eine Idee habe, was das Problem sein könnte. Und zwar hängt das write signal der Festplatte an pb0 seit dem at90s8515 eine neue Funktion hinzugekommen; "OC1" Dem Datenblatt kann ich zwar entnehmen, für was dass dieser Pin benutzt werden kann, allerdings finde ich nirgends etwas darüber, wie ich den denn einfach "normal" benutzen kann, also ohne dieses "OC1"...kann mir jemand sagen ob es dazu ein register gibt, mit welchem ich die funktion ausschalten könnte?
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.