Hallo Forum, ich liebäugle gerade mit den Cortex-M Mikrocontrollern von NXP, mit denen ich bisher noch nichts zu tun hatte. Generell habe ich was ARMs angeht, nur Oberflächlich rumprogrammiert, d.h. ich habe noch kein Projekt ohne eine Art Framework (wie CubeMX) programmiert. Davor habe ich immer auf AVRs gesetzt; mit denen kenne ich mich inzwischen echt gut aus und habe eine große Codebasis. Erst mal warum ich zu den LPCs tendiere: Ich habe eine Anwendung, die - einerseits die reine Rechenpower der AVRs überschreitet - mehr I/O Funktionen benötigt, ohne die CPU zu belasten (u.a. Stichwort DMA) Da in diesem System vor allem sehr viele Sensoren regelmäßig mehrere hundert mal die Sekunde abgefragt werden müssen (ja, das ist unumgänglich), aber gleichzeitig trotzdem viel gerechnet werden muss, wollte ich ein System aus mehreren Prozessoren verwenden. Z.B: ein Cortex-M4F ist der Hauptprozessor, der so gut wie nur rechnet, und ab und zu noch ein paar Aktoren steuert. Die Sensorwerte bekommt dieser von einem anderen µC, z.B. von einem Cortex-M0. Diese müssten natürlich über ein schnelles Interface miteinander kommunizieren, oder der M0 spielt einen Speicher über den der M4 via memory-mapped I/O zugreift. Aber halt. Da sprangen mir die asymmetrischen Designs von NXP ins Auge: - LPC54102: Cortex-M4F + Cortex-M0+ bis 96MHz (laut Errata, eig sinds 100MHz) - LPC4322: Cortex-M4F + Cortex-M0 bis 204MHz (lange Errata-List -.- ) Momentan tendiere ich zu der LPC54000 Serie, da ich nicht glaube, dass ich mehr als 80MHz wirklich sinnvoll nutzen kann. So nun zu meinen Fragen: 1) Setze ich damit evtl. auf ein "totes Pferd"? Wenn es um ARM-Cortexe geht hört man meist nur von den STM32. Und auch die Informationen hier im Forum sind spärlich und zum Teil nicht mehr aktuell. Was mich auch etwas wundert ist, dass NXP 2 Linien von Cortexen hat, eben die LPCs und dann noh die Kinetis-µCs. Eine davon stammt wahrscheinlich noch aus einer früheren Übernahme einer Konkurrenzfirma. Leben beide weiter? (nicht das wichtigste Kriterium, aber imho auch interessant) Gibt es bessere alternativen mit diesem asymmetrischen Dual-Core System? 2) Wie kann man die LPCs sinnvoll programmieren? Ich würde die µCs gerne mittels Makefile in einer IDE meiner Wahl programmieren, ohne das ich irgendein Plugin oder Ähnliches installieren muss. 2.1) Was für Tools brauche ich? Okay, das ist die einfachere Frage. Es sein ARMs, also brauche ich wohl den arm-none-eabi-gcc mitsamt make etc. 2.2) Was für andere Software brauche ich? Gibt es ein gutes etabliertes Kommandozeilentool für die Programmierung der µCs? Oder geht das alles über SWD und GDB? 2.3) Libraries Ich will zwar den µC "bare-metal" programmieren, ähnlich wie einen AVR, aber die Runtime/Startup-Files/Linkerfiles wären schon hilfreich. Im Prinzip möchte ich mir ein Softwarepaket ähnlich WinAVR zusammenschustern, bei dem ich wirklich mit int main(){/*...*/} loslegen kann, ohne mir jedes mal ein Linker-Script anlegen zu müssen und einen neuen Startup-Code zu schreiben. Ich bin mir nicht sicher, ob die CMSIS das richtig dafür ist. Und kann ich diese auf der Homepage von NXP irgendwo herunterladen? Ich finde immer nur deren IDE-Komplettpaket, das ich aber eigentlich nicht will/brauche. Wenn es geht kann ich mir natürlich auch daraus das benötigte extrahieren. Es wäre nett, wenn jemand, der Ahnung von ARMs allgemein und LPCs im speziellen hat, mir ein paar antworten auf diese Anfängerfragen zu geben. Mit freundlichen Grüßen und Danke im voraus, N.G.
Ich möchte hier nur einmal den Einwand bringen, dass ein Multicore Design erheblich grösseren Aufwand bedeutet, als den Code für einen Core zu optimieren. N. G. schrieb: > Da in diesem System vor allem sehr viele Sensoren regelmäßig mehrere > hundert mal die Sekunde abgefragt werden müssen (ja, das ist > unumgänglich), aber gleichzeitig trotzdem viel gerechnet werden muss, > wollte ich ein System aus mehreren Prozessoren verwenden. Wenn mehrere 100/s < 1kHz, würde ich behaupten da reicht auch ein core aus. Besonders wenn du noch DMA einsetzen möchtest, bleibt viel Zeit für den Prozessor. N. G. schrieb: > 1) Setze ich damit evtl. auf ein "totes Pferd"? Im Deutschsprachigen Hobbyraum sind AVR und STM32 nunmal beliebt. Der Umkehrschluss, dass andere Controller auf dem absteigenden Ast sind, ist falsch. Ja die Kinetisreihe stammt noch von Freescale, welche von NXP aufgekauft wurde. Was mit diesen beiden Reihen passiert ist unklar, ich würde aber davon ausgehen, dass bereits releaste Chips auch erhältlich bleiben. Von Freescale gibt es auch Chipdesigns mit einem Cortex-A und einem Cortex-M Kern, wenn denn die Leistung wirklich erforderlich ist. Ich würde mir anschauen, ob nicht ein Core mit hoher Taktrate (z.B. Cortex-M4F mit ~200MHz) ausreichend ist. Dieser kann ja auch von NXP sein, wenn du den Code aufteilen musst, bleibt vermutlich ein grosser Teil des Workflows erhalten.
Hallo Operator S, danke für deine Antwort. Operator S. schrieb: > Ich möchte hier nur einmal den Einwand bringen, dass ein Multicore > Design erheblich grösseren Aufwand bedeutet, als den Code für einen Core > zu optimieren. Das ist schon richtig, aber auch auf meinem bisherigen AVR-System habe ich schon mit mehreren Chips gearbeitet. Warum ich deinen Einwand (etwas) Entkräftigen kann steht unten. Operator S. schrieb: > N. G. schrieb: >> Da in diesem System vor allem sehr viele Sensoren regelmäßig mehrere >> hundert mal die Sekunde abgefragt werden müssen (ja, das ist >> unumgänglich), aber gleichzeitig trotzdem viel gerechnet werden muss, >> wollte ich ein System aus mehreren Prozessoren verwenden. > > Wenn mehrere 100/s < 1kHz, würde ich behaupten da reicht auch ein core > aus. Besonders wenn du noch DMA einsetzen möchtest, bleibt viel Zeit für > den Prozessor. Naja, ich komme immer noch aus der AVR-Ecke, mit den Größenordnungen im Kopf die dort herrschen. Nur kurz zu den Sensoren, dass es eben nicht ganz einfach ist: - 48 SPI-ADCs (bzw. weniger ADCs mit der gleichen Channel-Anzahl) - 32 SPI-ADCs für einen anderen Zweck, diese müssen aber wirklich mit mdst 100Hz, besser mehr als 1kHz ausgewertet (nicht nur ausgelesen) werden - 8 weitere ADCs - 7 Ultraschallsensoren - eine Kamera (CMUcam5, ist jetzt nicht so aufwändig, da diese den Großteil der Auswertung übernimmt) - 1 "Maussensor" - und weiterer Kleinkram Problem ist unter anderem, das es imho kaum Controller gibt, die so viele Slave selects haben oder externe Multiplexer (z.B. 74HC4051 o.Ä.) unterstützen, damit fällt DMA meines wissens ja flach. Als Daisy-Chain will ich es nicht betreiben, weil bei einer so langen Kette ist ein Ausfall nicht unwahrscheinlich und dann käme gar kein Wert mehr zurück. Ich möchte mir gar nicht vorstellen, dann den einen nicht-funktionieren Chip zu suchen... Operator S. schrieb: > N. G. schrieb: >> 1) Setze ich damit evtl. auf ein "totes Pferd"? > > Im Deutschsprachigen Hobbyraum sind AVR und STM32 nunmal beliebt. Der > Umkehrschluss, dass andere Controller auf dem absteigenden Ast sind, ist > falsch. Das wollte ich hören :D Operator S. schrieb: > Ja die Kinetisreihe stammt noch von Freescale, welche von NXP aufgekauft > wurde. Was mit diesen beiden Reihen passiert ist unklar, ich würde aber > davon ausgehen, dass bereits releaste Chips auch erhältlich bleiben. > Von Freescale gibt es auch Chipdesigns mit einem Cortex-A und einem > Cortex-M Kern, wenn denn die Leistung wirklich erforderlich ist. Ich gehe davon aus, dass die Chips länger als 3 Jahre existieren, sonst lohnt sich das für den Hersteller ja auch gar nicht. Mehr brauche ich vorerst eh nicht. Ich finde so was für spätere (berufliche) Entwicklungen aber immer gut zu wissen. Operator S. schrieb: > Ich würde mir anschauen, ob nicht ein Core mit hoher Taktrate (z.B. > Cortex-M4F mit ~200MHz) ausreichend ist. > Dieser kann ja auch von NXP sein, wenn du den Code aufteilen musst, > bleibt vermutlich ein grosser Teil des Workflows erhalten. NXP muss nicht sein, Atmel oder so käme auch in Frage, nur mit den STM32 kann ich mich wirklich nicht anfreunden (weiß auch nicht genau wieso...). Der Vorteil dieser LPC54k oder LPC4300 Reihen ist halt, dass man auf jeden Fall einen kompletten Cortex-M4F hat, der auch schnell (>100MHz) taktet. Wenn man sich selbst ein Multiprozessor-System ausdenkt (also mit mehreren Chips), dann ist man auf dieses festgenagelt, sobald das PCB steht. Da liegt meiner Meinung nach der große Vorteil des Dual-Core-on-a-single-Die-Designs: Wenn ich es brauche habe ich nochmal einen Prozessor, der dem anderen die Arbeit abnehmen kann, vor allem aber können beide auf die selben Resourcen zugreifen und ein Mailbox-System ist schon auf dem Chip integriert. Natürlich ist es ein gewaltiger Aufwand, das alles so hinzukriegen, dass die Cores sich nicht gegenseitig behindern, wenn sie auf die selbe Hardware zugreifen wollen, dort muss man halt im Vorfeld in der Planungspanne viel Zeit reinstecken (z.B. ein Prozessor hat eine eigenen SRAM-Block, nur ein Prozessor läuft aus dem Flash, nur einer greift auf Peripherie zu, etc.). Die interessanteren Fragen nach den Tools konntest du mir leider nicht beantworten :( Aber dein Einwand war auf jeden Fall berechtigt! N.G.
N. G. schrieb: > Es wäre nett, wenn.. Kein Problem. Ich selbst arbeite mit dem Keil, diese Toolchain finde ich deutlich besser als den GCC. Aber das ist auch ne Budget-Frage. Wer den Keil nicht bezahlen kann, ist notgedrungen auf GCC angewiesen, denn IAR ist auch teuer. Dein Startupfile solltest du dir selbst verfassen und dort mehr Komfort einbauen als bloß auf alles mit B . zu reagieren und und die passenden Sektionsauswahl gleich mit erledigen, daß der Kram an die erste Stelle kommt. Sowas wie Linkerscripte brauchst du bloß beim GCC - und das nur dann, wenn du mit den Sektionen nicht zurecht kommst. Der GCC-Linker hat sowas wie Default-Linkerscripte eingebaut, da muß man sich speziell beim Startupcode bloß drauf einstellen, dann kannst du den GCC auch ohne solche Scripte (und auch ohne Make) verwenden. Ansonsten guck dir die LPC-Chips von NXP genauer an, denn soweit ich die kenne, haben die alle einen mehr oder weniger komfortablen Bootlader fest eingebaut. Das ist nett und funktioniert besser als bei ST. Schau dir mal das kostenlose "FlashMagic"-Programmiertool an und schau dir vergleicheshalber das an, was ST zum selben Thema so liefert. OK, ich hab neulich selber ein Programmchen für die STM32 geschrieben, aber sowas wird von den allermeisten ignoriert, weil sie vor allem debuggen wollen und deshalb sowas wie J-Link-Edu oder J-Link-Chinaclone oder ST-Link sich besorgen und dann das Programmieren per Debugger und per SWD machen. Der Grund, weswegen hier so viel Traffic um die STM32 gemacht wird, besteht darin, daß ST seit einigen Jahren billige Evalboards in Massen unter die Leute schmeißt. Das schafft gerade bei jungen Leuten ne Menge Anreiz, damit herumzuspielen - und da die allermeisten davon nur wenig Ahnung haben und eher dazu tendieren, in Foren Fragen zu stellen, anstatt sich die Doku reinzuziehen, gibt es eben mehr Traffic über STM32. Wenn man mal die diversen LPC mit den STM32 vergleicht, dann fällt auf, daß die LPC eigentlich immer ein paar Jahre früher kamen und mittlerweile ausgereifter sind und daß ST immer nur nachgezogen hat. Bei den technischen Daten sollte man ganz vorsichtig das jeweilige RefMan zu Rate ziehen, denn von manchem wie z.B. den Taktfrequenzen kann man sich beirren lassen. Die Cortexe dieser Klasse hier (also M..) haben alle keinen Cache und wenn man bei 180 MHz Coreclock dann 6 oder 8 Wait-Takte braucht, relativiert sich da einiges. W.S.
W.S. schrieb: > Die Cortexe dieser Klasse hier (also M..) haben alle > keinen Cache und wenn man bei 180 MHz Coreclock dann 6 oder 8 Wait-Takte > braucht, relativiert sich da einiges. Bei ST hat man keinen richtigen Cache wie auf dem PC, aber den ART, der effektiv bei 168MHz mit 0 waitstates auskommt: "To release the processor full 210 DMIPS performance at this frequency, the accelerator implements an instruction prefetch queue and branch cache, which increases program execution speed from the 128-bit Flash memory. Based on CoreMark benchmark, the performance achieved thanks to the ART accelerator is equivalent to 0 wait state program execution from Flash memory at a CPU frequency up to 168 MHz." (en.DM00037051, Kapitel 2.2.2, Seite 19) data cache, instruction cache und prefetcher sind allerdings ab Reset nicht enabled, das muß man schon explizit tun. Ist aber im selben Register wie die Waitstate-Einstellung, FLASH_ACR, von daher muß man da ja sowieso ran. Wirklich warten muß man nur bei scattered access. Beispielsweise Lookup-Tabellen, die in Schleifen genutzt werden, sollte man daher in die .data-Sektion legen, wenn's vom RAM her paßt. Im Übrigen hat NXP in Sachen RAM nicht wirklich etwas, das mit STM32F405 gleichziehen kann, also 192kB (plus 4kB Backup-Ram).
N. G. schrieb: > Nur kurz zu den Sensoren, dass es eben nicht ganz einfach ist: > - 48 SPI-ADCs (bzw. weniger ADCs mit der gleichen Channel-Anzahl) > - 32 SPI-ADCs für einen anderen Zweck, diese müssen aber wirklich mit > mdst 100Hz, besser mehr als 1kHz ausgewertet (nicht nur ausgelesen) > werden > - 8 weitere ADCs > - 7 Ultraschallsensoren > - eine Kamera (CMUcam5, ist jetzt nicht so aufwändig, da diese den > Großteil der Auswertung übernimmt) > - 1 "Maussensor" > - und weiterer Kleinkram > > Problem ist unter anderem, das es imho kaum Controller gibt, die so > viele Slave selects haben oder externe Multiplexer (z.B. 74HC4051 o.Ä.) > unterstützen, damit fällt DMA meines wissens ja flach. Für solche Mengen an Sensoren ist ein FPGA eine gern genommene Lösung. FPGAs gibt es mit vielen Pins (wenn Du zB 700 IO-Pins brauchst, gibts auch dafür entsprechend große (teure!!!) FPGAs) und enthalten viele, viele 1000 Logikblöcke. Die arbeiten alle parallel, d.h. Du kannst einen Zustandsautomaten bauen, der alle ADCs parallel ausliest, in eine struct{} packt und diese dann mit hohem Takt zB per I2S/TDM/framed SPI an den Prozessor schickt, während bereits der nächste Abtastzyklus beginnt. Der Prozessor bekommt dann alle Werte mundgerecht geliefert und kann damit arbeiten. Du könntest sogar einen ganzen Prozessor ins FPGA laden, der dann irgendwelche Berechnungen durchführt, oder auch mehrere, je nachdem, wie groß Dein FPGA ist. Viele FPGAs haben auch Multiplizierer/Addierer als fertige Blöcke, so dass Du auch Sachen berechnen kannst. Wird zB für FFTs gerne verwendet. Und immer dran denken: alles arbeitet parallel und gleichzeitig - ist ja Hardware. Das vielleicht mal so als Idee. Und als Anregung zu dem Thema: Hier hat jemand 16 AVRs in ein noch recht kleines FPGA gepackt. Wenn Du davon nur 4 startest, läuft jeder mit 35MHz, schneller als ein echter. https://www.indiegogo.com/projects/arduissimo-multicore-arduino-for-more-arduino-and-raspberry-pi-interfacing#/ fchk
:
Bearbeitet durch User
Hallo W.S., danke für deine Antwort W.S. schrieb: > Ich selbst arbeite mit dem Keil, diese Toolchain finde ich deutlich > besser als den GCC. Aber das ist auch ne Budget-Frage. Wer den Keil > nicht bezahlen kann, ist notgedrungen auf GCC angewiesen, denn IAR ist > auch teuer. Naja, es wird wohl beim GCC bleiben müssen, da das hier kein berufliches Projekt ist, sondern was mehr oder weniger privates. Und da is das Budget nicht so hoch und man spart wo man kann. So schlimm ist der GCC ja auch nicht > Dein Startupfile solltest du dir selbst verfassen und dort mehr Komfort > einbauen als bloß auf alles mit B . zu reagieren und und die passenden > Sektionsauswahl gleich mit erledigen, daß der Kram an die erste Stelle > kommt. Das ist schon mal ein hilfreicher Tipp, danke. Nur habe ich bisher bei den Datenblättern und den User Manuals etwas so klassisches wie das Layout der Exception- und Interrupt-Handler übersehen, das brauche ich ja unter anderem dafür. > Sowas wie Linkerscripte brauchst du bloß beim GCC - und das nur dann, > wenn du mit den Sektionen nicht zurecht kommst. Der GCC-Linker hat sowas > wie Default-Linkerscripte eingebaut, da muß man sich speziell beim > Startupcode bloß drauf einstellen, dann kannst du den GCC auch ohne > solche Scripte (und auch ohne Make) verwenden. Wenn man eine grobe Vorlage hat, dann sollte das schon in den Griff zu bekommen sein. > Ansonsten guck dir die LPC-Chips von NXP genauer an, denn soweit ich die > kenne, haben die alle einen mehr oder weniger komfortablen Bootlader > fest eingebaut. Das ist nett und funktioniert besser als bei ST. Schau > dir mal das kostenlose "FlashMagic"-Programmiertool an und schau dir > vergleicheshalber das an, was ST zum selben Thema so liefert. OK, ich > hab neulich selber ein Programmchen für die STM32 geschrieben, aber > sowas wird von den allermeisten ignoriert, weil sie vor allem debuggen > wollen und deshalb sowas wie J-Link-Edu oder J-Link-Chinaclone oder > ST-Link sich besorgen und dann das Programmieren per Debugger und per > SWD machen. Ja, das stimmt. Im ROM liegen neben ein paar anderen Routinen auch ein oder mehrere Bootloader, die über UART und wenn vorhanden USB funktionieren. (Dein STM32-Flash-Programm haben ich nebenbei gesehen) Es wird aber am Anfang sowieso auf ellenlanges Debuggen rauslaufen, da ist das ISP erst einmal nicht so wichtig. FlashMagic kannte ich bisher noch nicht. > Wenn man mal die diversen LPC mit den STM32 vergleicht, dann fällt auf, > daß die LPC eigentlich immer ein paar Jahre früher kamen und > mittlerweile ausgereifter sind und daß ST immer nur nachgezogen hat. Bei > den technischen Daten sollte man ganz vorsichtig das jeweilige RefMan zu > Rate ziehen, denn von manchem wie z.B. den Taktfrequenzen kann man sich > beirren lassen. Die Cortexe dieser Klasse hier (also M..) haben alle > keinen Cache und wenn man bei 180 MHz Coreclock dann 6 oder 8 Wait-Takte > braucht, relativiert sich da einiges. Ja klar, das/die Datenblätter/refMans/User Manuals muss man immer lesen. Das mit dem Flash ist auch klar, dewegen sollte man ab gewissen Frequenzen schnelle Sachen aus dem RAM ausführen. Nebenbei: Im Datenblatt vom LPC5410x steht zum Flash lapidar: "The LPC5410x supports 512 kB of on-chip flash memory." Mehr nicht... Der Flash dieses Devices kommt aber auch mit einem "flash accelerator", wobei ich nicht weiß was diese genau bringt. In der Tabelle 62 steht aber, dass der Flash bei >85MHz 5 clocks braucht. --- Hallo Nop, danke auch für deine Ergänzung, Nop schrieb: > Im Übrigen hat NXP in Sachen RAM nicht wirklich etwas, das mit STM32F405 > gleichziehen kann, also 192kB (plus 4kB Backup-Ram). Naja, selbst wenn man 64kB Programm im RAM hat sollten 96kB ausreichen ;) Ich war sowieso immer auf der RAM-Sparer Seite. Und bei einem ATmega2560 mit einer riesigen Applikation haben mir 5kB auch gereicht... Sollte also nicht so das Problem darstellen. Nebenbei: Wenn STs ART so perfekt ist, dass man seinen Code immer im Flash ausführen könnte, dann bräuchte man meiner Meinung nach auch niemals fast 200kB RAM. Aber evtl. denke ich nur noch nicht in solchen Größenordnungen... ---- Hallo Frank K., danke auch für deinen Beitrag. Frank K. schrieb: > N. G. schrieb: >> Nur kurz zu den Sensoren, dass es eben nicht ganz einfach ist: >> - 48 SPI-ADCs (bzw. weniger ADCs mit der gleichen Channel-Anzahl) >> - 32 SPI-ADCs für einen anderen Zweck, diese müssen aber wirklich mit >> mdst 100Hz, besser mehr als 1kHz ausgewertet (nicht nur ausgelesen) >> werden >> - 8 weitere ADCs >> - 7 Ultraschallsensoren >> - eine Kamera (CMUcam5, ist jetzt nicht so aufwändig, da diese den >> Großteil der Auswertung übernimmt) >> - 1 "Maussensor" >> - und weiterer Kleinkram >> >> Problem ist unter anderem, das es imho kaum Controller gibt, die so >> viele Slave selects haben oder externe Multiplexer (z.B. 74HC4051 o.Ä.) >> unterstützen, damit fällt DMA meines wissens ja flach. > > Für solche Mengen an Sensoren ist ein FPGA eine gern genommene Lösung. Ja, das ist richtig, nur habe ich mich bisher immer davor gedrückt, auch nur ansatzweise in diese Richtung zu denken. Eigentlich habe ich sogar schon einmal versucht, etwas zu "programmieren", aber da bildet sich bei mir im Kopf immer ein Knoten. Ich komme mit der Art der FPGAs einfach noch nicht zurecht. Vielleicht ergibt sich das ja auch mal. > FPGAs gibt es mit vielen Pins (wenn Du zB 700 IO-Pins brauchst, gibts > auch dafür entsprechend große (teure!!!) FPGAs) und enthalten viele, > viele 1000 Logikblöcke. Arg, ich versuche immer bei Chips zu bleiben, die wenigstens unter 150 Pins habe und notfalls noch von Hand zu löten sind. Was man von BGA ja nicht gerade sagen kann. > Die arbeiten alle parallel, d.h. Du kannst einen > Zustandsautomaten bauen, der alle ADCs parallel ausliest, in eine > struct{} packt und diese dann mit hohem Takt zB per I2S/TDM/framed SPI > an den Prozessor schickt, während bereits der nächste Abtastzyklus > beginnt. Der Prozessor bekommt dann alle Werte mundgerecht geliefert und > kann damit arbeiten. Das wäre natürlich perfekt. Aber den Weg dahin stelle ich mir sehr Steinig vor... > Du könntest sogar einen ganzen Prozessor ins FPGA laden, der dann > irgendwelche Berechnungen durchführt, oder auch mehrere, je nachdem, wie > groß Dein FPGA ist. Viele FPGAs haben auch Multiplizierer/Addierer als > fertige Blöcke, so dass Du auch Sachen berechnen kannst. Wird zB für > FFTs gerne verwendet. Und immer dran denken: alles arbeitet parallel und > gleichzeitig - ist ja Hardware. Ja wenn ich so wetwas machen würde, dann würde es auf so etwas raus laufen. Aber ist ja auch nicht der Sinn von einem solchen Teil. > Das vielleicht mal so als Idee. Und als Anregung zu dem Thema: Hier hat > jemand 16 AVRs in ein noch recht kleines FPGA gepackt. Wenn Du davon nur > 4 startest, läuft jeder mit 35MHz, schneller als ein echter. > https://www.indiegogo.com/projects/arduissimo-multicore-arduino-for-more-arduino-and-raspberry-pi-interfacing#/ Respekt, schön das die AVRs sogar so schnell sind. Aber im allgemeinen finde ich FPGAs doch sehr viel aufwändiger als einen Prozessor: sie sind meistens größer, brauchen eine ganz andere Stromversorgung, tonnenweise Abblock-Kondensatoren, etc. Dazu brauchen sie evtl. auch noch ein externes RAM, falls das interne Block RAM nicht reicht und sowieso einen externen Konfigurationsspeicher. Da ist halt leider nichts mit: mal schnell VCC und GND anschließen und direkt das Programm starten können... Wenn ich Erfahrung mit FPGAs hätte, dann käme diese Lösung evtl. in Frage; aber so als Anfangsprojekt finde ich es schon Mutig. Schließlich ist dann schnell viel Geld im Eimer, wenn es nicht oder nicht rechtzeitig funktioniert. Aber danke für deine Anregung. Generell danke für eure Antworten
N. G. schrieb: > Nebenbei: Wenn STs ART so perfekt ist, dass man seinen Code immer im > Flash ausführen könnte, dann bräuchte man meiner Meinung nach auch > niemals fast 200kB RAM. Code aus dem RAM ausführen ist bei ST sogar oft genug langsamer, als wenn man es aus dem Flash laufen läßt. Erstens, weil der ART den RAM-Vorsprung ohnehin stark wegschmelzen läßt, und zweitens, weil man dann den Bus flutet. Plus daß ich bei NXP 5 Waitstates für 85MHz schon arg langsam finde. Bei ST schafft das Flash bis 30MHz ohne Waitstates, darüber ein Waitstate pro 30MHz. Mithin brauchen 168MHz dann nur 5 Waitstates, jedenfalls bei voller Versorgungsspannung. > Aber evtl. denke ich nur noch nicht in solchen > Größenordnungen... Kommt halt auch drauf an, was man damit machen will. Beispielsweise die aktuellen Schachcomputer von Millenium, die Chess Genius, nutzen ja einen Cortex M4. Für die Hashtabellen kann man gar nicht genug Speicher haben. Extern angebundener Speicher ist natürlich möglich, aber um einen Faktor 8 langsamer als interner. Klarer Nachteil bei ST war und ist die rottige Software. Deren Standard Peripheral Library kann man genauso vergessen wie deren Nachfolger (Hardware Abstraction Layer). Das sind schlecht zusammengestoppelte Dinger, die nichts abstrahieren, sondern eher als obfuscation layer dienen. Kann man als Template mal reingucken und dann nach Datenblatt selber programmieren. Vielleicht ist bei NXP die Espresso-Umgebung ja tauglicher. Das Interrupt-Layout ist übrigens denkbar einfach. Am Start des Flashes liegt erstmal der Pointer zum Stack, danach der Reset-Handler, danach die wichtigen Exceptions, danach die einzelnen Interrupts. Findet man bei ST in DM00031020, Tabelle 61 auf Seite 374. Wird bei NXP sicherlich ähnliche Doku geben. Was ich echt mau finde, ist das leider weit verbreitete Speicherlayout, bei dem die Leute ihren Stack ganz nach oben ins RAM linken, so daß er nach unten auf den Heap (sofern genutzt, sollte man eh nicht machen) und die globalen Variablen zuwächst. Auch ST macht das in ihren GCC-Linkerscripts so. Richtig legt man den Stack ganz nach unten ins RAM, unterhalb der globalen Variablen. Ein Stack-Overflow äußert sich dann in einem klaren Absturz, den man in einem Handler abfangen kann (ist aber etwas tricky). Wenigstens weiß man dann, was für ein Problem man hat, anstatt das System in einem undefinierten Zustand mit diffusen Problem weiterlaufen zu lassen.
Ich habe gerade ein Projekt mit dem LPC11U68 hier (Cortex M0). Ich habe auch schon TI-Arms gehabt. Letztendlich ist es egal, welcher Hersteller oder welche Architektur (mein Code läuft teilweise auch auf Mips), denn wenn man in C bleibt, dann ist das daraunter fast egal. Zu den Fragen: 1: Solange NXP fertigt, sollte das kein totes Pferd sein. Dokus und Compiler sind alle Vorhanden. 2: Ich habe die IDE unter Windows getestet. Bin dann aber zu Makefiles und GCC unter Linux gewechselt (mag ich lieber). Beides ist möglich. 2.1 Ich nehme arm-none-eabi-c++, mit den weiteren Tools des GCCs. 2.2 Mein NXP stellt sein Flash als USB-Massenspeicherdevice zur Verfügung. Ich kopiere per USB ein .bin-File drauf und boote neu. 2.3 Ich mache auch Bare Metal, benutze aber auch die eingebauten GCC Libraries wie printf. Den Startup-Code habe ich aus dem NXP-Devstudio übernommen. Im Dev-Studio kann man sich die Kommandos anzeigen lassen, und die entsprechend in sein eigenes Makefile übernehmen.
N. G. schrieb: >> FPGAs gibt es mit vielen Pins (wenn Du zB 700 IO-Pins brauchst, gibts >> auch dafür entsprechend große (teure!!!) FPGAs) und enthalten viele, >> viele 1000 Logikblöcke. > > Arg, ich versuche immer bei Chips zu bleiben, die wenigstens unter 150 > Pins habe und notfalls noch von Hand zu löten sind. Was man von BGA ja > nicht gerade sagen kann. Es gibt auch kleine, vor allem von Lattice. zB.: http://hackaday.com/2016/07/11/stm32-and-fpgas-in-a-tiny-package/ und GANZ kleine. http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/ Für bestimme Lattice-FPGAs gibts sogar Open Source Tools. >> Die arbeiten alle parallel, d.h. Du kannst einen >> Zustandsautomaten bauen, der alle ADCs parallel ausliest, in eine >> struct{} packt und diese dann mit hohem Takt zB per I2S/TDM/framed SPI >> an den Prozessor schickt, während bereits der nächste Abtastzyklus >> beginnt. Der Prozessor bekommt dann alle Werte mundgerecht geliefert und >> kann damit arbeiten. > > Das wäre natürlich perfekt. Aber den Weg dahin stelle ich mir sehr > Steinig vor... Alles Übung. Fang erstmal mit einem Adressdecoder an, das ist einfach. > Aber im allgemeinen finde ich FPGAs doch sehr viel aufwändiger als einen > Prozessor: sie sind meistens größer, brauchen eine ganz andere > Stromversorgung, tonnenweise Abblock-Kondensatoren, etc. Dazu brauchen > sie evtl. auch noch ein externes RAM, falls das interne Block RAM nicht > reicht und sowieso einen externen Konfigurationsspeicher. Da ist halt > leider nichts mit: mal schnell VCC und GND anschließen und direkt das > Programm starten können... Kommt halt aufs FPGA an, es gibt solche und solche. Und wenn da eh ein extra Prozessor dabei ist, kann der das FPGA laden. fchk
Hallo zusammen, leider hatte ich in den letzen Tagen nicht viel Zeit, deswegen kommt erst jetzt die Antwort. Nop schrieb: > N. G. schrieb: > >> Nebenbei: Wenn STs ART so perfekt ist, dass man seinen Code immer im >> Flash ausführen könnte, dann bräuchte man meiner Meinung nach auch >> niemals fast 200kB RAM. > > Code aus dem RAM ausführen ist bei ST sogar oft genug langsamer, als > wenn man es aus dem Flash laufen läßt. Erstens, weil der ART den > RAM-Vorsprung ohnehin stark wegschmelzen läßt, und zweitens, weil man > dann den Bus flutet. > > Plus daß ich bei NXP 5 Waitstates für 85MHz schon arg langsam finde. Bei > ST schafft das Flash bis 30MHz ohne Waitstates, darüber ein Waitstate > pro 30MHz. Mithin brauchen 168MHz dann nur 5 Waitstates, jedenfalls bei > voller Versorgungsspannung. Okay, das ist interessant. Das mit den Waitstates ist natürlich nicht schön, ich müsste mal schauen, was der Flash-Accelerator so leisten kann. Nop schrieb: > Klarer Nachteil bei ST war und ist die rottige Software. Deren Standard > Peripheral Library kann man genauso vergessen wie deren Nachfolger > (Hardware Abstraction Layer). Das sind schlecht zusammengestoppelte > Dinger, die nichts abstrahieren, sondern eher als obfuscation layer > dienen. Kann man als Template mal reingucken und dann nach Datenblatt > selber programmieren. Vielleicht ist bei NXP die Espresso-Umgebung ja > tauglicher. Das dürfte bei jedem Hersteller ähnlich sein. LPCXpresso habe ich mir mal runtergeladen und angeschaut und wirkt nicht mal schlecht, die Code-Beispiele habe ich mir noch nicht angeschaut. Nop schrieb: > Das Interrupt-Layout ist übrigens denkbar einfach. Am Start des Flashes > liegt erstmal der Pointer zum Stack, danach der Reset-Handler, danach > die wichtigen Exceptions, danach die einzelnen Interrupts. Findet man > bei ST in DM00031020, Tabelle 61 auf Seite 374. Wird bei NXP sicherlich > ähnliche Doku geben. Ich habs in der Zwischenzeit gefunden; die ersten Vektoren (Reset, Stack, HardFaults) findet man wohl nur in der ARM Cortex Referenz, die implementierten IRQs stehen im NXP Datasheet > Was ich echt mau finde, ist das leider weit verbreitete Speicherlayout, > bei dem die Leute ihren Stack ganz nach oben ins RAM linken, so daß er > nach unten auf den Heap (sofern genutzt, sollte man eh nicht machen) und > die globalen Variablen zuwächst. Auch ST macht das in ihren > GCC-Linkerscripts so. ich denke mal das kommt von der Denkweise: der Stack wächst nach unten, also setz ich ihn ganz nach oben, dann kann er den gesamten restlichen RAM nutzen. > Richtig legt man den Stack ganz nach unten ins RAM, unterhalb der > globalen Variablen. Ein Stack-Overflow äußert sich dann in einem klaren > Absturz, den man in einem Handler abfangen kann (ist aber etwas tricky). > Wenigstens weiß man dann, was für ein Problem man hat, anstatt das > System in einem undefinierten Zustand mit diffusen Problem weiterlaufen > zu lassen. Muss ich mal schauen ob und wie das geht, evtl auch mittels MMU. Die Cortexe haben ja meistens auch noch einen kleineren RAM, den man dafür nuten könnte. Nur muss man bei einem Mehrkernprozessor die Speicher erst mal so verteilen, dass es möglichst wenige Überschneidungen gibt, damit kein Busmaster warten muss. PittyJ schrieb: > Zu den Fragen: > ... Danke, ich denke so ähnlich wirds bei mir auch laufen. Frank K. schrieb: >> Das wäre natürlich perfekt. Aber den Weg dahin stelle ich mir sehr >> Steinig vor... > > Alles Übung. Fang erstmal mit einem Adressdecoder an, das ist einfach. Ja, natürlich könnte ich das jetzt machen, wäre vllt sogar gar nicht schlecht FPGAs zu "können", aber ich habe nicht wirklich einen Grund dafür. Solange die Prozessorleistung noch reicht... Aber ich informiere mich mal ein bisschen, schaden wird das sicher nicht.
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.