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++

automated building

Altera_Forum
Honored Contributor II
1,100 Views

Hi all, 

 

I am wondering about the possibility of automated build processes for the NiOS board. 

I am looking both at the process for FPGA designs and for C files. 

 

For FPGA designs: 

I understand that there is powerful commandLine scripting available; for example quartus_map, quartus_fit, quartus_tan, quartus_asm commands. And also the availability of TcL (tool command language). 

 

For C files: 

I am specifically looking at nios-build and nios-run that is called from the cygwin shell. 

 

Perhaps a bit more background on what I am attempting to do. 

I am in the process of creating a simple application that would allow the user to simply click their way thru the flow from compiling to dumping onto the NiOS board. Automated building with feedback in terms of the standard feed back of warning and error msg. Sounds rather simple but in order to do this I will need to invoke the above commands.  

 

For FPGA designs the tools available in the commandLine scripting seem adequate. But has anyone real life examples or suggestions on getting started? Drawbacks and what to look out for? Examples even? 

 

For nios-build & nios-run I cant seem to find relevant information. I don’t even know if it is possible to invoke them from another application thru Cygwin.  

 

Google and the Altera website are lacking in practical information especially those of examples. What are the experiences of those on this forum when attempting something like this. 

 

Thanks in advance guys 

 

Here’s the doco on commandLine scripting: 

http://www.altera.com/literature/hb/qts/qt...ts_qii52002.pdf (http://www.altera.com/literature/hb/qts/qts_qii52002.pdf)
0 Kudos
11 Replies
Altera_Forum
Honored Contributor II
386 Views

There is a section in the manual about command line tools which you should probably check. 

 

nios2-build and nios2-run are for the legacy SDK which is not recommended for new projects. 

 

For projects based on the HAL the best way is to create your project in the IDE, build it once and then use `make` and `nios2-download` to build and run it. In 1.0 and 1.01 the step of creating the makefile is not available from the command line, but there's a new script to do this available in 1.1.
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

According to me it should be a disaster if the legacy SDK would not be supported anymore. I write code already from teh start of NiosI, and it is easy to reuse in NiosII. 

 

After some experiments with the HAL, it looks that my old code works faster. 

 

Did anybody used the IDE envirenment already for projects that are not using the hal? Is it possible to foresee your own interrupt handling then? Is it easy to make makefiles with own libraries? ... 

 

If someone has some experience doing this, please let me know, maybe I'm looking in the wrong direction ... 

 

 

 

Stefaan
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

The commandLine options quartus_map (and the like) seem adequate and the TcL scripting is powerful (do quartus_sh --qhelp to get a help on available commands). A few things to iron out but it seems i can tackle this using generated batch files and running them. So that's a good progress.i 

 

 

--- Quote Start ---  

originally posted by wombat@Nov 16 2004, 07:09 AM 

nios2-build and nios2-run are for the legacy sdk which is not recommended for new projects. 

--- Quote End ---  

 

