[En-Nut-Discussion] Ethernut port for AVR32
Thiago A. Corrêa
thiago.correa at gmail.com
Fri Aug 21 20:05:59 CEST 2009
>> > Now, here are a few Qs:
>> > 1. Is the AVR32 (UC3A) port stable?
> I am concerned about the core functionality of the port. The context switch, memory management and anything else that comes to mind. More specific to the OS itself. If thats good, then there should be no problems.
> I am not much concerned about the drivers though (at least, if I want to use it). I have a bunch of drivers written for the platform. I have been working on these devices for quite some time now. Let me see, if I can so something about writing drivers for the port itself.
The context switching is working well, memory management seems fine
too, although I didn't do stressing on that. I did ran the threads
example for quite a while to test context switching, but memory
management doesn't have an specific sample app to test. The fact that
the httpd sample worked is a good sign that things are working
properly hehe. The only thing missing is critical neasting, which
isn't used by Nut/OS itself and non-volatile storage. At first I
thought about using the USER PAGE in flash, but it's too small to what
I need, so I was going to use serial flash in my projects. So, the
embedded flash controler code wasn't tested, but it should work. Might
need some tweaking though.
>> > 2. When do we expect the port be available in the main
>> line code?
>> Probably it will be in the next release, but you could try
> Any idea, when would be that?
Harald usually anounces here. It looks like one beta is out, so it
shouldn't take too long. I tend to use the svn code most of the time,
it's usually stable. Besides, unless something gets checked in there,
the release is just an svn snapshot :)
> Let me see, if I can get the code working on my custom hardware. That ways we would have tested it on the non-ES versions.
Let me know if you need some help.
>> I've been a
>> bit busy with an AP7000 project, but will get back to the
>> UC3 port as
>> soon as possible.
> I have worked on AP7000 standalone project and have a few NGW100 boards lying around. Please do let me know, if you plan to have a port for these devices. I will be more than happy to help and share my experiences. I have not worked on NUT/OS before, so not very familiar with it. But, that should be ok.
This project I'm finishing is linux based, but I was trying to keep
things working for AP7000 in my Nut/OS code as well. You should notice
some __AP7000__ defines here and there. Unfortunally, the toolchain
from atmel has differences for each chip, even though the hardware is
just the same, like different constant names in defines, which makes
it a bit harder to write code that is portable. On the bright side,
they seem willing to fix those issues. I complained with them about
one such case with the Watchdog I think, and the fix got out in the
2.1 or 2.2 toolchain release.
It's been a while, so forgive my weak memory.
Actually I have some AP7000 compile fixes hanging here that I still
haven't checked in. But those doesn't fix the whole thing, it just
gets the compiler further untill it hits another such AP vs UC3
toolchain naming differences. Right now my priority is UC3, but I
would be glad to help anyone willing to work with the AP processors.
Thiago A. Correa
More information about the En-Nut-Discussion