www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Günstiger uC mit hoher Taktfrequenz


Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich bin auf der Suche nach einem günstigen
Mikrocontroller mit hoher Taktfrequenz.

Ich habe eine Anwendung bei der sehr
oft pro Sekunde einen ISR durchlaufen werden
muss. Der Rechenaufwand ansich ist nicht sonderlich
hoch. Momentan experimentiere ich mit einem
ganz normalen ATMega8, leider gehen die
ICs - lt. DB - nur bis ~20MHz, das ist
etwas eng.

Kennt jemand uCs in der Preisklasse/mit
der Verfügbarkeit wie die AVRs, aber
gleichzeigt mit einer Taktfrequenz ab ca. 30/40MHz?

Man denkt natürlich direkt an ARM7/Cortex-M3.
Ich hätte nur gerne ne Lösung bei der RAM/Flash
integriert sind, und sonderlich billig sind
die ARM-Cores auch nicht.

Grüße,
   rw

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Robin Wenninger (rw83)

>Ich habe eine Anwendung bei der sehr
>oft pro Sekunde einen ISR durchlaufen werden
>muss. Der Rechenaufwand ansich ist nicht sonderlich
>hoch.

Dann kann man es wahrscheinlich auch anders lösen. Lies was über 
Netiquette und beschreibe den Problem, nicht deine vermeintliche 
Lösung.

MFG
Falk

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem hat der Core nichts mit dem Speicher zu tun. Es gibt auch ARM7 
mit integriertem Flash/RAM.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> @  Robin Wenninger (rw83)
>
>>Ich habe eine Anwendung bei der sehr
>>oft pro Sekunde einen ISR durchlaufen werden
>>muss. Der Rechenaufwand ansich ist nicht sonderlich
>>hoch.
>
> Dann kann man es wahrscheinlich auch anders lösen. Lies was über
> Netiquette und beschreibe den Problem, nicht deine vermeintliche
> Lösung.

Ich habe mein Problem beschrieben, und ich
habe absichtlich vermieden eine Diskussion
über alternative Lösungsansätze loszutreten.

Ich suche eine einfache Antwort, kein
Brainstorming.

Gruß.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Außerdem hat der Core nichts mit dem Speicher zu tun. Es gibt auch ARM7
> mit integriertem Flash/RAM.

Das habe ich auch nicht behauptet. Im
allg. ist bei diesen Cores zumindest
der Flash extern - du darfst mir gerne
einen ARM-Core bzw. eine Implementierung
aufzeigen bei der das nicht so ist.

Gruß.

Autor: schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC18F25K20 oder PIC18F25K22 können 64 MHz, kosten um 3 Euro

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann schau mal hier die LPC111x von NXP an:

http://ics.nxp.com/products/lpc1000/lpc11xx/

und zum starten:

http://ics.nxp.com/literature/leaflets/microcontro...

Das dürfte wohl reichen ;)

hans

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hans schrieb:
> Dann schau mal hier die LPC111x von NXP an:
>
> http://ics.nxp.com/products/lpc1000/lpc11xx/
> [...]

Aha! Dankeschön.

War allerdings grad erstmal erschrocken
als ich das BGA-Gehäuse auf der Seite
gesehen hab, aber den gibts ja auch in LQFP
und sogar PLCC, sehr fein. Muss ich nurnoch
guggn wo's den gibt.

Gruß und Dank.
    rw

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schorsch schrieb:
> PIC18F25K20 oder PIC18F25K22 können 64 MHz, kosten um 3 Euro

Danke für die Antwort, bin - noch -
kein Fan der PICs, aber die sehen
gut aus. knix

Gruß,
    rw

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC24H

Autor: ^ö^ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Ich suche eine einfache Antwort, kein
> Brainstorming.

Leute, wann versteht ihr es endlich? Die Motivation der 'Experten', in 
diesem Forum mitzuschreiben, ist es, an interessanten Fragestellungen 
mitzudenken und gute Lösungen zu erarbeiten. Niemand kommt her, um 
suchmaschinentaugliche Fragen zu beantworten. Also musst du als 
Threadstarter deine Situation gesamthaft formulieren und abweichende 
Lösungsansätze akzeptieren.

Es fällt nämlich auf, dass sich bei 95% der Fragen, wo jemand eine 
seltsame Anforderung hat, diese gar nicht notwendig ist und einfachere, 
elegantere, bessere Lösungen möglich sind. Also ist es sowohl aus deiner 
Sicht (du willst eine gute Lösung!) wie auch aus Helfersicht (sie wollen 
dir gut helfen!) wirklich notwendig, dass du Informationen lieferst und 
eine Diskussion zulässt.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, die haben eine höhere Taktfrequenz,
aber auch mehr MIPS?
Aber Du wolltest ja welche mit höherer Taktfrequenz.
Viel Erfolg.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
^ö^ schrieb:
>[...]
> Es fällt nämlich auf, dass sich bei 95% der Fragen, wo jemand eine
> seltsame Anforderung hat, diese gar nicht notwendig ist und einfachere,
> elegantere, bessere Lösungen möglich sind. Also ist es sowohl aus deiner
> Sicht (du willst eine gute Lösung!) wie auch aus Helfersicht (sie wollen
> dir gut helfen!) wirklich notwendig, dass du Informationen lieferst und
> eine Diskussion zulässt.

Ich gehöre zu den 5%.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Ich habe eine Anwendung bei der sehr
> oft pro Sekunde einen ISR durchlaufen werden
> muss.

Das ist doch wieder mal ne super Angabe, mit der jeder was anfangen 
kann.

In Pflichtenhefte gehören solche konkreten Eckdaten wie "sehr oft", 
"sehr genau", "sehr hoch" unbedingt mit rein!


Peter

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, mal für alle zum mitschreiben:

Ich habe mir bei der Art der Fragestellung
etwas gedacht - es mag sein dass das hier
bei den meisten nicht der Fall ist, bei
mir aber schon.

Ich wollte nur eine einfache Auskunft,
ich schreibe hier kein Pflichtenheft oder
eine Diplomarbeit.

Es scheint dass ihr alle SEHR viel Zeit
habt rumzunörgeln. Ich habe euch nicht
verpflichtet in irgendeiner Weise zu
Antworten. Ich bedanke mich nochmal bei
denen die mir hilfreiche Hinweise geliefert
haben und überlassen den Thread nun gerne
sich selbst und den "Experten"

rw

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Ich habe mir bei der Art der Fragestellung
> etwas gedacht

Kann ja sein aber nicht genug :-)
Kennst Du den Unterschied zwischen Taktzyklen und Instruktionen pro 
Sekunde?

Das und dein "sehr oft" passen exakt in das Schema des unteren Endes der 
95%.

Ich wünsche Dir trotzdem das Du Dein Problem gelöst bekommst.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:
> Robin Wenninger schrieb:
>> Ich habe mir bei der Art der Fragestellung
>> etwas gedacht
>
> Kann ja sein aber nicht genug :-)
> Kennst Du den Unterschied zwischen Taktzyklen und Instruktionen pro
> Sekunde?

Ich kenne den Unterschied, dir ist aber auch klar
dass das ganze stark korreliert?


> Ich wünsche Dir trotzdem das Du Dein Problem gelöst bekommst.
Danke.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:

> Ich kenne den Unterschied, dir ist aber auch klar
> dass das ganze stark korreliert?

Besonders beim oben angeführten PIC18 ;-).

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> ch kenne den Unterschied, dir ist aber auch klar
> dass das ganze stark korreliert?

Rofl, Du machst mir Spass,
Ein 8088 brauchte so ca. 170 Taktzyklen für eine 32 Bit / 16 Bit 
Ganzzahldivision. Ein Core Duo aber nicht mehr.

Viel Spass noch, ich geh jetzt mit einem Lächeln mehr zum Zahnarzt.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ A.K.
Den PIC24 kannte ich noch nicht, aber ich bezog mich auf die oben 
angegebenen PIC 18.
Na ja, vieleicht reicht ihm ja der Zugewinn von Faktor 2. Wenn Ihm der 
Wechsel auf einen anderen Hersteller mit allen Konsequenzen dafür recht 
ist, viel Glück.
Was mich jetzt noch interessieren würde ist in welcher Sprache er 
programmiert.
Jetzt muss ich aber weg.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Erfahrung ist, daß nur Leute, die nicht nachdenken sich in 
wischiwaschi Angaben wie "sehr oft" flüchten.

