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/LPC...
http://www.nxp.com/acrobat_download/usermanuals/UM...


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

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/LPC...

> 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.

Hier mal ein Zip von mir wo ich gerade eine ARM-BIN Datei gepackt habe.

Gruss Helmi

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.

Den LPC2468 gibt's auch bei elpro.
http://www.elpro.org/shop.php

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

Hallo Stefan

Das war direkter ARM Code.

Ja war wohl ein Tippfehler Danke.

Gruss Helmi

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):

/**
 * @param src: Zeiger auf array mit komprimierten Daten 
 * @param dst: Zeiger zu Ziel-Speicherstelle
 * @return: Anzahl Bytes entpackte Daten
 **/
int unpack(unsigned const* src, unsigned char* dst) {
  int len = ((((src[0]<<8)+src[1])<<8+src[2])<<8+src[3];
  int escape_code = src[4];
  int pos_src = 5;
  int pos_dst = 0;
  for(int i=0;i<len;++i) {
    unsigned char c = src[pos_src++];

    if (c == escape_code) {
      int ref_len = (int)src[pos_src++];
      if (ref_len) {
        int offset = (int)src[pos_src++];
        for(int e=0;e<ref_len;++e) dst[pos_dst++]=src[pos_dst-offset+e];
      } else {
        dst[pos_dst++] = c;
      }
    } else {
      dst[pos_dst++] = c;
    }
  }
  return post_dst;
}

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