mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FLASH -> Waitstates?


Autor: Gast1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute !
Hab eine kurze Verständnissfrage:
In den Datenblättern steht zB max Frequenz 96 MHz 1.25DMIPS/MHz bei 0 
Waitestates!

Wie weiß ich den wieviele waitstaits ich den benötige? Bzw wovon ist das 
abhängig bei einem Controller?

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bzw wovon ist das abhängig bei einem Controller?

Der Taktfrequenz mit dem Flash-Zugriffe ausgeführt werden

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas findet man raus bei innigem Studium des Datasheet oder User 
Manuals oder Reference Manuals oder Flash Programming Manuals oder wie 
immer das Ding beim jeweiligen Controller heisst.

Allerdings sind 0 Waitstates bei 96MHz "etwas unüblich" und soll wohl 
heissen, dass der Code im RAM läuft oder der Controller einen Cache hat 
und der besseren Zahlen wegen von 100% Hitrate ausgegangen wird. Aus dem 
Flash sind bei solchen Frequenzen 3-5 Waitstates üblich.

Autor: Gast1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für die antworten!
was bedeutet aus dem RAM? Wird der Code vom Flash ins Ram kopiert und 
von dort aus exekutiert?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja

Autor: Gast1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute! Danke für eure Infos!
Nur irgendwie komm ich nicht weiter .... zB der STR9 von ST .... wo 
finde ich bitte wieviele Waitsates ich wo benötige? Oder beim STR32? Bin 
die DOCs durchgegangen, jedoch werd ich einfach nicht schlau daraus!

Hat jemand vl noch einen Tipp?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich mich recht erinnere findet man das beim STR9 nicht im Manual 
zum Controller, sondern im separaten Manual zum Flash - ist ja auch ein 
separater Die, insofern logisch. Flash Programming Manual oder so 
ähnlich.

Beim STM32 steht das in der Reference.