Die anderen haben es nämlich nicht nötig. Sie können ganz konkret sagen, 
wie oft der Interrupt kommt und was der alles machen soll.


Peter

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:
> Robin Wenninger schrieb:
>> ch kenne den Unterschied, dir ist aber auch klar
>> dass das ganze stark korreliert?
>
> Rofl, Du machst mir Spass,
> Ein 8088 brauchte so ca. 170 Taktzyklen für eine 32 Bit / 16 Bit
> Ganzzahldivision. Ein Core Duo aber nicht mehr.

Äpfel mit Birnen. Dir ist mal aufgefallen, dass bei den
meisten, halbwegs modernen uCs ein Faktor zw. MHz und
MIPS angegeben werden kann? Dir ist klar dass ein AVR mit
30MHz schneller ist als einer mit 4Mhz? Dir ist klar dass ein
Core Duo mit 1GHz langsamer ist als einer mit 2Ghz? Ja? Fein.

> Viel Spass noch, ich geh jetzt mit einem Lächeln mehr zum Zahnarzt.
Hoffen wir dass du es danach auch noch hast.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:
> @ A.K.
> [...]
> Was mich jetzt noch interessieren würde ist in welcher Sprache er
> programmiert.

C und ASM. Die ISR in ASM.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Im allg. ist bei diesen Cores zumindest
> der Flash extern

Schwachsinn.

Der von mir derzeit eingesetzte Prozessor mit Cortex M3 (72MHz), 512KB 
Flash, 64KB RAM kostet auch nur ca. 4,50EUR. Er ist auch als TQFP und 
nicht nur als BGA erhältlich.

Da Du das ganze aber eh besser weißt, habe ich mich wohl geirrt, so dass 
ich dann ja auch nicht verraten muss, um welchen Typ es sich handelt.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Meine Erfahrung ist, daß nur Leute, die nicht nachdenken sich in
> wischiwaschi Angaben wie "sehr oft" flüchten.

Vorurteil und Erfahrung sind eng verwandt.

> Die anderen haben es nämlich nicht nötig. Sie können ganz konkret sagen,
> wie oft der Interrupt kommt und was der alles machen soll.

Musst du garnicht wissen um mir nen uC mit hoher Taktfrequenz
empfehlen zu können. Und ich werd für dich nun sicher nicht
mein "Laborbuch" rauskramen.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Äpfel mit Birnen. Dir ist mal aufgefallen, dass bei den
> meisten, halbwegs modernen uCs ein Faktor zw. MHz und
> MIPS angegeben werden kann? Dir ist klar dass ein AVR mit
> 30MHz schneller ist als einer mit 4Mhz? Dir ist klar dass ein
> Core Duo mit 1GHz langsamer ist als einer mit 2Ghz? Ja? Fein.

Dir ist aufgefallen, dass sich die Angaben in MIPS/MHz bei 
Microcontrollern meist auf Speicherzugriffe mit 0 Waitstates beziehen 
und die Controller keine Caches besitzen?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Angaben wie MIPS o.ä. sind doch eh nur von der Marketing Abteilung und 
deshalb für einen technisch versierten Menschen nicht wirklich das 
Entscheidungsmaß für den Einsatz eines bestimmten Prozessors.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleine übersicht der letzten CortexM3 auswertung von der Embedded

AT91SAM3U CortexM3 mit bis zu 96Mhz (256/52)
AT91SAM3S CortexM3 mit bis zu 64MHz (512/64)

ST32F10x  CortexM3 mit bis zu 72Mhz (1024/96)

ST32F2xx  CortexM3 mit bis zu 120Mhz ( weiss jemand mehr dazu?)

TI Stellaris CortexM3 mit bis zu 100Mhz (256/96)

Toschiba CortexM3 mit bis zu 64Mhz (2048/128)

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> Kleine übersicht der letzten CortexM3 auswertung von der Embedded

Robin hat aber ja schon festgestellt, dass die Prozessoren kein internes 
Flash besitzen. Folglich müssen sich sowohl die Hersteller als auch wir 
Anwender irren.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:
> @ A.K.
> Den PIC24 kannte ich noch nicht, aber ich bezog mich auf die oben
> angegebenen PIC 18.

Siehst, bist doch froh dass ich die Frage gestellt
hab. Konntest glatt was dazulernen.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Konntest glatt was dazulernen.

Aber nicht von Dir...

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Äpfel mit Birnen. Dir ist mal aufgefallen, dass bei den
> meisten, halbwegs modernen uCs ein Faktor zw. MHz und
> MIPS angegeben werden kann?
Nur ist der zwischen verschiedenen Architekturen meist total 
unterscheidlich.

> Dir ist klar dass ein AVR mit
> 30MHz schneller ist als einer mit 4Mhz?
darum ging es gar nicht.
es ging darum, dass ein AVR mit 20Mhz möglicherweise genauso schnell 
rechnet, wie ein PIC mit 30Mhz.

> Dir ist klar dass ein
> Core Duo mit 1GHz langsamer ist als einer mit 2Ghz? Ja? Fein.

die anzahl der benötigten Taktzyklen ist unabhängig von der 
Arbeitsfrequenz.
Also könnte selbst ein Core Duo mit 10Mhz schneller dividieren als ein 
8088 (wirklich 88?) mit 10Mhz (keine Ahnung mit was die laufen).

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NXP wurde ja schon genant

Cortex M3 mit bis zu 120Mhz,

ARM 7 / Cortex M3 hab ich persönlich noch nicht ohne Flash und RAM 
gesehen, bzw die zeiten sind vorbei, wo sich sowas verkaufen lassen 
würde. (kostet alles platz, unnötig pins, .... )

ARM 9/ Cortex A8/A9 die gibts nicht mit internem Flash, da der zu 
langsam währe, SRAM ist meist auch seher klein. dafür aber DDR / SDram 
interface und power satt.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> ARM 9/ Cortex A8/A9 die gibts nicht mit internem Flash, da der zu
> langsam währe, SRAM ist meist auch seher klein. dafür aber DDR / SDram
> interface und power satt.

Naja, internes Flash wäre zwar schon deutlich schneller, aber für 
"typische" Anwendungen von Prozessoren dieser Leistungsklasse müsste es 
schon ziemlich groß sein. Dann kann man es sich auch gleich ganz 
schenken.

Alle drei Prozessoren werden aber üblicherweise mit Cache konfiguriert, 
so dass dadurch der Geschwindigkeitsnachteil externer Speicher (DRAM) 
großenteils wieder kompensiert wird.

Autor: Z-Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute,
Ihr seht das Problem dieser Sache überhaupt nicht. Es dreht sich darum, 
ausreichend viele Interrupts pro Zeiteinheit zu verarbeiten - Umfang der 
Verarbeitung: Minimal.

Die ATMEl 8-Bitter schaffen brutto etwa 1.000.000 Interrupts / Sekunde - 
zu wenig!

Das, was zwischenzeitlich angeboten wurde, das schafft auch nicht so 
viel mehr. Der liebe Robin benötigt an dieser Stelle - denke ich - eine 
CPU mit richtig viel WUMM. Mein Vorschlag zu diesem Thema wäre eine IBM 
Z-Series der neuesten Generation. Diese niedliche CPU (16 Stück auf ca. 
100 * 100 mm) verarbeitet jeweils etwa 500.000.000 Interrupts / Sekunde. 
Wenn  das nicht ausreicht: Interrupts extern im "Round-Robin-Verfahren" 
auf die 16 CPUs verteilen - das gibt etwa 8 * 10^9 Interrupts / Sekunde.

Robin, reicht das?

Z-Fan

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:

> ARM 9/ Cortex A8/A9 die gibts nicht mit internem Flash, da der zu
> langsam währe

Ein ARM9 mit internem Flash existiert: STR9. Interner Doppeldecker. 
Nicht wirklich schnell, aber immerhin bis zu 2MB.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> NXP wurde ja schon genant
>
> Cortex M3 mit bis zu 120Mhz,
>
> ARM 7 / Cortex M3 hab ich persönlich noch nicht ohne Flash und RAM
> gesehen, bzw die zeiten sind vorbei, wo sich sowas verkaufen lassen
> würde. (kostet alles platz, unnötig pins, .... )

