Hallo, Vorweg kurz etwas zu meinem Wissenslevel: --- ich bin relativ neu in Sachen ARM-Mikrokontroller und vor allem Hardwareentwurf. Bisher habe ich nur eher Software für verschiedene embedded systems entwickelt, die allerdings als Applikation geladen wurden. Allerdings war das schon hardwarenahe Software (z.B. Graustufenemulation auf einem S/W-Display etc). Ansonsten habe ich schon mal einem Router per Serieller Schnittstelle eine neue Firmware verpasst... Ich hab ein abgeschlossenes Informatikstudium, allerdings keine Technische Informatik (d.h. mir fehlt ein Großteil des Wissens bzgl. Hardwarentwurf und Elektronik, die sonst enthalten wären. Einfache Prozessoren haben wir aber auch auf dem Papier entwickelt und ein paar Datenblätter von CPUs hab ich auch schon durchgeackert.) Das mal vorweg, damit man mir auch Antworten schreiben kann, die etwa mit meinem Wissensstand verständlich sind. Darum geht es: --- Ich benötige für mein Projekt etwas mehr Speicher, sowohl für Programmcode als auch Arbeitsspeicher. Mit internen 64kByte würde ich eher nicht auskommen. Daher möchte ich einen Mikrokontroller mit Hardwareschnittstelle für externen Speicher verwenden, damit ich direkt im Programm mit dem Speicher arbeiten kann und nicht bei jedem Zugriff wie zu DOS-Zeiten irgendwelche Speicherseiten (in sowieso schon sehr kleinen RAM) laden muss. Der Speicher soll auch effektiv als Arbeitsspeicher genutzt werden, d.h. häufig gelesen und geschrieben werden, weswegen Flash-Bausteine oder SD-Cards nicht in Frage kommen (nur um hier solchen Vorschlägen vorzubeugen, wie sie ja ständig hier im Forum zu finden sind). Es wird auch nur flüchtiger Speicher benötigt, also mir ist bekannt: Strom weg = Inhalt weg. Ich habe mir nun einen ARM7 Mikrokontroller ausgesucht (LPC2210), der aber in der Basisversion keinen internen Flash jedoch ein EMI (external memory interface) hat Auf den internen Flash möchte ich aus Kostengründen (und weil der evtl. sowieso zu klein ist) verzichten, d.h. eher die Version ohne internen Flash nehmen, wenn das geht. Laut Datenblatt/Herstellerseite soll das EMI (external memory interface) mit verschiedenem Speichern klar kommen, die 8-, 16- oder 32-bit organisiert sind und bis zu 16MByte pro Bank (ja "Byte" nicht Bit) groß sein dürfen. Datenblatt u. Usermanual gibs unter: http://www.nxp.com/acrobat_download/datasheets/LPC2210_2220_5.pdf http://www.nxp.com/acrobat_download/usermanuals/UM10114_1.pdf Zu den Fragen: --- Die Herstellerangaben sind ein wenig unterschiedlich bei den Angaben zu den unterstützten Speicherbausteinen. Im Usermanual (Kapitel 3.1: External Memory Controller -- Features, Seite 29) heißt es: "Supports static memory-mapped devices including RAM, ROM, flash, burst ROM, and some external I/O devices.". Allerdings steht im Datenblatt "Each memory bank is capable of supporting SRAM, ROM, flash EPROM, burst ROM memory, or some external I/O devices. [...] Each memory bank may be 8-bit, 16-bit, or 32-bit wide." Ich habe leider wenig Ahnung von den genauen Protokollen und Variationen von Speicherchips, daher folgende Fragen: 1. Kann ich da jetzt einen X-beliebigen SRAM oder Flash-Speicher anschließen, der 8-/16- oder 32-bit-organisiert ist oder muss ich da noch auf andere Details achten (Pegel-Spannung, Timing-Werte etc). 2. Kann ich statt SRAM auch DRAM verwenden, ohne dass ich mich um den Refresh des Inhalts kümmern muss (d.h. erledigt das dann der Memory Controller für mich) oder geht nur SRAM als RAM? Ansonsten wäre noch das Problem mit dem externen Flash-Speicher zu lösen. Ich muss ja irgendwie die Firmware in den Flash bekommen. Booten kann man wohl direkt vom externen Flashspeicher (bzw. Speicherbank 0). 3. Laut Benutzerhandbuch kann man den Flashspeicher nicht direkt per Bootloader (Serielles Interface) beschreiben. Gibts da evtl. ne fertige (kostenlose) Software, die man per Seriellem Interface in den RAM aufspielen kann, um dann damit den Flash (wiederrum via Seriellem Interface) zu beschreiben? -- Ich hab bisher nur mit dem seriellen Interface Erfahrung und da auch noch ein USB-Kabel (3V-UART) rumliegen, was ich dafür benutzen könnte/möchte... 4. Es gibt die Möglichkeit per JTAG-Interface den Flash zu beschreiben. Wie teuer ist so nen JTAG-Interface (sollte via USB angeschlossen werden, kein COM-Port oder Parallel-Port). Braucht man da spezielle Software bzw. bekommt man die vom Chiphersteller? Ist das ein Standard oder gibts da extreme Protokollabweichungen (so dass man jedes Mal z.b. ne andere Software/Hardware braucht, wenn man einen anderen Chip (anderer Chiphersteller) fernsteuern will)? Allgemein noch: 5. Gibt es vergleichbare Chips (preislich), die meinen Anforderungen nahe kommen würden. Ich hab jetzt speziell mal nur die von NXP durchgeschaut, weil ich mitbekommen habe dass es da welche mit External Memory Interface gibt. Speziell scheint es aber keine "Norm" für die Bezeichnung der Fähigkeit "Kann externe Speicher hardwareseitig direkt verwalten" zu geben, was mir die Eigen-Recherche doch sehr erschwert. Konkret wären also Produkte anderer Hersteller von Interesse, die preislich (in großen Stückzahlen) für 6-7 EUR zu haben sind und direkt mit externem Speicher arbeiten können. Also keine Software-Implementierungen bitte, es sei denn die arbeiten so dass man sich außer Initialisierung nicht mehr drum kümmern muss. Ich könnte mir da was vorstellen mit ExceptionHandling bei unzulässigen Speicherzugriffen etc... ist aber meiner Meinung nach eher ein Hack als eine saubere Lösung. Effektiv brauche ich so 1-2MB Flash (Firmware) und 2MB RAM (Arbeitsspeicher). Danke schonmal fürs Lesen... LG, Stefan
1: Du musst selbstverständlich auf Pegel, Timing und Art der Ansteuerung achten. Das übernimmt nicht der Speichercontroller für Dich. 2: DRAM kannst Du nur verwenden, wenn der Speichercontroller auch DRAMs ansteuern kann, Dein Philips-/NXP-ARM kann das nicht. Da müsstest Du schon einen eigenen DRAM-Controller stricken und anschließen. 3: Wie extern angeschlossene Flash-ROMs zu programmieren sind, hängt von diesen ab; die Hersteller definieren ihre Programmieralgorithmen, die Deine Programmiersoftware einhalten muss. 4: Das JTAG-Interface ist Bestandteil des ARM7-Kernes und also herstellerübergreifend standardisiert. Ein günstiger USB-JTAG-Adapter ist der von Olimex hergestellte FT2232-basierende OpenOCD-Adapter. Software für das Interface liefern oft die Compiler/Entwicklungssystemhersteller, wie IAR oder Rowley. 5: OKI stellt ARM7-Derivate mit externem Speicherinterface her; die Typbezeichnung kannst Du herausfinden, indem Du Dir ansiehst, welche Platinen für OKI-ARMe Olimex herstellt. Die unterstützen übrigens auch direkt SDRAM. Preise und Bezugsmöglichkeiten sind mir unbekannt. Bedenke jedoch: Extern angebundener Speicher ist langsam, der ARM wird also mit "angezogener Handbremse" (Waitstates) betrieben, vor allem beim Flash ist das so.
Rufus t. Firefly wrote: Danke für deine schelle und ausführliche Antwort! > 1: Du musst selbstverständlich auf Pegel, Timing und Art der Ansteuerung > achten. Das übernimmt nicht der Speichercontroller für Dich. Mir gings eher um die Auswahl der verwendbaren Hardware. Dass ich da per Software noch bissl konfigurieren muss ist klar. > 2: DRAM kannst Du nur verwenden, wenn der Speichercontroller auch DRAMs > ansteuern kann, Dein Philips-/NXP-ARM kann das nicht. > Da müsstest Du schon einen eigenen DRAM-Controller stricken und > anschließen. Wobei ich irgendwo (ich glaub bei Wikipedia) gelesen habe, dass es DRAMs gibt, die sich selbst refreshen, wenn man sie in den richtigen Modus versetzt.... Aber ich denke das ist mir etwas zu stressig, dann werde ich mich einfach mal auf SRAM beschränken (war halt nur etwas teurer ist). > 3: Wie extern angeschlossene Flash-ROMs zu programmieren sind, hängt von > diesen ab; die Hersteller definieren ihre Programmieralgorithmen, die > Deine Programmiersoftware einhalten muss. OK, also müsste ich hier was eigenes entwickeln oder die JTAG-Variante wählen. > 4: Das JTAG-Interface ist Bestandteil des ARM7-Kernes und also > herstellerübergreifend standardisiert. Ein günstiger USB-JTAG-Adapter > ist der von Olimex hergestellte FT2232-basierende OpenOCD-Adapter. > Software für das Interface liefern oft die > Compiler/Entwicklungssystemhersteller, wie IAR oder Rowley. Gibts da was zu empfehlendes das OpenSource / Freeware ist (Betriebssystem WinXP oder Linux)? Ich wollte eher mit GCC (entsprechende Tool-Chain fürs ARM crosscompilen natürlich) entwickeln... > 5: OKI stellt ARM7-Derivate mit externem Speicherinterface her; die > Typbezeichnung kannst Du herausfinden, indem Du Dir ansiehst, welche > Platinen für OKI-ARMe Olimex herstellt. Die unterstützen übrigens auch > direkt SDRAM. Preise und Bezugsmöglichkeiten sind mir unbekannt. Gut, da werd ich mich mal schlau machen. Mit SDRAM-Controller gibts auch Chips von Philips, allerdings nicht die Preisklasse die ich anstrebe... Es sei denn die SDRAMs sind preiswerter als die SRAMs, dann würde sich das aufheben. > Bedenke jedoch: > Extern angebundener Speicher ist langsam, der ARM wird also mit > "angezogener Handbremse" (Waitstates) betrieben, vor allem beim Flash > ist das so. Danke für die Warnung. Dessen war ich mir an sich bewußt. Ich rechne hier mit Faktor 4-10 Geschwindigkeitsverlust, je nach Speicher den ich halt einsetze. Aber da wir grad beim Thema sind, nur mal zum Verständnis: Ich geh mal davon aus, dass der Prozessor ne gewisse Anzahl Pipelines hat, die Parallel arbeiten (d.h. Instruction Fetch, Data Read, Execution, Data Write laufen jeweils parallel ab) und max. 1 Befehl pro Takt. Der Prozessortakt ist 60Mhz also sind das 16,67ns pro Takt. Wenn ich jetzt nen SRAM-Chip mit 55ns Zugriffzeit hab, wären das (etwas mehr als 3 also) 4 Takte für jede Speicheroperation. Entsprechendes würde wohl auch für das Instruction-Fetching gelten, da das aber parallel läuft, wäre die Verzögerung das maximum aus beidem. Allerdings nur, wenn ich für beides getrennte Speicher verwende oder bekomme ich da konflikte auf dem Speicherbus (d.h. dass ich die Speicherbänke nur nacheinander lesen/schreiben kann und nicht parallel)? Nehme ich einen flotten SRAM mit 10ns anschließe, sollte der Prozessor dann doch mit voller Geschwindigkeit arbeiten... oder gibts da trotzdem Verzögerungen gegenüber dem internen SRAM? (Jetzt mal nur theoretisch, wahrscheinlich werd ich sowieso keinen mit solcher Größe und der Geschwindigkeit für kleinen Preis bekommen) Ich hätte ja persönlich erwartet, dass der Controller wenigstens einen winzigen Instruction Cache von ein 128bit oder sowas hat (da hab ich mich wie es aussieht getäuscht... eine Suche nach "Cache" im Datenblatt schlägt jedenfalls fehl) Notfalls sollte ich ja noch den internen Speicher für Geschwindigkeitsoptimierungen benutzen können. Kritische Programmteile könnte man evtl. ja auch in den (internen/externen) SRAM kopieren, wenns wirklich problematisch wird. Wobei der Flash-Speicher nicht so viel langsamer zu sein scheint als ein großer SRAM (70ns, also wohl 5 Takte statt 4). --- Sind irgendwelche Fehler in den "Vorstellungen" die zum Waitstate-Problem so habe? Zudem: Ist das Geschwindigkeitsproblem ein reines Problem wegen der Zugriffzeiten der Speicher selbst oder gibts hier eher konflikte wegen gleichzeitiger Nutzung des External Memory Interface? Ich glaube allerdings, dass die Prozessorleistung trotz Speicherflaschenhals für meine Zwecke ausreichen sollte. LG, Stefan
@stefan: wenn dir 512kb Flash und 128kb ram reichen würde ich dir den at91sam7x512 empfehlen, der hat das alles schon intern und du ersparst dir die probleme mit ext. memory interface. gruss gerhard
> 1: Du musst selbstverständlich auf Pegel, Timing und Art der Ansteuerung > achten. Das übernimmt nicht der Speichercontroller für Dich. Dazu hätt ich noch fragen. Also beim Pegel gehts um die Spannung(-stolleranzen) an Adress/Steuer- und Datenleitungen - also die Versorgungsspannung der Chips ist ja davon unabhängig, oder? Timing ist so in etwa klar... die Frage war sehr ungenau gestellt. Hier meine ich eher: gibt es da irgendwelche Probleme wie sie beim PC auftreten... Z.B. wenn ich einen PC1600-SDRAM in einen Rechner einbaue der für PC533-SDRAMs ausgelegt ist. Was Ansteuerung von Speicher angeht, bin ich absolut schlecht im Bilde, daher frag ich lieber, eh ich dann was bastle, dass zwar kurzzeitig funktioniert, aber dann langzeitig fehleranfällig ist... Bei der Art der Ansteuerung? Was gibts da für "Ansteuerungsarten"? Also SPI-Interface hab ich irgendwo schonmal gelesen... allerdings wird das nicht sein, was ich verwenden kann mit dem EMI von dem Chip, zumindest wenn ich das richtig verstanden habe, was bei Wikipedia dazu steht [ich habs nur kurz überflogen, aber es sieht eher nach einem Protokoll aus bei dem wie beim I2C-Bus die Daten Bitweise über eine Steuer/Datenleitung geschickt werden - und nicht, dass 8/16/32-Bit am Stück per Datenleitung ausgeliefert werden] Gibt es eine "Bezeichung" für dieses Protokoll/Interface das für den EMI in Frage kommt?
gerhard wrote: > @stefan: > wenn dir 512kb Flash und 128kb ram reichen würde ich dir den > at91sam7x512 empfehlen, der hat das alles schon intern und du ersparst > dir die probleme mit ext. memory interface. Hallo Gerhard, also 128kB RAM reichen eher nicht. Wenn dann müsste ich die Algorithmen so abändern und einschränken, dass ich dann auch gleich mit 64kB arbeiten könnte. Der Flash-Speicher wäre mit 512kB evtl. ausreichend, ich hab da noch kein Gefühl, wie groß die kompilate werden. Aber was ich so von PC-Software gewohnt bin, ist halt immer in Dimensionen, wo das locker gesprengt würde... Aber: Danke für die Empfehlung... vielleicht ziehe ich das noch in Betracht, wenn der Aufwand mit den externen Speichern zu hoch wird. Rufus t. Firefly wrote: > 5: OKI stellt ARM7-Derivate mit externem Speicherinterface her; die > Typbezeichnung kannst Du herausfinden, indem Du Dir ansiehst, welche > Platinen für OKI-ARMe Olimex herstellt. Die unterstützen übrigens auch > direkt SDRAM. Preise und Bezugsmöglichkeiten sind mir unbekannt. Also bei Oki hab ich da mal recherchiert. Der einzige ARM-basierende Chip den ich gefunden hab, der eben SRAM,Flash und SDRAM anbinden kann, ist der ML675050... Siehe auch: http://www.okisemi.com/eu/Products/ARMSolutions/armmcu.html ...und zu dem finde ich tatsächlich nirgends ein Angebot (weder bei www.mercateo.com noch per google "ML675050 EUR preis"). Der ist wohl wirklich noch zu neu... LG, Stefan
Angehängte Dateien:
-
armcpu.png
71 KB
Hallo Stefan Wenn du denn LPC2214 von Philips nimmst hast du 512 Kbyte Flash On board. Denn kannst du auch extern erweitern. Allerding ist externer Flash langsamer als interner. Auch kannst du an dem externes SRAM anschliessen. Ich habe da mal ein Board mit gemacht das 1MByte SRAM und 4Mbyte Flash hat. Den Loader um das externe Flash zu programmieren habe ich dabei selber gemacht. Gruss Helmi
Hallo Helmut, Helmut Lenzen wrote: > Wenn du denn LPC2214 von Philips nimmst hast du 512 Kbyte Flash On > board. Das kann ich leider nicht bestätigen... Laut datenblatt hat er leider nur 256KB Flash-Speicher (und 16kB RAM) zudem ist er sehr viel teurer. http://www.nxp.com/acrobat_download/datasheets/LPC2212_2214_4.pdf > Allerding ist externer Flash langsamer als interner. Wieso sollte das so sein? Also am Speicher selbst wird das nicht liegen. Ich meine: größere Speicher sind sicher komplexer organisiert und daher ist die Zugriffszeit tendenziell höher, aber ein Flash-Speicher mit vergleichbarer Größe, wie übliche interne Flashs, sind sicher mit gleichen Zugriffzahlen erhältlich. Ich könnte mir aber schon vorstellen, dass es für interne Flash-Speicher eine feste "Verdrahtung" und damit schnelleren Zugriff gibt. Woher hast Du denn Deine Infos? > Ich habe da mal ein Board mit gemacht das 1MByte SRAM und 4Mbyte Flash > hat. > Den Loader um das externe Flash zu programmieren habe ich dabei selber > gemacht. Dann weiß ich ja wo ich notfalls fragen kann und vor allem, dass es einigermaßen praktikabel ist. Danke... Stefan
Externer Flash ist deswegen langsamer als interner, weil er über ein schmaleres Businterface angebunden wird. Das Flash der LPC21xx-Reihe beispielsweise ist 128 Bit breit organisiert und kann so mit einem Lesezugriff gleich vier DWORDs liefern. Beim OKI-ARM ist das externe Businterface sogar nur 16 Bit breit ...
Sorry stimmt mit den 256KByte hatte noch den AT91SAM7SE512 im Hinterkopf gehabt der hat 512 Kbyte. Schnelleres Flash als 60nS habe ich bisher noch nicht gefunden. Gruss Helmi
Ich hab inzwischen mal recherchiert. Also die SDRAMs scheinen doch recht flott zu sein und vor allem auch preiswert (zumindest die Module, dazu kämen allerdings noch die Kosten für den Sockel) und riesig :) Folgende Mikrocontroller hab ich gefunden, die SDRAMs direkt ansteuern können... NXP: LPC2880FET180 LPC2888FET180 Freescale: MC9328MXLVP15 Allerdings sind die irgendwie nicht zu haben... Ansonsten hab ich folgende Mikrocontroller gefunden, die externe Speicher ansteuern können: LPC2210 - kein Flash LPC2290 - kein Flash LPC2210FBD144/01 - kein Flash LPC2212FBD144/01 - kein Flash LPC2214FBD144/01 - kein Flash LPC2292FBD144/01 - kein Flash LPC2212 - 128K LPC2214 - 256K LPC2214FBD144/00 - 128K LPC2212FBD144/00 - 256K LPC2292 - 256K LPC2292FBD144/00 - 256K LPC2292HBD144/00 - 256K --- Was ich aber finden konnte war ein ARM9-CPU: LPC3180FEL320 kein Flash, aber SDRAM support (DDR und SDR) und 32kb Instruktions- sowie 32kb Datencache... Damit sollten die Performance-Probleme der externen Speicher weitgehend kompensiert werden. ARM9 + 2MByte SDRAM + 16MB NAND-Flash (Preisabschätzung für größere Stückzahlen): 4,17 EUR 2MB SDRAM (1MB x 16, 5ns), IS42S16100C1-7TL 3,81 EUR 16MB NAND-Flash, NAND128W3A2BN6E 12,38 EUR LPC3180FEL320 - kein Flash --------- 20,36 EUR Auf jeden Fall ist hier mehr Geschwindigkeit zu erwarten, 5ns Zugriffzeit für den RAM und dazu noch vorgeschalteter Cache sowohl für RAM als auch den Flash... auf jeden Fall eine bessere Lösung was die Leistung angeht, bei vergleichbarem Preis... LG, Stefan
Hallo Stefan AT91SAM7SE512 von Atmel hat auch ein SDRAM Interface Gruss Helmi
Helmi wrote: > AT91SAM7SE512 von Atmel hat auch ein SDRAM Interface Super! Danke Helmi, das reduziert die Kosten dann gleich um ein drittel, wenn ich mich auf 512KB Flash beschränken kann (was ich für sehr realistisch halte)... Amtel ARM7 mit 512KB internem Flash + 2MByte SDRAM extern: --------- 9,08 EUR ARM7 mit SDRAM-Support, AT91SAM7SE512 4,17 EUR 2MB SDRAM (1MB x 16), IS42S16100C1-7TL --------- 13,25 EUR Was die Geschwindigkeit der externen Flashs angeht: 32Mbit, 70ns, M29DW323DT70N6E 512Kbit, 70ns, 64kx8, AT29C512-70JU Was viel kleineres oder schnelleres hab ich spontan garnicht gefunden. Wahrscheinlich bekommt man so winzige Flashs halt einfach nicht (mehr). Dementsprechend stimmt die Aussage indirekt wahrscheinlich, dass die internen Flashs schneller sind. Wobei eben die Frage wäre wie schnell der 512KB große Flash im AT91SAM7SE512 ist. Im AT91SAM7SE512 gibts für den Flash jedenfalls einen Prefetchbuffer... Zur In-System-Programmierung des AT91SAM7SE512: Das Datenblatt liefert hier folgende Aussagen: "The embedded Flash memory can be programmed in-system via the JTAG-ICE interface or via a parallel interface on a production programmer prior to mounting." "The SAM-BA Boot is a default Boot Program which provides an easy way to program in-situ the on-chip Flash memory. The SAM-BA Boot Assistant supports serial communication via the DBGU or the USB Device Port." (Quelle: http://www.atmel.com/dyn/resources/prod_documents/6222s.pdf) D.h. mit normalen seriellem Interface kommt man da wohl nicht weit, aber USB ist ja an sich unproblematisch... Man muss im Prinzip nur paar Pins für nen USB-Port rauslegen, wo man dann nen Adapter (Pin-Stecker auf USB-Buchse) dran klemmt. Und für die Produktion kann man die Flashs ja dann evtl. auch vor dem löten programmieren lassen. Da werd ich mich auf jeden Fall noch schlau machen müssen, was das angeht. Soar... auf jeden Fall bin ich schon mal sehr viel weiter! Und vielleicht hilft es ja auch dem einen oder anderen der auch viel Arbeits-Speicher braucht und Kosten sparen muss... Schade ist, dass sowas leider auf Dauer veralten wird. Ich hatte mal kurzzeitig über eine globale Datenbank nachgedacht, wo man von sämtlichen Chipherstellern die Daten importiert (irgendwie automatisiert oder direkt die Chiphersteller eintragen lässen... die haben ja Interesse daran, dass Ihre Chips verwendet werden) und dann eine parametrische Suche hat, wie bei den meisten Herstellerseiten - nur eben so, dass man nicht auf den Hersteller beschränkt ist... Am Besten mit regelmäßigen, automatisierten Preis-Daten über Preissuchmaschinen, um dann nach Preis (mit wählbarer Stückzahl) sortieren zu können - und z.B. auch Modelle rausfiltern kann, die nicht vernünftig erhältlich sind. Vielleicht gibts das sogar auch schon... Wäre mal eine Recherche wert. Wenn ja, sollte das irgendwo hier auf der Seite gut auffindbar (z.B. bei den Beschreibungen zu den Mikrokontroller-Eigenschaften) verlinkt werden.... lg, Stefan
Hallo Stefan Doch die kleinen Flash bekommt man schon noch die werden fuer Steuerungen eingesetzt (da braucht man keine hunderte von Megabyte). Aber wie gesagt was schnelleres als 60nS habe ich bisher nicht gefunden ausser irgendwelche Pagemode Flashs (aber die nutzt der Prozessor nicht). Da RAM wesentlich schneller ist kann man ja beim Start das Flash ins RAM kopieren und dann dort ausfuehren. Das interne Flash AT91SAM7SE512 habe ich mit SAMBA ueber die RS232 programmiert. Unter diesem Thread habe ich mal eine Schaltung mit dem AT91SAM7SE512 gepostet. Beitrag "DRAM am Prozessor" Gruss Helmi
Tach, wenn es mit SRAM genügt (was es auch sehr schnell gibt) wäre doch ein neuer STR9xx auch vielleicht eine alternative. Den gibt es mittlerweile mit 2MB auf Bank 0 und 128k auf Bank 1 Flash intern, so wie ich das gesehen habe.. Grüsse Michael
noch ein vorschlag falls du mit den 512kb internem flash nicht auskommst: nimm für den program- und für den datenspeicher ein paralleles schnelles sdram (wie von helmut vorgeschlagen) und lade mittels bootloader den code aus einem seriellen flash (gibt es sehr günstig) in das sdram (danke an die von-neumann architektur). gruss gerhard
Michael Gerkens wrote: > wenn es mit SRAM genügt (was es auch sehr schnell gibt) wäre doch ein > neuer STR9xx auch vielleicht eine alternative. Den gibt es mittlerweile > mit 2MB auf Bank 0 und 128k auf Bank 1 Flash intern, so wie ich das > gesehen habe.. Also bei den STR9xx hab ich glatt übersehen, dass die nen externen Speicherbus haben (sollten sie auf Ihrer Webseite mal unter key benefits/features aufzählen :). Laut Webseite von ST heißt es "Plentiful SRAM and flash memories. Up to 96Kbytes SRAM, and up to 544Kbytes of dual bank flash. Either SRAM or Flash memories maybe used for instructions or data" für die STR9-Serie... Also intern nur 96KB RAM. 2MB externer SRAM kostet mal eben 10-11 EUR, wenn der Chip nur 2 EUR kostet, wäre das günstiger. Zudem wäre halt die Frage, ob 128kB Flash reichen (wird eher sehr sehr knapp) oder ob da wieder nen externer Flash (zusätzliche Kosten + Platz auf der Platine weg) nötig ist. Problematisch ist außerdem: Ich kann keine Verkaufsangebote für die STR9-Serie finden... Aber: Danke für den Vorschlag... Vielleicht hast Du Dich auch bei der Bezeichnung geirrt? Passiert ja schnell mal... oder kennst Du Bezugsmöglichkeiten? (allerdings wär das nur wirklich interessant, wenn wirklich 2MB RAM direkt intern wären) LG, Stefan
gerhard wrote: > noch ein vorschlag falls du mit den 512kb internem flash nicht > auskommst: > nimm für den program- und für den datenspeicher ein paralleles schnelles > sdram (wie von helmut vorgeschlagen) und lade mittels bootloader den > code aus einem seriellen flash (gibt es sehr günstig) in das sdram > (danke an die von-neumann architektur). Naja, von der Sache her könnte man auch Datenkompression benutzen und den Code "einpacken". Dann einen Loader + eingepackten Code in den Flash laden, der den Code in den SDRAM entpackt und dann ausführt. Da kann man evtl. auch noch einiges rausholen ohne großartig in zusätzliche Hardware zu investieren und hat dann SDRAM-Geschwindigkeit für den Instruktionsspeicher. Statt 2MB SDRAM 4MB SDRAM jedenfalls preiswerter als zusätzlich einen Flash mit 1-2MB dazu zu nehmen. Auf jedenfall sparts Platz auf der Platine und verringert Kosten/Zeitbedarf durch aufbringen der Chips. Is halt die Frage, wie gut der Code sich so komprimieren lässt. Das ist halt schwer abschätzbar... aber ich schätz fast das 20% bis 70% weniger Speicherbedarf möglich sind. Damit könnte man evtl. sogar auf 256KB Flash-Speicher zurückgehen, wenn das geht. D.h. später wenn die entwicklung der Software fertig ist schauen, ob man mit kompression die Flash-Größe kleiner halten kann. Wenn mal wer Lust/Zeit hat: Kann mal einer ein paar seiner ARM7-Binaries packen und schauen, wie sich die größe ändert? (aber ich werd erstmal im Forum recherchieren, ob das vielleicht schon einer probiert hat ... also macht euch nicht zu viel Arbeit deswegen :) Danke, Stefan
Als Controller könntest du auch den LPC2468 verwenden. Der hat auch 512kB Flash und einen SDRAM-Controller.
Kai F. wrote: > Als Controller könntest du auch den LPC2468 verwenden. Der hat auch > 512kB Flash und einen SDRAM-Controller. Auch den finde ich leider nirgends im Handel...
Helmut Lenzen wrote: > Hier mal ein Zip von mir wo ich gerade eine ARM-BIN Datei gepackt habe. > > Gruss Helmi Danke Helmut, ich hab das ARM-BIN nochmal mit stärkerer Kompression neu eingepackt, Ergebnis: - gepackt: 58'086 Bytes - entpackt: 274'550 Bytes Der Kompressionsfaktor liegt also bei ca. 4,72fach-kleiner oder 21,16% der Ausgangsgröße bzw. -78,84% Größe... Mir scheint aber, dass Du da ziemlich viele Strings drin hast, die eher DEBUG-Infos sind. Evtl brauchst Du nur im Compiler mal "keine Debuginformationen" aktivieren bzw. die "Debuginfos" deaktiveren und hast schonmal extrem viel kleiner Binarys. Beim gcc bei den CFLAGS die Option "-g" oder "-ggdb" rausnehmen. Evtl. hilft auch das tool "strip" weiter, welches Debuginformationen aus executables entfernt... Nur mal als Vergleich: -rwxr-xr-x 1 root root 36702 2008-04-16 14:54 test -rwxr-xr-x 1 root root 26560 2008-04-16 14:56 test.striped -rwxr-xr-x 1 root root 242990 2008-04-16 14:53 test.gdb -rwxr-xr-x 1 root root 26560 2008-04-16 14:56 test.gdb.striped -rwxr-xr-x 1 root root 11910 2008-04-16 15:05 test.striped.gz Das ist zwei mal die selbe Anwendung (C++, allerdings für normale PCs) mit und ohne Debuginfos und jeweils nochmal striped... Der Unterschied ist enorm, wie man sieht und beeinflusst normalerweise in keiner Weise die Ausführung (es sei denn man hat manuell irgendwo an dem Binary rumgewerkelt oder irgendwelche Daten angehängt etc) - Daten hinten anhängen kann man später auch noch. Es betrifft auch keine Strings, die in der Anwendung Verwendung finden, sondern nur sowas wie Namen von Funktionen oder globalen Variablen... Allerdings finde ich selbst dann noch "SPAM" vom Compiler "GCC: (GNU) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)" (und zwar gleich mehrfach, also locker 1KB) - den kann man sicher auch noch irgendwie raus bekommen, aber für die grobe Analyse sollte das erstmal reichen. Zudem habe ich mal testweise das ge-stripe-te File gepackt. Wie man sieht, kann man damit nochmal über die Hälfte rausholen (nur noch 44,85% der Dateigröße)... Mal ehrlich: das macht schon echt was aus. Nehmen wir an, man bekommt den Bootloader mit Entpacker in ein paar KB rein, dann kann man ein Image das eigentlich einen 256KB-Flash benötigt in einen 16KB Flash oder gar in einen 12KB Flash quetschen und dann in den RAM entpacken. Der zusätzliche RAM-Speicherbedarf würde hier z.B. 26560 Bytes also knapp 26KB betragen... LG, Stefan
Den LPC2468 gibt's z.B. bei Schukat (leider nur für Gewerbetreibende) und bei Digikey. Zwar etwas teurer, aber auch bei tme.eu ist er erhältlich.
Habe jetzt nicht jede Zeile der recht langen und ausführlichen Antworten gelesen, werfe aber mal kurz mal ein paar Anmerkungen ein: SDRAM != PSRAM: Es gibt DRAMs mit interner Refresh Logik, die als PSRAMs (Pseudo-Static) bekannt sind. Sind recht flott, müssen aber initialisiert werden. D.h. der Bootloader des ARM, der vorzugsweise nur mit dem internen FLASH und RAM (so vorhanden) arbeitet, muss das PSRAM initialisieren. SRAM DRAM SDRAM SRAM ist sicherlich teuer im Vergleich zu DRAM. DRAM wiederum setzt einen Refresh-Controller voraus, mal abgesehen von PSRAM. Will man (S)DRAM an einen Controller anschließen, so sollte man die Datenblätter beider genau vergleichen. U.A. sind auch Dinge wie Pagesize, RAS und CAS Latency genauer zu untersuchen. Der Cotroller sollte diese Parameter entsprechend dem (S)DRAM Datenblatt liefern können. JTAG != EXT-Mem Programming Über das JTAG der meisten CPUs wird nur ein kleiner Loader in das RAM der CPU installiert. Dieser nutzt das JTAG als 'serielle' Schnittstelle um dann die Software ins RAM zu laden und auszuführen. Bei kleinen CPUs ohne oder mit nur wenig eigenem Speicher geschieht dies sogar mehrstufig: Mini-Loader wird geladen und initialisiert externe Speicher und lädt großen Loader. Großer Loader lädt Applikation. Flashloader: Da, wie zuvor schon angemerkt, FLASH Bausteine leicht unterschiedliche Programmierinterfaces haben, wird auch hier das JTAG Verfahren angewandt. Ein FLASH-Loader wird ins RAM der CPU geladen und nutzt dann den JTAG um eine Datei ins FLASH zu kopieren. Dieser Loader muss auf das vorhandene FLASH abgestimmt werden. Mit der Unterstützung von Intel und Spansion Protokoll hat man aber schon schon 90% aller Varianten abgedeckt, wenn man nicht auf unheimliche Performance-Optimierung beim Programmieren achten muss. Man kann aber die ID des Chips abfragen und dann entscheiden, welcher Typ flash wie programmiert werden muss. Dies zeigt Dir aber auch einen recht einfachen Lösungsweg für Deine Probleme: Das Einfachste ist eine CPU zu nehmen, die neben einem externen Memroy-Interface auch etwas internen FLASH und RAM hat. Zum einen kann man natürlich einen Performance-Boost erreichen, in dem man Code, der Zeitkritisch ist, im internen RAM ablaufen lässt, aber man kann auch ganz einfach eine komplette Initialisierung der externen Peripherie von dort aus machen. Auch die kompletten FLASH-Algorithmen und Update Prozeduren können dort liegen. Einschränkend und erleichternd möchte ich aber noch erwähnen, dass auch die CPU Hersteller mitgedacht haben. D.h. in den Datenblättern findest Du zum einen die Startadressen der CPU ( Reset-Vector) d.h. dort muss FLASH liegen. Dieses FLASH wird nach Reset mit den größ möglichen Waitstates angesprochen. Deine Reset-Routine nimmt dann in den ersten Zeilen gleich eine Initialisierung aller Speicher einschließlich eines Herabsetzens der Waitstates für das Flash vor. Und dann Volldampf voraus... Mein Herangang wäre damit erste einmal nach Dev-Kits zu suchen, die von einer breiteren Gemeinde unterstützt werden. Olimex oder Ethernut wären nur ein paar Beispiele. Für diese gibt es Entwicklungssysteme, die die Boards auch gleich initialisieren. Dort würde ich mich einfach mal einlesen und dann vielleicht einfach die Externe Bestückung danach auswählen, was andere schon nutzen und für gut befunden haben. Alles von anfang an alleine zu machen heißt, das Rad neu zu erfinden. Soll die Entwicklung später in Serie gehen und es kommt auf jeden Cent an, dann kann man immer noch optimieren. Gruß, Astralix
Man kann im übrigen beim GCC die option "-s" benutzen, die dann das selbe wie ein "strip" bewirkt. Und man kann die Infos die der Compiler über sich hinterlasst wie folgt entfernen: strip -R .comment <executablename> Ersparnis: 638 Bytes Zusätzlich kann man noch 32 Byte mit folgendem Befehl beseitigen: strip -R .note.ABI-tag <executablename> Ergebnis (gepackt/ungepackt): -rwxr-xr-x 1 root root 25776 2008-04-16 15:48 test -rwxr-xr-x 1 root root 11784 2008-04-16 16:02 test.gz Sind also gepackt nochmal 11910 - 11784 = 126 Bytes weniger... Das könnte in Fällen, wo man wegen kleiner Änderungen geradeso über die Größe des Flashs hinaus kommt schon helfen... insbesondere bei Firmware-Updates, wenn man die Hardware nicht mehr anpassen kann, weil sie schon verkauft wurde.
Ulrich P. wrote: > SRAM DRAM SDRAM > SRAM ist sicherlich teuer im Vergleich zu DRAM. DRAM wiederum setzt > einen Refresh-Controller voraus, mal abgesehen von PSRAM. Will man > (S)DRAM an einen Controller anschließen, so sollte man die Datenblätter > beider genau vergleichen. U.A. sind auch Dinge wie Pagesize, RAS und CAS > Latency genauer zu untersuchen. Der Cotroller sollte diese Parameter > entsprechend dem (S)DRAM Datenblatt liefern können. Solche Infos wollte ich haben! Also auch bei den Parametern "Pagesize" und "RAS/CAS Latency" muss darauf geachtet werden, dass Controller und Speicherbaustein(e) korrekt zusammenarbeiten könen. Zusammenfassend: Speichertyp, Organisation (Adressierbare Speichereinheit, Pagesize) und RAS/CAS Latency, Pegel der Steuer/Datenleitungen, Protokoll im Allgemeinen bzgl.: > JTAG != EXT-Mem Programming > Flashloader: Letztlich muss aber irgendwie die Firmware ins Gerät und das insbesondere bei der Entwicklung möglichst ohne das der Speicherchip (ROM, EEPROM, FLASH etc) ständig aus der Schaltung herausgenommen werden muss. > Dies zeigt Dir aber auch einen recht einfachen Lösungsweg für Deine > Probleme: Das Einfachste ist eine CPU zu nehmen, die neben einem > externen Memroy-Interface auch etwas internen FLASH und RAM hat. > [...] > Soll die > Entwicklung später in Serie gehen und es kommt auf jeden Cent an, dann > kann man immer noch optimieren. Das Problem ist hier, dass sich das auf die späteren Produktkosten negativ auswirkt, wenn die Hardware eben teurer ist. Zudem möchte ich nach Abschluss der Entwicklung der Software nicht mehr an der Hardware herumändern, weil das bedeutet, dass man sämtliche Funktionstests (und Langzeittests) wiederholen müsste, um sicherzustellen dass alles noch sauber läuft. Was ich mir wirklich als einzigstes erlauben würde, wäre eben einen Chip selber Art nur mit weniger Flash-Speicher zu nehmen, sofern der Flash-Speicher nicht für Speicherung von Daten verwendet wird, sondern nur den Programmcode selbst enthält. Schon die Änderung des verfügbaren Arbeitsspeichers oder die Änderung des Systemtaktes könnte sich auf die Funktion des Gerätes auswirken. Deswegen möchte ich hier erstmal schauen, dass ich jetzt mit der Hardware arbeite, die dann auch im fertigen Produkt verwendet werden kann. Und meiner Erfahrung nach ist es aufwändiger später die Hardware zu optimieren, wenn es an sich zu spät ist... also die Software dafür programmiert wurde. Angefangen beim Platinenlayout, den Pinbelegungen für Sensoren die sich ändern könnte (und selbst wenn man nur das mapping ändern müsste, dabei kann es einfach zu Fehlern kommen). Zudem sollte für die Gehäuseentwicklung klar sein, wie groß das Board wird... dann dauert eine CE-Konformitätsprüfung auch noch seine Zeit. Evtl. muss da dann was angepasst werden... Dann muss ich z.B. auch im Vorfeld kalkulieren können, ob das Projekt überhaupt durchführbar ist. D.h. ob das Endprodukt so günstig produziert werden kann, dass man es dem Kunden auch noch verkaufen kann. Insbesondere entscheidet sich hier, ob man sich über Preis und Produkteigenschaften gegenüber der Konkurrenz profilieren kann oder ob man komplett auf Produkteigenschaften/Qualität setzen muss. Zudem: wenn ich gleich das Hardwarelayout entwickle und dann auch gleich die Prototypen davon zur Entwicklung nutzen kann, spare ich das Geld für irgendwelche Experimentier-Boards... Als größere Firma kann man sich das vielleicht leisten, aber als jemand der versucht privat ein Projekt auf die Beine zu stellen, wo noch nichtmal ganz klar ist, ob es was wird oder nicht... kann man nicht eben 200 EUR für Experimentierboards rauspulvern, um dann am Anfang weniger Arbeit zu haben, die man am Ende wieder investieren muss, um die Software auf die Zielhardware zu portieren. Deswegen ist meine Entscheidung hier: Erst Hardware optimieren und zusammenstellen und dann Software entwickeln. Insbesondere ist das als Kostenrecherche im Vorfeld nötig, bevor zu viel Geld und Zeit für etwas investiert wird, was am Ende sowieso nicht zu Ende geführt wird, weil man mittendrin feststellt, dass etwas (vor allem kostentechnisch) nicht geht. > aber man > kann auch ganz einfach eine komplette Initialisierung der externen > Peripherie von dort aus machen. Auch die kompletten FLASH-Algorithmen > und Update Prozeduren können dort liegen. Hab ich schon mehrfach so gesehen und finde ich ne gute Lösung, wenn z.B. der Kunde Firmwareupdates selbst machen können soll. Z.B. einschalten+Reset gedrückt halten = Bootloader läuft an und startet Software für Flash-Programmierung über USB/Netzwerkkarte etc. Und wenn man dabei den Bootloader nicht überschreibt (weil anderer Flash-Speicher), kann der Kunde auch an sich nix kaputt machen beim Firmware aufspielen. Notfalls muss er einfach nochmal neu die Firmware aufspielen, wenn er das zu früh abgebrochen hat... Natürlich kann man das auch so lösen, dass man den Bootloader in den ersten paar Bytes (mit Paddingbytes, sodass keine Flash-Zeilen von Bootloader und Firmware gemeinsam genutzt werden) des Flashs hinterlegt und danach eben die eigentliche Firmware draufbrennt und damit das selbe erreichen.. > Einschränkend und erleichternd möchte ich aber noch erwähnen, dass auch > die CPU Hersteller mitgedacht haben. D.h. in den Datenblättern findest > Du zum einen die Startadressen der CPU ( Reset-Vector) d.h. dort muss > FLASH liegen. Dieses FLASH wird nach Reset mit den größ möglichen > Waitstates angesprochen. Deine Reset-Routine nimmt dann in den ersten > Zeilen gleich eine Initialisierung aller Speicher einschließlich eines > Herabsetzens der Waitstates für das Flash vor. Und dann Volldampf > voraus... So war das geplant: Bootloader für Speicherinitialisierung + paar Hardwarespezifische Initialisierungen, die nötig sind und dann die eigentliche Firmware, die dann bei der Entwicklung regelmäßig ersetzt werden kann, ohne dass man die Hardware komplett auseinander nehmen muss. Also: Kabel anschließen, Reset halten/anschalten, Firmware drauf laden, Neustart, fertig! > Alles von > anfang an alleine zu machen heißt, das Rad neu zu erfinden. Alles mach ich ja auch nicht allein. Zum Beispiel benutze ich ja verfügbare Komponenten und entwickle keinen speziellen Prozessor, ich entwickle mir keinen eigenen Compiler, noch entwickle ich mir eine eigenen Programmiersprache oder muss viel Assembler oder direkt Maschinencode programmieren... Problematisch wird es aber ab dem benutzen fremder Bibliotheken, weil man dann evtl. selbst OpenSource bzw. unter GPL arbeiten muss. Das bedeutet, dass möglicherweise irgendwer das eigene Produkt dahernehmen kann und selbst produzieren und verkaufen kann... Denn die Software ist ja dann "frei" verfügbar und nutzbar (zumindest GPL) und darf nur nicht einzeln verkauft werden. Die Hardware mit der GPL-Software drauf darf ich dann aber schon verkaufen. Sprich: hier kann man sehr schnell in Lizenz-Probleme laufen... Zum anderen ist das ja nicht immer schlecht das Rad neu zu erfinden. Zum einen kann man eine neue Art Rad erfinden (z.B. eines mit Gummi statt Eisenbeschlag). Und nicht zu letzt kann man am Ende sicher nicht einfach die Schaltung des Entwicklerboards nachbauen und um ein paar Teile reduzieren, weil auch das Urheberrechtlich problematisch sein könnte... Ich kann aber mal bei Olimex und Ethernut schauen, ob was für mich dabei ist. Das Problem war für mich bisher die Beschränkung bzgl. Arbeitsspeicher (meist nur 32kB RAM oder weniger) oder ein Preis der sich so sehr gewaschen hat, dass man das Geld lieber gleich in die Entwicklung des eigenen Boards investiert, was sowieso letztlich fällig ist. Auch dir mal ein großes Danke für Deine Tips... ((Dass ich nicht genau danach handle heißt nicht, dass ich deine Ratschläge nicht akzeptiere sondern einfach in meiner Situation denke so besser zu fahren... aber es bringt durchaus zusätzliches Für und Wider, an dem ich meine Entscheidung nochmal überprüfen konnte.)) Lg, Stefan
Hallo Stefan Ich habe das File mit dem Compiler von Keil compeliert. Es sind einige Strings drin soviel aber nun auch wieder nicht. Ich kann dir aber auch das HEX-FILE davon schicken da duerfte kein Debug Infos drin sein. Vielleicht versuchst du es damit mal Gruss Helmi
Roland Schmidt wrote: > Den LPC2468 gibt's auch bei elpro. > http://www.elpro.org/shop.php Das wäre eine Alternative zu der Amtel-Veriante, allerdings bei den Preisen dort etwas teuerer (weil EINZELPREIS!!!!): 14,14 EUR -- LPC2468 -- 64kB RAM (+32KB Ram für Netzwerk), 512kb Flash, SDRAM support... Vorteile: kann via seriellem Interface programmiert werden. Nachteil: kein Cache, was bedeutet, dass der externe Speicher möglicherweise das System ausbremst. Und eben der Preis. Kennt jemand vielleicht noch eine andere Bezugsquelle? Bzw. gibts hier im Forum evtl. eine Art Liste von Internet-Elektronikshops, wo man schauen kann? (werd ich gleich mal schauen) Danke... und LG, Stefan PS: Nicht wundern, ich rechne immer mit Bruttopreisen...
Helmut Lenzen wrote: > Hallo Stefan > > Ich habe das File mit dem Compiler von Keil compeliert. > Es sind einige Strings drin soviel aber nun auch wieder nicht. > Ich kann dir aber auch das HEX-FILE davon schicken da duerfte kein Debug > Infos drin sein. > > Vielleicht versuchst du es damit mal > > Gruss Helmi Das sieht schon besser aus wenns die selbe Software ist dürfte nicht mehr viel "Debugging Info" und anderer Müll drin sein... entpacktes ARM-BIN: 274'550 Bytes HEX-FILE (in Binärdatenmenge): 44943 Bytes (bzw. 2813 angefangene 16-Byte-Zeilen = 45008 Byte effektiver Verbrauch) Ich hab das File mal geparsed und in Binär umgewandelt... also die 45008 Bytes, wobei die Lücken mit 0xFF aufgefüllt wurden. Vom Kompressionsgrad sieht das dann so aus: -rw-r--r-- 1 root root 19211 2008-04-16 20:36 binfile.dat.gz -rw-r--r-- 1 root root 45008 2008-04-16 20:37 binfile.dat Macht: 42,68% der Größe also etwas mehr als 57,3% Ersparnis, zzgl/abzüglich des Speicherbedarfs für den Loader/Entpack-Code. Im Binärfile finde ich an sich auch nur Strings, die wohl zum Programm selbst gehören... Mir ist da übrigens grad nen gröberer Tippfehler in einem der Strings aufgefallen: "Usage: Ping 129.168.0.1" das soll sicher "Usage: Ping 192.168.0.1" heißen... Also evtl. mal korrigieren, wenn die Software noch im Einsatz ist :) Mal als Frage noch: Ist das direkter ARM- oder Thumb-Maschinencode? Das wäre für eine Bewertung des Kompressionsfaktors wichtig. Effektiv geschätzt, sieht das Kompressionslevel wohl ähnlich wie bei Code für Intel-PC-Architektur aus. D.h. etwa 50% Größe, wenn man den Entpacker/Loader mitrechnet. Danke jedenfalls für die Sample-Daten... Lg, Stefan
Im übrigen: Die Test-Software wurde mit -O3 (also Optimierungsstufe "3" compiliert). Ich habe mal testweise -Os benutzt (code size minimalhalten): -rwxr-xr-x 1 root root 11784 2008-04-16 16:02 test.striped.gz -rwxr-xr-x 1 root root 21136 2008-04-16 21:30 test.Os -rwxr-xr-x 1 root root 9500 2008-04-16 21:31 test.Os.striped.gz Wie man sieht, bleibt auch hier das Kompressionslevel bei etwa 55%... Meine Überlegung war, dass vielleicht die Kompression nur deswegen so gut ist, weil vielleicht durch die Optimierungen (Loop-Unrooling-Techniken z.B.) der Code viele Wiederholungen enthält. Es scheint also nur wenig Abhängigkeit zur Optimierungsstufe zu bestehen, zumindest bei meinem Testprogramm. Stefan
Moin bei dem STR9xx gibt es derivate mit 2MB Flash auf Bank 1 und zusätzlich 128k Flash auf Bank 2. Beides natürlich intern. Des weiteren hat er intern 96k SRAM ,aus dem mit 96MHz direkt gearbeitet werden kann, ohne Wait-States (kannst du ja als Cashe missbrauchen). Und dann natürlich noch die überflüssige Peripherie wie Ethernet, USB, CAN,... ;-) Nachteil kann (muss aber nicht) sein, das der externe Bus gemultiplext ist. Wenn du viele Daten hin un her schaufeln willst (MP3, Video, ...), dann solltest du auf jeden Fall einen ARM9 nehmen. Gibts ja auch reichlich Derivate.... Den ARM7 sehe ich nur als echte alternative zum 8051/AVR., denauso wie den CortexM3-Kern. Und wenn du einzelne Chips brauchst, musst du mal bei den RS- oder Farnell-Apotheken nachsehen. Unsere Chips besorgt der Bestücker, was sehr bequem ist... ein 1k-Preis sollte bei etwa 8EUR liegen, was ganz fair ist. Ich arbeite seit einem Jahr mit dem ARM9 und bin eigentlich ganz zufrieden. FREE TIBET Grüsse Michael
Hallo, sorry, wenn OT... @Michael Gerkens ich versuche seit ein paar Tagen ein STR9xx Derivat unter IAR-Workbench mit einem Wiggler-Clone zu programmieren. Das Problem das ich habe ist, dass der Wiggler-Clone nicht unter IAR-Workbench erkannt wird. Kannst du mir einen Tip geben, wie ich diesen Wiggler-Clone zum laufen bekomme, oder welches andere preisgünstige JTAG-Interface ich unter IAR-Workbench benutzen könnte? Das STR9xx-Derivat sitzt auf diesem Minimodul: http://www.propox.com/products/t_163.html das evtl. auch für den Threadersteller interessant sein könnte. Gruß Udo
Udo und vielleicht auch Stefan, ich arbeite mit der IDE von Rowley in Verbindung mit deren CrossConnect. Klappt super, wenn mann das 20pol. Flachbandkabel auf 5cm reduziert ;-)... Und das Preis-Leistungsverhältnis ist auch absolut in Ordnung. Keil (ist ja ARM) und IAR kenne ich nicht. Mit einem Wiggler Interface habe ich noch nicht gearbeitet, aber ich würde mir zum einen mal die Signale anschauen und zum anderen die JTAG-Frequenz extrem herabsetzen (Faktor 10 oder so) um die oben beschriebenen Kabel-Probleme auszuschliessen. Und wenn du dann immer noch keine Verbindung bekommst, den IAR-Support kontaktieren und/oder mal nachsehen, welche JTAG-Interfaces unterstützt werden. Ich werde für einen automatischen Teststand das J-Link einsetzen, ist super-schnell, kann autonom flashen und ist mit der Software schweine-teuer (approx. 500EUR). ARM7/9 ist halt Männersport, was sich auch im Preis Namhafter Hersteller wiederspiegelt (deren Produkte wirklich gut sind!). Ist aber erst mal nix, um einfach mal so ein bisschen rumzuprobieren, wie beim 8-bitter. Michael
Stefan K. wrote: > Mal ehrlich: das macht schon echt was aus. Nehmen wir an, man bekommt > den Bootloader mit Entpacker in ein paar KB rein, dann kann man ein Soviel sollte der Entpacker nicht verbrauchen hab mal eine Huffmankompression (gz nuzt ne Abwandlung davon) für AVR geschrieben, braucht nur ~300bytes code: Beitrag "[AVR ASM] Huffman (de)kompression" und erreicht ganz gute Raten. Du kannst ja mal eines deiner Testfiles zum vergleich mit "meinem Packer" komprimieren und schauen was bei rauskommt.
@Udo: wenn du die iar workbench v5.xx einsetzt unterstützt diese auch einem gdb-server und damit kannst du den olimex arm-usb-ocd oder den wiggler-clone (ist aber ziemlich langsam) in verbindung mit openocd einsetzen. mit dem olimex wiggler clone hatte ich mit der workbench auch keinen erfolg. gruss gerhard
Hallo Gerhard, vielen Dank für den Tip. @Michael Komischerweise arbeitet die Rowley-Soft bei mir mit dem Wiggler-Clone einwandfrei. Aber ich möchte gern die IAR-Soft verwenden. Trotzdem vielen Dank für deine Antwort. ps.: ich hoffe, das "ich Tarzan, du Jane"-Syndrom setzt sich nicht weiter durch... Gruß Udo OT off...
Läubi Mail@laeubi.de wrote: > Stefan K. wrote: > Du kannst ja mal eines deiner Testfiles > zum vergleich mit "meinem Packer" komprimieren und schauen was bei > rauskommt. Ich hab testweise das in binär-daten umgewandelte ARM-HEX-File von Helmi genommen: Ursprünglich: 45008 Bytes Gepackt: 32875 Bytes (= 32108 Bytes Daten + 767 Bytes Header) Das sind ca. 73% der Originalgröße oder etwa 26,96% Ersparnis. Der Huffman-Algorithmus scheint also nicht optimal geeignet zu sein. Im 4-Bit-Modus ist der Kompressionsgrad geringer/schlechter. Ich hatte jetzt eigentlich eher so 40% Ersparnis erwartet und bin ein wenig enttäuscht... Evtl. wäre ein 16Bit-oder 32bit-Modus interessant, da der Maschinencode ja 32bit pro Befehl nutzt (es sei denn man nimmt den Thumb-Code). Evtl. kann man auch noch was rausholen, indem man den Wissen über den Aufbau des Maschinencodes ausnutzt... Der Algorithmus von GZIP (also der Kompressor mit dem ich meine obigen Tests durchgeführt habe) ist eine modifizierte Variante des LZW-Algorithmus (also das was z.B. bei GIF-Dateien benutzt wird). Der LZW-Algorithmus hat den Vorteil, dass kein riesiger Header nötig ist, weil der "Huffman-Tree" (wenn man ihn in dem Fall noch so nennen will) während der Dekompression anhand der bereits entpackten Daten rekonstruiert wird. Es gibt aber noch eine andere, sehr simple zu implementierendes Packverfahren, das man probieren könnte: dabei wird ein sliding Window von 256 Bytes der entpackten Daten mitgeführt. Beim Packen, kann man dann sagen "nimm die 10 Bytes, die vor 40 Bytes verarbeiteten Daten grad entpackt wurden". Der Entpacker ist irre simple und dürfte in der Größenordnung 30-50 Bytes umsetzbar sein... z.B. könnte der Dekomprimierungsalgorithmus so umgesetzt werden (man kann da sicher noch optimieren, ich hab das jetzt nur mal zusammengetippt):
1 | /**
|
2 | * @param src: Zeiger auf array mit komprimierten Daten
|
3 | * @param dst: Zeiger zu Ziel-Speicherstelle
|
4 | * @return: Anzahl Bytes entpackte Daten
|
5 | **/
|
6 | int unpack(unsigned const* src, unsigned char* dst) { |
7 | int len = ((((src[0]<<8)+src[1])<<8+src[2])<<8+src[3]; |
8 | int escape_code = src[4]; |
9 | int pos_src = 5; |
10 | int pos_dst = 0; |
11 | for(int i=0;i<len;++i) { |
12 | unsigned char c = src[pos_src++]; |
13 | |
14 | if (c == escape_code) { |
15 | int ref_len = (int)src[pos_src++]; |
16 | if (ref_len) { |
17 | int offset = (int)src[pos_src++]; |
18 | for(int e=0;e<ref_len;++e) dst[pos_dst++]=src[pos_dst-offset+e]; |
19 | } else { |
20 | dst[pos_dst++] = c; |
21 | }
|
22 | } else { |
23 | dst[pos_dst++] = c; |
24 | }
|
25 | }
|
26 | return post_dst; |
27 | }
|
Ich hab mir hier sämtliche Prüfungen bzgl. Buffer-Overflow gespart, da ich von korrekten Eingabedaten ausgehe bei einer Firmware. Sollte der Code an anderer Stelle eingesetzt werden, wo benutzerdefinierte Daten verarbeitet werden sollen (also keine vom Hersteller/Programmierer vorgegebenen), muss er solche Prüfungen enthalten, um nicht Fehlfunktionen zu verursachen... Wichtig: Der Quellcode ist ungetestet und nur für Demonstrationszwecke bzgl. Platzbedarf!!! Der Kompressor dazu ist etwas aufwändiger, aber einfacher als Huffman-Encoding. Wie gut der allerdings unsere Sampledaten packt, kann ich nicht sagen. Müsste man halt mal implementieren und probieren. LG, Stefan
So, nachdem ich das mal implementiert habe - hier die Ergebnisse: --- -rw-r--r-- 1 root root 45008 2008-04-16 20:37 binfile.dat.orig -rw-r--r-- 1 root root 33693 2008-04-17 14:38 binfile.dat.orig.pkg D.h. 74,86% Größe danach, bzw. 25,13% Ersparnis. Wobei das Verfahren noch Optimierungspotential hat von der Speicherstruktur (z.B. Offset und Länge in einem Byte und dafür kleineres Suchfenster oder Huffman-Encoding oder andere Speicherung mit variabler Bitlänge für die Angaben). Das Verfahren ist also nicht viel besser aber auch nicht viel schlechter geeignet von der Kompression (zumindest in der aktuellen Implementierung). Allerdings ist es sehr viel einfacher und kompakter umsetzbar. Ich werd mal noch etwas dran herum optimieren... vielleicht können wir hier gleich noch nen kleines Bootloader-Kit basteln. D.h.: 1st Stage: Check RESET-Taste -> Upgrade via Datenkabel / 2nd Stage 2nd Stage: RAM-Init + Entpacken der Firmware in den RAM + Starten der Firmware Dazu dann noch: - Firmware-Packer (2nd Stage builder) - Upgrade-Tool (zum 2nd Stage austauschen) Stefan
> Komischerweise arbeitet die Rowley-Soft bei mir mit dem Wiggler-Clone > einwandfrei. Aber ich möchte gern die IAR-Soft verwenden. Dann solltest Du ein anderes JTAG-Interface verwenden. IAR verwendet zur Ansteuerung des Wigglers den Macraigor-Treiber (OCD Remote o.ä.), und der taugt ums Verrecken nichts, jedenfalls nicht auf zeitgemäßen Windows-Versionen*. Du solltest Dir entweder ein USB-JTAG-Interface von Segger anschaffen (J-LINK) oder aber herausfinden, ob die OpenOCD-Treiber für FT2232-basierende JTAG-Interfaces auch mit IAR genutzt werden können. Crossworks unterstützt in Version 1.7 auch die OpenOCD-Interfaces, aber das willst Du ja aus welchen Gründen auch immer nicht nutzen. *) Windows NT 5.0, 5.1, 5.2 oder gar 6.0. Auch als "Windows 2000", "XP", "2003" und "Vista" bekannt. Nicht zeitgemäß ist der Windows-95-Schrott, der auch als "98" und "Me" Rechner unbrauchbar machte.
PS: Ich hab mal den Output von dem von mir programmierten Kompressor durch den Huffman-Encoder gejagt: Das Ergebnis: vorher: 45008 (ohne alles) Bytes gepackt: 26122 (=767 + 25355) Bytes (mit beiden Algorithmen) Macht: 58,04% bzw. 41,96% Ersparnis... Das kann sich dann schon langsam sehen lassen... Stefan
@Udo bin ich zu barsch? War ganz und gar nicht so gemeint. Wollte nur zum Ausdruck bringen, das ein Start mit ARM7/9 eine andere preisliche Herausforderung ist, als der Einstieg in die 51er oder AVR Welt. Sorry... M
Der Kompressor hatte noch einen kleinen Bug, daher wurden größere Referenzierbare Teile nicht gefunden... -rw-r--r-- 1 root root 45008 2008-04-16 20:37 binfile.dat.orig -rw-r--r-- 1 root root 29388 2008-04-17 15:46 binfile.dat.orig.pkg Macht: 65,3% bzw. 34,7% Ersparnis nur durch den "kleinen" Algorithmus... Danach komprimiert mit dem Huffman encoding ergibt: header bytes: 764 Original size bytes: 29388 Compressed size bytes: 19142 Also: 19906 Bytes... also 44,23% der ursprünglichen Größe, also 55,77% Ersparnis. JETZT sind wir konkurrenzfähig mit gzip :). Evtl. kann man jetzt immernoch etwas optimieren und noch mehr rausholen... Allerdings wäre als nächstes erstmal zu prüfen, ob meine Implemtierung sauber ist (d.h. ob man die Daten auch wieder entpacken kann G). LG, Stefan
@Michael Gerkens, ich habe mich zu Entschuldigen. Die Form meiner Bemerkung war Missverständlich und sollte sich nicht auf dich beziehen. Im Gegenteil, du hast die Preisgestaltung der Hersteller treffend mit dem Wort "Männersport" beschrieben und ich wollte nur zum Ausdruck bringen, das sich dieses Verhalten der Hersteller hoffentlich nicht weiter durchsetzt. Denn nicht jeder kann sich diese hohen Preise leisten, möchte aber doch gerne am Stand der Technik teilhaben. Zu meinem Problem mit dem Wiggler und der IAR-Soft habe ich mit OpenOCD eine Lösung gefunden, die zwar nicht aus der IAR-Soft selbst funktioniert, aber ich kann zumindest damit das elf-File auf den Target brennen. Gruß Udo nochmals sorry für das OT....
Stefan K. wrote: > Allerdings wäre als nächstes erstmal zu prüfen, ob meine Implemtierung > sauber ist (d.h. ob man die Daten auch wieder entpacken kann G). Tja, da war wohl wirklich noch ein grober Bug drin... allerdings konnte ich noch ein wenig optimieren. Und ich hab nun encoder und decoder getestet (also ob es sich wieder entpacken lässt): -rw-r--r-- 1 root root 45008 2008-04-16 20:37 binfile.dat.orig -rw-r--r-- 1 root root 33442 2008-04-18 01:25 binfile.dat.orig.pkg -rw-r--r-- 1 root root 45008 2008-04-18 01:29 binfile.dat.orig.pkg.dec Ein "diff" zwischen original und dekodierter Datei war erfolgreich... ...mit zusätzlichen Huffman-Encoding sind wir dann bei 42,61% Ersparnis. Das ist dann leider nicht mehr so "toll", wie mit dem Bug drin, aber dafür kann mans auch wieder entpacken. Stefan PS: Hatte mich schon gewundert, dass ich so dicht an gzip ran gekommen bin mit dem Kompressionsgrad... da konnte irgendwie was nicht ganz stimmen :)
Hi! Gibt es irgendwo ein wenig meehr Infos zu den Compressoren? Im Grunde geht es bei mir darum, dass ich einem 'dummen' LCD Leben einhauchen möchte. D.h. die ganzen Zeichensätze müssen im Controller abgelegt werden. Die Zeichensätze stehen als .h Dateien zur Verfügung. Edel wäre es nun diese beim Compilieren zu komprimieren. Natürlich wird man um eine Tabelle nicht herum kommen, die einen Einsprungsvector für jedes Zeichen in die komprimierten Daten behält. Ich danke schon mal für ein paar weiterführende Links! Gruß, Astralix
Thread beobachten
Seitenaufteilung abschaltenBitte 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.