Autor: Michael Leusink (hasimaus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gast1,

sieht aus, als hättest Du da einen ARM Cortex, vielleicht Cortex-M3.
Die "Übersetzung" wird etwa heißen:
"Bis zu einer maximalen Frequenz von 96MHz wird ein Programm aus dem 
Flash ohne Wartezyklen ausgeführt und der Prozessor erreicht 
1.25DMIPS/MHz."

Es gibt Prozessoren, die "nur" bis ca. 72MHz aus dem Flash ohne 
Waitstates ausführen können, so weit ich weiß viele von ST. Es gibt aber 
auch einige die bis 100MHz ohne waitstates auskommen, z.B. Toshiba.
Das ändert sich aber ständig.

Bei höheren Frequenzen werden mindestens ein Waitstate benötigt bzw. 
Ausführung aus RAM notwendig. Ab wann waitstates notwendig werden und 
wieviele hängt vom implementierten Flash ab und ob noch Besonderheiten 
eingebauten wurden.

Gruß

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Leusink schrieb:

> sieht aus, als hättest Du da einen ARM Cortex, vielleicht Cortex-M3.
> Die "Übersetzung" wird etwa heißen:

Ich kenne keine ARM-Controller im Bereich 60-100MHz Fetch-Zyklus, die 
beim Flashzugriff keine Waitstates haben - jedenfalls nicht von NXP, ST, 
Atmel.

Sowas wie 1.25 DMIPS/MHz sind Werbezahlen von ARM, die der Hersteller 
des Controller direkt durchreicht. Demzufolge erreicht der von ARM 
eingekaufte Core theoretisch eine Performance von 1.25DMIPS/MHz, wenn 
keine Waitstates auftreten. Das heisst durchaus nicht, dass aus dem 
Flash keine Waitstates auftreten, zumal in dieser(!) Aussage auch kein 
Flash erwähnt wird.

> Es gibt Prozessoren, die "nur" bis ca. 72MHz aus dem Flash ohne
> Waitstates ausführen können, so weit ich weiß viele von ST.

Der STM32 benötigt bei 72MHz sehr wohl Waitstates. Der STR9 bei den 
üblichen 96MHz ebenfalls, und nicht zu knapp.

Flash-Waitstates bedeuten jedoch aber nicht automatisch, dass damit der 
Befehlsablauf entsprechend abgebremst wird. Pufferung, Prefetching und 
Caches können helfen, Wartezeiten zu vermeiden. Der STR9 hat 
beispielsweise eine Art Branch-Target-Cache und das Pendant beim LPC1700 
hat recht viel Ähnlichkeit mit einem normalen kleinen Cache für's Flash.

Autor: Michael Leusink (hasimaus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.
Bitte gib mir doch Hinweise, wo ich die von Dir besagten Informationen 
finde, z.B. Waitzyklen bei ARM Prozessoren zwischen 60 und 100MHz.

Bis dahin empfehle ich folgende Informationen
http://www.st.com/stonline/stappl/cms/press/news/y...
http://www.toshiba-microcontroller.com/sites/Corte...

Du kannst, richtiger weise, argumentieren, dass dies Herstellerseiten 
sind und alles nur Marketinggefasel.

Dhrystone Daten waren immerschon ein Grund für Diskussionen und Zweifel.

Gruß

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man muss präziserweise unterscheiden zwischen
- den Waitstates beim Flash-Zugriff,
- der Auswirkung auf den Programmablauf.

Eine Aussage wie

"To release the processor’s full 150 DMIPS performance at this frequency 
the accelerator implements an instruction pre-fetch queue and branch 
cache, enabling program execution from Flash at up to 120MHz with zero 
wait states."

besagt wie ich schon skizzierte nur, dass es Mechanismen gibt, die den 
Einfluss der Zugriffszeit auf den Flash-Speicher für laufende Programme 
im Idealfall auf 0 reduzieren können.

Die Begriffswahl von ST ist dabei allerdings technisch betrachtet etwas 
unglücklich, denn Waitstates treten durchaus auf, werden explizit auch 
als solche abhängig von der Taktfrequenz konfiguriert. Nur wirken sie 
sich dank des erwähnen Prefetchings und der Caches nicht so stark aus.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Konkret findet man das zu den bisherigen(!) STM32 beispielsweise im 
PM0042 Flash Programming Manual auf Seite 25, mit 2 obligatorischen 
Waitstates bei 72MHz. Bei sequentiellem Zugriff spielt das keine Rolle, 
bei Sprüngen mangels Branch Target Cache sehr wohl, ebenfalls bei 
Datenzugriffen auf das Flash (die bei CM3 weniger wichtig sind als bei 
ARM7/9).

Die neuen schnelleren STM32 (s.o.) existieren  m.W. bisher nur als 
Ankündigung, Daten habe ich noch keine gesehen.

Die LPC1700 erkaufen sich ihre 100MHz mit 4 Waitstates. Kompensiert 
durch einen kleinen 8x16 Byte Cache für das Flash, der vor allem Sprünge 
beschleunigt, aber auch bei Datenzugriffen wirksam ist.

Beim STR9 ist das etwas komplizierter, weil dessen Flash-Memory auf 
einem separaten Die liegt und aus dessen offiziellen 2 Waitstates (ab 
75MHz, siehe Flash Programming Manual) aus Sicht der CPU 
erfahrungsgemäss mehr werden (d.h. die Zugriffszeit ist grösser als 
diese 2 Takte suggerieren). Kompensiert wird das durch einen 16x32 Byte 
Branch Cache. Die bei ARM-Cores vor Thumb2 typischerweise sehr häufigen 
Datenzugriffe auf das Flash werden allerdings nicht beschleunigt, was 
die effektive Performance dieses Controllers stark negativ beeinflusst.

Autor: Michael Leusink (hasimaus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.
Vielen Dank für die konkreten Hinweise. Jetzt können wir über Fakten 
sprechen !

Wenn ich's richtig verstanden habe, haben die STM32 einen doppelten 
64Bit Puffer vorm Flash. Das Flash selbst hat eine Zugriffszeit von 
35ns. Die "Marketing Figures" von 0 Waitstates bei 72MHz beziehen sich 
demnach ausschließlich auf den linearen Programmablauf im Thumb-2 Modus.
Wie Du schon richtig sagst, gilt dies scheinbar nicht für Daten und auch 
nicht mehr bei Sprüngen, trotz Prefetch.

Ähnliches gilt vermutlich auch für die 96MHz oder 120MHz, nur das hier 
zusätzliche oder andere Methoden der Optimierung benutzt werden. Sind 
wir uns
soweit einig ?

Gruß


Um doch nochmal kurz auf die Ausgangsfrage zurückzukommen.
Ich denke, das bezieht sich auf die Sicht des Programmierers, der sich 
weniger für die HW Implementierung, sondern mehr für die, für ihn 
sichtbare Geschwindigkeit interessiert.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Leusink schrieb:

> Die "Marketing Figures" von 0 Waitstates bei 72MHz beziehen sich
> demnach ausschließlich auf den linearen Programmablauf im Thumb-2 Modus.

Sowie annähernd auch auf Code, der im RAM läuft (daraus entstehende 
I/D-Konflikte mal aussen vor gelassen). Geltend für die bisherigen 
STM32, die bis 72MHz.

> Wie Du schon richtig sagst, gilt dies scheinbar nicht für Daten und auch
> nicht mehr bei Sprüngen, trotz Prefetch.

Der Prefetch ist sequentiell, beim Sprung bringt er nichts. Der CM3 Core 
hat freundlicherweise ein bischen Branch-Spekulation drin um Sprünge 
etwas zu beschleunigen.

Bei Datenzugriffen hilft nur ein Cache oder mindestens ein Puffer - 
letzteres findet sich beispielsweise bereits bei den LPC2000.

> Ähnliches gilt vermutlich auch für die 96MHz oder 120MHz, nur das hier
> zusätzliche oder andere Methoden der Optimierung benutzt werden. Sind
> wir uns soweit einig ?

Wenn du mit Optimierung erweiterte Hardware-Mechanismen wie einen Branch 
Cache meinst, ja.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Leusink schrieb:

> Um doch nochmal kurz auf die Ausgangsfrage zurückzukommen.
> Ich denke, das bezieht sich auf die Sicht des Programmierers, der sich
> weniger für die HW Implementierung, sondern mehr für die, für ihn
> sichtbare Geschwindigkeit interessiert.

Je komplexer die Cores werden, desto schwieriger ist es, aus 
irgendwelchen Taktangaben und Architektur- oder Implementierungsdetails 
auf reale Performance zu schliessen. Da hilft irgendwann nur noch das 
Nachmessen am konkreten Programm.

Das gilt letztlich auch hier. Eine DMIPS Angabe ist nicht mehr als eine 
grobe Daumenpeilung und hilft sonst nur beim Primzahlensuchen. Wieviel 
zusätzliche Flash-Waitstates ausmachen kann auch stark vom Compiler 
abhängen, beispielsweise wieviel Mühe er sich gibt, die beim STR9 ganz 
üblen Datenzugriffe auf das Flash zu vermeiden. Die klassische 
ARM/Thumb1-Architektur kommt ihm da nicht wirklich entgegen.

Allerdings bezog ich den Anfang des Threads auch auf die Eigenheit von 
ST, die Information über die notwendige(!) Einstellung von Waitstates im 
separaten Flash Programming Manual zu verstecken, was anfangs wohl jeder 
als Manual für's Selberbrennen vom Flash-Inhalt missversteht und 
folglich ignoriert. Und sich dann wundert, warum er dazu in Datasheet 
und Reference nichts findet.

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Sorry das ich den alten Thread ausgrabe, aber ich habe eine Frage:

STM32: Flash Access @72Mhz benötigt 2 waitstates
STR9:

Sind das "alle" Waitstates die auftreten, bzw wo find ich diese Infos 
für den STR9? Ich hab keine Hinweise gefunden wie das hier bei 96MHz 
aussehen soll. Habt ihr einen Tipp? Ich hab das Flash Programming Manual 
und das Reference Manual durchgesehen und sogar nach "wait" und "96" 
gesucht ;) - leider erfolglos.

Vl. hat ja hjemand noch Infos!

Lg

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Flash Programming Manual steht das definitiv drin. Nur kann es sein, 
dass die Suchfunktion bei Dingen scheitert, die das Auge noch findet 
;-).

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Leusink schrieb:
> Dhrystone Daten waren immerschon ein Grund für Diskussionen und Zweifel.

Ich hätte gedacht, dass über die Aussagefähigkeit der Dhrystone 
Ergebnisse inzwischen keine Zweifel mehr bestehen :-)