Auf der Arbeit wurde für ARM7TDMI entwickelt, und ich hatte auch
danach farnellt und spontan nur welche ohne internen Flash
gefunden, vll. hab ich nicht genau hingeschaut, mag sein.
Allerdings zieht immernoch das Argument mit dem
"Kostenfaktor" - aber ich werd die ~4,- EUR wohl ausgeben.

Wobei ich eigentlich nur was gesucht hab, dass von der
Leistung her zwischen AVR und ARM-Cortex-MX ist.

> ARM 9/ Cortex A8/A9 die gibts nicht mit internem Flash, da der zu
> langsam währe, SRAM ist meist auch seher klein. dafür aber DDR / SDram
> interface und power satt.

rw

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Z-Fan schrieb:
> Ihr seht das Problem dieser Sache überhaupt nicht.

richtig, weil leider noch nicht gesagt wurden ist was nun genau macht 
wird. Wenn in der ISR nur eine Variabel hochgezählt wird, dann könnte es 
auch sehr gut von einem externen Zähler übernommen werden. Ein µC ist 
zwar universell aber es gibt für spezelle anwendungen auch spezielle 
ICs.

Aus dem Grund ist sehr hilfreich etwas mehr um das ringsrum zu erfahren.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, nimm einen AVR, pack einen Frequenzteiler davor und vergieße das 
alles in Kunstharz: Der Etliche-Hundert-Megaherz-Controller ist fertig!

Wenn es wirklich so einfach ist: LPC2103 kann glaub ich 72 MHz und ist 
dank schnellem Flash und FIQ vielleicht ein bischen schneller als der 
AVR. Kostet um die 2 Ören.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Z-Fan (Gast)

>Ihr seht das Problem dieser Sache überhaupt nicht. Es dreht sich darum,
>ausreichend viele Interrupts pro Zeiteinheit zu verarbeiten - Umfang der
>Verarbeitung: Minimal.

Wenn das wirklich so ist, kann man die Aufgabe wahrscheinlich besser in 
einen CPLD packen, der hat bei einfachen Logiksachen um Größenordnungen 
mehr Power.

>Die ATMEl 8-Bitter schaffen brutto etwa 1.000.000 Interrupts / Sekunde -
>zu wenig!

Das ist eine Vermutung deinerseits.

>viel mehr. Der liebe Robin benötigt an dieser Stelle - denke ich - eine
>CPU mit richtig viel WUMM.

Du denkst nicht. Du glaubst. Denn der "liebe Robin" ist 
beratungsresistent oder superschlau. Naja, ist ein Grundrecht.

> Mein Vorschlag zu diesem Thema wäre eine IBM
>Z-Series der neuesten Generation. Diese niedliche CPU (16 Stück auf ca.
>100 * 100 mm) verarbeitet jeweils etwa 500.000.000 Interrupts / Sekunde.
>Wenn  das nicht ausreicht: Interrupts extern im "Round-Robin-Verfahren"
>auf die 16 CPUs verteilen - das gibt etwa 8 * 10^9 Interrupts / Sekunde.

Welche Drogen nimmst du?

MfG
Falk

Autor: NurEinGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Aus dem Grund ist sehr hilfreich etwas mehr um das ringsrum zu erfahren.

Tja - aber hier scheint es sich mal wieder ein super geheimes Projekt zu 
handeln.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte mal wissen wo das große
Problem ist wenn man einen uC mit
etwas mehr dampf sucht? WENN sich das
alles auf schlaue Art und Weise anders
lösen lässt, WIESO gibts denn dann
Controller mit Taktraten jenseits
der 20MHz? Und wenn die Taktrate
so total scheiss egal ist, wieso
verbaut ihr dann nicht alle
8088 mit 4MHz?

Die Diskussion mit den meisten von
euch ist Witzlos - ich war ja nichtmal
Beratungsresistent - ich wollte ja beraten
werden; nur nicht SO wie das einige gerne
gesehen hätten.
Aber damit bin ich wohl voll in die Falle gelaufen.

Schönen Tag noch.
rw

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Ich möchte mal wissen wo das große
> Problem ist wenn man einen uC mit
> etwas mehr dampf sucht?
Das Problem ist, dass "mehr Dampf" keine technisch sinnvolle Aussage 
ist. Es gibt nicht umsonst so viele verschiedene Mikroprozessortypen, 
jeder für seinen eigenen Zweck gebaut.
Was meinst du also mit "mehr Dampf"?
Und jetzt sag nicht, du willst "ganz ganz viele" Interrupts mit "gar 
nicht mal so viel Code drin" pro Sekunde ausführen lassen.

> WENN sich das
> alles auf schlaue Art und Weise anders
> lösen lässt, WIESO gibts denn dann
> Controller mit Taktraten jenseits
> der 20MHz?
Weil es in manchen Applikationen nötig ist, eine hohe Taktrate zu haben. 
Sei es für hochfrequente/hochauflösende PWMs, schnelle Kopieraktionen im 
RAM o.ä..

> Und wenn die Taktrate
> so total scheiss egal ist,
Also das hast du jetzt gesagt, nicht einer von uns.

> Die Diskussion mit den meisten von
> euch ist Witzlos - ich war ja nichtmal
> Beratungsresistent - ich wollte ja beraten
> werden; nur nicht SO wie das einige gerne
> gesehen hätten.
> Aber damit bin ich wohl voll in die Falle gelaufen.
Wie soll man jemanden beraten, der selber nicht weiß was er braucht und 
will.

> Schönen Tag noch.
> rw

Haunse rein.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Robin Wenninger schrieb:
>> Ich möchte mal wissen wo das große
>> Problem ist wenn man einen uC mit
>> etwas mehr dampf sucht?
> Das Problem ist, dass "mehr Dampf" keine technisch sinnvolle Aussage
> ist. Es gibt nicht umsonst so viele verschiedene Mikroprozessortypen,

Lies den Thread.

> jeder für seinen eigenen Zweck gebaut.
> Was meinst du also mit "mehr Dampf"?

Höhere Taktrate? Siehe Betreff.


>> WENN sich das
>> alles auf schlaue Art und Weise anders
>> lösen lässt, WIESO gibts denn dann
>> Controller mit Taktraten jenseits
>> der 20MHz?
> Weil es in manchen Applikationen nötig ist, eine hohe Taktrate zu haben.
> Sei es für hochfrequente/hochauflösende PWMs, schnelle Kopieraktionen im
> RAM o.ä..

Und wer hat euch gesagt, dass es nicht genau
darum geht? Davon abgesehen dass es euch für
die Antwort auf die Frage nicht kümmern muss.

Wie du ja selbst sagst, gibt es Anwendungsfälle.

Ist euch in den Sinn gekommen, dass ich weiß was
ich tue und nur einfach ein paar Hinweise auf
nette uCs haben wollte?

>> Und wenn die Taktrate
>> so total scheiss egal ist,
> Also das hast du jetzt gesagt, nicht einer von uns.

Dann solltest du den Thread nochmal genauer
lesen. Es wurde so getan als gäbe es keinerlei
Zusammenhang zwischen Rechenleistung und Taktrate.

>
>> Die Diskussion mit den meisten von
>> euch ist Witzlos - ich war ja nichtmal
>> Beratungsresistent - ich wollte ja beraten
>> werden; nur nicht SO wie das einige gerne
>> gesehen hätten.
>> Aber damit bin ich wohl voll in die Falle gelaufen.
> Wie soll man jemanden beraten, der selber nicht weiß was er braucht und
> will.

[x] Du willst den Thread nochmal lesen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Simon K. schrieb:
>> Robin Wenninger schrieb:
>>> Ich möchte mal wissen wo das große
>>> Problem ist wenn man einen uC mit
>>> etwas mehr dampf sucht?
>> Das Problem ist, dass "mehr Dampf" keine technisch sinnvolle Aussage
>> ist. Es gibt nicht umsonst so viele verschiedene Mikroprozessortypen,
>
> Lies den Thread.
>
>> jeder für seinen eigenen Zweck gebaut.
>> Was meinst du also mit "mehr Dampf"?
>
> Höhere Taktrate? Siehe Betreff.

