GPIO read - Mico32

[Noro S. (Firma: Home) (schmidt)]

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

[Jim M. (turboj)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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?

[Noro S. (Firma: Home) (schmidt)]

Mit dem richtigen Format bei der Ausgabe klappt es ;-)
Mit folgendem Code kann ich mir die Blink-Methode nun via DIP-Schalter 
einstellen:

...
MICO_GPIO_READ_DATA(dip, test_select);    
int test = ((~test_select) >> (8*7)) & 0xff;

switch(test) {
  case 1:
      Rider(leds, &rider);
      break;
  case 3:
      ms = 20;

      POVDisplay(ms,0b00011000, leds);
            ...
}
...

Grüße, Noro

[Noro S. (Firma: Home) (schmidt)]

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

[Noro S. (Firma: Home) (schmidt)]

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

[Noro S. (Firma: Home) (schmidt)]

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ß?

[Duke Scarring (Gast)]

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:

shared variable ram : ram_t :=
(
     0 => x"0b3bf148",
     1 => x"d2d4005b",
     2 => x"00000000",
...

4. Modelsim simuliert und Xilinx-XST synthetisiert.

Für reine Softwareänderungen/-updates gibt es data2mem.

Duke

[Noro S. (Firma: Home) (schmidt)]

>In der .elf-Datei sind mit sicherheit noch die ganzen Debug-Sektionen
>mit drin.

Habe noch keine Möglichkeit gefunden, die Debug-Sektionen auszulassen.