I am looking at modifying the NiosII ethernet examples to support the reduced pin configuration (only 24pins vs 72) of the Lan91C111 daughtercard that altera seems to have abandoned. QuartusII4.1 supports adding the component, but Eclipse gives a linker error about not supporting this configuration. At first glance it looks like only the two associated driver files would need to be modified.I know that this card worked under NiosI, but with different drivers/sw. Is anyone familiar with this card, or if the hw module for this configuration should work under NiosII/uCos/Lwip once a proper driver is written? Is it possible for users to add new components to the NiosII HAL?.
tns asked"Is it possible for users to add new components to the NiosII HAL?." Yes, and if you look in the Nios II Software Developers Handbook Chapter 5 tells you how to go about this. "I know that this card worked under NiosI, but with different drivers/sw. Is anyone familiar with this card, or if the hw module for this configuration should work under NiosII/uCos/Lwip once a proper driver is written? " It should be possible to modify the existing driver to work with this card. If you modify the existing driver then from memory I think you need to look at the routines which transfer data to/from the lan91c.
In addition to what rugbybloke said:No, we didn't ship support for the older daughter cards with the IDE/HAL drivers as these cards came & went before Nios II; all of our current dev boards use the Ethernet interface soldered to the dev board. However it shouldn't be too much work to make the changes yourself. Really the main difference WRT software drivers is the data bus size; 32 bits for the dev board vs. 16 for the daughter card. I suggest that you look in the *legacy* lan91c111.c file (in the sdk folder) and look for# ifdef's called "DATA_BUS_WIDTH" (or something similar); just grep the file for all instances of this and you'll see the 32-bit bus code along with its 16-bit counterpart; you could then use this as a guide to apply equivalent changes to our new HAL driver (altera_avalon_lan91c111.c, in the UCOSII folder).
Hello mountain8848,You will find the needed information in the “Nios Ethernet Development Kit User Guide” which is available from: http://www.itc-electronics.com/cd/altera%2.../ug_niosedk.pdf (http://www.itc-electronics.com/cd/altera%2010005/ug/ug_niosedk.pdf) Bye, niosIIuser
I've got a modified lan91c111 component that I've gotten to work with the mentioned 91c111 daughtercard in SOPC Builder and Nios II IDE. The only changes are to the data width in the driver and component .ptf file. I've posted the component to the "Post your own IP" section of the forum athttp://www.niosforum.com/forum/index.php?a...t=st&f=15&t=466 (http://www.niosforum.com/forum/index.php?act=st&f=15&t=466) Note that Altera doesn't officially support this modified component, but it works for me and should get you going. Just unzip it in C:\altera\kits\nios2\components (or the equivalent if you've installed NiosII in a different location), then add it to your system in SOPC builder as you would the standard 91c111 component.
I cannot get your files to generate properly. I replaced the existing component folder and deleted my old lan module, then added the new one (same name). SOPC completes the generate step without ever seeing the lan module. It shows up in the updated bsf symbol, but the project will not compile. I'll try again tomorrow.thanks
The problem was not with the new files. I replaced the original component files and found the same thing. During a Generate, a message is kicked out for every component except the lan91c111. Puzzling since it does appear on the updated NiosII symbol, the project compiles, and so far things are working.
Aside from the PDF document mentioned above, is there an actual schematic for this card?Nate, how did you make the pin assignments for your modified code? I am following the daughtercard docs for a 32bit CPU and I see you have reduced the address bus to [3..0] so I cannot use A2,A3,A4 as described. I believe your code requires the use of a byte enable as well. I went ahead and use A1,A2,A3 (16bit cpu config) and most of the code does execute OK. The telnet example I am trying doen't crash, but I do see some incorrect accesses. It looks like all short accesses are converted to two byte accesses. I see accesses to odd offsets which I don't think will write correctly without the byte enable. Anyway, let me know what your test configuration was. thanks,
I did get the posted driver code to work for me with some changes.My hw had some problems initially, so you may just want to try the code as is. I believe for the posted code, you will need to connect A1,A2,A3 and SBE0,SBE1. The registers will be on 16bit boundaries. If you want to go the route I went, do the following: My interest was in a minimal pin count interface (24pins). You could also save another 8pins using an 8bit bus. I followed the CPU32 connection scheme for 16bit bus using A2,A3,A4 and SBE1#. This places all registers on full word boundaries. I changed the class.ptf to use native rather than dynamic address alignment. I modified the ..regs.h file to support the above changes. There were a few fixes needed in the alignment code of the low level data transfer functions, and the mac address/ip address code. For simplicity, turn off dhcp in LWIP and use a static IP to test with.