Hehe, oh mann. Du hast nichts verstanden oder? Es gibt Prozessoren, die 
haben eine 4 mal so hohe Taktrate wie ein AVR, aber nur "halb soviel" 
(subjektiv) Rechenleistung.
Also, WOFÜR(!) brauchst du die höhere Taktrate? Darum geht es doch.

>>> WENN sich das
>>> alles auf schlaue Art und Weise anders
>>> lösen lässt, WIESO gibts denn dann
>>> Controller mit Taktraten jenseits
>>> der 20MHz?
>> Weil es in manchen Applikationen nötig ist, eine hohe Taktrate zu haben.
>> Sei es für hochfrequente/hochauflösende PWMs, schnelle Kopieraktionen im
>> RAM o.ä..
>
> Und wer hat euch gesagt, dass es nicht genau
> darum geht? Davon abgesehen dass es euch für
> die Antwort auf die Frage nicht kümmern muss.
Aarrgh! Ok, ruhig bleiben ;-)

> Wie du ja selbst sagst, gibt es Anwendungsfälle.
>
> Ist euch in den Sinn gekommen, dass ich weiß was
> ich tue und nur einfach ein paar Hinweise auf
> nette uCs haben wollte?
Wenn du weißt, was du tust, warum fragst du dann nach Beratung? Was sind 
nette uCs? Kann man sich gut mit denen unterhalten? Oder was?

>>> Und wenn die Taktrate
>>> so total scheiss egal ist,
>> Also das hast du jetzt gesagt, nicht einer von uns.
>
> Dann solltest du den Thread nochmal genauer
> lesen. Es wurde so getan als gäbe es keinerlei
> Zusammenhang zwischen Rechenleistung und Taktrate.
Vielleicht solltest du den Thread nicht nur lesen, sondern auch 
verstehen, was geschrieben wurde. Vielleicht eröffnet sich dir dann, 
dass niemand behauptet hat, dass die Taktrate egal ist.

>>
>>> Die Diskussion mit den meisten von
>>> euch ist Witzlos - ich war ja nichtmal
>>> Beratungsresistent - ich wollte ja beraten
>>> werden; nur nicht SO wie das einige gerne
>>> gesehen hätten.
>>> Aber damit bin ich wohl voll in die Falle gelaufen.
>> Wie soll man jemanden beraten, der selber nicht weiß was er braucht und
>> will.
>
> [x] Du willst den Thread nochmal lesen.
Von wollen kann bei deinem Geschreibsel keine Rede sein.

Autor: JW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute, das bringt nix,
der will keine Hilfe für sein nicht genanntes Problem.

Autor: Reiner Zufall (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Ist euch in den Sinn gekommen, dass ich weiß was
> ich tue und nur einfach ein paar Hinweise auf
> nette uCs haben wollte?

dafür gibt es Google nur das die Suchmaschine mit begriffen wie "mehr 
Dampf" nicht soviel anfangen kann.
Da muss man schon selber wissen das wenn 20Mhz beim AVR z.B. "wenig 
Dampf" entspricht und man vielleicht 40Mhz bräuchte. oder aber eine 
16Biter nimmt (MSP) und da dann 25Mhz langen.

Die Frage ist ja auch was du alles in der ISR nur einen Zähler hoch 
zählen willst oder mehr machen musst. So eine Angabe wie die ISR im AVR 
braucht 10 Instruktionen oder 1000 hätte schon viel gebracht. Ohne nur 
irgendetwas "geheimes" Preisgeben zu müssen.


Robin Wenninger schrieb:
> Ich bedanke mich nochmal bei
> denen die mir hilfreiche Hinweise geliefert
> haben und überlassen den Thread nun gerne
> sich selbst und den "Experten"

Und wenn du keine neuen Informationen mehr liefern willst halte dich 
bitte an deine Aussage, danke!

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich habe eine Anwendung bei der sehr oft pro Sekunde einen ISR durchlaufen werden 
muss.

Also so 50 bis 100 mal? Wenn ich meine Mutter frage: "Mein µC muss 
[irgendwas] 100 mal pro Sekunde machen! Ist das oft?" Wird sie ja sagen

Wenn ich einen Freund frage: "Mein µC muss 200 mal pro Sekunde 2 
Eingänge einlesen und vergleichen. Ist das oft?" Wird er nein sagen

Autor: Scenix (Ubicom) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit diversen SX-Prozessoren habe ich vor Jahren 'mal rumgespielt. 
Unkompliziert PIC 16C5x-kompatibel, aber schnell: 50 - 75 MHz und 
genausoviele Mips:

http://www.sxlist.com/techref/ubicom/index.htm

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JW schrieb:
> der will keine Hilfe für sein nicht genanntes Problem.

Weil er nicht weiß, wo das Problem ist.

Robin Wenninger schrieb:
> Ich habe eine Anwendung bei der sehr
> oft pro Sekunde einen ISR durchlaufen werden
> muss. Der Rechenaufwand ansich ist nicht sonderlich
> hoch.

Ich würde auch einen schnelleren µC nehmen, wenn die LED zu langsam 
blinkt.

Autor: ^ö^ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Ich habe mir bei der Art der Fragestellung
> etwas gedacht - es mag sein dass das hier
> bei den meisten nicht der Fall ist, bei
> mir aber schon.

Dann teile doch deine Gedanken! Es kann ja nicht sein, dass wir dir 
helfen sollen, du uns hingegen alles vorenthälst.

Übrigens: Deine Sturheit, dass es nur so geht wie du dir ausgedacht 
hast, weist eigentlich schon auf mangelnde Fachkenntnisse und 
Erfahrungen hin. Hättest du die, wärst du dir im klaren darüber, dass es 
noch andere Lösungen gibt, und dass es sehr viel Sinn macht, diese zu 
diskutieren.

Und wer soviele Interrupts auslösen will, dass er einen schnelleren 
Controller braucht, der macht grundsätzlich etwas falsch.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach nur irgendein ein schneller 32Bit-Rechner hilft dem Fragesteller 
nicht unbedingt. Es geht hier um die Interruptrate, und die muss 
garantiert sein. Da fallen Prozessoren mit Cache doch schon flach. Wenn 
die parallel den cache gerade mit anderen Programmen und Daten gefüllt 
haben, dann gibt das doch garantiert eine lausige Interrupt-Antwortzeit 
oder irre ich mich da?
Was ist den bein Cortex oder anderen ARMs da als maximale Interrupt 
Latenzzeit spezifiziert? 100 Zyklen?

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Was ist den bein Cortex oder anderen ARMs da als maximale Interrupt
> Latenzzeit spezifiziert? 100 Zyklen?

Die längsten Operationen bei "alten" ARMs (7/9) sind die Anweisungen LDM 
und STM, die bis zu 16 Register in den/aus dem Speicher übertragen. Je 
nachdem, wie der Speicher angebunden ist, kann das schon einige Zeit 
dauern.

Ein Problem des ARM9 mit seinem virtuell gemapten Cache besteht darin, 
dass bei einem Kontextwechsel und Umschalten der MMU-Konfiguration bis 
zu 50.000 Instruktionen unter Interruptsperre ausgeführt werden müssen, 
da physikalische Speicherseiten ggf. unter mehreren virtuellen Adressen 
erreichbar sein können.

Autor: Robin Wenninger (rw83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reiner Zufall schrieb:
[...]
> Robin Wenninger schrieb:
>> Ich bedanke mich nochmal bei
>> denen die mir hilfreiche Hinweise geliefert
>> haben und überlassen den Thread nun gerne
>> sich selbst und den "Experten"
>
> Und wenn du keine neuen Informationen mehr liefern willst halte dich
> bitte an deine Aussage, danke!

Ich konnte nicht widerstehen - ebensowenig
wie du.

Autor: sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert:

>Kennt jemand uCs in der Preisklasse/mit
>der Verfügbarkeit wie die AVRs, aber
>gleichzeigt mit einer Taktfrequenz ab ca. 30/40MHz?

z.B.
- NEC V850
- AVR32
- Renesas R32

Alle mit internem Flash und RAM erhältlich.

Verfügbarkeit? Für den Hobby bedarf?

>Man denkt natürlich direkt an ARM7/Cortex-M3.
>Ich hätte nur gerne ne Lösung bei der RAM/Flash
>integriert sind, und sonderlich billig sind
>die ARM-Cores auch nicht.


Der Preis eines uC ist stark abhängig von der Grösse von RAM/ Flash und 
dem Gehäuse(Anzahl der Pins). Bei gleichem Gehäuse/ RAM / Flash und 
Peripherie ist ein 32Bitter nicht (viel) teuerer als ein 8Bit uC. Hat 
der 32Bitter mehr RAM/ Flash etc. wird er natürlich teurer.


>Ich habe eine Anwendung bei der sehr
>oft pro Sekunde einen ISR durchlaufen werden
>muss. Der Rechenaufwand ansich ist nicht sonderlich
>hoch.

Es währe schon nett wenn du dich an dieser stelle etwas konkreter 
ausdrücken könntest.

Autor: sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
UPS Ich meine natürlich @Robin und nicht Robert. Entschuldigung.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem es hier eine so "nette" Unterhaltung gab muss ich doch auch noch 
meine Meinung kundtun :-)

@Robin die Angabe moeglichst hohe Frequenz ist wirklich nicht so doll 
aber kommt des oefteren vor. Ist allerdings etwas unmodern geworden, 
selbst Intel und AMD kaempfen nicht mehr auf der GHz Ebene.
Eine evtl. bessere Formulierung waere gewesen "moeglichst hohe Interrupt 
Frequenz". Dann spielen allerdings ganz andere Faktoren rein als die 
MHz. Z.B. kann ein Cortex-M3 bei gleicher Taktfrequenz wie ein ARM7 
deutlich mehr Interrupts abarbeiten, weil einfach der Interrupt 
Controller viel mehr uebernimmt als beim ARM7.
Glaubts oder glaubts nicht, aber ein schneller 8051 wie z.B. ein 100 MHz 
Typ von Silabs stellt so ziemlich jeden ARM in den Schatten basierend 
auf Deiner Definition weil er Registerbaenke umschalten kann und nichts 
retten muss. Das gilt auch fuer einen XC2000, der mag zwar weniger MHz 
haben ist aber in Sachen Interrupt fast nicht zu schlagen, ist dafuer 
gemacht!
Beide Familien, die von Silabs und XC2000 von Infineon haben internes 
Flash, sind allerdings etwas teurer als ein Mega8.
Hier eine Frage, was fuer eine Rolle spielt der Preis der MCU bei 
niedrigen Stueckzahlen, z.b. "1"? Gar keine, oder lieg ich da falsch?

Zusammengefast, Deine Frage war eindeutig, laesst aber auf mangelnde 
Sachkenntnis schliessen, deshalb hast Du so viel Feuer bekommen. Hier im 
Foru, gibt es schon eine Menge Erfahrung und wenn Fragen gestellt 
werden, dann ist oft die beste Gegenfrage was moechtest Du eigentlich 
machen. Eine Forumierung wie "ich moechte alle 50 usec einen Interrupt 
ausfuehren der ca. 50 Befehle hat" waere auch eindeutig und wuerde von 
mehr Sachkenntnis zeugen.

Viel Spass bei Deinem Projekt!
Basierend auf Deinen Angaben wuerde ich den LPC1113FBD48, also im QFP48 
mit 24K Flash, 8k SRAM und 50 MHz empfehlen. Persoenlich denke ich 
allerdings, dass der LPC1313FBD48 einen besseren Wert darstellt. Hat 
eine M3 CPU, ist damit ca. 20-30% schneller als eine M0 CPU bei 
derselben Taktfrequenz und kann 72 MHZ laufen. Also in Summe 60-70% 
schneller als ein LPC1113.

Noch ein nicht so ganz ernst gemeinter Rat ;-) Der LPC3130 im 180-pin 
BGA Gehaeuse hat 96K!! SRAM und laeuft 180 MHz schnell. Kostet als 
Einzelstueck ca. 6 Euro. Ein echtes Schnaeppchen, wenn da nicht die 
Sache mit dem BGA waere. Start von einem externen Flash, dann ins 
interne SRAM kopieren und ab die Post. 96K Program/Daten sehr schnell, 
sehr billig, sehr bastlerunfreundlich.