A. K. schrieb:
> Die bei ARM-Cores vor Thumb2 typischerweise sehr häufigen
> Datenzugriffe auf das Flash werden allerdings nicht beschleunigt

Was hat sich denn da mit Thumb-2 fundamental geändert?

ARM's DMIPS Angaben beziehen sich meines Wissen nach immer auf idealen 0 
Waitstate Speicher. Was sollten sie sonst auch annehmen?

Gruß
Marcus

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:

>> Die bei ARM-Cores vor Thumb2 typischerweise sehr häufigen
>> Datenzugriffe auf das Flash werden allerdings nicht beschleunigt
>
> Was hat sich denn da mit Thumb-2 fundamental geändert?

ARM und Thumb können nur sehr kleine Konstanten direkt im Befehl laden. 
Für alles jenseits dieser Formate, insbesondere Adresskonstanten deren 
Wert erst der Linker kennt, ist es üblich, sie PC-relativ zu laden. 
Folglich aus dem Flash. Die LPC2000 besitzen dazu immerhin bereits einen 
16-Byte Puffer, der sich aufgrund der hohen Lokalität dieser Daten 
durchaus lohnt.

Thumb2 besitzt wie wohl alle anderen RISCs mit 32-Bit Befehlswort die 
Möglichkeit, 32-Bit Konstanten in 2 Befehlen als 2 16-Bit Konstanten zu 
laden. Das geht folglich sequentiell im Befehlsfluss ungebremst ab. Da 
dies mit 8 Bytes etwas länger ist die PC-relative Variante mit 6 Bytes 
wird es aber ggf. bei Optimierung auf Platz nicht verwendet.

