Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

libs for NIOSII

Altera_Forum
Honored Contributor II
1,760 Views

Hi all, 

do anyone have found information about building a library for the niosII and how I can use this library in IDE projects? 

Thank you for help. 

Siegmar
0 Kudos
12 Replies
Altera_Forum
Honored Contributor II
546 Views

If you are asking about how to create a library which can then be shared by multiple projects, I am writing up an example now to show how to do that, and should have it posted for you by Wednesday. The example will show how to link a library, created externally to the IDE, into your project managed by the Nios II IDE, without copying the source code for the library into the Nios II IDE Project directory.  

 

Best regards, 

Stephen
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hi Stephen 

yes, there are the two tasks: 

1) building the lib, I can do that outside the IDE, but sometimes it could be nice to do that also inside the IDE by having a project type "library" 

2) using the lib in one or more software projects inside the IDE. 

This can be done, but there are some problems with the path that the lib can be found by the linker (I have to specify the absolute!? path) and after that there are problems if I debug, because the sources can not be found and the setting for this seems to work not properly. 

 

Best regards 

Siegmar
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hi Siegmar, 

 

Yes, we agree. Support for a project of type "Library" will be supported within the Nios II IDE so that the IDE will manage the library's makefile in a release targeted toward the end of this year. I will be posting an example by Monday (perhaps tonight) which will show you how you can add a dependency to an IDE managed project which links in a common library which has been built externally to the IDE. The paths do need to be absolute though, and the IDE does not know about how the library is built, so debugging of a library built outside the IDE can be problematic. This should be all taken care of when the IDE can handle a "Library" type project later this year. For now, you could debug your library sources by pulling them into an IDE managed project, and then pull the library sources out into the externally built library after it has been debugged. 

 

Best regards, 

Stephen
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hello Siegmar, 

 

The example I am creating contains screen shots in Word format. I will forward the Word .doc file to you directly to your e-mail address as listed on this forum. This example will also get posted to our Altera internal Molson site next week, which is accessible by any Altera distributor FAEs, as well as our regional support centers, if anyone else would like to request a copy. 

 

Best regards, 

Stephen
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hello Sigiz, 

 

The example I sent to you last night is capable of debugging source code built in the external library, as the Nios II IDE does have information about how that library is built . Add the line:  

 

CFLAGS = -g  

 

to the libcommon.a Makefile. Rebuild the libcommon.a library project. Then rebuild the hello_world_2 application project and any other project which links against the common library. 

 

The resulting Makefile for the Nios II IDE Advanced project which builds the common library then would look as follows: 

 

----------------------------------------------------------------------------------------------------------------- 

 

CC = nios2-elf-gcc 

AR = nios2-elf-ar 

 

CFLAGS = -g 

 

LIB = common 

 

OBJS = $(patsubst %.c,%.o,$(wildcard *.c)) 

 

all: lib$(LIB).a 

 

lib$(LIB).a: $(OBJS) Makefile 

$(AR) src $@ $(OBJS) 

 

clean: 

$(RM) *.o lib$(LIB).a 

 

----------------------------------------------------------------------------------------------------------------- 

 

The makefile for the Nios II IDE Application Project which is generated automatically by the Nios II IDE does not need to change, and still looks like the following. I am repeating it here primarily for the benefit of those who would like to see how this makefile defines dependencies for the common library, but have not seen the Word .doc format application note I sent to you: 

 

Note that there are comments which mention how the Nios II IDE application properties page can be modified to add the makefile dependency for the common library project into the makefile variables named CFLAGS, LDFLAGS and LIBS. These comments refer to the steps I detailed in the screen shots I sent to you in the Word .doc format application note. 

 

The makefile for the Nios II IDE Application Project follows: 

----------------------------------------------------------------------------------------------------------------- 

# ********************************************************************** # # THIS IS AN AUTO-GENERATED FILE. DO NOT EDIT DIRECTLY# # To change the settings in here:# - Right click on the project# - Select "Properties" option# - Use property pages to set options. Details given below # # **********************************************************************  

# These flags can be set from C/C++ build property page -> nios2-elf-gcc -> General 

CFLAGS = -DALT_DEBUG -O0 -g -I/cygdrive/c/Common_Library -Wall 

ASFLAGS = -g 

# These flags can be set from C/C++ build property page -> nios2-elf-gcc.linker -> General 

LDFLAGS := -L/cygdrive/c/Common_Library 

LIBS :=  

-lcommon 

LIBS += -lm 

 

RM := rm -rf 

# This project 

PROJECT := hello_world_2# Location of this project 

APP_DIR :=C:/altera/kits/nios2/examples/verilog/niosII_stratix_1s40/full_featured/software/hello_world_2 

# Configuration for application project# The configuration can be changed from C/C++ build property page -> Configuration drop-down box.# If changed a new configuration folder (e.g. Release) is generated with all the generated and built files 