Viele Artikel ueber Cortex-M3 von verschiedenen Herstellern, alle mit 
Flash gibt's hier:
http://mcu-related.com/architectures/35-cortex-m3

Gruss, Robert

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> Helmut S. schrieb:
>> Was ist den bein Cortex oder anderen ARMs da als maximale Interrupt
>> Latenzzeit spezifiziert? 100 Zyklen?
>
> Die längsten Operationen bei "alten" ARMs (7/9) sind die Anweisungen LDM
> und STM, die bis zu 16 Register in den/aus dem Speicher übertragen. Je
> nachdem, wie der Speicher angebunden ist, kann das schon einige Zeit
> dauern.
>
> Ein Problem des ARM9 mit seinem virtuell gemapten Cache besteht darin,
> dass bei einem Kontextwechsel und Umschalten der MMU-Konfiguration bis
> zu 50.000 Instruktionen unter Interruptsperre ausgeführt werden müssen,
> da physikalische Speicherseiten ggf. unter mehreren virtuellen Adressen
> erreichbar sein können.

Dann kann man ja die meisten Ratschläge die bisher gegeben wurden in der 
Pfeife rauchen. Einige der Leute, die hier glaubten so glorreich 
geantwortet zu haben, haben schlicht das Thema verfehlt. Wie war das 
nochmal: Setzen ... :-)