Bei ARM (nativ) kann man an sich 32-Bit Konstanten auch aus mehreren 
Befehlen zusammensetzen. Mit insgesamt 4 Befehlen (den load/store ggf. 
eingeschlossen) geht das - benötigt aber viel Platz. GCC scheint das 
nicht zu tun, anderswo meine ich das aber schon einmal gesehen zu haben. 
Beim STR9 dürfte sich das auch lohnen.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Thumb2 besitzt wie wohl alle anderen RISCs mit 32-Bit Befehlswort die
> Möglichkeit, 32-Bit Konstanten in 2 Befehlen als 2 16-Bit Konstanten zu
> laden.

MOV32, aka (MOV/MOVT) -- theoretisch schon.

> Das geht folglich sequentiell im Befehlsfluss ungebremst ab. Da
> dies mit 8 Bytes etwas länger ist die PC-relative Variante mit 6 Bytes
> wird es aber ggf. bei Optimierung auf Platz nicht verwendet.

Ich habe überhaupt noch nie gesehen, dass diese Konstruktion vom 
Compiler erzeugt wurde. Ich bin mir auch nicht sicher, ob sich das 
beizeiten ändern wird. Bei Sprungadressen muss der Linker die 
Platzhalter letztlich mit echten Adressen ausfüllen. Mit literal pools 
ist das relativ einfach. Beim MOVT/MOV hingegen muss der Linker sich mit 
dem Opcodeformat auseinandersetzen und anschließend zwei Instrutionen 
modifizieren. Alles möglich, wird aber meiner Erfahrung nach aber nicht 
gemacht.

Mit "normalen" Konstanten habe ich da bisher auch keine Bewegung in 
diese Richtung erkennen können. Vor langer Zeit habe ich deswegen auch 
mal einen Support Case bei ARM aufgemacht.

--
Marcus

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:

> Ich habe überhaupt noch nie gesehen, dass diese Konstruktion vom
> Compiler erzeugt wurde.

GCC erzeugt mit -Os die PC-relative Variante, ansonsten bei 
eingeschalteter Optimierung oft MOV32.

> beizeiten ändern wird. Bei Sprungadressen muss der Linker die
> Platzhalter letztlich mit echten Adressen ausfüllen.

Es geht hauptsächlich um die Datenadressen.

Codeadressen sind üblicherweise kein Problem - mit Ausnahmen, vor allem 
bei manchen C++-Konstrukten und bei RAM-Funktionen, bei denen der 
Compiler keine Annahme über die Codeplatzierung treffen kann und die 
vollen 32 Bits frei wählbar lassen muss.

> Mit literal pools ist das relativ einfach.

Ja, nur dass man dann nichtsequentielle Datenzugriffe in Flash an der 
Backe hat. Und die sind vergleichsweise teuer, wenn das Flash-Interface 
keine entsprechenden Massnahmen trifft.

> Beim MOVT/MOV hingegen muss der Linker sich mit
> dem Opcodeformat auseinandersetzen und anschließend zwei Instrutionen
> modifizieren.

Ja und? Klar, das Format muss in die relocations rein, aber da ist je 
nach Architektur sowieso jede Menge derartiger Häckselkram drin. 
Routine.

Beispiel: 16-Bit Adresskonstanten aufgeteilt auf zwei AVR-Befehle sind 
auch ziemlich schräg verteilt. Einerseits auf die Befehle, andererseits 
in zwei 4-Bit Stücken. Und mal als Byte- mal als Wortadresse.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ja, nur dass man dann nichtsequentielle Datenzugriffe in Flash an der
> Backe hat. Und die sind vergleichsweise teuer, wenn das Flash-Interface
> keine entsprechenden Massnahmen trifft.

