Hallo zusammen, folgendes Anliegen: Ich habe hier ein Altera De1 SoC Board, welches mit einem Cyclones V FPGA mit integriertem Dual Core ARM Cortex A9 bestückt ist. Auf dem FPGA realisiere ich Audiosignalverarbeitungsalgorithmen. Ich würde gerne den ARM dort drin zukünftig mitbenutzten können für die Signalverarbeitung. Sprich dort soll eine relativ beschränke Applikation laufen, welche immer wieder das gleiche rechnet, während ich ihm einfach neue Daten in den Speicher reiche. Ohne langjährige Erfahrung würde ich annehmen, dass sich dafür eine Bare Metal Programmierung des Prozessors ohne Linux oder ähnliches anbietet - welche ja auch von der Altera SoC EDS Design Suite in der kostenpflichtigen Standard Version als Feature genannt wird. So weit für alle logisch, oder ist mein Ansatz hier schon falsch? Nun möchte ich aber die eine lizensierte SoC EDS Design Suite die zur Verfügung steht noch nicht installieren, da sie aktuell noch nicht an einen bestimmten Rechner gebunden werden soll. Alternativ würde ich lieber ein dezidiertes Development Kit mit einem Cortex A9 auf 800MHz getaktet anschaffen, auf dem auch Code für den ARM parallel zur Entwicklung auf dem FPGA entwickelt werden kann. Das gerne mit passender IDE vom Board-Hersteller zur Verfügung gestellt, die ohne langes gebastel läuft und mir die Möglichkeit gibt ohne Linux drunter auf meinem ARM Code in C zu entwickeln und zu benchmarken und zu einem späteren Zeitpunkt auf meine eigentliche Zielplattform zu portieren und dort eine vergleichbare Performance zu bekommen. Jedoch erscheint es mir nach kurzer Recherche so, als würden abgesehen von den SoC Lösungen von Altera und Xilinx kaum ein Hersteller explizit ein Augenmerk auf Bare Metal Programmierung dieses Prozessortyps legen, so dass die von mir gefundenen Development Kits inkl. IDE z.B. von NXP oder TI jeweils immer auf die Linux basierte Programmierung ausgerichtet sind. Daher die Frage: Hat jemand einen guten Tip für ein Board + eine erfolgreich getestete IDE + Toolchain (optimalerweise sogar noch mit Beispiel-Projekten) zur Bare Metal Programmierung dieses Prozessors, an der man sich nicht ewig die Zähne ausbeißt bis man was am Laufen hat? Es herrscht nämlich ein wenig Zeitdruck in diesem Projekt... Oder ist mein Ansatz so grundsätzlich falsch oder komplex, dass ich das oben genannte erst gar nicht versuchen sollte wenn ich nicht ewig Zeit zur Verfügung habe? Alternativ würde ich mich auch zu einem anderen ähnlich leistungsfähigen Prozessor überreden lassen, welcher sich entspannt ohne Betriebssystem programmieren lässt. Viele Grüße & Danke im Voraus Janos
Janos B. schrieb: > Ohne langjährige Erfahrung würde ich annehmen, dass > sich dafür eine Bare Metal Programmierung des Prozessors ohne Linux oder > ähnliches anbietet - welche ja auch von der Altera SoC EDS Design Suite > in der kostenpflichtigen Standard Version als Feature genannt wird. Wenn du die reine Rechenpower des Prozessors benötigst, ist bare-metal eine brauchbare Alternative. Janos B. schrieb: > Alternativ würde ich lieber ein dezidiertes Development Kit mit einem > Cortex A9 auf 800MHz getaktet anschaffen, auf dem auch Code für den ARM > parallel zur Entwicklung auf dem FPGA entwickelt werden kann. Warum? du besitzt bereits ein Board mit einem Cortex A9. es wird nicht einfacher, wenn man noch mehr Tools und Hardware anschafft. Janos B. schrieb: > Jedoch erscheint es mir nach kurzer Recherche so, als würden abgesehen > von den SoC Lösungen von Altera und Xilinx kaum ein Hersteller explizit > ein Augenmerk auf Bare Metal Programmierung dieses Prozessortyps legen >[...]. Warum wohl? Hast du dich mit dem SoC beschäftigt? Allein der Cortex-A9 CPU Core ist ein Monster. Dein SoC hat zwei davon. Aus Gründen der Übersichtlichkeit verwenden viele in solchen Fällen nur einen Kern. Es ist zwar grundsätzlich möglich den Dualcore mit baremetal brauchbar zu verwenden. Aber ohne Betriebssystem schießt man sich dabei schneller selbst ins Bein, als dass es hilft. Neben der leicht benutzerunfreundlichen CPU kommt dann auch noch ein ganzer Haufen Peripherie dazu. Große Teile davon wirst du nicht benötigen. Wenn du externen RAM benötigst, darfst du dich mit der Initialisierung des Speichercontrollers, des Caches und verschiedenen anderen komponenten beschäftigen. Eventuell auch mit der MMU, die ich bei bare-metal, falls nicht standardmäßig, sofort abstellen würde. Um die Clock-Konfiguration wirst du wahrscheinlich nicht drumherum kommen. Und solche systeme haben meist schon ein Clock-Management, dass man keine Lust mehr hat, sobald man das mal angeschaut hat. Janos B. schrieb: > Daher die Frage: Hat jemand einen guten Tip für ein Board + eine > erfolgreich getestete IDE + Toolchain (optimalerweise sogar noch mit > Beispiel-Projekten) zur Bare Metal Programmierung dieses Prozessors, an > der man sich nicht ewig die Zähne ausbeißt bis man was am Laufen hat? Meiner Meinung nach solltest du versuchen was mit diesem Board und dieser CPU hinzubekommen. Die Zähne ausbeißen kann allerdings ziemlich leicht passieren. Diese Controller sind nicht für bare-metal Anwendungen gedacht und es gibt deswegen auch dementsprechend wenig Material. Wenig Material ist falsch ausgedrückt. Es gibt genug Material. Jedoch ist die Thematik ungeschickt und erfordert einiges an Einarbeitung. Es ist nicht selten,d ass man ein Linkerskript ändern bzw. selbstschreiben muss, um bestimmte Funktionalitäten zu realisieren etc. Zu den Cortex A kernen findet man auch mit Stichworten "Raspberry Pi baremetal"... Ressourcen. Altera hat ein Unterforum für Bare-Metal Programmierung. Ebenso stellen sie Hardware Libraries zur Verfügung, um den Anwender nicht komplett verzweifeln zu lassen. Janos B. schrieb: > Alternativ würde ich mich auch zu einem anderen ähnlich > leistungsfähigen Prozessor überreden lassen, welcher sich entspannt ohne > Betriebssystem programmieren lässt. Ähnlich leistungsfähig ist wie definiert? Da du hauptsächlich Rechenleistung benötigst und weniger die fancy Voodoo-Peripherie, kommen schon einige ARM Controller in Frage. Grundsätzlich wirst du aber nichts in der Leistungsklasse außerhalb der Coretx-A Reihe finden. Übliche "Mikro"-Controller wie die STM32Fxxx haben Taktraten von bis zu ~200MHz. Eventuell ist auch ein DSP Prozessor (von TI?) eine Alternative. Da hast du dann natürlich das Problem, dass du neue Hardware benötigst. Ebenfalls wirst du die Datenverbindung zwischen FPGA und CPU bei einer Zwei-Chip-Lösung nicht so performant hinbekommen wie bei einer integrierten SoC Lösung. Je nach Aufgabe ist vielleicht ein Softcore im FPGA eine Alternative. Da gibt's viele. Altera Nios, openrisc... Die sind aber im vergleich zu nem festen Core recht langsam. Also eher weniger. Mein Rat ist: Überleg dir genau, ob du den ARM Core brauchst bzw. ob es das wert ist einige Zeit zu investieren. wenn du sagst, du brauchst den Core, dann hilft nur in den sauren Apfel zu beißen und sich da einzuarbeiten. Die Altera SoC EDS ist glaub ich frei... Dachte ich zumindest. nur der Debugger kostet Geld. Aber es gibt iwie keinen angenehmen weg das Programm da reinzubekommen ohne Debugger. Irgendwie schon doof. Grundsätzlich kann man natürlich alles mit nem GCC und nem GDB + openocd oder so komplett frei mit eclipse oder einer IDE deiner Wahl entwickeln. Das ist aber auch keine schnelle Lösung.
Moin, Hab' zwar keinen Plan, welches Board dafuer gut geeignet ist, ich wuerde aber mal vermuten, dass tendentiell SoCs ohne VideoHW nicht ganz so "geheim" sind und damit besser dokumentiert. "Frueher" war bei den u-boot sourcen auch ein bare-metal-example dabei, d.h. u-boot hat keinen linux-kernel gestartet, sondern das bare-metal-binary. Weiss nicht, obs das noch gibt - aber das spart einem die ganz harten Initialisierungen beim ARM-Start selber zu machen. Die macht dann schon das u-boot. Gruss WK
Janos B. schrieb: > uf dem FPGA > realisiere ich Audiosignalverarbeitungsalgorithmen. Ich würde gerne den > ARM dort drin zukünftig mitbenutzten können für die Signalverarbeitung. > Sprich dort soll eine relativ beschränke Applikation laufen, welche > immer wieder das gleiche rechnet, während ich ihm einfach neue Daten in > den Speicher reiche. Mal ne blöde Frage: Was heißt denn rel. beschränkt? Ich meine, wenn das eine wirklich "beschränkte" Applikation ist, warum dann den Umweg über SW gehen? Oder hast ist dein FPGA voll? Wenn nicht, würd es sich doch anbieten den Spass auch in HW zu realisieren. Ansonsten: Wie schon gesagt, es gibt fürn Raspberry ein paar Tutorials, Folien etc. im Neuland zu finden. Ich hab mir das mal für ne Studienarbeit angeschaut. Zusammenfassend: Man kann es schon machen, Spass macht das allerdings wirklich nicht mehr. Die größten Hürden sind (wie auch schon gesagt wurde): - Das Ding überhaupt bare-metal zum laufen zu bringen - alles richtig initialisieren Tasks bzw. Operationen an sich (oder rechnen) sind dann genauso wie überall anders auch. Aber bis man mal soweit ist, macht das schon keinen Spass mehr. Hab ich gefunden (ohne es wirklich mal probiert zu haben). Wenn man sich ein custom linux baut (yocto , angstrom, etc.), dann kann man sich rel. Einfach ein linux zusammenbauen, das unterm Strich nichts mehr macht, außer die HW zu initialisieren und hin und wieder den Kernel zu starten. Das läuft aber dann auch schon recht performant. Meiner Meinung nach wäre dieser Weg der schnellere. Ob der Performanceunterschied soviel ausmacht ist schwierig zu beurteilen, kommt halt auf deine Applikation drauf an. Nicht umsonst ist das ein A Prozessor. A = Application = (normalerweise)(nicht echtzeitfähige)OS
ui schrieb: > Mal ne blöde Frage: > Was heißt denn rel. beschränkt? Ich meine, wenn das eine wirklich > "beschränkte" Applikation ist, warum dann den Umweg über SW gehen? Oder > hast ist dein FPGA voll? Wenn nicht, würd es sich doch anbieten den > Spass auch in HW zu realisieren. Okay, ich führe es noch mal etwas genauer aus: Das ganze Ding ist aktuell eine Bachelorarbeit. Da soll erst mal ganz doof und unvoreingenommen die Performance verschiedener genutzter Algorithmen unter verschiedenen Gesichtspunkten auf verschiedenen Plattformen untersucht werden. Dahinter steckt aber am Ende, über die Bachelorarbeit hinaus schon ein ernsthaftes Ziel, eventuell ein lauffähiges Produkt umzusetzen. Hierbei könnte dann gut der gesamte Signalverarbeitungspfad in teil-Algorithmen über Hardware im FPGA und Software im ARM verteilt werden, so dass jeder Core seine stärken bzgl. des gerechneten Algorithmus ausspielen kann. Damit soll dann die Zielanwendung irgendwann auf einem bezahlbaren Ziel-Device wie es in dem Kontext das Cyclone V SoC ist einfach maximal groß skaliert werden, was z.B. I/O Kanäle und geringe Latenz angeht. Aktuell bin ich aber noch in der Arbeit. Und da will ich erstmal gerne eine halbwegs aktuelle ARM Architektur mit NEON SIMD Einheit haben, die ich unter dem aktuellen Zeitdruck fix programmiert bekomme um da grundsätzlich die Performance zu benchmarken. Ich habe mich nun für einen TI Cortex A8 entschieden, für den TI die StarterWare zur Verfügung stellt, die direkt alles für die Bare Metal Programmierung bereithält inkl. Bootloader der den Chip beim start passend initialisiert.
Wie gut baremetal ist und was man alles braucht, kann man hier am C++ framwork für den raspberyy sehen ! https://github.com/rsta2/circle Zitat: C++ build environment Simple delay functionality Get properties (model, memory size) from VideoCore new and delete Using GPIO pins Manipulating Act LED Set pixel on screen Use kernel options Switch on MMU Formatting strings Using devices Writing characters to screen Writing characters to UART Logging output to screen or UART Using assertions and debug hexdump Using interrupts Timer class with clock, timers and calibrated delay loop Exception handler USB host controller interface (HCI) driver (no split support for now) USB device class (basic device initialization) USB hub driver (dectects and enables the supported devices) Driver for the on-board Ethernet device (receiving and transmitting frames) Driver for USB mass storage devices (bulk only, read and write) Detects low- and full-speed devices Driver for USB keyboards Using GPIO interrupts Driver for USB mice Using GPIO clock Simple 12 MHz GPIO sampling routine PWM sound device DMA controller support PWM output (2 channels) Simple USB printer support FAT file system support (reduced) I2C (master and slave) support Multi-core support on Raspberry Pi 2 Experimental (UDP only) TCP/IP network stack Setting system time from an Internet time (NTP) server Cooperative non-preemtive scheduler TCP support DHCP support Simple HTTP webserver class GDB debug support on Raspberry Pi 2 using rpi_stub Bluetooth device inquiry support SPI0 master support
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.