Autor: Reiner Zufall (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
>> Robin Wenninger schrieb:
>>> Ich bedanke mich nochmal bei
>>> denen die mir hilfreiche Hinweise geliefert
>>> haben und überlassen den Thread nun gerne
>>> sich selbst und den "Experten"
>>
>> Und wenn du keine neuen Informationen mehr liefern willst halte dich
>> bitte an deine Aussage, danke!
>
> Ich konnte nicht widerstehen - ebensowenig
> wie du.

Ich musste nicht widerstehen ich gehöre ja zu den "Experten" den du es 
ja freigelassen hast weiterzuschreiben.
Übrigens werde ich jetzt hier wirklich aufhören da du anscheint nur noch 
die sinnlosen Sachen (wie diese) kommentierst. Ich bin raus!

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm nen AVR und übertakte den ordentlich, der Rekord liegt glaub ich 
grad bei 32 MHz.
:D

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> ARM 9/ Cortex A8/A9 die gibts nicht mit internem Flash, da der zu
> langsam währe, SRAM ist meist auch seher klein. dafür aber DDR / SDram
> interface und power satt.

Der eigentliche Grund ist aber, dass man die größeren Prozessoren in 
Technologien fertigt, die kein Flash auf dem selben Die unterstützen. 
Daher ist man auf teure Doppeldeckerlösungen angewiesen, wenn man das im 
selben Gehäuse unterbringen möchte.

--
Marcus

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haben die ARM7 / ARM9 nicht auch sowas wie Registerbänke? zumindest ein 
grossteil der Register ist mehrfach ausgeführt.


Also um mit nem ARM7 / ARM9 richtig dampf bei den ISR abzurufen, hab ich 
irgendwo den trik gelesen.

1. für Systeme mit MPU / MMU den code für die ISR in den Cash vorladen 
und die entsprechenden zeilen sperren. Der code wird ab dann direckt aus 
dem Cash abgearbeitet und nicht erst extern geladen. Die Zeilen werden 
auch nicht mehr freigegeben durch das sperren. Je nach MPU /MMU version 
geht das oder auch nicht.

2. Den code in asm schreiben. soll ja klein und schnell sein.

3. nur die Register verwenden, die von der Architektur für IRQ oder FIRQ 
doppelt vorgehalten werden. (R1 - R4 darf man glaubich nicht verwenden)

4. externe Speicherzugriffe vermeiden, da langsam, ggf chashen. HW 
Register gehen natürlich nicht.

5. die startadresse der ISR auf den IRQ / FIRQ Verktor legen. damit 
entfällt der lästige sprung in die eigentliche ISR Rotine.

6. die Software darf nur eine IRQ quelle verwenden, ARM7 / ARM9 haben 
nur 2 IRQs, der rest wird durch externe Interruptcontroller gehändelt.

gruss

Autor: Uwe Jaster (Firma: Ing.-Büro U. Jaster) (jupec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übertakten brauchste garnicht! Es gibt mitlerweile ATXMega (AVR) die 
laufen standartmäßig mit 32MHz kosten nur 2,20€/100 mit DMA. Falls das 
nicht reicht kann ja noch ein Latch zur Synchronisation (PMW) 
nachgeschaltet werden.

UJ

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> Die längsten Operationen bei "alten" ARMs (7/9) sind die Anweisungen LDM
> und STM, die bis zu 16 Register in den/aus dem Speicher übertragen. Je
> nachdem, wie der Speicher angebunden ist, kann das schon einige Zeit
> dauern.

Kommt aber in der Praxis recht selten vor. Beim "Guten RealView 
Compiler" kann man aus diesem Grund die maximale Anzahl von Registern 
pro erzeugter LDM/STM Instruktion übrigens einschränken.

> Ein Problem des ARM9 mit seinem virtuell gemapten Cache besteht darin,
> dass bei einem Kontextwechsel und Umschalten der MMU-Konfiguration bis
> zu 50.000 Instruktionen unter Interruptsperre ausgeführt werden müssen,
> da physikalische Speicherseiten ggf. unter mehreren virtuellen Adressen
> erreichbar sein können.

DSL jetzt mit bis zu 50000Kbps ;-) Kannst Du mir dafür mal eine 
Referenz nennen?

Bei allem Respekt, die Diskussion geht langsam etwas am Ziel vorbei. 
Niemand würde für schnelle Interruptverarbeitung einen 
Applikationsprozessor verwenden.

Gruß
Marcus

Autor: TrippleX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es nur nach den blöden Megahertz geht dann soll der TE
auf Prozessoren der XScale3xx Serie oder auf die Aktuelle TI-OMAP
Serie greifen.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansonsten gibt es noch die FPGAs wo es beliebig viele Kerne zum Laden 
gibt.
Die gehen dann je nach Technologie hoch im Takt. Und sonst kann man noch 
meherere Kerne parallel arbeiten lassen.

Der Frage nach zu urteilen ist es eine akademische Aufgabe mit einer 
uebersteuerten Loesung, die viel einfacher zu haben waere.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Dann kann man ja die meisten Ratschläge die bisher gegeben wurden in der
> Pfeife rauchen.

Nein, das heißt es nicht. Man sollte bloß kein Betriebssystem auf dem 
Prozessor verwenden, das solche Kontextwechsel verursacht. Alternativ 
kann man mehrere Prozesse zu sog. Domains zusammenfassen, die sich die 
entsprechenden Kontexte teilen.

Wenn man sehr genau weiß, was man tut, kann man aber den FIQ weiterhin 
verwenden. Nur sollte man tunlichst darauf achten, dass die 
entsprechenden Speicherseiten nicht umkonfiguriert werden.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:
> Andreas Schweigstill schrieb:
>> LDM und STM, die bis zu 16 Register in den/aus dem Speicher übertragen.
>
> Kommt aber in der Praxis recht selten vor. Beim "Guten RealView
> Compiler" kann man aus diesem Grund die maximale Anzahl von Registern
> pro erzeugter LDM/STM Instruktion übrigens einschränken.

Ich hatte eine Frage zur ARM-Architektur beantwortet, nicht zu den 
Sonderlocken, die von manchen Compilern angeboten werden. Wenn es um die 
Abschätzung maximaler Latenzzeiten geht, spielt ein "recht selten" keine 
Rolle.

LDM/STM mit 10-12 Registern sind aber absolut keine Seltenheit.

>> Ein Problem des ARM9 mit seinem virtuell gemapten Cache besteht darin,
>> dass bei einem Kontextwechsel und Umschalten der MMU-Konfiguration bis
>> zu 50.000 Instruktionen unter Interruptsperre ausgeführt werden müssen,
>> da physikalische Speicherseiten ggf. unter mehreren virtuellen Adressen
>> erreichbar sein können.
>
> DSL jetzt mit bis zu 50000Kbps ;-) Kannst Du mir dafür mal eine
> Referenz nennen?

Diese Thematik wird für Linux und uClinux recht ausgiebig in den 
Publikationen zum FASS-Projekt diskutiert, z.B. hier zu finden:

http://tinyurl.com/39gugth

Das "bis zu" gilt für die maximale Cache-Größe von 32KB/32KB. Wurde der 
Prozessor jedoch nur mit 8KB/8KB konfiguriert, fallen die Zahlen 
natürlich geringer aus. Wie von mir schon an anderer Stelle erwähnt, 
können mehrere Prozesse/Threads zu sog. Domains (verwandt mit dem sog. 
Cache Colouring) zusammengefasst werden, wodurch sie signalisieren, dass 
sie keine mehrfach an verschiedene virtuelle Adressen gemapte 
physikalische Speicherseiten (sog. Cache Aliasing) und somit auch 
mögliche Cache-Einträge besitzen. Dann kann man sich das ggf. 
erforderliche Rückschreiben und für ungültig Erklären des Cache 
ersparen.

> Bei allem Respekt, die Diskussion geht langsam etwas am Ziel vorbei.
> Niemand würde für schnelle Interruptverarbeitung einen
> Applikationsprozessor verwenden.

Doch, man kann natürlich auch einen ARM9 für solche Dinge verwenden, 
wenn man entweder nur wenige Interruptquellen oder eine Implementierung 
mit einem ordentlichen Interruptcontroller verwendet. Zudem sollte man 
dann kein Betriebssystem mit virtueller Adressierung einsetzen.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> Ich hatte eine Frage zur ARM-Architektur beantwortet,...

Genau genommen hast Du das nicht. Wir wissen nun lediglich wieviele
Register mit einer einzigen Instruktion in den Speicher übertragen
werden können. Inwieweit das zur Interruptlatenz (Zeit zwischen dem
Signalisieren des Interrupts bis zur ersten Instruktion der
eigentlichen ISR) beiträgt hängt sehr stark von sowohl HW als auch SW
Implementierung ab.

> Diese Thematik wird für Linux und uClinux recht ausgiebig in den
> Publikationen zum FASS-Projekt diskutiert, z.B. hier zu finden:

Vielen Dank. Das ist ein sehr informativer Artikel und auch das
eigentliche Paper von Wiggins, et al.

>> Niemand würde für schnelle Interruptverarbeitung einen
>> Applikationsprozessor verwenden.
>
> Doch, man kann natürlich auch einen ARM9 für solche Dinge verwenden,
> ...

Klar kann man aber dann eher jene ohne Cache und MMU. Ich vermute, der
originale Beitrag ist etwas aus dem Blickfeld geraten. Wenn ich mal
einen Satz herausgreifen darf:

"Momentan experimentiere ich mit einem ganz normalen ATMega8, leider
gehen die ICs - lt. DB - nur bis ~20MHz, das ist etwas eng."

Diese ganze Argumentation mit Kontextwechsel usw. scheint mir in
diesem Licht besehen etwas weit gegriffen.

> Zudem sollte man dann kein Betriebssystem mit virtueller
> Adressierung einsetzen.

In dem Fall wären ja Deine postulierten "50.000 Instruktionen"
(Zyklen?  Bus oder Prozessortakt?) nur noch Makulatur. Ich kenne den
Code auf den Du Dich beziehst zwar nicht, vermute aber, dass nur
während eines Teils dieser Zeit Interrupts gesperrt sein müssen.

Ist doch kein Wunder, dass so viele in diesem Forum Angst vor den
"32bit Boliden" bekommen.

Für derartige Kontrollaufgaben ist ein CM3 mit fest definierter und
obendrein (innerhalb der ARM Familie) geringer Interruptlatenz
sicherlich die bessere Wahl und obendrein billiger.

Gruß
Marcus

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Robin Wenninger
Ein kleiner Schritt zurück an den Anfang. Wenn das die Frage ist:
>>>> Kennt jemand uCs in der Preisklasse/mit
>>>> der Verfügbarkeit wie die AVRs, aber
>>>> gleichzeigt mit einer Taktfrequenz ab ca. 30/40MHz?
Und gleich danach sowas kommt:
>>> Dann schau mal hier die LPC111x von NXP an:
>> Aha! Dankeschön.
Und sowas:
> Danke für die Antwort, bin - noch - kein Fan der PICs,
> aber die sehen gut aus.
Dann hast du ja noch nicht mal die "üblichen Verdächtigen" abgegrast. 
Und wenn dann nicht mal eine einzige handgreifliche Zahl daherkommt 
(wieviele Interrupts pro Zeiteinheit von welchem Baustein), dann kann 
das Ganze ja nur in Raterei und wilde Diskussionen ausufern.

