[En-Nut-Discussion] FW: AVR32 / ARM support

[Thiago A. Corrêa]

Hi Johan,



On Tue, Sep 28, 2010 at 9:34 AM, Johan van der Stoel <johan at streamit.eu> wrote:
>
> I tried to find at the ethernut website and wiki, but could not find answers
> on my questions. So I decided to make a posting as I think this question can
> be interesting as well for other users.
>

     In our company, we plan to migrate all of our mega128 designs
using ethernut to the AVR32 UC3A0 devices, and we also have just
finished building a board with UC3B164. So, I should be supporting it
for a while.

>
> We are investigating to start developing of a new platform for our internet
> audio products. Currently we use the ATMEGA2561 and ATMEGA128 devices,
> mainly based on Ethernut 1. And.. Nut/OS of course. We have developed lots
> of application modules and also written some own drivers.
>
>
>
> Our new platform should - of course - be more powerful and we considering
> whether we should use Nut/OS again or move to another platform. As we know
> Nut/OS quite well, our preference would be Nut/OS but we have some questions
> left.
>
> 1.       Which ARM and AVR devices are actively supported by the community
> yet; is there somewhere an overview where the limitations are?


Ulrich is working with Cortex-M3 port in a branch, and others have
been using the SAM arms. All of the MCUs used in the Egnite boards
should be well supported.
There is also the AVR32 that I should be able to support.

> 2.       We want to have more advanced support of Ethernet devices and
> networking; currently we use RTL8019, but in our new platform we want to be
> able to support devices with MII / RMII interfaces and also switches with
> this kind of interfaces, like the Micrel KS8993 and KS8995. In the postings
> I have read about some limitations; is someone able to comment on the
> complexity once we decide to proceed with this?

I don't have too much experience with this, except from what I learned
porting the MAC driver for the AVR32. But it looks like those switches
behave just like a normal PHY when using the MII/RMII interface. I
have only briefely looked at the datasheets though.
PHY devices seems to implement a common command interface. The only
part of Nut/OS that I'm aware that prevents from using a different phy
is the initialization. It queries the device ID to make sure it's what
it expects. The expected value can be configured with nutconf, or the
verification can be disabled entierely (for AVR32 and some ARMs).


> 3.       IPv6 support.
>

I would like to see that as well :)

>
> I look forward to receive some comments (either privately or through the
> mailing list). As well from experienced Nut/OS developers who are interested
> in - for example - developing of Nut/OS drivers for our new platform.
>


Perhaps some of those will overlap with what I still need to implement
for our board :)

Kind Regards,
    Thiago A. Correa