oh dear ... i was looking at the tutorial available on the 'nios software development tutorial' (http://www.altera.com/literature/tt/tt_nios_sw.pdf) doco and also the web server example ('nios ethernet development kit' (http://digital5.ece.tntech.edu/public/altera/books/ug/niosedk.pdf), pg12) and they both seem to demonstrate using nios-build and nios-run. I have successfully managed to complete these examples/tutorials and also in addition make changes and tinker with the code. At no point was there a need for me to use the IDE (except for when loading the reference design). Am i going down the wrong track? 

 

 

--- Quote Start ---  

originally posted by wombat@Nov 16 2004, 07:09 AM 

for projects based on the hal the best way is to create your project in the ide, build it once and then use `make` and `nios2-download` to build and run it.  in 1.0 and 1.01 the step of creating the makefile is not available from the command line, but there's a new script to do this available in 1.1. 

--- Quote End ---  

 

So is there no way for me to escape using the IDE? 

 

A bit more info, im using the NiOS excallibur with the Ethernet Development Kit, Quartus4.0, running on windows2k3 and developing the application in .NET 

 

Thanks for the current feedback ... do bear with me as i am still trying to come to grips with NiOS and the like.
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

There seems to be some confusion here. The document you referred to is for Nios I (a previous processor family, not compatible with Nios II). The HAL and IDE aren't supported for Nios I. 

 

The legacy SDK is supported on Nios II to help with porting Nios I projects to the Nios II processor. We aren't adding new features to it though. 

 

For new projects you will probably be better off using Nios II and the HAL (unless you have particularly old hardware which doesn't support Nios II). 

 

And as for escaping from the IDE, release 1.1 of Nios II will be out in December and will let you do the full build, download and debug cycle using command line tools if you want to. You can do all of it except project creation and the first build right now. 

 

Of course there is no reason why you couldn't just your own make system from scratch if you have time to spare. All the parts are there - make, gcc, gas, ld, nios2-download and gdb.
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

wombat, 

 

You mean only the lib, src and inc directory for the legacy sdk will dissapear?  

 

That's no problem. If there is still a header file generated with the system memory layout. 

 

Stefaan
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

Stefaan, 

 

You may find advantages in porting your code from the SDK to the HAL. For example nice IDE, new features etc. 

 

The HAL provides a memory map file (system.h) which is similar to the SDK memory map file and should provide a superset of the SDK capabilities (if it doesn't then please tell us). 

 

But if you don't want to port your code from SDK to HAL then there are no plans to make any part of the legacy SDK dissapear. 

 

ps. If you want a bare environment then try using the HAL alt_main entry point.
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

wombat, 

 

 

I had a look at the 'bare' way to use the hal, but I got stuck on the interrupt handling. 

 

I need a very specific interrupt handling function, directly in the address of the entry point for the interrupt.  

 

I was able to override the interrupt handler itself, because it was in a C file in the HAL. But for putting code at the irq vector address itself it is not possible I believe, because this is in a header file. 

 

About the SDK, it schould be even easier if the memory layout (the addresses of the peripherals and RAM) are in a seperate header file, and not toghether with the structure definitiens of the peripherals and other things. 

 

 

stefaan.
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

stefaan, 

 

If you really want to have your ISR at the irq entry point there is nothing stopping you re-writing the code which lives there. This can be found in the nios2 component in the file alt_irq_entry.S. Though obviously the hal APIs to do with registerring interrupts will no longer work. 

 

As for you comment about it the old SDK that it would be useful if the memory map was separated from the function prototypes, structure definitions etc. This is something we completely agree with. This is why with the Hal you will find that system.h does not contain structures, function prototypes etc, and only contains information about the hardware, it's memory map etc. However I should say once again there is little point requesting new features on the SDK it is included for backwards compatability, but there is no new development scheduled for it.
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

alt_irq_entry.s ? Is this part of the HAL? 

 

 

I think it was not possible because the code is located in alt_irq_entry.h, filled with inline assembler.
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

Yes, you are right. In 1.0 the code was in a header file but its in its own assembler file for 1.1. But there is no reason why you can't override code in a header file in the usual way (only from the system library). Or override the C file which includes it. 

 

The bare way to use the HAL is just to write a function called alt_main (overriding the standard alt_main). At this point you have complete control of the processor and can do what you like. Nothing is provided unless you explicitly initialise it. Working this way is a lot more complicated, but a lot more powerful, so it's not recommended unless you really need it.
0 Kudos
Altera_Forum
Honored Contributor II
386 Views

OK, 

 

You mean 1.1 as new release, not 1.0 service pack 1 (1.01). Or my service pack update didn't worked wary well. 

 

I know about the header file because at that moment it seemed to be hard to override. But anyway, I'm doing legacy stuff now. we'll see what the future brings... 

 

Stefaan
0 Kudos
Reply