Und deshalb war m.E. die erste Antwort von Falk Brunner auch schon die 
beste.

> Aber damit bin ich wohl voll in die Falle gelaufen.
Robin, du hast sie selbst gestellt, diese Falle...  :-o

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:
> Andreas Schweigstill schrieb:
>> Ich hatte eine Frage zur ARM-Architektur beantwortet,...
>
> Genau genommen hast Du das nicht. Wir wissen nun lediglich wieviele
> Register mit einer einzigen Instruktion in den Speicher übertragen
> werden können.

Doch. Der Befehlssatz der ARM-Prozessoren ist in der 
Architekturbeschreibung (z.B. ARM v4t, ARM v5, ARM v7) festgelegt und 
nicht in der Implementierung der Architektur (ARM 7, ARM 9, Cortex Mx). 
Auch die Tatsache, dass die Übertragung der durch LDM/STM referenzierten 
Register sequentiell zu erfolgen hat, ist eine Merkmal der 
ARM-Archiktektur.

Folglich handelt es sich sogar ausschließlich um eine 
architekturbezogene Frage/Antwort.

> Inwieweit das zur Interruptlatenz (Zeit zwischen dem
> Signalisieren des Interrupts bis zur ersten Instruktion der
> eigentlichen ISR) beiträgt hängt sehr stark von sowohl HW als auch SW
> Implementierung ab.

Ich habe doch an keiner Stelle konkrete Angaben zur Interruptlatenz 
gemacht. Das (externe) Businterface selbst ist gerade bei den älteren 
ARM-Prozessoren ja kein Architekturmerkmal, sondern 
implementierungsabhängig.

>> Doch, man kann natürlich auch einen ARM9 für solche Dinge verwenden,
>> ...
>
> Klar kann man aber dann eher jene ohne Cache und MMU.

Den Cache kann man natürlich verwenden. Bei Betrachtungen zur 
Interruptlatenz sollte man eben bloß von 100% Cache Miss ausgehen.

Die MMU kann man verwenden, wenn man SEHR GENAU weiß, was man tut. 
Dann muss man während der Page-Table-Operationen auch nicht den FIQ 
sperren. Selbst bei der Verwendung eines Linux (nicht nur uClinux) ist 
dies unter erheblichen Auflagen möglich. Ich habe dies ja selbst schon 
für zwei Kundenprojekte realisiert. Das Debugging war da aber schon eine 
sehr knifflige Angelegenheit, d.h. wir mussten schon genau analysieren, 
welche Speicherseite bei welcher MMU-Operation nicht zur Verfügung 
stand. Teilweise ließen sich solche Probleme erst im Rahmen von 
mehrstündigen Testdurchläufen nachweisen. Sämtliche hierbei gefundenen 
Probleme waren jedoch auf Code zurückzuführen, den der Kunde selbst 
geschrieben hatte.

Auf den ARM-Linux-Mailinglisten finden sich auch hinreichend viele, zum 
Teil sehr fundierte Diskussionen über den FIQ-Einsatz.

> Diese ganze Argumentation mit Kontextwechsel usw. scheint mir in
> diesem Licht besehen etwas weit gegriffen.

Es wurde von Helmut S. eine Interruptlatenz von 100 Zyklen in den Raum 
geworfen. Durch meine Ausführungen habe ich jedoch belegt, dass wir über 
eine ganz andere Größenordnung sprechen.

Aber wie ebenfalls ausgeführt, muss man nun nicht immer von 50k Zyklen 
ausgehen, sondern muss nur sein SW-Konzept, insbesondere bei 
MMU-/Cache-Nutzung, entsprechend auslegen, um solche Fälle zu vermeiden.

>> Zudem sollte man dann kein Betriebssystem mit virtueller
>> Adressierung einsetzen.
>
> In dem Fall wären ja Deine postulierten "50.000 Instruktionen"
> (Zyklen?  Bus oder Prozessortakt?) nur noch Makulatur.

Komisch. Zuerst wirfst Du mir vor, den Ausdruck "bis zu 50.000 
Instruktionen" verwandt zu haben, und plötzlich lässt Du das "bis zu" 
weg und unterstellst mir, eine feste Zahl genannt zu haben. Das ist doch 
ziemlich absurd, insbesondere weil ich sowohl selbst die hierfür 
benötigten Bedingungen aufgeführt als auch die gewünschten Referenzen 
genannt habe.

> Ich kenne den
> Code auf den Du Dich beziehst zwar nicht, vermute aber, dass nur
> während eines Teils dieser Zeit Interrupts gesperrt sein müssen.

Nein, im allgemeinen Fall müssten sie während der gesamten Zeit gesperrt 
sein. Jedoch lassen sich spezielle Fälle mit erheblichen Einschränkungen 
finden, in denen der FIQ weiterhin nutzbar wäre. Oder man kann schon im 
Design des "Betriebssystems" ausschließen, dass physikalische 
Speicherseiten mehrfach virtuell gemaps sind.

> Ist doch kein Wunder, dass so viele in diesem Forum Angst vor den
> "32bit Boliden" bekommen.

Na und? Das ganze hat nichts mit 32Bit zu tun. Das Mapping, wie es 
gerade bei 8Bit-Prozessoren, z.B. manchen 8051-Ablegern, gemacht wird, 
ist doch noch schlimmer. Da kann man doch auch nicht erwarten, dass in 
die in ausgeblendeten Seiten enthaltenen Daten und Programmteile 
jederzeit verfügbar sind.

Aber ich habe auch schon mehrere Entwickler erlebt, die so etwas 
"normal" finden und für die eine Welt zusammenbricht, wenn man ihnen 
erzählt, dass man bei 32Bit-Microcontrollern einen so großen linearen 
Adressraum hat, dass man sich auf Applikationsebene nur selten mit 
Mapping beschäftigen muss. Verständnisprobleme gibt es aber häufig dann, 
wenn man denjenigen erzählt, dass man auf Applikationsebene mehr 
Speicher reservieren kann als physikalisch vorhanden ist und 
physikalische Speicherseiten erst beim ersten tatsächlichen Zugriff 
zugewiesen werden.

Das hat aber nichts mit 32Bit zu tun, sondern mit (V)MMUs, die es auch 
bei anderen Wortlängen gibt.

> Für derartige Kontrollaufgaben ist ein CM3 mit fest definierter und
> obendrein (innerhalb der ARM Familie) geringer Interruptlatenz
> sicherlich die bessere Wahl und obendrein billiger.

Keine Frage. Insbesondere auch die Definition des Interrupt-Controllers 
durch CMSIS und ein endlich brauchbares Interruptkonzept machen es einem 
doch deutlich leichter, prozessorübergreifende Lösungen zu entwickeln. 
Zwar gab es auch schon bei ARM7/9 vereinzelt gute Lösungsansätze für 
vektorisierte Interrupts, aber leider auch ziemlich schlechte 
Implementierungen. Ich erinnere mich an ein Projekt auf Basis eines 
Alcatel MTC-20285, bei dem ich einen unglaublich verschachtelten 
Interrupthandler programmieren musste, bei dem Unmengen an Bits in 
verschiedenen Peripherieregistern abzuklappern waren, um nach zig 
Instruktionen endlich eine der möglichen Interruptquellen ausfindig zu 
machen. Der Interrupthandler musste dann auch noch in einer Schleife 
ausgeführt werden, und zwar so lange, bis kein Interruptbit mehr gesetzt 
war. Das war ziemlich nervtötend.

Autor: Moin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin

Für den ARM 7 im ARM mode (nicht THUMB) sind für den FIRQ R9 Bis R16 
doppelt voerhanden. Wird der FIRQ ausgelöst, müssen diese Register nicht 
gesichert werden.
kommt man jetzt ohne R1 bis R8 in der ISR für den FIRQ aus, und ohne 
externen IRQ Controller für den FIRQ.
Der code und Data sollte aus dem Internen SRAM oder aus dem Cash kommen.

