NiosII IDE to Build old Nios project

[Altera_Forum]

Does Somebody knows how to build old software project developed for Nios# 1 in new IDE for Nios# 2? 

I ask SOPC builder to add legacy software components such as "excalibur.h" file, so I can build old software project in the NiosII SDK Shell. But I want to use IDE that looks more convenient for software development. Any ideas?

[Altera_Forum]

--- Quote Start ---  originally posted by macshiz@Nov 9 2004, 05:09 AM does somebody knows how to build old software project developed for nios# 1 in new ide for nios# 2? i ask sopc builder to add legacy software components such as "excalibur.h" file, so i can build old software project in the niosii sdk shell. but i want to use ide that looks more convenient for software development. any ideas?  --- Quote End ---   Sorry I'm afraid the new IDE is only available for the new software. The legacy code is available to be used just as it was in the past being built from the shell, but you don't get the new IDE.

[Altera_Forum]

I've never tried porting old software to the new IDE but I suspect that it's not complicated. If you're willing to replace your Nios with a Nios II, then the software effort involved would be something like: 

 (1) copy all the old source code into a Nios II IDE project (2) change all references to hardware to use HAL style references.  Could be more to it but I haven't tried myself.

[Altera_Forum]

Well, I've just finished porting five (yes five) Nios I designs to Nios II. You need to read an 350: upgrading nios processor systems to the nios ii processor (http://www.altera.com/literature/an/an350.pdf) 

 I followed this and everything worked fine. I am using the standard Nios II so I have no data cache. I've been a little lazy in that I haven't converted all of my peripheral reads and writes to the HAL versions. I will, of course, be doing this in the future.

[Altera_Forum]

I have read AN350 and I have ported my Nios I project to Nios II like it described there. 

So my question is can I do something in NiosII IDE to build projects that use legacy sdk and components. For example create a custom makefile or set the compiler to external nios-build tool? Without changing anything. For example periferials reads and writes to HAL calls and so on. In AN350 is noted that if legacy sdk is used NiosII IDE is not supported! But I want to use it. So I need info about any kind of expert setup of NiosII IDE or something like that.  PS. Sorry my English. I don't have practice for long time.

[Altera_Forum]

MacShiz, 

 The IDE is capable of what you would like, but not without some substantial effort -- we have made the concious decision not to perform this or support it (as our policy is not to add any new features to the legacy SDK), but it can be done.  The ultra-brief steps, off the top of my head, which may or may not be correct are: - Create an SOPCBuilder project - Turn on the legacy SDK - Generate the SDK (via SOPC Builder or calling "mk_custom_sdk" from the legacy SDK shell command line). This gives you the traditional "<cpu name>_sdk" directory structure & contents. - Import the above into the IDE as an "advanced" project - Write/modify makefiles to (1) build libnios.a and libnios_debug.a (what the old auto-generated makefile in the sdk/lib folder would do) and (2) to build your source code in the sdk/src directory as appropriate.   The sdk/src/peripheral_test example can be referenced as an example of how to build using the legacy &#39;way&#39;....  There have been some other threads on this board about how to make an &#39;advanced&#39; project work.. I believe all you need is a makefile in the root of your project with &#39;all&#39; and &#39;clean&#39; targets, but I could be wrong.  Again, all of the above is certainly possible within the IDE, but we have no plans to (nor do we) support it.

[Altera_Forum]

MacShiz, 

If you are going to a NIOS II why the reluctance to convert your code to the new HAL? I&#39;ve also done a number of conversions at this point and it&#39;s not very difficult. Since Altera is not going to support the legacy SDK you are really limiting your support going forward I feel.   The biggest thing you have to watch out for is the data cache issues (if you use one). If you are using a NIOS2 with the old SDK I don&#39;t think that is going to handle that any way. You will have to either convert to the HAL calls or use the bit 31 method (setting bit 31 in address on the NIOS says by pass the cache). If you use the bit 31 method you simply need to modify the base addresses before you use them.   The rest is all compiler and header file updates. Some of that you have to do anyway since you have to go to the new compiler with NIOS II.   On note of caution on the dcache however. If found 1 case where the dcache was corrupting my data. We debugged for a number of days assuming it was SDRAM (with Altera on site helping for part of it). Turned out that a 512 byte cache was selected and not working. Changed to 2K and all of the problems resolved.   Dan

[Altera_Forum]

jesse, danc  

Thanks a lot for such detailed description. I&#39;ll try to follow your advices. The only reason for me to use legacy sdk is in the small size of code footprint of generated software. I&#39;m building system with TCP/IP network (feat by lan91c111:). And when I use old plugs library I can fit all code to onchip memory of Stratix1S10 device.  I have build such sistem for Nios CPU. So when NiosII was released I try to migrate to all brand new: NiosII CPU, NiosII IDE and lwIP tcp/ip stack realization. But unfortunately code footprint even for standalone lwIP realization is near 250Kb that is ten times bigger that my previous plugs tcp/ip realization (approx 24Kb). I decide to try to use old sdk but with new CPU and with new tools cause new tools is much more convenient for software development. So if anyone can give me a pice of advice how to reduce code foot print for standalone lwIP library I will immediately stop to use old sdk.

[Altera_Forum]

The official line from Altera is: 

 "In the past, Altera produced a simple, proprietary networking stack called PLUGS for use with the Nios I processor. This stack was created out of necessity because (at the time) there were no other readily usable, cost-effective alternatives which we could provide to customers. PLUGS, however, was never a functionally complete networking stack and never fully implemented the TCP/IP protocol. With the release of the Nios II processor, a conscious decision was made to provide users with a super-set of the functionality found in the Nios I development system, networking stack included. During the Nios II development effort (c.a. 2003), we found that an open-source networking stack existed called Lightweight IP (LWIP), which was far more robust in protocol support and compliance to existing network RFCs. In order to provide our customers with the best possible networking stack solution for the Nios II processor, we decided to drop our existing PLUGS networking stack and adopt the LWIP solution. All Nios I customers migrating to the Nios II processor are strongly encouraged to adopt the LWIP solution- they not only will get continued support and bug-fixes for this stack from Altera, but also their applications will also benefit from the services provide by a robust networking stack. Customers wishing to use the PLUGS networking stack on the Nios II processor do so at their own risk."  In short if you want a fully functional Altera supported TCP/IP stack, you will need to migrate to LWIP. In particular, you will need to do this if you want reliable TCP.  If you are only using a subset of the available protocols, then it is possible to configure LWIP so it doesn&#39;t include unecessary code. When using the MicroC/OS-II version this is done through the "Software Components..." button on the system library properties page. Note that additional options are available if you expand out the "Lightweight TCP/IP Stack" option on the left hand side of the window.  Options that are particularly important in terms of code footprint are the "Memory Options". You may also want to consider disabling TCP support if you are only using UDP (for example).  These same options are also available for controlling footprint when using the standalone version of the LWIP stack. I&#39;m not familiar with how those are presented, but I imagine that they are set in the lwipopts.h file.