NIOS II and ASMI

Altera_Forum · ‎10-26-2004

Folks,

Why is the ASMI interface considered a "legacy" peripheral in NIOS II when it has a set of functions in the NIOS II kit? Is anybody using this component with success in NIOS II?

Altera_Forum · ‎10-26-2004

> Why is the ASMI interface considered a "legacy" peripheral in NIOS II when

> it has a set of functions in the NIOS II kit?

I'm not sure ... aside from the new bootloader feature (and associated memory),

the epcs interface behaves the same as the original asmi. I'm using the same

code for the epcs component that I used for asmi.

> Is anybody using this component with success in NIOS II?

I'm using the new epcs component in Nios-II .... without any problems. But I'm not

using the bootloader feature yet ... just the original asmi interfaces for non-volatile

storage of various config data.

Regards,

--Scott

Altera_Forum · ‎10-27-2004

smcnutt,

What did you do about the include path for the Fn calls? I seem to be missing a step in converting to using HAL, I have had to install lots of includes to reach the Fn protos for HAL devices. The system.h does not have the correct linkages to get to the HAL devices. The data sheet for the ASMI device does not cover this.

Thanks

Altera_Forum · ‎10-27-2004

Hi Edward,

I'm not a big fan of the HAL ... so I don't use it ... especially when I see things in the

manuals like:

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

--- Quote Start ---

Altera does not publish the usage of the control and data registers. To access the

EPCS device, you must use the HAL drivers provided by Altera.[/b]

--- Quote End ---

(emphasis added)

From a programming point-of-view, the ASMI peripheral is just an SPI interface with a

flash eeprom hanging off it. So the control/data register usage is, in reality, published.

Regardless, I use my own code and avoid any associated HAL compile/link-time issues

... and any artificial restrictions that may be present in the "secret" HAL implementation ;-)

Regards,

--Scott

Altera_Forum · ‎10-27-2004

Scott,

Thanks for the info. Did you roll your own because you could not get the supplied functions working? I am trying to use the supplied functions to save time. For some reason the ASMI is not very well documented in the NIOS II kit. There are no examples and I cant seem to get the library to link in. I seem to be missing a step or an include or whatever that allows the underlying code to be included and linked in. The altera_avalon_asmi is present in the Nios II Device Drivers tree in the IDE, but I have to put an explicit include in my source file to get a compile:

# include "C:\altera\kits\nios2\components\altera_avalon_asmi\sdk\asmi_struct.h"

Altera_Forum · ‎10-27-2004

Hi Edward,

>Did you roll your own because you could not get the supplied functions working?

No ... I never tried the supplied functions. I implemented the interface as part of u-boot

with Nios-32 ... before the IDE, and epcs programming via JTAG, etc. etc. So I just brought

the code forward and continue to use it with Nios-II.

And, as you may have detected ... it bothers me when I'm told I "must" use vendor-supplied

drivers ... I've been burned too many times 8-(

> There are no examples and I cant seem to get the library to link in.

If it's any help, you can download the u-boot code and see cpu/nios2/epcs.c:

http://www.psyent.com/download (http://www.psyent.com/download)

Regards,

--Scott

Altera_Forum · ‎10-28-2004

To answer your original question, the only big differences between the EPCS and ASMI cores are the inclusion of boot support and the HAL software interface.

If you are using the altera_avalon_epcs_controller peripheral you can simply read and write the EPCS device using the HAL flash API. For example using alt_flash_open_dev(), alt_read_flash(), and alt_write_flash(). Details are given in chapter 4 of the Software Developers Handbook.

Nothing is particularly "secret" here. All of the source code has been made available, so that if the published interface doesn't meet your needs, it's easy for you to change the code.

However sticking to the higher level published API is recommended simply to save you time. It will save you time in the short term, since you won't have to reinvent the wheel, and it will save you time in the long run since it's that interface that Altera wil try hardest to maintain in future versions of the kit.

In this particular case it also means that you will be able to use the same application code to read/write bulk data regardless of whether you store it in an EPCS or CFI flash device, or future devices that will be supplied with HAL flash drivers.