damit sollte man die maximale performenc aus einem ARM 7 herauskitzeln. 
Erst etliche Register wegsichern, kann dadurch komplett entfallen. es 
treten somit nur die reinen hw latenci zeiten auf.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin schrieb:
> Moin
>
> Für den ARM 7 im ARM mode (nicht THUMB) sind für den FIRQ R9 Bis R16
> doppelt voerhanden. Wird der FIRQ ausgelöst, müssen diese Register nicht
> gesichert werden.
> kommt man jetzt ohne R1 bis R8 in der ISR für den FIRQ aus, und ohne
> externen IRQ Controller für den FIRQ.
> Der code und Data sollte aus dem Internen SRAM oder aus dem Cash kommen.
>
> damit sollte man die maximale performenc aus einem ARM 7 herauskitzeln.
> Erst etliche Register wegsichern, kann dadurch komplett entfallen. es
> treten somit nur die reinen hw latenci zeiten auf.

Gehen wir mal davon aus, dass der Fragesteller in der ISR kurz was 
rechnet und jedesmal auf einem 8-Bit-Port etwas ausgeben will. Geht das 
mit Raten im Mega-Hertz-Bereich beim ARM7. Ich erinnere mich, dass mal 
jemad was von extrem langsamen I/O Zugriffen geschrieben hat. Hast du da 
zufällig eine Zahl parat?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:

> Ich erinnere mich, dass mal
> jemad was von extrem langsamen I/O Zugriffen geschrieben hat. Hast du da
> zufällig eine Zahl parat?

"Extrem langsam" ist relativ zu verstehen. Es sind ein paar Takte.

Auf den ARMs sind Zugriffe auf die Peripheriebusse (APBx) langsamer als 
Zugriffe auf den Primärbus (AHB) und je nach Bauweise sind die I/O-Ports 
dort angesiedelt. Das war insbesondere auffällig bei den ersten LPC2000, 
deren maximale Pin-Toggle-Rate deshalb nur wenige MHz betrug, weshalb 
NXP in der zweiten Generation die Ports auf den Primärbus verlagerte.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte mal die XMEGAs in den Raum werfen. Lt. Atmel zeichnen sich 
jene durch eine besonders performatnes Interrupt / Event System aus; 
also genau das Richtige für die gesuchte Anwendung.
XMOS könnte auch einen Blick wert sein

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
XMOS und Propeller sind extrem gut, wenn es um sehr kurzfristige 
Reaktion geht, weil die in einem Takt erfolgen kann (also 10ns bzw. 
50ns) und keine Sicherung eines Kontextes erforderlich ist.

Richtig billig sind allerdings beide nicht. Beim Propeller ist der 
Systemaufbau einfach aber der Chip ist relativ teuer, bei XMOS sind die 
Preise der Chips ok, aber der Systemaufbau ist komplex (SPI-Flash, 
Core-Spannung, Reset-Chip, Taktoszillator).

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin Wenninger schrieb:
> Man denkt natürlich direkt an ARM7/Cortex-M3.
> Ich hätte nur gerne ne Lösung bei der RAM/Flash
> integriert sind, und sonderlich billig sind
> die ARM-Cores auch nicht.

Och? Wo hast du denn geschaut?

Preis-Leistung bei zB sam7s64 ist doch viel besser, als bei AVRs mit 
gleichem Flash, RAM ...

Bei Reichelt kostet der sam7s64 nur um die 6EUR, bei Schukat sogar nur 
5EUR ...

Grüße,
Markus

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> [...er hätte die Frage "Was ist den bein Cortex oder anderen ARMs da
> als maximale Interrupt Latenzzeit spezifiziert? 100 Zyklen?"
> beantwortet]
>
> Ich habe doch an keiner Stelle konkrete Angaben zur Interruptlatenz
> gemacht.

Genau das war aber die Frage :^)

> Es wurde von Helmut S. eine Interruptlatenz von 100 Zyklen in den Raum
> geworfen. Durch meine Ausführungen habe ich jedoch belegt, dass wir über
> eine ganz andere Größenordnung sprechen.

Nein, Du sprichst über ganz andere Größenordnungen in ganz
bestimmten Anwendungsbereichen, die Robin mit Sicherheit nicht im Sinn
hatte. Dort sind Latenzen in dieser Größenordnung unabhängig vom
Prozessor keine Seltenheit.

> Komisch. Zuerst wirfst Du mir vor, den Ausdruck "bis zu 50.000
> Instruktionen" verwandt zu haben

Das einzige was ich Dir hier vorwerfe ist eine Form von
Betriebsblindheit. Du hast ohne Not einen (in diesem Zusammenhang
absurden) Anwendungsfall konstruiert, der andere dazu veranlasst "die
meisten Ratschläge die bisher gegeben wurden in der Pfeife [zu]
rauchen" (Helmut S.). (Helmut, Du kannst beruhigt zu einem ARM
Prozessor greifen -- die brauchen nicht jedesmal 50000 Instruktionen
bis zur Bearbeitung eines Interrupts.)

> Das ist doch ziemlich absurd, insbesondere weil ich sowohl selbst
> die hierfür benötigten Bedingungen aufgeführt[...]

Stell Dir mal vor da kommt jemand daher, der jahrelang mit AVR
gespielt hat und schon lange überlegt, sich mal am ARM zu
versuchen. Liest den erstbesten Thread in dem jemand einen Prozessor
sucht, der etwas schneller ist als sein ATMega8, und bekommt vom
Experten Informationen über Kontextwechsel, MMU, virtuell addressierte
Caches und 50000 Instruktionen unter Interruptsperre um die Ohren
gehauen. Den sehen wir doch bei ARM nie wieder :-)

> als auch die gewünschten Referenzen genannt habe.

Für die ich Dir ehrlich sehr dankbar bin.

Einen schönen Tag noch, bei mir geht er gerade zu Ende.
Marcus

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn dir 20MHz zu knapp sind:
AT89C2051 kann mit 24MHz arbeiten und ist bei den üblichen Verdächtigen 
bereits um EUR 1.39 (Einzelstück) erhältlich.

und um ein wenig zu trollen:
>> Dir ist klar dass ein AVR mit 30MHz schneller ist als einer mit 4Mhz?
Gleiche Architekturen mit unterschiedlicher Frequenz vergleichen kann 
ich auch:
Dir ist klar das ein 8051er (z.B. AT89LP4052) mit 10MHz deutlich 
schneller ist als ein ein 8051er (z.B. AT89C4051) mit 20MHz?

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
p.s.: Ich hab früher im Support gearbeitet und bei Fragen wie deiner 
kommt mir jetzt die Galle hoch.

pp.s.: Heißt "etwas eng" nicht: "Hey, den nehm ich!" ?

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ppp.s.: Tschuldigung, hab grad erkannt, dass Du wirklich zu den 5% 
gehörst, die wissen, wovon sie reden.
Robin Wenninger schrieb:
> Man denkt natürlich direkt an ARM7/Cortex-M3.
> Ich hätte nur gerne ne Lösung bei der RAM/Flash
> integriert sind, und sonderlich billig sind
> die ARM-Cores auch nicht.

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn nicht allzuviel an Leistung fehlt, kann man auch das ganze Programm 
in ASM schreiben. Man kann dann oft einige Register nur für die 
Interrupts reservieren und kann so schneller sein, als wenn das 
Hauptprogramm in C ist.
Wenn man keine neue IDE will, ist die Xmaga Serie ein kleiner Schritt.

Wenn schon PIC, dann eventuell PIC24 oder PIC33, aber nicht PIC18. Ein 
PIC18 müßte schon mit ewta 80 MHz laufen um etwa so schnell wie der 20 
MHz AVR zu sein.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ulrich (Gast)

>Wenn nicht allzuviel an Leistung fehlt, kann man auch das ganze Programm
>in ASM schreiben.

Nöö, das meiste kann man, wenn es denn schon in C ist, auch in C 
belassen. Lediglich den Interrupt und ein paar wenige, kritische 
Teile macht man in ASM, wenn überhaupt.

MFG
Falk

Autor: High Performer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat der OP jetzt eigentlich schonmal hier gepostet, wie viele Interrupts 
pro Sekunde verarbeitet werden sollen? Oder ist das sein Geheimnis?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  High Performer (Gast)

>Hat der OP jetzt eigentlich schonmal hier gepostet, wie viele Interrupts
>pro Sekunde verarbeitet werden sollen?

Nein.

> Oder ist das sein Geheimnis?

Ja.

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.