Schon klar. Ich sage ja nur, dass ich das im Zusammenhang mit ARM noch 
nicht gesehen habe.

[später] Du hast recht. Ein kurzes grep über alle erzeugten assembler 
Dateien hat in der Tat ein paar Treffer hervorgebracht. Allerdings nur 
bei GCC-erzeugten Dateien. Keine einzige RVCT-erzeugte Assembler Datei 
enthält MOV/MOVT.

Wie groß die tatsächliche Ersparnis ist müsste man mal mit 
praxisrelevanten Tests untersuchen. Womit wir wieder beim Thema 
Dhrystone wären :-)

--
Marcus

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du kannst, richtiger weise, argumentieren, dass dies Herstellerseiten
>sind und alles nur Marketinggefasel.
Ja. Aus STR91 -DS :
"– Up to 96 MIPS directly from Flash memory"
!!!!!!!!!!!!!!!!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:

> Wie groß die tatsächliche Ersparnis ist müsste man mal mit
> praxisrelevanten Tests untersuchen. Womit wir wieder beim Thema
> Dhrystone wären :-)

Der (Kommerz-) Compiler, der beim Dhrystone diese Konstanten nicht schon 
vor der Schleife ins Register läd, der hat seinen Zweck verfehlt.

Autor: P. S. (pati2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Die LPC1700 erkaufen sich ihre 100MHz mit 4 Waitstates. Kompensiert
> durch einen kleinen 8x16 Byte Cache für das Flash, der vor allem Sprünge
> beschleunigt, aber auch bei Datenzugriffen wirksam ist.

Auch wenn der Beitrag schon etwas älter ist, hoffe ich, dass mir hier 
noch jemand antwortet.

Wie heißt das zugehörige Dokument von LPC für die 1700-Reihe bzw. 
genauer gesagt für den LPC1788/LPC1768 in dem ich das nachlesen kann? Im 
User Manual von NXP habe ich leider nichts dazu gefunden (nur für den 
EMC (External Memory Controller) ). Habe ich es dort überlesen bzw. nach 
den falschen Begriff gesucht ("wait state") oder steht dies in einem 
anderen Dokument?

Autor: Jim Meba (turboj)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Zum Bleistift im UM10360.pdf, Kapitel 5.4: "Flash Accelerator 
Configuration register". Und ja, "wait state" kommt da tatsächlich als 
solches nicht vor.

Autor: P. S. (pati2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@turboj: Herzlichen Dank! Sorry, hätte man auch so drauf kommen können 
^^

Autor: MCUA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
ST, NXP, Freescale, Atmel, MS (und viele weitere) haben (wie schon 
mehrfach erwähnt) Std-Flash von nur ca 33MHz! Auch wenn die dollsten 
MHz-Zahlen am Controller stehen! Wenn der Hersteller nicht explizit eine 
höhere Flash-Geschwindigkeit oben erwähnt, kann man getrost von diesen 
(ca) 33MHz ausgehen, (die er ja verstecken will).
Einige Japaner haben Flash bis zu 120MHz.

Autor: P. S. (pati2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, dass es die Hersteller meistens nicht mal im Kleingedruckten 
erwähnen.

Autor: MCUA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
>Schade, dass es die Hersteller meistens nicht mal im Kleingedruckten
>erwähnen.
In den Flash-Characteristics bzw Waitstate-konfig uä steht es schon drin 
(man muss es gezielt suchen, werben tun man für dieses Gurken-Flash 
nicht),
Selbst manche Hersteller auf Messen geben es nicht preis, bzw plappern 
das (Falsche!) was im DB ganz oben steht.
(warum erwähnt M.M. das nicht in seinem Artikel?)

Autor: P. S. (pati2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um wieder das Beispiel von NXP ausführen: Existiert für einen 
LPC1768/LPC1788 ein deartiges Dokument? 
(Flash-Characteristcs/Waitstate-Config...)

Autor: bko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> (...)
> höhere Flash-Geschwindigkeit oben erwähnt, kann man getrost von diesen
> (ca) 33MHz ausgehen, (die er ja verstecken will).
> Einige Japaner haben Flash bis zu 120MHz.

Interessant, welche uCs wären dies?

Autor: P. S. (pati2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@bko: Zum Beispiel die RX200 oder RX600-Serie von Renesas...

Siehe hier:
http://am.renesas.com/products/mpumcu/rx/rx600/index.jsp

: Bearbeitet durch User

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.