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 | MICO_GPIO_READ_DATA(dip, test_select); |
3 | int test = ((~test_select) >> (8*7)) & 0xff; |
4 | |
5 | switch(test) { |
6 | case 1: |
7 | Rider(leds, &rider); |
8 | break; |
9 | case 3: |
10 | ms = 20; |
11 | |
12 | POVDisplay(ms,0b00011000, leds); |
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
:
Bearbeitet durch User
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ß?
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 | shared variable ram : ram_t := |
2 | (
|
3 | 0 => x"0b3bf148", |
4 | 1 => x"d2d4005b", |
5 | 2 => x"00000000", |
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.
Bitte 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.