www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM-Prozessor mit SRAM+Flash extern, ISP möglich?


Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut Lenzen (helmi1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zepettl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan

AT91SAM7SE512 von Atmel hat auch ein SDRAM Interface

Gruss Helmi

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Gerkens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Controller könntest du auch den LPC2468 verwenden. Der hat auch 
512kB Flash und einen SDRAM-Controller.

Autor: Helmut Lenzen (helmi1)
Datum:
Angehängte Dateien:

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

Gruss Helmi

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland Schmidt (Gast)
Datum:

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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut Lenzen (helmi1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan

Das war direkter ARM Code.

Ja war wohl ein Tippfehler Danke.

Gruss Helmi

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Gerkens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Gerkens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Udo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Gerkens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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....

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.