APP_CONFIG := Debug 

 

# Referenced system library & location. # These can be changed from App Options property page 

SYSTEM_NAME := hello_world_2_syslib 

SYSTEM_DIR := C:/altera/kits/nios2/examples/verilog/niosII_stratix_1s40/full_featured/software/hello_world_2_syslib 

# Configuration for system library project# The configuration can be changed from system library properties -> C/C++ build -> Configuration drop-down box.# If changed a new configuration folder (e.g. Release) is generated with all the generated and built files 

SYS_CONFIG := Debug 

# Change this setting from Window->Preferences->Nios II Run and Build Settings 

DO_MAKE_OBJDUMP := 0 

# Autogenerated list of subdirectories which contain source files 

SUBDIRS :=  

.  

# Include the makefiles for each source subdirectory 

-include ${patsubst %, %/subdir.mk, $(SUBDIRS)} 

MAKEFILE_LIST += $(patsubst %, %/subdir.mk, $(SUBDIRS)) 

 

# Include makefile for the OS we are building on as specified in system library project 

APP_MAKEFILE := C:/altera/kits/nios2/components/altera_hal/build/app.mk 

include $(APP_MAKEFILE) 

 

 

-----------------------------------------------------------------------------------------------------------------
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hi Stephen, 

 

first thanks for the example and the document how to build a lib with an advanced project, it was very helpfull and it works as expected.  

But there is one problem left, even if I insert the <CFLAGS = -g> I am not able to step into the lib because instead of opening the source the IDE opens the "source not found" window. 

I am wondering about the settings for "source code location" accessible in the preferences or in the "source not found" window. It seems that these settings will be ignored. (I have tried with and without entering the path to the sources of the lib). 

Also I am confused about the path format: 

cygwin works with the /cygdrive/c/... path (also uses unix like forslash) but the IDE works with c:\... (also uses backslashes). How do this works together? 

 

Thank you for help 

 

Siegmar
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hello Sigmar, 

 

I&#39;ll send an e-mail with some screen shots I got from one of our IDE developer&#39;s to your e-mail address which should help clarify this issue. 

 

Best regards, 

Stephen
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hello Siegmar, 

 

I have reproduced the problem you were seeing regarding the "source not found" window, and I have a solution. You simply need to edit the properties for the application project, Project References, and check the box for the Common_Library project. This should allow you to hit the breakpoints you set in source code for the external library built under the Common_Library project.
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Stephen, 

 

I received the library documentation from my FAE yesterday. Everything looks good except the following: 

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  

This method of creating a shared common library with functions used by multiple projects can only be used for libraries which are not dependent on the HAL (Nios II Hardware Abstraction Layer) or other system library functions.  To create such a shared set of functions, a software component must be created by following the documented process to create a HAL software component within the Nios II IDE directory structure.[/b] 

--- Quote End ---  

 

Correct me if I&#39;m wrong, but I believe this says the generic code in my library can&#39;t access the hardware through any HAL fucntions. The only hardware I need to access is a PIO and an SPI. These don&#39;t really have HAL functions. Will I still be able to include the _regs.h files I need? If not, I guess I&#39;ll try making a HAL software component. Mine would be simliar to the PIO and SPI ones. In the PIO, there is nothing in the HAL directory and in the SPI the _INSTANCE and _INIT don&#39;t seem to do anything. I am assuming that the only reason they are in the SPI HAL files is because the SPI supplies a single function, while the PIO supplies nothing but the macros in the _regs.h file. Does this sound correct? 

Thanks again,
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hello Dave, 

 

Yes, that is correct. If you have code which will be accessing PIO or any device registers, it is best to add that code as a HAL Device Driver. Details for adding a HAL Device Driver are described in chapter 5 of the Nios II Software Developer&#39;s Handbook, titled "Developing Device Driver&#39;s for the HAL".
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hi Dave, 

 

To clarify further, it would be possible for you to write code which resides in a library external to Nios II IDE which writes directly to hardware registers through hard-coded address values, but that would really defeat the purpose of having an external generic common source code library. This is not clean or portable. Another option would be to make a copy of the register header file to put with your common code library, since your device will make such limited use of the Hardware Abstraction Layer; but again, the drawback is that this is not clean, and could cause you trouble later if one copy of the header file changes but not the other, which could create problems which are even more difficult to find than just using hard-coded register values in your common library code. So I would strongly recommend against the above tactics. 

 

For the current release of Nios II IDE, the safest thing to do is to keep your code which uses system devices within a Nios II IDE project, and only use external common libraries for truly system independent functions.
0 Kudos
Altera_Forum
Honored Contributor II
546 Views

Hello Siegmar, 

 

I am glad that you can now debug sources which reside in an external library by checking the application project properties - project references checkbox for the Common_Library. Have a great weekend.
0 Kudos
Reply