Hi, habe meinen C Code in Eclipse für den NIOS eingefügt. Es wurden Fehler angezeigt. Z.b wurde conio.h wohl nicht gefunden. Habe ich auskommentiert. Nach stundenlangem suchen habe ich auch meine pow() funktion mit math.h auskommentiert und nach weiteren Stunden mein globales 2D array in die main gebracht und den funktionen eben seinen Zeiger übergeben. Auch mein fopen habe ich gestrichen xD Nun werden keine Fehler angezeigt. Aber meine Programm geht 3 Funktionen durch und springt dann wieder zum Anfang. Und das ohne Schleife xD Also ich nehme an man muss mit diesem BSP Editor einiges aktivieren um z.B. fopen verwenden zu können oder ? Warum mein Code sich so merkwürdig verhält verstehe aber nicht. Ich werde einfach mal alles was global ist ebenfalls in die main verschieben .. Vielleicht hat jemand einen Tipp ? Ich werde mich jetzt mal mit dem BSP Editor beschäftigen.. Danke :D
Geldesch B. schrieb: > . Z.b wurde conio.h wohl nicht gefunde Das ist ein Windows header. Läuft Windows auf deinem Nios? Geldesch B. schrieb: > Also ich nehme an man muss mit diesem BSP Editor einiges aktivieren um > z.B. fopen verwenden zu können oder ? Was für ein OS nutzt du denn, welches fopen bereitstellen soll?
Geldesch B. schrieb: > Nun werden keine Fehler angezeigt. Werden Warnungen (bei höchstem aktivierten Warn Level) ausgegeben?
Geldesch B. schrieb: > Also ich nehme an man muss mit diesem BSP Editor einiges aktivieren um > z.B. fopen verwenden zu können oder ? Welche Dateien willst Du denn öffnen, auf deinem FPGA? Und wie soll der da rankommen? Mir scheint hier noch ein fundamentales Verständnissproblem zu existieren. Programmierer schrieb: > Das ist ein Windows header. Läuft Windows auf deinem Nios? Jungspund? conio ist älter als Windows (aber nicht viel): https://en.wikipedia.org/wiki/Conio.h Duke
Duke Scarring schrieb: > conio ist älter als Windows (aber nicht viel): Ich finde es trotzdem i.O. es als "Windows-Header" zu bezeichnen, denn schließlich ist Windows das meistgenutzte System, dessen Compiler diesen Header mitliefern. Es verdeutlicht jedenfalls, dass das nicht viel mit RTOS zu tun hat.
>Welche Dateien willst Du denn öffnen, auf deinem FPGA? Eine Textdatei. >Und wie soll der da rankommen? Die Textdatei soll einfach im Projektordner vom NIOS liegen und irgendwie mitgeladen werden. >Mir scheint hier noch ein fundamentales Verständnissproblem zu >existieren. Ja deswegen muss ich so dumme Fragen stellen xD >Das ist ein Windows header. Läuft Windows auf deinem Nios? Nein. Es läuft ein main() Programm. >Was für ein OS nutzt du denn, welches fopen bereitstellen soll? Quasi gar keins auf dem NIOS... Also diese main-Schleife... >Werden Warnungen (bei höchstem aktivierten Warn Level) ausgegeben? Sehr wichtige Frage. Muss ich mir anschauen ! Vielleicht kann ich so weitere Fehler debuggen. Danke :D Ich habe meinen einzulesenden Text in ein Array getan xD Der kann jetzt auch so gelesen werden :D Passt auch. ABER: Wie würdet ihr das denn machen ? Wenn ihr eine textdatei hättet und diese einlesen wollen würdet auf einem NIOS ?
Oder muss man dann ein kleine Filesystem implementieren in das man die textdatei reinlädt ? Da steht was: https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/entwurf-daten-in-den-flash-speicher-des-esp-ablegen
Geldesch B. schrieb: > Wie würdet ihr das denn machen ? Wenn ihr eine textdatei hättet und > diese einlesen wollen würdet auf einem NIOS ? Einlesen wovon? Wenn das in einem Speicher fest liegt, dann kannst du statisch sagen wo der Text ist. Da brauchst du auch keine Datei sondern nur einen Speicherbereich dessen Inhalt als Text interpretiert wird. Und Text braucht man eigentlich auch nur wenn man etwas für Menschen lesbares ausgeben will. Wenn es auf einem Wechselspeicher liegt der auch von einem PC bequem gelesen und beschrieben werden soll dann ist ein Dateisystem sinnvoll. Edit: Was willst du denn mit dem Text machen? Warum soll das überhaupt Text sein und wieso eine Datei?
:
Bearbeitet durch User
Geldesch B. schrieb: > irgendwie mitgeladen werden. Wie stellst du dir "irgendwie" vor? Geldesch B. schrieb: > Nein. Es läuft ein main() Programm. Das ist kein OS. Geldesch B. schrieb: > Quasi gar keins auf dem NIOS... Also diese main-Schleife... Dann hast du: Keine Konsole, daher kein conio.h Keinen Treiber für Speicher und kein Dateisystem, daher kein fopen Geldesch B. schrieb: > Wie würdet ihr das denn machen ? Wenn ihr eine textdatei hättet und > diese einlesen wollen würdet auf einem NIOS ? Dann würde ich mir erst einmal anschauen was für ein Speicher zur Verfügung steht... externer Flash? Festplatte? SD-Karte? Nur der Prohrammspeicher selbst? Wie groß ist die Datenmenge? Im Endeffekt wird man es sehr ähnlich zu einem "normalen" Mikrocontroller machen... Geldesch B. schrieb: > Ja deswegen muss ich so dumme Fragen stellen xD Wer hat dich auf ein FPGA losgelassen...
Das geht schon. Bloß nicht von alleine. Der NIOS HAL bringt die NIOS Newlib mit (mit den stdio-Funktionen). Wenn man die benutzen will, muß man sie natürlich "irgendwo" (an ein Dateisystem) anschliessen. Entweder man baut sich was, oder man nimmt, was mitkommt: im einfachsten Fall das "read-only zip file system" (entsprechendes Kapitel im Handbuch lesen!). Von da aus weitersehen.
>Geldesch B. schrieb: >> Quasi gar keins auf dem NIOS... Also diese main-Schleife... >Dann hast du: >Keine Konsole, daher kein conio.h >Keinen Treiber für Speicher und kein Dateisystem, daher kein fopen Ok jetzt komme ich der Sache schon näher >Was willst du denn mit dem Text machen? Warum soll das überhaupt Text >sein und wieso eine Datei? Es handelt sich um OPCODE: bsp:
1 | à` a b¢ @@"A Ðòp |
2 | char * text= " à` a b¢ @@"A Ðòp"; |
Simmt man kann diesen ja auch einfach in ein char * -array legen. -- >>irgendwie mitgeladen werden. >Wie stellst du dir "irgendwie" vor? Die Datei wird durch den Compiler zugänglich gemacht und in einen Speicherbereich des NIOS geladen xD Aber ok ich sollte wohl erst verstehen wie der Compiler mit Dateien im Ordner umgeht. --- Gut danke euch für die Antworten ! Es ist wichtig das ich verstehe wie der Compiler arbeitet, dann brauche ich mich auch nicht zu wundern wie er sich verhält !
Geldesch B. schrieb: > Aber ok ich sollte wohl erst verstehen wie der Compiler mit Dateien im > Ordner umgeht. Überhaupt nicht. Der Compiler hat damit sowieso nichts zu tun. Es hat etwas damit zu tun, was für Speicher du angebunden hast, was für Treiber und Bibliotheken und ggf. was für ein OS du verwendest. Den Compiler interessiert es nicht ob "fopen" einen Linux-Syscall absetzt oder z.B. eine FAT32-Bibliothek wie FatFs nutzt um auf eine SD-Karte zuzugreifen. Du legst fest, welcher Speicher angebunden ist und wie die Software das macht. Der Compiler übersetzt nur C-Code in Assemblercode; der weiß nichts von Speicher, Dateisystemen, Treibern, OS... Geldesch B. schrieb: > Es handelt sich um OPCODE: bsp: à` a b¢ @@"A Ðòp > char * text= " à` a b¢ @@"A Ðòp"; Codiere das doch besser hexadezimal:
1 | const char text [] = { 0x20, 0x12, 0x34, ... }; |
So kurze Datenmengen kann man problemlos in den Code selber packen. Das landet dann direkt im Programmspeicher (RAM?), braucht keine Treiber oder OS. Geldesch B. schrieb: > Die Datei wird durch den Compiler zugänglich gemacht und in einen > Speicherbereich des NIOS geladen xD Und was für ein Speicherbereich soll das sein? Welches Dateisystem liegt da? Welche Software-Komponente implementiert das Dateisystem?
Man kann auch Dateien über den Linker so mit ins Programm einbinden, dass man über eine Adresse (Zeiger) darauf zugreifen kann. Dann braucht man diese nicht erst in Hexcode oder ähnliches wandeln. Bei ein paar Byte spielt das aber keine Rolle.
>Entweder man baut sich was, oder man nimmt, >was mitkommt: im einfachsten Fall das "read-only zip file system" Interessant Danke. Dadurch habe ich das wiedererkannt: >>"Altera provides a read-only zip file system for use with the hardware abstraction layer (HAL). The read-only zip file system provides access to a simple file system stored in flash memory. This file system is suitable for embedded software use. The drivers take advantage of the HAL generic device driver framework for file subsystems. Therefore, you can access the zip file subsystem using the ANSI C standard library I/O functions, such as fopen() and fread()." >So kurze Datenmengen kann man problemlos in den Code selber packen. Das landet dann direkt im Programmspeicher (RAM?), braucht keine Treiber oder OS. Ja genau danke :D Allerdings werde ich die Hexa-Notation nicht verwenden, da der Inhalt austauschbar sein soll und außerdem sind das wirklich manchmal viele Zeichen. Also wenn ich jetzt einen anderen OPCODE testen möchte, wäre es zeitaufwändig das erst selber umzuwandeln. Mit Zeichenverarbeitung in C werde ich das dann einfach lösen. Ja der Arbeitsspeicher wird dann wohl benutzt. >Und was für ein Speicherbereich soll das sein? Welches Dateisystem liegt da? Welche Software-Komponente implementiert das Dateisystem? Das Board Support Package hätte das ja organsieren können. Also irgendwas in der Art ist ja wirklich möglich. >Der Compiler übersetzt nur C-Code in Assemblercode; der weiß nichts von Speicher, Dateisystemen, Treibern, OS... Ok macht Sinn :D Ein Board support package könnte dann dabei helfen bestimmte Funktionen bereitzustellen: C-Code -> Board-Support-Package-> Hardware
Ich habe übrigens meine globalen Variablen und Zeiger in die main Funktion gebracht und die Zeiger an die Funktionen weitergeben. Nun wird der Code fast korrekt ausgeführt ! Es sieht etwas langsamer aus auf der Konsole des NIOS und außerdem fehlt ein Zeichen . Ich habe den Code auch mal 1:1 ( außer alt_printf ) auf meinem PC laufen lassen. Da ist er schneller und das Zeichen ist vorhanden xD Mal schauen . Kann auch daran liegen, dass die Übertragung nicht "so gut" ist zur Konsole...
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.