Falls jemand Rechenleistung braucht und sich mal außerhalb des STM32 umtun will: von NXP gibt es unter dem Schlagwort "500 MHz für 1$" den i.MX RT1010. Eckpunkte: Cortex M7 (1 Core) mit 500 MHz, FPU, 128 kB RAM, 8x32 Bit-Timer. Gehäuse: LQFP80. Braucht wohl externes Flash (QSPI), hat aber einen großen Cache. Der 1$ ist zwar nur für (sehr) große Stückzahlen gültig, aber EUR 2,40 in 100er-Stückzahlen (Mouser) sind auch nicht schlecht. Demo-Board ist für 10,10 USD oder 9,09 EUR bei den üblichen Verdächtigen zu haben. Disclaimer: ich habe weder mit NXP noch mit Freescale irgendetwas zu tun. Ich finde nur den Baustein interessant und überlege, was ich damit machen könnte. Außer BLDC-Steuerung und Spracherkennung fällt mir aber aktuell nichts ein. Gegenstück von ST ist der STM32F730, der "nur" mit 216 MHz läuft, dafür aber internen Flash hat. Preislich schenken sich die beiden Typen nicht viel.
Max G. schrieb: > Außer BLDC-Steuerung und Spracherkennung fällt mir aber > aktuell nichts ein. Genau das ist das Problem an diesen Boliden: Je mehr nackte unintelligente Performance desto dünner die sinnvolle Anwendung-Auswahl. Weil die Leistung schlicht überdimensioniert ist. Weil sie schlicht zuviel Strom schluckt. Jeder 8Bitter bietet hier einen meilenweit besseres Verhältnis von Aufwand zu Nutzen. Selbst zu den genannten Spezial-Anwendungen gibts schon längst zahlreiche fertige Lösungen. Spart Euch das Rumgeprotze. Einfach nur dumm und primitiv.
Das ist weder Fisch noch Fleisch. Es ist kein richtiger µC, dazu fehlt das Flash. Es ist aber auch kein richtiger Applikaitonsprozessor, dazu fehlen ein ordentliches Grafikinterface (z.B. HDMI), Performance, und ein brauchbares Speicherinterface. Die Peripherie passt eher zu einem µC. Größter Nachteil aus meiner Sicht: Der winzige Speicher muss Code UND Variablen fassen. Da werden die 128kB schnell sehr klein. Außer man exekutiert vom externem Flash. Das will mir trotz Cache langsam vorkommen, aber ich kann mich auch täuschen ;-) Man sollte auch nicht vergessen, dass man um ein paar Euro mehr eine Komplettlösung wie einen PIC32MZ oder STM32F4 bekommt, die nicht viel langsamer sind, aber Flash und RAM schon dabei haben.
jemand schrieb: > Der winzige Speicher muss Code UND Variablen fassen. Da werden die 128kB > schnell sehr klein. die 128K sind RAM für diesen Bereich doch recht normal USB, I²S und serielle schnittstellen. Daher eigentlich auch OK Code kommt immer von externem FLash. also auch ausführen von externem Flash Kritische funktionen legt man ins ITCM mach ich zB mit ISR's > Außer man exekutiert vom externem Flash. Das will > mir trotz Cache langsam vorkommen, aber ich kann mich auch täuschen ;-) ist laut einigen benchmarks nicht mal so viel langsamer man muss etwas aufpassen das man keine elend langen funktionen mit riesigen switch/cases baut. lieber kleine funktionen
hfhd schrieb: > jemand schrieb: >> Der winzige Speicher muss Code UND Variablen fassen. Da werden die 128kB >> schnell sehr klein. > > die 128K sind RAM > für diesen Bereich doch recht normal Und, wo hast du deinen Code? Den wirst du wohl ins Ram laden müssen, denn ein internes Flash hat er nicht. Die QSPI ist schnell, aber nicht schnell genug, um einen 500MHz-Prozessor zu füttern.
jemand schrieb: > Den wirst du wohl ins Ram laden müssen, denn ein internes Flash hat er > nicht. Die QSPI ist schnell, aber nicht schnell genug, um einen > 500MHz-Prozessor zu füttern. Ach Gott, das meiste ist so ein Prozessor ehe in der Polling-schleife und die läuft im Cache. Da ist speed am memory-interface Nebensache.
hfhd schrieb: > ist laut einigen benchmarks nicht mal so viel langsamer > man muss etwas aufpassen das man keine elend langen funktionen mit > riesigen switch/cases baut. > lieber kleine funktionen Oh, sorry. Man sollte auch mal Zuende lesen (und verstehen). Exekutieren auf einem QSPI-Flash? DAS klingt nach genau der fürchterlichen Krücke, die ich befürchtet habe. Und ich bezweifle, dass (außer in Spezialanwendungen), der Prozessor dann eine sinnvolle Performance erreicht. Selbst mit 100MHz auf dem Bus ist eine QSPI nicht vergleichbar mit einem internen Flash. Ein µC hat bei 200MHz zwar auch kein 1-Waitstate-Flash, aber das Flash hängt immerhin mit voller 32-Bit Busbreite am Cache, und muss nicht über ein serielles Interface. Das ist eine ganz andere Kategorie, was Zugriffszeiten und Übertragugnsrate angeht. Natürlich gibt es immer Anwendungen, bei denen das trotzdem sehr gut passt, sonst würde niemand den Chip produzieren. Aber "general Purpose" ist das nicht.
jemand schrieb: > Natürlich gibt es immer Anwendungen, bei denen das trotzdem sehr gut > passt, sonst würde niemand den Chip produzieren. Dem Hersteller interessiert es lediglich, ob es Käufer gibt, "Anwender" oder gar sinnvolle Anwendungen sind eher nachrangig. So dürfte der Grossteil der RasPis irgendwo verstauben oder mit Spielerein unnötig Energie verbrennen.
Perlen vor Säue - 500MHz für Bastler schrieb: > Dem Hersteller interessiert es lediglich, ob es Käufer gibt, "Anwender" > oder gar sinnvolle Anwendungen sind eher nachrangig. Soweit schon richtig... Du glaubst doch aber nicht, dass die paar Bastler die sich so einen Chip kaufen ausreichen, um Entwicklung und Herstellung zu bezahlen? Jeder andere der den Chip dann in größeren (für den Hersteller lukrativen) Mengen kauft nutzt ihn dann folglich auch in einer (für ihn) sinnvollen Anwendung.
Perlen vor Säue - 500MHz für Bastler schrieb: > Dem Hersteller interessiert es lediglich, ob es Käufer gibt, "Anwender" > oder gar sinnvolle Anwendungen sind eher nachrangig. Der Hersteller hat das Ding aber auch sicher entwickelt weil es jemanden gab, der sagte, dass er genau so etwas wollte/brauchte. ;)
Angehängte Dateien:
-
accesstime.png
29 KB
jemand schrieb: > DAS klingt nach genau der fürchterlichen Krücke, die ich befürchtet > habe. Und ich bezweifle, dass (außer in Spezialanwendungen), der > Prozessor dann eine sinnvolle Performance erreicht. Selbst mit 100MHz > auf dem Bus ist eine QSPI nicht vergleichbar mit einem internen Flash. Allein von der Anbindung des Speichers kann man kaum die reale Performance abschätzen. Das hängt sehr stark mit der internen Architektur/Chaches zusammen. Angehängt ein Bild der Zugriffszeiten auf den RAM einer modernen x86 PC CPU(entnommen aus dem Meltdown paper: https://meltdownattack.com/meltdown.pdf). Un das ist der RAM... Trotzdem würde ich jetzt nen modernen i7 nicht als Krücke bezeichnen. Es kommt eben auf die Caches und allgemeine Architektur des Systems an. Moderne CPUs erreichen ihre Performance durch gute Branch-Prediction und die Minimierung von Cache-Misses.
Max G. schrieb: > Gegenstück von ST ist der STM32F730, der "nur" mit 216 MHz läuft, dafür > aber internen Flash hat. Preislich schenken sich die beiden Typen nicht > viel. Bei kleineren Stückzahlen ist der Stückpreis eher unwichtig. Meine Alternative wäre der STM32H750, der mit 480 MHz und float/double-Hardware, viel RAM und schneller Peripherie punkten kann.
M. H. schrieb: > Allein von der Anbindung des Speichers kann man kaum die reale > Performance abschätzen. Das hängt sehr stark mit der internen > Architektur/Chaches zusammen. Der PC-Vergleich ist nicht gut, weil ein DDR4-Interface mit 3 Cache-Ebenen einfach kein Vergleich mit einer QSPI ist. Das eine ist ein auf Durchsatz optimiertes Speicherinterface, das andere ein grottenlahmes serielles Flash. Das einen dicken 500MHz Prozessorkern speisen soll. Ein fast identischer i.MX6 UL hat immerhin ein 16-Bit DDR3-Interface und 192k Cache. Für den gleichen Prozessorkern. Das DDR3-Interface dürfte um mehrere Größenordnungen leistungsfähiger sein als die QSPI. Einen Linux-Kernel startest du auf dem Ding niemals, und als µC kämpfst du mit dem SFLASH, speziell bei größeren Anwendungen. Da wird es schon Anwendungen geben, aber Code über SFLASH exekutieren ist ein ernsthaftes Hindernis.
Also ich finde solche Prozessoren durchaus interessant. Mit 128kb Arbeitspeicher kann man eine Menge machen. Und wenn der Preis stimmt wieso nicht. Wenn einem das Teil zu schnell ist kann man ihn ja auch mit weniger Mhz laufen lassen. Allerdings sollte man bedenken das man bei solchen Prozessoren auch alle gaengigen Schnittstellen einfach in Software machen kann und dann auf einem beliebigen Portpin zur Verfuegung hat. Nachteilig bei solchen konzepten ist allerdings das man ein externen QSPI wohl nicht gegen auslesen schuetzen kann. Ausserdem brauchen sie nach dem einschalten eine gewisse Zeit bis ihr Programm reingezogen haben. Olaf
Bernd schrieb: > Genau das ist das Problem an diesen Boliden: > Je mehr nackte unintelligente Performance desto dünner die sinnvolle > Anwendung-Auswahl. Weil die Leistung schlicht überdimensioniert ist. > Weil sie schlicht zuviel Strom schluckt. Jeder 8Bitter bietet hier einen > meilenweit besseres Verhältnis von Aufwand zu Nutzen. Selbst zu den > genannten Spezial-Anwendungen gibts schon längst zahlreiche fertige > Lösungen. Spart Euch das Rumgeprotze. Einfach nur dumm und primitiv. Selten so einen Blödsinn gelesen. Die wenigsten Mikrocontroller Anwwendungen brauchen viel Flash Speicher. Und es sagt ja keiner dass du den mit 500 MHz takten musst. Selbst NXP sagt, dass die 500 MHz ein "Turbo" Mode sind. Der Stromverbrauch ist deutlich geringer als der von uC's mit 50 - 200 MHz, dank deutlich kleinerer Strukturbreiten! Der Cache ist mit 16 kByte Instruction und 8 kByte Daten schon grösser als der gesammte RAM von so manchem 8 Bit Microcontroller. Peripherie ist dieselbe wie bei den schwächeren uC's, sogar USB High Speed mit PHY ist dabei.
jemand schrieb: > Ein fast identischer i.MX6 UL hat immerhin ein 16-Bit DDR3-Interface und > 192k Cache. Für den gleichen Prozessorkern. Gleicher Prozessorkern? Das eine ist ein Cortex A, das andere ein M. Olaf schrieb: > Nachteilig bei solchen konzepten ist allerdings das man ein externen > QSPI wohl nicht gegen auslesen schuetzen kann. Du kannst beim o.g. Chip den Flash-Inhalt verschlüsseln und On-the-fly entschlüsseln. Der Schlüssel dafür liegt sicher im Chip.
Dominik S. schrieb: > Perlen vor Säue - 500MHz für Bastler schrieb: >> Dem Hersteller interessiert es lediglich, ob es Käufer gibt, "Anwender" >> oder gar sinnvolle Anwendungen sind eher nachrangig. > > Soweit schon richtig... Du glaubst doch aber nicht, dass die paar > Bastler die sich so einen Chip kaufen ausreichen, um Entwicklung und > Herstellung zu bezahlen? In Bezug auf RasPi sind paar Bastler fette Millionen, und oft ist das, was als neue Entwicklung angepriesen wird in Echt x Jahre alt und wird, da die Entwicklung und Fertigung längst durch das damalige Serienprodukt (bspw. LocCost China Handy-Tröte) abgeschrieben sind, einfach auf den "alten" fertigungslinien weiterproduziert und verramscht. Hauptsache die Auslastung stimmt.
Das erinnert mich an ein Design aus den 90-ern. Damals sollte ein schneller DS80C320 mit 32MHz eingesetzt werden, aber es gab keine ausreichend schnelle Flash. Es gab aber schnelle Cache SRAMs, also einen Coolrunner CPLD von Philips genommen, der eine kleine Bootroutine beinhaltete, die den SRAM von einem 24C512 geladen hat und dann den SRAM als Code gemappt hat. Die restlichen 64kB des SRAM wurden als Datenspeicher gemappt. Das Ganze wurde über 20 Jahre produziert und eingesetzt. Es wurden dabei mehrere Anpassungen nötig. Der Coolrunner mußte durch einen Xilinx ersetzt werden, der wiederum einen extra 3,3V Regler benötigte. Der Xilinx brauchte auch die doppelte Anzahl an Macrozellen, da er kein Produktterm-Sharing mehr konnte und auch der Xilinx-Fitter schlechter war.
Aus dem NXP forum The performance of the RT1050 with the Adesto EcoXiP is 1912 coremark at 5% miss rate. That's roughly 66% of the max performance of this CPU when running from on-chip memory (3000 Coremark). The 1912 is equivalent to what you will get out of a 400MHz Coretex M7-based CPU if you can find one. Note that any other external memory would reduce the performance of the CPU relative to what you could get when running from on-chip. die kleinen sind da ähnlich
jemand schrieb: > Exekutieren auf einem QSPI-Flash? > > DAS klingt nach genau der fürchterlichen Krücke, die ich befürchtet > habe. Und ich bezweifle, dass (außer in Spezialanwendungen), der > Prozessor dann eine sinnvolle Performance erreicht. Selbst mit 100MHz > auf dem Bus ist eine QSPI nicht vergleichbar mit einem internen Flash. > Ein µC hat bei 200MHz zwar auch kein 1-Waitstate-Flash, aber das Flash > hängt immerhin mit voller 32-Bit Busbreite am Cache, und muss nicht über > ein serielles Interface. Das ist eine ganz andere Kategorie, was > Zugriffszeiten und Übertragugnsrate angeht. > > Natürlich gibt es immer Anwendungen, bei denen das trotzdem sehr gut > passt, sonst würde niemand den Chip produzieren. > Aber "general Purpose" ist das nicht. Bei den STM32F4 kann der Zugriff auf einen QSPI-Flash schneller sein als auf den internen Flash. Der ist nämlich grottenlahm bei ST im Gegensatz zu z.B. Renesas. Daher stimmt die Aussage pauschal so nicht.
Es geht darum, das Volk am arbeiten halten. Da kann man jetzt wieder viele Entwickler damit beschäftigen, Algorithmen zu entwickeln, die mindestens 500 MHz brauchen. Anwendungsgebiete wären z.B. IoT im Wald, um zu überwachen, ob die Hunde angeleint sind, die Menschen die Wege nicht verlassen, ob jemand nackig rumläuft oder den Klimawandel.
Hallo, neben QSPI wird auch HyperFlash/RAM unterstützt, womit eine Performance erreichbar ist, die der von integriertem Flash sehr nahe kommt. Wesentlicher Vorteil dieser Chip-Familie ist dass damit eine breite Palette von Anwendungen abgedeckt werden kann ohne unterschiedliche Prozessoren einsetzen zu müssen. Der Core und die peripherals sind immer die gleichen. Weiterer Vorteil: oft wird ein Chip mit nur wenigen Ports/kleiner Bauform aber sehr viel Flash/RAM benötigt. Das lässt sich mit dem i.MXRT einfach skalieren. Gruss Gerhard
Bernd schrieb: > Max G. schrieb: >> Außer BLDC-Steuerung und Spracherkennung fällt mir aber >> aktuell nichts ein. > > Genau das ist das Problem an diesen Boliden: Nur weil jemand keine Anwendung hat sind die Dinger über? Linux und VoIP mit 200MHz ist arg grenzwertig, da ist man froh wenn es dann moderneres mit 500MHz bei gleichen Kosten gibt.
der allseits beliebte esp32 hat seinen code auch in einem externen SPI Flash gespeichert und füttert damit 2x 240 MHz CPUs. Auf den Wrover Boards hat er dann auch noch sein PSRAM am selben SPI Bus und trotzdem scheint der Cache diesen Flaschenhals auszugleichen.
drm schrieb: > der allseits beliebte esp32 hat seinen code auch in einem externen > SPI > Flash gespeichert und füttert damit 2x 240 MHz CPUs. Auf den Wrover > Boards hat er dann auch noch sein PSRAM am selben SPI Bus und trotzdem > scheint der Cache diesen Flaschenhals auszugleichen. z.B. Hier hinterfragt das scheinbar keiner NichtWichtig schrieb: > Linux und VoIP mit 200MHz ist arg grenzwertig, da ist man froh wenn es > dann moderneres mit 500MHz bei gleichen Kosten gibt. Linux geht auf den STM/NXP RT dingern nicht wirklich... Gerhard schrieb: > Wesentlicher Vorteil dieser Chip-Familie ist dass damit eine breite > Palette von Anwendungen abgedeckt werden kann ohne unterschiedliche > Prozessoren einsetzen zu müssen. Der Core und die peripherals sind immer > die gleichen. > Weiterer Vorteil: oft wird ein Chip mit nur wenigen Ports/kleiner > Bauform aber sehr viel Flash/RAM benötigt. Das lässt sich mit dem i.MXRT > einfach skalieren. das ist der wichtigste Punkt Siehe STM Warum gibt es denn 700 verschiedene MCU's es gibt einen Kern , hier und da verchsiedene Peripherie und noch 2-6 varianten in RAM und FLash größe ist der Flash extern hat man nur einen bruchteil der varianten Grenzt man die RAM größe auf einen Wert ein reduziert man nochmal so gibts halt RT600 M33 quasi der kleine RT1010 M7 viel rechenpower aber wenig perpiherie RT1020 M7 wie RT1010 , etwas mehr ram und peripherie RT1050 M7 wie RT1020 nur mehr RT1060 M7 wie RT1050 nur mehr Ja auch einen RT1064 mit integrierten 4MB Flash. Hier sitzt ein QSPI Flash mit im Package. Manche sind sogar pinkompatibel. Damit soll ja auch kein LED blinky oder so ersetzt werden. Das sind µC für IoT .. ggf wo Daten verschlüsselt übertragen werden. Gibt sicher genug Anwendungen für die dinger.
hfhd schrieb: > drm schrieb: >> der allseits beliebte esp32 hat seinen code auch in einem externen >> SPI >> Flash gespeichert und füttert damit 2x 240 MHz CPUs. Auf den Wrover >> Boards hat er dann auch noch sein PSRAM am selben SPI Bus und trotzdem >> scheint der Cache diesen Flaschenhals auszugleichen. > > z.B. > Hier hinterfragt das scheinbar keiner > > NichtWichtig schrieb: >> Linux und VoIP mit 200MHz ist arg grenzwertig, da ist man froh wenn es >> dann moderneres mit 500MHz bei gleichen Kosten gibt. > > Linux geht auf den STM/NXP RT dingern nicht wirklich... Was aber weniger das Problem der 200 MHz Takt als das von Linux ist. IMHO ist es ziemlicher Blödsinn ein latenzkritische Anwendung wie Telefonie über ein packetorientiertes Netzwerk mit einem nichtechtzeitfähigen Betriebssystem auf ein embeddes System zu verheiraten. Ein DSP mit dedizierten Wardwareblöcken ist die bessere wahl, das geht dann auch mit deutlich weniger Takt.
Perlen vor Säue - 500MHz für Bastler schrieb: > Was aber weniger das Problem der 200 MHz Takt als das von Linux ist. > IMHO ist es ziemlicher Blödsinn ein latenzkritische Anwendung wie > Telefonie über ein packetorientiertes Netzwerk mit einem > nichtechtzeitfähigen Betriebssystem auf ein embeddes System zu > verheiraten. Ein DSP mit dedizierten Wardwareblöcken ist die bessere > wahl, das geht dann auch mit deutlich weniger Takt. Das wird allerdings seit Jahren schon so gemacht und steckt auch in mehreren gut etablierten Produkten. Ist allerdings kein Linux, sondern ein uClinux. Telefonie gilt in dem Bereich jetzt nicht wirklich als latenzkritisch, geschweige Echtzeit. Siehe auch div. Asterisk-Anwendungen. Und wenn man garantiert unter <150us antworten müsste, gibt's Xenomai.
Argh, warum gibt es das Referenzmanual nur gegen Registrierung bei NXP! Kann jemand sagen, ob die GPT Timer mit 500 MHz betrieben werden koennen?
8–6 CLKSRC Clock Source select. The CLKSRC bits select which clock will go to the prescaler (and subsequently be used to run the GPT counter). • The CLKSRC bit field value should only be changed after disabling the GPT by clearing the EN bit in this register (GPT_CR). • A software reset does not affect the CLKSRC bit. 000 No clock 001 Peripheral Clock (ipg_clk) 010 High Frequency Reference Clock (ipg_clk_highfreq) 011 External Clock 100 Low Frequency Reference Clock (ipg_clk_32k) 101 Crystal oscillator as Reference Clock (ipg_clk_24M)
Uwe B. schrieb: > Kann jemand sagen, ob die GPT Timer mit 500 MHz betrieben werden > koennen? Ich hatte die Tage im Datenblatt gelesen und bin auf 60 MHz gekommen. Wer bietet mehr?
unter GPT: gpt1_ipg_clk perclk_clk_root gpt1_ipg_clk_24m xtal_clkout gpt1_ipg_clk_32k ckil_sync_clk_root gpt1_ipg_clk_highfreq perclk_clk_root gpt1_ipg_clk_s perclk_clk_root Clock Root Default Frequency (POR)(MHz) Maximum Frequency (MHz) AHB_CLK_ROOT 12 600 IPG_CLK_ROOT 3 150 PERCLK_CLK_ROOT 6 75 USDHC1_CLK_ROOT 12 198 USDHC2_CLK_ROOT 12 198 SEMC_CLK_ROOT 8 166 CSI_CLK_ROOT 12 80 FLEXSPI_CLK_ROOT 2 332 LPSPI_CLK_ROOT 6 132 TRACE_CLK_ROOT 6 132 SAI1_CLK_ROOT 3 66 SAI2_CLK_ROOT 3 66 SAI3_CLK_ROOT 3 66 LPI2C_CLK_ROOT 24 66 CAN_CLK_ROOT OFF 60 UART_CLK_ROOT 4 80 LCDIF_CLK_ROOT 3 75 SPDIF0_CLK_ROOT 1.5 66 FLEXIO1_CLK_ROOT 1.5 120 FLEXIO2_CLK_ROOT 1.5 120
hfhd schrieb: > 010 High Frequency Reference Clock (ipg_clk_highfreq) Hmm ... ist die High Frequency Reference Clock der CPU Takt oder liegt sie drunter. Ich habe hier ein Device anderer Firma, da hat eine sogenannte High Frequency Reference Clock Konfigurationsabhängig max. 200 MHz (CPU Takt sind max. 600 MHz) und die bekommt man nicht nach draussen ... ich denke aus gutem Grund ;).
Gibt es uCs mit Timern die mit 500+ MHz getaktet sind? STM32H7 kann "nur" 240 MHz. Und die STM32 HRTimer haben viele Einschraenkungen.
hfhd schrieb: > gpt1_ipg_clk_highfreq perclk_clk_root das steht im Datenblatt Wird also eher vom perclk_clk_root( max 75Mhz ) abgeleitet.
Vielleicht sollte man mal aktualisieren wenn man unterbricht beim schreiben. Ich gehe mich jetzt für den late post schämend essen Uwe B. schrieb: > Gibt es uCs mit Timern die mit 500+ MHz getaktet sind? Wozu werden die 500 MHz+ gebraucht? FPGA!?, aber die Antwort kennst du ja bestimmt bereits. Schöne Grüße nach Science City
UndNun schrieb: ... > Wozu werden die 500 MHz+ gebraucht? > FPGA!?, aber die Antwort kennst du ja bestimmt bereits. Frequenzzaehler, Pulser ohne FPGA...
Uwe B. schrieb: > Frequenzzaehler, Jain. Bei den Frequenzen kann man auch Vorteiler verwenden, sofern damit die Ereignisse gezählt werden sollten. Als Zeitreferenz bei reziproker Messung ist es fast egal, ob nun 240 MHz (mit H7xx) oder 500 MHz genommen werden können. 2 oder 4 ns Auflösung sind wenig gegenüber einer Lösung mit TDC, die besser 0,1 ns auflösen kann. Allerdings sind die genannten 75 MHz der RT-Teile schon recht bescheiden.
Uwe B. schrieb: > Gibt es uCs mit Timern die mit 500+ MHz getaktet sind? STM32H7 kann > "nur" 240 MHz. Und die STM32 HRTimer haben viele Einschraenkungen. Ich glaube fast das nicht. Maximum das ich so kenne liegt typisch bei 100 MHz. Da sticht der STM schon heraus. Meist sind es ja 50-80 MHz bei sehr aktuellen CPUfreq >= 200-800 MHz. Schnellste was ich sonst noch ausserhalb der STM kenne sind 100 MHz und das dann als Systemtimer ... immerhin compare und PWM-Pin. Natürlich alles unter Ausschluss von FPGAs/SOCs z.B. Ultrascale+ Familie. m.n. schrieb: > Allerdings sind die genannten 75 MHz der RT-Teile schon recht > bescheiden. Kennst du etwas anderes im Bereich >= 200 MHz?
UndNun schrieb: > Kennst du etwas anderes im Bereich >= 200 MHz? Da mußt Du konkreter fragen, was "etwas anderes" ist.
Damit meine ich Mikrocontroller, welche einen Timer mit f_timer >= 200 MHz haben +Compare +PWM Pin. Dein schwach hat in mir die Erwartung erweckt, dass es mehr gibt die "besser" sind als ich dachte. Mir fällt da gerade nichts ausser dem STM32H7 ein. Selbst da hätte ich nicht dran geglaubt ... ich kenne dort die Timer Peripherie beüglich ihrer Clock restriktionen nicht wirklich, obwohl ich damit hier schon etwas gemacht habe (1h einem Kollegen geholfen -> Encoder niedrige kHz keine MHz).
Uwe B. schrieb: > Frequenzzaehler, ach nö. Sowas wird hier ja immer mal heiß diskutiert, ist aber dennoch kein wirkliches Thema für einen Chip aka µC, der seine Eingangssignale taktet. Wo Samples anfallen, gilt eben auch das Abtasttheorem. Was mir hier einfallen würde, wäre ein Teil-SDR. Also HF -> Mischer -> 192kHz ADC -> Software. Für Filter kann man den Hals nicht voll genug kriegen. W.S.
Ja und? Bei 240 Mhz Timertakt kannst Du bis zu 120 Mhz Frequenz messen...
UndNun schrieb: > Damit meine ich Mikrocontroller, welche einen Timer mit f_timer >= 200 > MHz haben +Compare +PWM Pin. Da kenne ich keine schnelleren als H7xx, die auch bei der Frequenz auch noch Capture erlauben. Für PWM gibt es einige, die zwar im GHz Bereich getaktet werden bzw. mit Verzögerungsleitungen arbeiten, aber weder Ereignisse zählen können noch Capture zulassen. Interessant finde ich noch den G071, der mit 64 MHz Takt noch zwei Timer mit 128 MHz bietet, die auch Capture erlauben. Das sollte STM noch bei den H7 einbauen ;-) Uwe B. schrieb: > Bei 240 Mhz Timertakt kannst Du bis zu 120 Mhz Frequenz messen... Das steht im Datenblatt. Probiere mal aus, ob Du es auch schaffst. Ich würde hier max. 100 MHz ansetzen.
Moin, Apropos NXP: Bei deren Website hab' ich ja in Bezug auf Ubersichtlichkeit, etc. eh' schon kaum mehr Ansprueche (OK, Intel ist noch fieser...). Aber wenn ich da in jetzt in die Suchfunktion irgendwas eingeb', kommt immer nur noch: ERROR: Please contact support. Hab' ich da jetzt nur nicht den neuesten, heissesten Browsershice mit javascript++ und HD-HTML in 4kp60, oder geht das anderen auch so? Gruss WK
Moin, soeben mit Firefox probiert. https://www.nxp.com/ Suchbegriff "iMXRT1062" und die Seite war da. Oder du warst zur falschen Zeit am falschen Ort. :-)
udok schrieb: > Fpga um < 2 Dollar / 10k Stück? Sogar bei 1 Stück: https://www.digikey.com/product-detail/en/lattice-semiconductor-corporation/ICE40UL640-CM36AI/220-1959-ND/5129488
Moin, Veit D. schrieb: > Moin, > > soeben mit Firefox probiert. https://www.nxp.com/ > Suchbegriff "iMXRT1062" und die Seite war da. > Oder du warst zur falschen Zeit am falschen Ort. :-) Merci - Oeha! 's ist anscheinend bei mir der uBlock Adblocker... Gruss WK
Uwe B. schrieb: > Bei 240 Mhz Timertakt kannst Du bis zu 120 Mhz Frequenz messen... Ein Zählfrequenzmesser soll ein Meßgerät sein und kein Applausiometer. Deine Denkweise geht davon aus, daß man einen sauberen Rechteck mit 50% duty oder einen Sinus hat - und daß das alled garantiert unterhalb der halben Samplefrequenz liegt. Genau DAS ist jedoch nicht gegeben bei einem Gerät, daß all dieses erst noch durch Messungen herausfinden soll. W.S.
Hallo, falls es jemand interessiert: Unter den Link https://www.nxp.com/docs/en/white-paper/NXPADESTOWP.pdf findet sich ein whitepaper in welchem auf die Performance bei XIP eingegangen wird. Gruss Gerhard
Dergute W. schrieb: > Hab' ich da jetzt nur nicht den neuesten, heissesten Browsershice Scheint so, denn bei mir funktioniert das Suchfeld (Ubuntu, Firefox 70.0, Adblock Plus)
So, nachdem sich all das Gezänk hier inzwischen gelegt hat, hab ich mal eine Frage: Hat hier jemand mit den i.MX RT 1010 oder 1015 selber schon mal was gebaut? Also Schaltung, LP, eigene Firmware, bootbaren Datenblock erzeugen, via Chip den ext. Programmspeicher programmieren? Und würde davon hier mal etwas näheres zum Besten geben? Das Teil stammt ja von Frescale, ich hab mir die Doku dazu heruntergeladen, also Datenblatt, RefManual, AppNotes und zugehörige .zip's. Und beim Lesen dieses Zeugs ist mir mal wieder die Zornesader geplatzt. Die Chips als solche sind sicherlich eine nette Sache, aber ich beiße mich nur sehr ungern durch Dokumentationen von Freescale. Bin derzeit am Überlegen, ob ich trotz dieser Doku mich auf diese Chips einlasse oder nicht. W.S.
Hallo W.S. zu Deinen Fragen: >Hat hier jemand mit den i.MX RT 1010 oder 1015 selber schon mal was >gebaut? Also Schaltung, LP, eigene Firmware, bootbaren Datenblock >erzeugen, via Chip den ext. Programmspeicher programmieren? Und würde >davon hier mal etwas näheres zum Besten geben? Bis jetzt wurden nur diverse Evaluierungen mit Hilfe der EvalBoards durchgeführt. Primär ging es um die Ermittlung der Performance bei Verwendung des FlexSPI Controllers und seriellem Flash (QSPI bzw. HyperFlash). Ergebnis: ohne I- bzw. D-Cache ist die Performance eher bescheiden. Des weiteren wurden EMV-Messungen an den EvalBoards durchgeführt, speziell was die HF-Abstrahlung bei Verwendung des SDRAM-Interfaces und dem HyperFlash betrifft. Ergebnis: keine Überschreitungen bei der HF-Emission. >Das Teil stammt ja von Frescale, ich hab mir die Doku dazu >heruntergeladen, also Datenblatt, RefManual, AppNotes und zugehörige >.zip's. Und beim Lesen dieses Zeugs ist mir mal wieder die Zornesader >geplatzt. Die Doku ist kein Ruhmesblatt! Das Reference-Manual ist eigentlich kaum brauchbar, die Application Notes sind hilfreicher. Anfragen im NXP-Support-Forum werden aber prompt beantwortet. Das MCUXpresso Config Tool ist etwas gewöhnungsbedürftig und langsam aber sehr hilfreich da die Initialisierung des Chips nicht trivial ist. Das MCUXpresso Software Development Kit (SDK) ist brauchbar, die Doku ausreichend und die Beispiele laufen ohne Probleme. Weitere Erfahrungen würden mich auch interessieren. Gruss Gerhard
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.