Hi, ich versuche mich gerade mit dem Mico32 auf dem Lattice Versa-Board. Die ersten Schritte sind soweit getan. Nun möchte ich in Abhängigkeit der Dip-Schalter die LEDs unterschiedlich zum leuchten bringen. Die Mico-Config mit den Adressbereichen ist in "MSB.gif" zu sehen. Das C-File: "LM32_Versa_Tutoral.c" Wenn ich das generierte .elf-File im Debug-Modus einspiele, so erhalte ich in der Console folgende Meldungen: found GPIO instance named LED found GPIO instance named gpio_7Segs found timer instance timer found dip switches DIP testselect:-16777216 testselect:-16777216 testselect:-16777216 testselect:-16777216 testselect:-16777216 Anscheinend wird der DIP-Switch gefunden, totzdem scheint der Funktionsauftruf MICO_GPIO_READ_DATA(dip, test_select); einen Wert zu liefern, den ich so nicht verstehe, sieht nach einem Überlauf/Unterlauf-Wert aus. Der Funktionsaufruf ist als #define in der Datei "MicoGPIO.h" zu finden: /* ******************************************** ******************************************** MACROS FOR ACCESSING GPIO REGISTERS ******************************************** NOTE: FOR THE MACROS, THE FOLLOWING RULES APPLY: X is pointer to a valid MicoGPIOCtx_t structure Y is unsigned int variable */ /* reads data register */ #define MICO_GPIO_READ_DATA(X,Y) \ (Y)=((volatile MicoGPIO_t *)((X)->base))->data Kann mir jemand sagen, wieso das Lesen der DIP-Schalter-Stellungen nicht klappt? Grüße, Noro
Lies mal ein Buch über C-Grundlagen, die Sprache ist nicht selbsterklärend. Unsigned int formatiert man mit "%u", bei Portpins ist die hexadezimale Darstellung "%X" aber IMHO besser, da man die Bits dort direkt ablesen kann.
Jim M. schrieb: > bei Portpins ist die hexadezimale Darstellung "%X" aber IMHO besser Full ACK. > da man die Bits dort direkt ablesen kann. Wenn man hexadezimale Zahlen direkt lesen kann. ;-) Und wenn nicht, dann lernt man es so auf die schnellste Art... Noro S. schrieb: > testselect:-16777216 > testselect:-16777216 > testselect:-16777216 Und: ändert sich der Wert beim Umschalten?
Mit dem richtigen Format bei der Ausgabe klappt es ;-) Mit folgendem Code kann ich mir die Blink-Methode nun via DIP-Schalter einstellen:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Grüße, Noro
Noch eine Frage, die zwar nicht direkt mit der Eingangs-Fragestellung zu tun hat, ... Nun möchte ich das FPGA-Design inkl. Mico32 in Modelsim simulieren. Ich habe mir die verschiedenen Pdfs, die es dazu gibt, durchgelesen: mico32-hw/swdeveloperug.pdf versatutorial.pdf Das Ganze ist nicht wirklich gut beschrieben. Man kann unter Software Deployment Tools ->Mico32 On Chip Memory Deployment ein Memory-Initialization-File erstellen, was in meinem Fall 148MB groß ist. Meine Frage: Wie bekomme ich den Programmablauf (aus dem C-File) in meine Modelsim-Simulation? Der Programmablauf muss ja in irgendeinem EBR-Speicher enthalten sein? Wie kommt er für die Simulation da rein und wie groß ist dieser FPGA-Speicher? Grüße, Noro
Habe folgende Diskussion ausgegraben: Beitrag "Lattice Mico32 EBR Initialisierung" Die Vorgehensweise wie von "cfgardiner" beschrieben führt bei mir zum Abbruch, wenn ich in MSB-Eclipse den "Run Generator" starte. Ich erhalte die Fehlermeldung: Got ERROR - scuba: Address is too large in memory file "D:/lm32_tutor/LED_versa/release_memfile.mem - max address allowed is 4096. Line 4097 ERROR - edif2ngd failed to execute ip command file pmi_2\pmi_ram_dpEhrelease_memfilemem_322... Wie bereits oben beschrieben ist das generierte MEM-File (von Software Deployment Tool) 148MB grob. Was übersehe ich? Grüße, Noro
Interessanterweise ist die elf-Datei, auf Basis derer die Mem-Datei generiert wird, lediglich 103 KB groß. Wieso gerät die Mem-Datei so groß?
Gast
#4687487
Noro S. schrieb: > Interessanterweise ist die elf-Datei, auf Basis derer die Mem-Datei > generiert wird, lediglich 103 KB groß. Wieso gerät die Mem-Datei so > groß? Weder die .elf-Datei, noch die .mem-Datei enthalten offenbar nur die binären Teile Deines Programms. In der .elf-Datei sind mit sicherheit noch die ganzen Debug-Sektionen mit drin. Und Dein .mem startet möglicherweise schon ab 0x00000000 statt erst ab 0x08000000. Noro S. schrieb: > Meine Frage: Wie bekomme ich den Programmablauf (aus dem C-File) in > meine Modelsim-Simulation? Der Programmablauf muss ja in irgendeinem > EBR-Speicher enthalten sein? Wie kommt er für die Simulation da rein und > wie groß ist dieser FPGA-Speicher? Ich kann nicht für den LM32 sprechen (obwohl ich den auch schonmal ausprobiert habe, aber auf Xilinx). Bei meinem SoC ist der Ablauf der Folgende: 1. gcc-Derivat kompiliert 2. objcopy erzeugt ein Binary 3. das Binary wird von einem Programm geparst und zu einer VHDL-Beschreibung formiert, ala:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
4. Modelsim simuliert und Xilinx-XST synthetisiert. Für reine Softwareänderungen/-updates gibt es data2mem. Duke
>In der .elf-Datei sind mit sicherheit noch die ganzen Debug-Sektionen >mit drin. Habe noch keine Möglichkeit gefunden, die Debug-Sektionen auszulassen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.
