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
@ 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
Außerdem hat der Core nichts mit dem Speicher zu tun. Es gibt auch ARM7 mit integriertem Flash/RAM.
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ß.
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ß.
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/microcontrollers/pdf/lpcxpresso.pdf Das dürfte wohl reichen ;) hans
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
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
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.
Klar, die haben eine höhere Taktfrequenz, aber auch mehr MIPS? Aber Du wolltest ja welche mit höherer Taktfrequenz. Viel Erfolg.
^ö^ 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%.
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
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
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.
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.
Robin Wenninger schrieb: > Ich kenne den Unterschied, dir ist aber auch klar > dass das ganze stark korreliert? Besonders beim oben angeführten PIC18 ;-).
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.
@ 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.
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
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.
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.
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.
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.
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?
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.
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)
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.
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.
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).
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.
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.
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
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.
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
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.
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.
@ 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
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.
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
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.
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.
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.
Leute, das bringt nix, der will keine Hilfe für sein nicht genanntes Problem.
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!
>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
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
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.
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.
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?
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.
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.
@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.
UPS Ich meine natürlich @Robin und nicht Robert. Entschuldigung.
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
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 ... :-)
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!
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
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
Ü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
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
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.
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.
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.
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.
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
@ 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
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.
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.
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?
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.
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
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).
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
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
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?
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!" ?
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.
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.
@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
Hat der OP jetzt eigentlich schonmal hier gepostet, wie viele Interrupts pro Sekunde verarbeitet werden sollen? Oder ist das sein Geheimnis?
@ 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.