Hi ihr, ich bin noch Anfänger und hab deswegen folgende Frage: Beim Lesen der technischen Daten zum ARM LPC2000 ist mir aufgefallen, dass er nur 512kB ROM und je nach Ausführung 2-64 kB RAM hat. Meine Frage: Kann man diese Wert nicht mit zusätzlichen Speicherchips erweitern oder kann nur der physisch im Baustein selbst gelegene Speicher genutzt werden? Ich brauche für mein Projekt am besten 256kB RAM und 1-2MB Programmspeicher. Danke und Gruß Theo
Danke für den Tipp! Sind RAM und ROM genauso schnell wie die internen, oder wird alles langsamer? Danke und Gruß Theo
>Danke für den Tipp! Sind RAM und ROM genauso schnell wie die internen, >oder wird alles langsamer? Es wird langsamer. Aber da du Anfänger bist macht das wohl kaum einen Unterschied.
Ich weiss, es ist nervig, wenn man keine direkte Antwort auf seine Frage bekommt,sondern eine "Empfehlung" zu etwas Anderem. Aber so viel RAM und ROM braucht man wirklich nur für größere Sachen. Wenn du gerade erst einsteigst, wärs vielleicht sinnvoll auch mal darüber nachzudenken irgend ein kleines, günstiges Board mit einem Microcontroller zu holen, welches nur ein paar kB Speicher hat um erstmal anzufangen. Man spart sich oft einen Haufen Ärger und Bastelei, wenn man zuerst mal mit was fertigem Anfängt und die Grundlagen sammelt.
Also ich brauche den RAM Speicher unbedingt, weil ich auf den Controller ein Schachprogramm portieren möchte. Das Programm an sich würde auch mit 64kB ROM und 4kB RAM auskommen, aber es empfiehlt sich eine grosse Eröffnungsdatenbank (= je mehr ROM desto besser) und mindestens 128kB RAM (besser 1MB !) für so genannte Hashtables. Damit spielt das Programm dann viel intelligenter, weil es bereits untersuchte Positionen im Haupsspeicher hält und nicht mehrfach untersuchen muss. Das RAM und ROM sollten beide nicht viel langsamer sein, als die internen und auch nicht über Umwege ansprechbar.
>Also ich brauche den RAM Speicher unbedingt, weil ich auf den Controller >ein Schachprogramm portieren möchte. Als Anfänger mal eben so ein Schachprogramm portieren. Ach wie niedlich. Bring erstmal mal eine LED zum leuchten.
Hallo Theo, für Schach reicht ein kleines Board mit MEGA8! http://bralug.de/wiki/BLIT2008-Board_spielt_Schach Das Schach selber ist auch sehr klein: http://home.hccnet.nl/h.g.muller/max-src2.html Ob dein Programm, falls es dann mal läuft dieses schlägt? avr
> für Schach reicht ein kleines Board mit MEGA8! Ich weiß! Es gibt da ein Projekt im Elektor. Mit dem Programm von H.G. Müller drin iirc. Ich möchte ein spielstärkeres Programm mit Eröffnungsbibliothek und Hashtables implementieren. Außerdem würde mich interessieren, wie gut bekannte OpenSource C-Programme wie GnuChess und besonders Fruit (Großmeisterstärke) darauf laufen. > http://bralug.de/wiki/BLIT2008-Board_spielt_Schach Toll! Kannte ich noch nicht, danke! > Das Schach selber ist auch sehr klein: > > http://home.hccnet.nl/h.g.muller/max-src2.html Das Programm ist mir allerdings bekannt. Schon ganz nett, aber eben auf geringe Größe und nicht Spielstärke optimiert. > Ob dein Programm, falls es dann mal läuft dieses schlägt? Ja.
Wenn es dir darum geht in irgendwelche Hash-Tables zu gucken um Schach zu spielen, reicht das allemal. Dazu bräuchtest du nichtmal so einen grossartigen Controller. Von der Leistung her würde für sowas locker ein 8051 mit ein paar Mhz ausreichen. Bei denen hast du nur eben das Problem, dass der Speicher lang nicht so gross ist. holger, solche Kommentare kannst du dir sparen. Er will wissen, wie die Hardware auszusehen hat und nicht ob du es niedlich findest was er vorhat. Dass das keine leichte Aufgabe ist, wird ihm spätestens klar werden, sobald er mal Quellcodes zu GnuChess o.ä. sieht. Aber das ist nicht dein Problem. Theo, so etwas portieren wird nicht ganz frei von Ärger sein. Jenachdem wie gut der Programmierstil ist, kannst du die "Intelligenz" ohne Probleme von der GUI trennen. Aber ich glaube kaum, dass das alles so strikt auseinandergehalten wurde, dass da c&p reichen wird. Schachcomputer und Software gibt es zuhauf und Quellcodes dazu schon seit zig Jahren, angefangen in 64er Heften. Da gibt es auch sehr viel Einfacheres. Ich weiss ja nicht, wie weit du bist/was du bereits kannst, aber deine Ziele sind sehr hoch gesteckt. Gerade bei der Elektronik/Controller würde ich noch gar nich an Schach denken. Kümmer dich erstmal darum, wie du die Informationen an den Controller bringst, wie du sie wieder ausgibst, wie du den Speicher verwendest, ... . Die Schachsoftware an sich ist, zumindest in Hochsprachen geschrieben, kaum anders als am PC.
Wenn du vorher wirklich noch nie etwas mit Mikrocontrollern gemacht hast, dann würde ich auf jeden Fall zunächst ein einfacheres Projekt vorziehen! Du musst keine 3 Jahre damit üben, aber mindestens mal den Controller an sich und die wichtigste Peripherie verstehen - das geht eben nur, in dem man sich Schritt für Schritt herantastet. Du wirst dann beispielsweise auch sehen, wie sich das mit dem RAM/ROM verhält. Ein Schachprogramm kann noch so sauber geschrieben sein - du wirst Probleme kriegen, die du lösen musst. Und das geht eben nur, wenn du dich mit dem Controller auskennst.
>Ich möchte ein spielstärkeres Programm mit Eröffnungsbibliothek und >Hashtables implementieren. Außerdem würde mich interessieren, wie gut >bekannte OpenSource C-Programme wie GnuChess und besonders Fruit >(Großmeisterstärke) darauf laufen. Das hört sich so an, als ob du ein Linux laufen lassen willst. In dem Fall muss dein µC eine MMU haben ( Memory Management Unit) Extern. # Mehr Pins am µC notwendig. # bedeutend mehr Aufwand im Platinendesign ( Mehr Bauteile, Signalleitungen) # bedeutend empfindlicher gegen Störungen ( EMV) # Austauschbare RAM/ROM Größe Intern. # geringere Aufwand beim Hardwaredesign/Aufbau # Billiger # unempfindlicher gegen EMV # RAM/ROM Größe nicht mehr Änderbar ( maximal durch Austausch des µC gegen einen anderen Typ aus der gleichen µC Familie)
Inwiefern wird dafür viel RAM benötigt? Eröffnungsdatenbank => feste Daten => ROM. Hashtable auf feste Daten => feste Daten => ROM.
da es bei einem Schachprogramm nicht so auf Geschwindigkeit ankommt, sind die Zugriffszeiten auf externen Speicher egal, würd ich behaupten. die ganzen statischen Daten kann man wirklich auslagern. Wenn mans ganz billg haben will, kann man eine SD Karte benutzen. Da hast du quasi unbegrenzt (zumindest für Mikrokontroller-Verhältnisse) Speicher zur Verfügung und die Ansteuerung ist auch einfach. Allerdings weiß ich nicht, was der Code an Ram braucht.
A. K. schrieb: > Inwiefern wird dafür viel RAM benötigt? > Eröffnungsdatenbank => feste Daten => ROM. Ja, das sind total statische Daten, die am besten auf ein EPROM ausgelagert werden. Oder eine SD-Karte. Schachprogramme können allerdings bis zu 512kB an Programmspeicher einnehmen, da sie bereits im Code diverse precalculations enthalten und dadurch die Programmgröße erheblich anschwillt. > Hashtable auf feste Daten => feste Daten => ROM. Nein, richtig ist Hashtable auf dynamische Daten => RAM ! Die Hashtable-Daten werden bei jeder Zugberechnung neu generiert. Es gibt fast so viele Lese/Schreibzugriffe wie Positionen in der Sekunde untersucht werden. RAM sollte mindestens 128kB und idealerweise etwa 1MB für Hashtables zur Verfügung stehen. Vlad Tepesch schrieb: > da es bei einem Schachprogramm nicht so auf Geschwindigkeit ankommt, > sind die Zugriffszeiten auf externen Speicher egal, würd ich behaupten. Leider nicht! Ausführungsgeschwindigkeit ist für Schach sehr wichtig. Jede Verdoppelung in der Geschwindigkeit bedeutet 70 Rating Punkte mehr. Das ist sehr viel. Schachweltmeister haben etwa 2800 Punkte, durchschnittliche deutsche Clubspieler so um die 1600. dago schrieb: > Ich weiss ja nicht, wie weit du bist/was du bereits kannst, aber deine > Ziele sind sehr hoch gesteckt. Gerade bei der Elektronik/Controller > würde ich noch gar nich an Schach denken. Kümmer dich erstmal darum, wie > du die Informationen an den Controller bringst, wie du sie wieder > ausgibst, wie du den Speicher verwendest, ... . Die Schachsoftware an > sich ist, zumindest in Hochsprachen geschrieben, kaum anders als am PC. Gast schrieb: > Ein Schachprogramm kann noch so sauber geschrieben sein - du wirst > Probleme kriegen, die du lösen musst. Und das geht eben nur, wenn du > dich mit dem Controller auskennst. Ja, das hört sich sinnig an. In der Programmierung allgemein kenne ich mich sehr gut aus, aber in der uC-Welt habe ich keine Ahnung. Es würde mich jedoch privat und beruflich weiterbringen, falls sich das ändert! Meint ihr das wäre vernünftig mit einem ARM7-Board die LEDs zum Leuchten zu bringen und später dann was komplizierteres darauf verwirklichen? Oder wäre für mich so ein kleines ATmega besser? Nur weiß ich, daß ich mittelfristig eh ARM7 brauchen werden, da die Anforderungen für das Schachprogramm eh klar sind. @Ralph Vielen Dank für die Auflistung, sehr sehr hilfreich !!! Das o.g. Board hatte externes RAM mit 10ns. Wahrscheinlich ist internes RAM auch nicht schneller. Aber extern ist halt empfindlicher, aufwändiger und teuerer, das muß ich auf jeden Fall bedenken!
> Vielen Dank für die Auflistung, sehr sehr hilfreich !!! > Das o.g. Board hatte externes RAM mit 10ns. > Wahrscheinlich ist internes RAM auch nicht schneller. Doch, das on-chip-RAM ist schneller. Auf das kann ohne Wartezyklen zugegriffen werden, auf das externe RAM hingegen nicht.
Theo Heinze schrieb: > RAM sollte mindestens 128kB und idealerweise etwa 1MB für Hashtables zur > Verfügung stehen. In diesem Fall sind Controller mit internem Cache an Stelle eines internen RAMs sicherlich wesentlich sinnvoller, als solche mit vorrangig internem Speicher ohne Cache. Also jene Typen die auf Linux-Implementierung abzielen, oft auf ARM9 Basis. > Board hatte externes RAM mit 10ns. Wahrscheinlich ist internes RAM auch > nicht schneller. Nicht die Zugriffszeit des RAMs entscheidet, sondern das Tempo des externen Zugriffs durch den Controller. Der braucht dafür mehrere seiner Takte und jeder davon hat bei LPC2000 bereits um die 15ns. Auf das interne RAM kann jedoch in 1 Takt zugegriffen werden.
Da du dich mit Programmiern auskennst würde ich aller höchstens für die ersten Grundlagen ein 8biter nehmen. Eher würde einen ARM7 oder vielleicht für den Anfang ein ARM Cortex-M3 nehmen, dann kannst du bei einer Architektur bleiben. Bei deinem Mamutprojekt kannst du alle 8bit sowieso vergessen. Du wirst aber vermutlich später externes RAM benötigen. Evt. lassen sich durch geschicktes Programmieren die zeitkrischen Sachen auf das interne RAM legen
Die LPC2000, in die er sich verguckt hat, sind bereits ARM7. Und da er auch einigermassen ausgewachsene Linux-Programme darauf laufen lassen will, sind auch die ARM7 mangels MMU noch zu klein.
Hab nicht gesehen, dass er Linux betreiben will. Gibt es einen Grund? Verbraucht in diesem Fall doch nur unnötig Ressourcen. ... Da Speed für dich wichtig ist, wirst du wohl langfristig einen ARM9 nehmen (müssen)
Matthias Keller schrieb: > Hab nicht gesehen, dass er Linux betreiben will. Gibt es einen Grund? > Verbraucht in diesem Fall doch nur unnötig Ressourcen. Beitrag "Re: RAM und ROM extern vs intern" Da kommt wohl nur ein fertiges Linux-Board in Frage. Solche Programme auf eine Umgebung ohne Betriebssystem zu portieren ist zwar vielleicht möglich, aber doch etwas Aufwand.
Nur weil er die "Intelligenz" von GnuChess auf einen Controller portieren will, heisst das noch lange nicht, dass da ein Linux drauf soll. Das wäre ein sinnloser Schritt in die falsche Richtung. Auch wenns einfach ist, darauf Programme zu schreiben, wird das Linux letztendlich der Flaschenhals sein, wenns ihm mal wirklich um geschicktes Optimieren geht.
Mit Linux ist ein Programm genauso schnell wie ohne Linux, wenn sonst nichts nebenher darauf läuft. Wenn man von dem bischen Timer-Interrupt absieht. Und was da nebenher läuft hat man selbst unter Kontrolle. Was bitteschön hat geschickte oder ungeschickte Programmoptimierung mit dem Betriebssystem zu tun? Von welchem Hals welcher Flasche ist da die Rede?
Beschränkungen beim Zugriff auf Speicher, keine Möglichkeit an manche Speicherbereiche heranzukommen, Assembler ist heftig für Linux, ...
dago schrieb: > Beschränkungen beim Zugriff auf Speicher, Beschränkungen beim Zugriff auf Speicher, auf den man keinen Zugriff benötigt. Oder an welchen Speicher dachtest du dabei? > keine Möglichkeit an manche Speicherbereiche heranzukommen, Warum musst du in einem Schachprogramm unbedingt den Bootloader vom Controller überbügeln oder am Interrupt-Controller drehen wollen? Wenn das natürlich Killerkriterien sind, dann stimmt's. > Assembler ist heftig für Linux, ... Es ist der gleiche Assembler, die gleiche Maschine, die gleiche Programmierung. Wo genau ist der Unterschied? Dass ein Schachprogramm hohe Datenmengen mit einem 3D-Grafik-Chip austauscht kann ich mir grad nicht vorstellen. Ein Schachprogramm tut fast die gesamte Zeit nichts anderes als rechnen.
Von Deinen Schachprogrammen habe ich keine Ahnung :-) Geschick ist es in jedem Fall, möglichst viel schnelles statisches RAM zur Verfügung zu haben, sofern sich die verwendeten Tabellen zum Programmstart errechnen lassen. Externes ROM ist immer deutlich langsamer als RAM. Auch die meisten internen ROMs bremsen bei maximalem Takt durch Wartezyklen den Programmablauf aus. Prozessoren mit schneller CPU und schneller Speicherschnittstelle findet man auch bei den SH2A von Renesas.
@ Theo Hier mal eine Beispielschaltung wie man am LPC2214 extern 1MByte RAM anschliesst. Der externe Speicherzugriff geschieht hier mit 16Bit man kann aber auch das ganze auf 32 Bit auslegen. Das RAM hat eine Zugriffszeit von 10nS. Auch ist es nach dem gleichen Schema moeglich externes FLASH anzubinden. Bei externen FLASH allerdings hast du laengere Zugriffszeiten weil die gaengigen Flashbausteine bei den Zugriffzeiten bei rund 60 .. 70nS liegen. Du koenntes dein Programm so organisieren das die Zeitkritschen Routinen im internen Speicher ausgefuhert werden und langsame im Externen Speicher. Auch gibt es noch die moeglichkeit das du noch mehr RAM anschliesst und eine externe FLASH-Speicherkarte an den LPC. So koenntes du das Programm von der Speicherkarte ins RAM Laden un dann dort starten. Gruss Helmi
>> Beschränkungen beim Zugriff auf Speicher, > Beschränkungen beim Zugriff auf Speicher, auf den man keinen Zugriff > benötigt. Oder an welchen Speicher dachtest du dabei? Das ist eigentlich das gleiche, wie das zweite Zitat von mir in deinem Beitrag, gemeint war natürlich etwas anderes. Die Beschränkung ist die Zeit. Wenn ich erstmal ein Array deklarieren muss und aus irgend einer Datei laden, die irgendwo im Flash/SD/Lochkarte/Fliegenpilz/.... liegt, dann braucht das enorm Zeit im Gegensatz dazu, wenn du das ohne die Zugriffsbeschränkungen von Linux einfach von A nach B "mov-en" kannst (dazu gleich noch mehr, erstmal noch zwei andere Sätze ;)). Der komplette I/O, seis RAM, SD, IDE, ..., wird durch das Linux einfach verlangsamt. Nur als Beispiel: der Kernel kümmert sich um jegliche DMA-Kanäle und du brauchst nur einen. Also ist dein Programm, jenachdem wie gut du bist, um einiges schneller. Genauso beim Zugriff auf Daten. Ob du jetzt einen kleinen Treiber von ~5kB für die SD Karte mit FAT hast oder da der Kernel durchmuss, welcher ja auch für zig verschiedene Dateisysteme, Quellen, Ziele usw ausgelegt ist, macht ebenfalls einen großen Unterschied. Sag mir erstmal für was er diesen ganzen Overhead brauchen könnte. Weil er damit erstmal 5MB Flash verbrät und 2 Wochen dran rumbastelt, bis da mal ein Linux ordentlich drauf läuft oder gleich mal 50 Eier mehr ausgibt, für ein fertiges Linux-Board? Die Einarbeitung in das Linux kommt sowieso immer noch dazu. Und die Konsole per UART ist schneller in Assembler geschrieben, als dafür ein Linux aufgesetzt und eingerichtet. Versteh mich nicht falsch, ich bin auch ein überzeugter Linuxer, gerade im embedded-Bereich, aber dafür ist es einfach nur unnötiger Ballast. >> Assembler ist heftig für Linux, ... >Es ist der gleiche Assembler, die gleiche Maschine, die gleiche >Programmierung. Wo genau ist der Unterschied? Du kannst (darfst) nicht am Linux vorbeiprogrammieren. Du musst das beachten. Nicht umsonst werden solche netten Geschichten wie Speicherverwaltung, Schichten, Benutzer (und deren Rechte) in ein Betriebssystem eingebaut. >Dass ein Schachprogramm hohe Datenmengen mit einem 3D-Grafik-Chip >austauscht kann ich mir grad nicht vorstellen. Ein Schachprogramm tut >fast die gesamte Zeit nichts anderes als rechnen Und diese Daten müssen so flott wie möglich in und aus dem Speicher und dort landen wo man sie braucht. Ein Betriebssystem, welches die komplette Speicherverwaltung (zwangsweise) abnimmt, hindert da nur. Solange er keine zig Threads gleichzeitig haben will, nebenher einen Webserver drauf laufen haben und an Regentagen mit dem Teil Filme gucken will, braucht er kein Linux.
Hallo Helmi, danke schön für die Schaltung! Das wäre erstmal genau das richtige für den Anfang. Die Idee Daten/Programm auf einer Flash-Speicherkarte zu halten und dann aus dem RAM starten finde ich super. Und zwar bräuchte die Eröffnungsdatenbank gar nicht ins RAM geladen werden, weil der Nur-Lese-Zugriff darauf ruhig sehr langsam sein darf. Der Programmcode müsste aber idealerweise vollständig im RAM liegen. Außerdem brauchen ja die Hashtables möglichst viel RAM. So könnte ich eine 128MB Flashkarte nehmen mit 127MB Eröffnungsdatenbank und 512kB Programmcode und hätte dann bei 1MB RAM zur Laufzeit immer noch 512kB für Hashtables im RAM übrig. Kann man eigentlich auch mehr als 1MB RAM verbauen mit dem schnellen 10ns Zugriff? Danke und Gruß Theo
>Kann man eigentlich auch mehr als 1MB RAM verbauen mit dem schnellen >10ns Zugriff? Ja, wobei Du aber keine 10ns Zugriffszeit erreichen wirst. Ein ext. Speicherzyklus dauert je nach Prozessor und Einstellungen 2 - 3 Taktzyklen. Bei 60MHz sind dann ca. 50ns realistisch. Effektiver wird der Zugriff mit größerer Datenbusbreite: bei 16Bit * 2, bei 32Bit *4.
>Kann man eigentlich auch mehr als 1MB RAM verbauen mit dem schnellen >10ns Zugriff? Ja das geht. Ohne zusaetzliche Hardware vom RAM mal abgesehen kannst du bis zu 4 RAMS anschliessen. Rechts unten in meiner Schaltung siehst du die Ausgaenge CS0 .. 3. Zwei davon sind nicht belegt und der dritte ist fuer meine externen BUS . Damit kann man genauso gut weitere RAMs anschliessen. Wenn du mehr als 4 RAMS anschliessen willst muss du einen zusaetzlichen Dekoder ala 74xx138 einsetzen. Auch kann man groessere RAMs als 1 MByte anschliessen. Schau mal auf die Seite von www.issi.com Von denen ist mein RAM. Gruss helmi
@helmi Besten Dank !!! > > Das hört sich so an, als ob du ein Linux laufen lassen willst. > In dem Fall muss dein µC eine MMU haben ( Memory Management Unit) Eigentlich nicht. Kann man im uC-Linux mehrere Prozesse nebeneinander laufen lassen, so wie Thread bei "normalen" Betriebssystemen? Hat der LPC2000 eine MMU? Oder AVR32? Oder Cortex M3? Oder brauche ich da schon was aus der ARM9 Klasse?
Du kannst dir auch mal den Hitex LPC3250 Stick anschauen. Er ist ein Arm9 Prozessor und hat relativ viel Power (266 MHz) und viel Speicher (intern 256 k Ram, extern 32 MB RAM, 128MB Flash). Zudem hat er Cache und eine FPU (k.A. ob sinnvoll für Schach). Es gibt als fertige Erweiterungsmodule auch ein Display. Renesas hat auch schnelle Mikrocontroller z.B. SH2 Familie.
Ach so: uC-Linux unterstützt Mutlitasking. Ob es nun beides Threads und Prozesse oder nur ein "Mittelding" gibt weiß ich nicht. z.B. bei Windows kann ein Prozess aus mehreren Threads bestehen und mehrere Prozesse laufen gleichzeitig. Beides man im Taskmanager nachschauen (Prozesse und Threads pro Prozess).
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.