Nabble - MicroControllers - Ethernut

Submit some patches

2009-11-25T11:02:38Z

hi everyone,

my first post here...
I have inherited a firmware project that was based on ethernut 4.0.1.
This project contains a number of modifications to the Nut/OS, which I
dont know if they were ever submitted as patches or not. I have merged
the patches with 4.8.5 and tested them. They work well, so I have
submitted them to sourceforge in the patch area. Please evaluate the
utility and applicability of them.

They are:

1. fix to nut\crt\write.c to guarantee serialized access to the
write used in fputs.c. this prevents multiple threads from interleaving
characters
2. fix to \nut\pro\dhcpc.c - modification to DHCP client code so
you can switch between DHCP and static IP addresses without
resetting/power cycling.
3. fix to nut\net\ifconfig.c - modification so NutNetIfSetup()
doesn't save settings to the EEPROM. This was using up the available
memory writes for the eeprom part since it happens each time the unit
powers up. Code was added to the application to determine when the
network information should be saved in the EEPROM. This might impact
compatibility, so maybe this needs to be implemented as a parameter to
this function.

thanks

Rich

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Hardware combo of Ethernut 1.3h & 2.1b

2009-11-25T02:58:37Z

Hi!
What of this ways are prefer? And where i can get an xc9636xl source,
if it possible? Ty!

2009/11/9 Harald Kipp <harald.kipp@...>:

> asdus wrote:
>> Can i use ethernut 2.1b schematic, but exchange ethernet part with one
>> from 1.3h?
>> Just RTL8019 + FB2022 instead of LAN91C111 + TG110
>
> Not one to one. On Ethernut 1 the Realtek is at address 0x8300 to 0x831F
> (using the Realtek's internal address decoder). On Ethernut 2 this
> region is occupied by RAM:
>
> http://www.ethernut.de/en/hardware/enut2/memmap.html
>
> You may either use the Ethernet Controller chip select from the CPLD and
> set the RTL8019 address pins to 0x_300 or connect A14 *and* A15 to the
> inputs of IC7. This will map the Realtek to 0xC300.

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: A few network related feature polls

2009-11-23T17:54:58Z

On Mon, Nov 23, 2009 at 04:21:56PM +0100, Harald Kipp wrote:
> Bernd Walter wrote:
> > My target is to get 6LoWPAN including forwarding from Ethernet running.
> > Hardware is a AT91SAM7X256/512 with CC2420 Module.
>
> Interestingly we at egnite plan something similar. Our first idea was to
> implement ZigBee, but license issues makes this far less attractive.

That was the same reason why I never used ZigBee, but the ZigBee
modules always had been quite atractive.
About half a year ago I first heared about 6LoWPAN and was very excited,
because it was IP and I work with IPv6 since about 10 years.

> > So far I have two options available.
> > - Run a uIP thread on Nut/OS and catch all IPv6 packet.
> > - extend Ethernut to every required feature
>
> Adam's license fits well and we can probably steal a lot from his code
> to extend the Nut/OS stack.

At least the MAC code should be able to port without problems and I
hope a lot of the header compression code can be taken as well.

> > The second is a lot more work, but more attractive in the long run.
> > Basicly it is a list of many features, which I'm unsure about current
> > development status.
> > The main points are:
> > - running multiple interfaces with multiple IPs
>
> A little bit tricky, but not too difficult. At least routing is already
> prepared for more interfaces.

Well IPv6 is a bit more tricky if done completely.
Additoonal to the 128bit address you have a scope, which is a local
interface number.
Every packet parsed locally has to take the scope into account because
the scope tells on which interface to send the answer back.
The scope is technically nothing more than an index to the local
interface extending the addresses within the OS.
An interface have multiple addresses by design.
You always have a link-local address in the fe80::/64 range.
You usually want a routable IP address as well.
You should handle multicast address for everyhost and 6LoWPAN routers
also need to handle neighbor discovery related multicast addresses.

I think I will start adding a uIP thread to Ethernut.
Having a working reference would be good I asume.
Then start with adding hosts running native stack, which neither require
routing nor multiple interfaces.

> > - forwarding packet between networks
>
> dito.
>
>
> > - IPv6 packet format in general
> >
> > I know that IPv6 is not available, but it was often discussed and what
> > about the other points?
>
> Exactly.
>
> I'm only unsure about the release. We have 4.9 beta available for some
> time now. Actually I'd prefer to have 4.10 (or 5.0?) out first, before
> starting to add such a modification like IPv6. There is still some
> clean-up work to be done (mainly the docs) for the next stable version.
> I'd also like to have the qt based configurator and stable AVR32 builds
> as well.

Well for me that's a different thing :)

--
B.Walter <bernd@...> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: A few network related feature polls

2009-11-23T17:16:31Z

Hi,

On Mon, Nov 23, 2009 at 1:21 PM, Harald Kipp <harald.kipp@...> wrote:
> Bernd Walter wrote:
>> My target is to get 6LoWPAN including forwarding from Ethernet running.
>> Hardware is a AT91SAM7X256/512 with CC2420 Module.
>
> Interestingly we at egnite plan something similar. Our first idea was to
> implement ZigBee, but license issues makes this far less attractive.
>

I'm also interested in an 6LoWPAN implementation in Nut/OS. Is the
merge with btnut still on the horizon? Perhaps we should think on a
radio interface implementation as we have for the ethernet so drivers
implement a common API and we can choose different radio chips.

>> So far I have two options available.
>> - Run a uIP thread on Nut/OS and catch all IPv6 packet.
>> - extend Ethernut to every required feature
>
> Adam's license fits well and we can probably steal a lot from his code
> to extend the Nut/OS stack.
>

Last I saw there was some heavy development, specially at the routing
level. Is it stable now?

>> The second is a lot more work, but more attractive in the long run.
>> Basicly it is a list of many features, which I'm unsure about current
>> development status.
>> The main points are:
>> - running multiple interfaces with multiple IPs
>
> A little bit tricky, but not too difficult. At least routing is already
> prepared for more interfaces.
>

I guess we should include a Nut Configurator option, to keep the
binary size down for those who don't need it. I for one can see myself
building both routed and unrouted versions for different products.

>> - IPv6 packet format in general
>>
>> I know that IPv6 is not available, but it was often discussed and what
>> about the other points?
>

It was a requested feature from way back. I know very little about
IPv6, but I've been trying to study a bit.

>
> I'm only unsure about the release. We have 4.9 beta available for some
> time now. Actually I'd prefer to have 4.10 (or 5.0?) out first, before
> starting to add such a modification like IPv6. There is still some
> clean-up work to be done (mainly the docs) for the next stable version.
> I'd also like to have the qt based configurator and stable AVR32 builds
> as well.
>

The qnutconf is missing a Delegate (so it will show radio icons on the
tree instead of a checkbox icon) and create proper editor widget
(qcombobox) for the multiple choice options and spinbox for the
integer options. Other than that, tweaks here and there, and the part
that generates the sample tree. It actually builds already, but with
the missing custom delegate, some choices are unavailable for
modification.

Are you aware of problems with the AVR32 build?

Kind Regards,
Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: A few network related feature polls

2009-11-23T07:21:56Z

Bernd Walter wrote:
> My target is to get 6LoWPAN including forwarding from Ethernet running.
> Hardware is a AT91SAM7X256/512 with CC2420 Module.

Interestingly we at egnite plan something similar. Our first idea was to
implement ZigBee, but license issues makes this far less attractive.

> So far I have two options available.
> - Run a uIP thread on Nut/OS and catch all IPv6 packet.
> - extend Ethernut to every required feature

Adam's license fits well and we can probably steal a lot from his code
to extend the Nut/OS stack.

> The second is a lot more work, but more attractive in the long run.
> Basicly it is a list of many features, which I'm unsure about current
> development status.
> The main points are:
> - running multiple interfaces with multiple IPs

A little bit tricky, but not too difficult. At least routing is already
prepared for more interfaces.

> - forwarding packet between networks

dito.

> - IPv6 packet format in general
>
> I know that IPv6 is not available, but it was often discussed and what
> about the other points?

Exactly.

I'm only unsure about the release. We have 4.9 beta available for some
time now. Actually I'd prefer to have 4.10 (or 5.0?) out first, before
starting to add such a modification like IPv6. There is still some
clean-up work to be done (mainly the docs) for the next stable version.
I'd also like to have the qt based configurator and stable AVR32 builds
as well.

Any other opinions?

Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

A few network related feature polls

2009-11-21T15:47:58Z

My target is to get 6LoWPAN including forwarding from Ethernet running.
Hardware is a AT91SAM7X256/512 with CC2420 Module.

So far I have two options available.
- Run a uIP thread on Nut/OS and catch all IPv6 packet.
- extend Ethernut to every required feature

The first point sounds easy since there is uIP code for 6LoWPAN with
CC2420 available.
The bad side is that this requires a rewrite of all applications
because IPv6 and IPv4 services use different client API.
Likely I will do this anyway to have a reference design available and
start doing simple services.

The second is a lot more work, but more attractive in the long run.
Basicly it is a list of many features, which I'm unsure about current
development status.
The main points are:
- running multiple interfaces with multiple IPs
- forwarding packet between networks
- IPv6 packet format in general

I know that IPv6 is not available, but it was often discussed and what
about the other points?

--
B.Walter <bernd@...> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: support for SD-HC cards

2009-11-21T12:03:06Z

Hello Malte,

> But the changelogs does not say anything about sd-hc, so I think its
> not
> included yet.
> Would someone be so kind, to tell me where I can find the modifications
> or send them to me?

October 2008 I send the modifications in phatdir.c and phatfs.c (support for
SD-HC and some small fs enhancements). Harald and Ole looked into these
modifications but that was the last thing I heard about it. There is still
some other work to do when it comes to improve the current filesystem.
Although we use it without too many problems in our streaming-audio
applications, we would like to speed up the write routines. But SD-HC
support is working fine as well as the support for long filenames.

Kind regards,

Rob van Lieshout

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

support for SD-HC cards

2009-11-20T11:12:23Z

Hello,
I found in several messages in the mailinglist archive, that there are
modifications to support SD-HC cards:
http://lists.egnite.de/pipermail/en-nut-discussion/2008-April/009258.html
http://lists.egnite.de/pipermail/en-nut-discussion/2009-February/010325.html
But the changelogs does not say anything about sd-hc, so I think its not
included yet.
Would someone be so kind, to tell me where I can find the modifications
or send them to me?

Regards,
Malte
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-19T17:53:22Z

On Wed, Nov 18, 2009 at 05:21:25PM +0100, Ole Reinhardt wrote:
> Hi Ulrich,
>
> > I come back to your code next week. I'd like to implement PDC/DMA for
> > the network and the SPI channels. If supported, I'd like to implement it
> > for a background memcpy too.
>
> Background memcopy won't work, as the PDC does not support
> memory<->memory dma.

Not directly, but there are IO functions which have internal loopback
support - at least USART would do.
Unless you use that function for real IO it can be harnessed to
copy data.
But you need to be carefull - byte level IO does byte access to memory,
while a CPU driven copy would access long words.
Depending on the actual overhead for reading opcodes it might be
less efficient.

--
B.Walter <bernd@...> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-19T11:00:31Z

Hi!

That would be great. I started with a local version for my OLED too, but
I missed to take my scope with me. So no timing tests possible and then
the day turned into a meeting day... Uah...
Didn't get anything done...

Bye, Ulrich

Ole Reinhardt schrieb:

> Hi!
>
>> Hihi, with my radio driver I was experimenting on that. I first need to
>> send out 2 bytes for the chipset to set it to the right mode, then I
>> have to send the complete radio packet. So I tried a double buffer DMA,
>> programming the first page for 2 bytes of the command and the second
>> pointer pair points to the data buffer.
>>
>> But I didn't get it to work, as I had not enough time to figure out how
>> to enable the PDC support or what to do with these pipes mentioned in
>> the PDC driver version. I'll keep on as I have time.
>
> If you mind and I find it again, I could send you a short example
> routine that uses SPI with PDC. It's not encapsulated in a NutOS driver
> but a simple routine to communicate with a LCD display.
>
> Bye,
>
> Ole
>

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: [Bulk] Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-19T02:39:10Z

Hi!

> Yes if it works, it can be a great speed improvement. But it is
> difficult to implement in an 'intelligent' way, as Ole stated in this
> thread. Setting up 10 PDC registers doesn't make sense if you need to
> transfer to bytes only :)

Especial if you have an end of transfer interrupt you still need to
calculate the thread switch latency if the CPU was given up to another
thread in the meantime.

Bye,

Ole

--
_____________________________________________________________
| |
| Embedded-IT |
| |
| Ole Reinhardt Tel. / Fax: +49 (0)271 7420433 |
| Luisenstraße 29 Mobil: +49 (0)177 7420433 |
| 57076 Siegen eMail: ole.reinhardt@... |
| Germany Web: http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-19T02:35:04Z

Hi!

> Hihi, with my radio driver I was experimenting on that. I first need to
> send out 2 bytes for the chipset to set it to the right mode, then I
> have to send the complete radio packet. So I tried a double buffer DMA,
> programming the first page for 2 bytes of the command and the second
> pointer pair points to the data buffer.
>
> But I didn't get it to work, as I had not enough time to figure out how
> to enable the PDC support or what to do with these pipes mentioned in
> the PDC driver version. I'll keep on as I have time.

If you mind and I find it again, I could send you a short example
routine that uses SPI with PDC. It's not encapsulated in a NutOS driver
but a simple routine to communicate with a LCD display.

Bye,

Ole

--
_____________________________________________________________
| |
| Embedded-IT |
| |
| Ole Reinhardt Tel. / Fax: +49 (0)271 7420433 |
| Luisenstraße 29 Mobil: +49 (0)177 7420433 |
| 57076 Siegen eMail: ole.reinhardt@... |
| Germany Web: http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: [Bulk] Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-18T15:37:03Z

Hi!

Marcus Jansson schrieb:
> Ulrich Prinz wrote:
>>> Marcus Jansson schrieb:
>>>> I'd like to implement PDC/DMA for the network and the SPI channels.
>>> This can be done, the SPI seem to have a long list of errata associated with the PDC, though.
>>>
>> Yes, I saw it and I don't like it :) But what should I do, I'd like to
>> get out optimal performance...
>
> All I see is an opportunity clever workarounds.

Yea, read the part today and was not so upset as I feared. There are
only a few erratas about SPI and PDC and mostly problems with CS1 or
different timing setups ( SPI timer and CPOL). In my system, CS1 is not
used for any device and CPOL is the same for all devices. So there
should be no problem. It is some more work to detect these situations
that possibly crash in a general Nut/OS version. If you write an open
source driver, it should be more comfortable... or have #warning or lots
of comments...

>
>>>> If supported, I'd like to implement it for a background memcpy too.
>>> I can not see how this can be done with the PDC ...hand optimized LDM/STM block copy ... existing
>>> slow memcpy()... increasing performance in internal RAM?
>>>
>> Yeah ... optimization ... CPU driven memcpy ... many different tasks...
>> It's another strategy... DSP ... DMA ... modify the content ... chain
> > ... pipe ... totally different ... 12MBit ... polling mode No!...
>
> Yes, that should be possible. I wasnt thinking out of the box.
> These pipes btwn ETH-unit and SPI are totally different.
> The CPU will mostly wait for DMA to be finished! Lots of power left for other
> things to do. Very good.

Yes if it works, it can be a great speed improvement. But it is
difficult to implement in an 'intelligent' way, as Ole stated in this
thread. Setting up 10 PDC registers doesn't make sense if you need to
transfer to bytes only :)

Best regards, Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-18T15:32:29Z

Hi Ole,

Ole Reinhardt schrieb:
> Hi Ulrich,
>
> Background memcopy won't work, as the PDC does not support
> memory<->memory dma.
The data sheet is a bit unclear in that point, but I figured out that is
doesn't work too. Doesn't harm the actual application. IN most cases 90%
of the buffer content needs to be created or modified and instead of
writing it back I can write it to the new position as well.
>
> And always keep in mind the overhead for the pdc. Especial with the SPI
> I implemented PDC for the SPI function and these became notably slower
> as polling mode when just sending small data packets.
>
Yes, that's an important point. I didn't mention that as it was obvious
that is doesn't make sense to preset 10 registers if you have to send
out only two bytes.

> Having both possibilities and an automatic decision which of them to use
> would be nice.

Hihi, with my radio driver I was experimenting on that. I first need to
send out 2 bytes for the chipset to set it to the right mode, then I
have to send the complete radio packet. So I tried a double buffer DMA,
programming the first page for 2 bytes of the command and the second
pointer pair points to the data buffer.

But I didn't get it to work, as I had not enough time to figure out how
to enable the PDC support or what to do with these pipes mentioned in
the PDC driver version. I'll keep on as I have time.

Regards, Ulrich

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-18T08:21:25Z

Hi Ulrich,

> I come back to your code next week. I'd like to implement PDC/DMA for
> the network and the SPI channels. If supported, I'd like to implement it
> for a background memcpy too.

Background memcopy won't work, as the PDC does not support
memory<->memory dma.

And always keep in mind the overhead for the pdc. Especial with the SPI
I implemented PDC for the SPI function and these became notably slower
as polling mode when just sending small data packets.

Having both possibilities and an automatic decision which of them to use
would be nice.

Bye,

Ole

--
_____________________________________________________________
| |
| Embedded-IT |
| |
| Ole Reinhardt Tel. / Fax: +49 (0)271 7420433 |
| Luisenstraße 29 Mobil: +49 (0)177 7420433 |
| 57076 Siegen eMail: ole.reinhardt@... |
| Germany Web: http://www.embedded-it.de |
|_____________________________________________________________|

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: [Bulk] Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-18T06:26:11Z

Ulrich Prinz wrote:
>> Marcus Jansson schrieb:
>>> I'd like to implement PDC/DMA for the network and the SPI channels.
>> This can be done, the SPI seem to have a long list of errata associated with the PDC, though.
>>
> Yes, I saw it and I don't like it :) But what should I do, I'd like to
> get out optimal performance...

All I see is an opportunity clever workarounds.

>>> If supported, I'd like to implement it for a background memcpy too.
>> I can not see how this can be done with the PDC ...hand optimized LDM/STM block copy ... existing
>> slow memcpy()... increasing performance in internal RAM?
>>
> Yeah ... optimization ... CPU driven memcpy ... many different tasks...
> It's another strategy... DSP ... DMA ... modify the content ... chain
> ... pipe ... totally different ... 12MBit ... polling mode No!...

Yes, that should be possible. I wasnt thinking out of the box.
These pipes btwn ETH-unit and SPI are totally different.
The CPU will mostly wait for DMA to be finished! Lots of power left for other
things to do. Very good.

/Marcus
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-17T10:47:42Z

Hi,

On Tue, Nov 17, 2009 at 4:33 PM, Ulrich Prinz <uprinz2@...> wrote:
>>> I'd like to implement PDC/DMA for the network and the SPI channels.
>> This can be done, the SPI seem to have a long list of errata associated with the PDC, though.
>>
> Yes, I saw it and I don't like it :) But what should I do, I'd like to
> get out optimal performance and why carrying bytes by hand if these is
> an automated way for the background.

I saw a similar question on the Linux mailing list. It was more like,
which driver one was supposed to use, and their answer as to use the
gpio driver, as the atmel spi driver never worked reliabily.

>> What was the reason for not having Thumb code in Nut/OS?
>
> I never thought about that and I wasn't in the project at the time where
> these decision was made. So you have to ask Harald for that.
>

I believe that has been asked before. Looks like parts of the lib
could be compiled with Thumb, and the user code could also be thumb.
But I don't use ARM, so I know very little about that.

Kind Regards,
Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-17T10:33:07Z

Hi!

Marcus Jansson schrieb:
> Ulrich Prinz wrote:
>> I'd like to implement PDC/DMA for the network and the SPI channels.
> This can be done, the SPI seem to have a long list of errata associated with the PDC, though.
>
Yes, I saw it and I don't like it :) But what should I do, I'd like to
get out optimal performance and why carrying bytes by hand if these is
an automated way for the background.

>> If supported, I'd like to implement it for a background memcpy too.
> I can not see how this can be done with the PDC, unless you're talking about a memcpy() to/from memories (possibly
> eeproms) connected to the SPI or similar. Otherwise a hand optimized LDM/STM block copy loop instead of the existing
> slow memcpy() might be in order for increasing memcpy() performance in internal RAM?
>
Yeah, there might be an optimization chance in the code for the CPU
driven memcpy. But most systems do many different tasks. So why block
the CPU with some dump copy while other things that need calculation
work have to wait. And it doesn't make programming much more complex.
It's another strategy behind the programming style, more DSP way. SO
something ist giving you an interrupt and you setup DMA to fetch the
data into a buffer_1. After DMA finishes, you setup a function to modify
the content at special places, lets say filling in certain data into
certain positions. Then you setup DMA to copy the buffer over to another
functions buffer to fill in other data or preparation of frame
information. This can be repeated many times until the chain reaches a
point where everything is prepared and the data can be send to another
device like TCP or IIS or whatever. This can also be done via DMA.

Now, while this DMA chaining doesn't make sense if you only have one
buffer and slow incoming data, it important for situations where you
have several of each buffer in parallel. While receiving in buffer 1,
copy out of buffer 0. While decoding in the first functions buffer 0,
transfer decoded data to buffer 1 of second function.

The style of programming is then totally different as it is in Nut/OS
now, as you program functions as interrupt requests. The software is
controlled by the data moving through it and not the other, normal, way
round.

It's sort of DSP programming where you attach handlers to the buffers,
the so called pipes.

In my case I have to route radio packets the often only need another
header in front of existing data. Instead of creating another buffer of
the size of the packet plus the packet itself, filling in the new header
and attaching the packet with memcpy, I simply create a new buffer, add
the header in front and DMA-copy the packet into the tail. With the DMA
Interrupt I setup another DMA throwing the new packet through SPI to tha
radio chipset.

There is another way of handling this. I setup a table of pointers
collecting a radio packet and it's different headers out of the memory.
But then I have to carefully track each pointer operation and have to
check if another header exists and so on. It will save some time but I
have to track a lot. The previous DMA wakes DMA is much more elegant and
the CPU can do lots of other things while the DMA works in background.

There is another reason for DMA. The SPI to the radio chipset can run at
12MBit plus. You cannot put data fast enough together if you try to do
that in polling mode... I guess that even on 4MBit I have larger gaps
between the packets where the CPU is busy with fetching bytes.

> What was the reason for not having Thumb code in Nut/OS?

I never thought about that and I wasn't in the project at the time where
these decision was made. So you have to ask Harald for that.

Best regards, Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Maybe obvious ...

2009-11-17T06:16:03Z

Hey, seems that it wasn't all that obvious ;-)
Thank you very much for sharing.

Ciao
Paolo

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Propox board for Sam7X, Good or Bad?

2009-11-16T10:44:11Z

Hi All,

Does anyone have experience with Propox? Their website has a copy of
Ethernet 3.8, or some such. My engineer likes the 16x2 LCD available.

*E
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-16T05:25:59Z

Ulrich Prinz wrote:
> I'd like to implement PDC/DMA for the network and the SPI channels.
This can be done, the SPI seem to have a long list of errata associated with the PDC, though.

> If supported, I'd like to implement it for a background memcpy too.
I can not see how this can be done with the PDC, unless you're talking about a memcpy() to/from memories (possibly
eeproms) connected to the SPI or similar. Otherwise a hand optimized LDM/STM block copy loop instead of the existing
slow memcpy() might be in order for increasing memcpy() performance in internal RAM?

What was the reason for not having Thumb code in Nut/OS?

Regards,
Marcus
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Maybe obvious ...

2009-11-15T12:09:56Z

Hey Rob,

On Sun, Nov 15, 2009 at 6:26 AM, Rob van Lieshout (PragmaLab) <
info@...> wrote:

>
> Please be aware that in the end 'fprint' is using IO to print the message
> (normally the UART will be used for that). So in other words, this fprintf
> statement might end up in a NutThreadYield() as well... If there's enough
> space in the IO-buffer (driver) to send the message in 1 piece, the thread
> will not be yielded, if not, the thread is yielded and is set running again
> by the driver as soon as its buffer has space available.....
>

That's sort of what I what I was trying to say, but fprintf doesn't have to
use
any actual IO (in ram filesystem or null dev), could do non-blocking IO, or
could use polling IO (avr's debug uart), all of which won't require a
context
(thread) switch.

Nathan
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-15T04:03:59Z

Never mind,

I come back to your code next week. I'd like to implement PDC/DMA for
the network and the SPI channels. If supported, I'd like to implement it
for a background memcpy too.

Regards,
Ulrich

Marcus Jansson schrieb:

> Oh, I should think before posting! And sorry for not getting the mails into threads.
>
> What I should have said in the previous post from me was:
> "For AT91SAM7X256 I have ADC PDC implemented, and PWMC too. But I have not done PDC implementations of the other PDC
> channels. My code is not yet in the Nut/OS."
>
> I hope I didnt give anyone false hopes.
>
> >> Wiegelmann wrote:
> >>> I'm looking for hardwareplattform with a little bit more performance than Ethernut 1-2 but cheaper than 3 or EIR.
> The At91Sam7x with the integrated network controller seems to ideal for me. Does anyone has experience with the
> At91Sam7x- Eval Board and NutOs running? I think that a design with this processor could be a good and cheap replacement
> for Ethernut1.3 or 2. What do you think?
> >>
> >> The bad thing is, that Nut/OS doesn't make use of all the goodies
> >> offered by this chip [sam7x]. For example, PDC (DMA) is almost not implemented
> >> in the drivers.
> >
> >I have implemented PDC (DMA) and also the PWMC unit for the AT91SAM7X256 Olimex board in Nut/OS.
> >I think Ulrich Prinz is reviewing the code right now ;)
> >Hopefully the code can make it into Nut/OS.
>
> Regards,
> Marcus
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-15T03:33:37Z

Hi!

I have to step in :) Even I love the EIR and did a lot of development on
the Ethernut 3 board, the AT91SAM7X-EK is perfect. We have a fleet of
20 Boards as development and prototype- / field-test systems at work and
they are pretty cool and running perfectly with Nut/OS.

I did some extensions to Nut/OS like new button driver and LED driver.
The AT45D serial flash should work fine too.

We are now running very complex software on that system including a
radio stack with several network layers and it seems to run out a
coldfire system with lots more ram and flash. It is fast enough, costs
only a fraction and consumes a lot less power.

Regards,
Ulrich

Harald Kipp schrieb:

> Hi Joerg,
>
> Wiegelmann wrote:
>> I'm looking for hardwareplattform with a little bit more
>> performance than Ethernut 1-2 but cheaper than 3 or EIR. The
>> At91Sam7x with the integrated network controller seems to ideal for
>> me. Does anyone has experience with the At91Sam7x- Eval Board and
>> NutOs running? I think that a design with this processor could be a
>> good and cheap replacement for Ethernut1.3 or 2. What do you think?
>>
>
> egnite doesn't offer something in that range and as a good company
> guy I should convince you, that Ethernut 3 is the best choice. ;-)
>
> Seriously, the SAM7X is a very good choice, if you are just looking
> for a bit more performance and memory space. Nut/OS is running very
> well on this platform and our company currently develops a network
> device based on this chip (no developer board). We regularly run
> tests on the AT91SAM7X-EK as well. I was told, that Nut/OS also works
> with the SAM7X board from Olimex.
>
> The bad thing is, that Nut/OS doesn't make use of all the goodies
> offered by this chip. For example, PDC (DMA) is almost not
> implemented in the drivers.
>
> If calculating your memory requirements, be aware, that Ethernet
> transmit and receive buffers are taken from internal RAM.
>
> Harald
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Maybe obvious ...

2009-11-15T03:26:08Z

> Also, it's good to remind that Nut/OS uses cooperative threads,
> meaning one thread must relinquish it's hold on the CPU before the
> other runs. This happens when you call IO functions, NutSleep or
> NutThreadYield. So, if your hello world had something like this:
>
> main() {
> fprintf( fp, "Hello World" );
> while( true );
> }
>
> Then no context switching is ever happening, because of the inifinite
> loop in there. Unless of course, you had a NutThreadYield in the loop.

Hello Nathan,

Please be aware that in the end 'fprint' is using IO to print the message
(normally the UART will be used for that). So in other words, this fprintf
statement might end up in a NutThreadYield() as well... If there's enough
space in the IO-buffer (driver) to send the message in 1 piece, the thread
will not be yielded, if not, the thread is yielded and is set running again
by the driver as soon as its buffer has space available.....

Kind regards,

Rob van Lieshout

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Common way for exact timing

2009-11-13T10:42:00Z

Daniel wrote:

> I have 3 Threads where each of them has to be executed every 50 ms. A
> deviation of 3-4 ms is enough here. I had to many situations in the last
> month, where NutSleep(x) did not work as expected (maybe because of my
> code).

NutSleep guarantees a minimal sleep time only. In typical applications
(avoiding CPU intensive loops) the deviation is probably below 1ms.

However, polling device drivers may provide problems. Try to stick with
interrupt driven drivers.

> So, is there a common way of exact timing for those realtime-threads?

Hard realtime requirements can be fulfilled by timer interrupts only.
Unless you use NutEnterCritical (or avr-lib's cli), this will provide
minimum jitter (less than 200 us on AVR systems). Nut/OS minimizes
critical sections to minimize interrupt latencies and provide hard
realtime behavior on interrupts.

In any case, interrupt latencies caused by the kernel are deterministic.
That means, that the is a maximum latency, which will never be
exceeded. No matter how many timers, events or threads are active. But
note, that in worst case situations all critical section will sum up.
This is the maximum latency. In reality it is possible, but quite
difficult to determine this time.

As a side note: There are several discussions about whether an RTOS with
cooperative scheduler will be an RTOS. If one refers to task switching,
it won't without strict programmer's discipline. If one refers to
response time in general, it definitely will. Interrupts are the key to
strict timing.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Common way for exact timing

2009-11-13T10:09:30Z

Hi all,

Sorry to bother you with timing questions again.

Which is a common way to get sure, that a thread is executed everytime with
the same interval?

I have 3 Threads where each of them has to be executed every 50 ms. A
deviation of 3-4 ms is enough here. I had to many situations in the last
month, where NutSleep(x) did not work as expected (maybe because of my
code).

So, is there a common way of exact timing for those realtime-threads?

Best regards
Daniel
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Maybe obvious ...

2009-11-13T06:52:06Z

>
> main() {
> fprintf( fp, "Hello World" );
> while( true );
> }
>
> This could yield before the while loop based on what the file described by
fp did with _write, which is called indirectly by fprintf.
_write could call NutEventWait which calls NutThreadYield.

Once you got into the while loop there wouldn't be any more context
switching, so no other threads could run.

Nathan
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-13T06:35:23Z

Oh, I should think before posting! And sorry for not getting the mails into threads.

What I should have said in the previous post from me was:
"For AT91SAM7X256 I have ADC PDC implemented, and PWMC too. But I have not done PDC implementations of the other PDC
channels. My code is not yet in the Nut/OS."

I hope I didnt give anyone false hopes.

>> Wiegelmann wrote:
>>> I'm looking for hardwareplattform with a little bit more performance than Ethernut 1-2 but cheaper than 3 or EIR.
The At91Sam7x with the integrated network controller seems to ideal for me. Does anyone has experience with the
At91Sam7x- Eval Board and NutOs running? I think that a design with this processor could be a good and cheap replacement
for Ethernut1.3 or 2. What do you think?
>>
>> The bad thing is, that Nut/OS doesn't make use of all the goodies
>> offered by this chip [sam7x]. For example, PDC (DMA) is almost not implemented
>> in the drivers.
>
>I have implemented PDC (DMA) and also the PWMC unit for the AT91SAM7X256 Olimex board in Nut/OS.
>I think Ulrich Prinz is reviewing the code right now ;)
>Hopefully the code can make it into Nut/OS.

Regards,
Marcus

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Ethernut 3 Ethernet not working

2009-11-13T06:13:31Z

Hi Martin,

ml wrote:

> There are only 2 (Description from harald was 4 in the 4.40 version of nut,
> but 2 are set) .
> It must be 3 or more because the timing with 2 is so critical that
> tolerances of the chips and
> oszillator may add so bad that the write command to the nic failed.
>
> After changing this my boards works reliable.

I feel guilty:

http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/arch/arm/init/crtat91_rom.S

My assumption is, that I wanted to unify the wait states used in
different setups (crt.S, bootloader). Obviously I did this in a very
casual way, without too much testing or verifying the timings in the
datasheet. I'm most sorry that you and probably others wasted their time
to locate the troublemaker.

Many thanks for reporting this.

Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: TCP connection to fixe IP

2009-11-13T05:32:16Z

Hi,

On Thu, Nov 12, 2009 at 6:24 PM, Ulrich Prinz <uprinz2@...> wrote:
> I cannot really believe that exchanging ip-packets through the internet
> doesn't work with Nut/OS, as I use the Elektor Internet Radio. It gets
> its playlists via http-request and receives the selected streams without
> any problems.
>

My company produces Ethernut 1 based boards and one of those was
accessible thru the internet as a server and working ok. Harald and
some others also have done the same with ARM, so I think there is
clearly a problem with either the code or the network configuration.

A better test than ping is to telnet to your port 5001 from the board
network to your remote network. If a connection isn't established,
then there is some network config issue, most likely a NAT forward
rule missing on the remote end. While pinging is valid, if there is a
NAT forward rule to access this specific port, a telnet will also
certify that a connection to that port specific, using the TCP
protocol is possible.

I noticed that you have enabled Nut Discovery, what does the nutdisc
tool gives you as your board's setup address? Does the gateway IP is
correct? And mask? According to your earlier emails, the only way your
board at 192.168.1.x would be able to access your gateway at
192.168.0.254 were if it was using an 255.255.0.0 mask. Also, notice
that your gateway must use the same mask or it won't talk back to the
board ;)

Kind Regards,
Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Maybe obvious ...

2009-11-13T05:17:27Z

On Thu, Nov 12, 2009 at 5:20 PM, Nathan Moore <nategoose@...> wrote:
> Other threads that might be running though you didn't call NutThreadCreate
> directly are the receive threads
> for any network devices you have, the TCP state machine thread, the PPP
> state machine thread, and the
> DHCP thread. There could be more, and it's likely that not all of these are
> running on your "hello world"
> set up. These threads are created by the functions you would call to set up
> the network interfaces.
>

Also, it's good to remind that Nut/OS uses cooperative threads,
meaning one thread must relinquish it's hold on the CPU before the
other runs. This happens when you call IO functions, NutSleep or
NutThreadYield. So, if your hello world had something like this:

main() {
fprintf( fp, "Hello World" );
while( true );
}

Then no context switching is ever happening, because of the inifinite
loop in there. Unless of course, you had a NutThreadYield in the loop.

Kind Regards,
Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Ethernut 3 Ethernet not working

2009-11-13T05:03:32Z

Hi,

on some of my own build (Ethernut 3 based) cpu boards ethernet interface is not working when
code is in rom. In ram it works good.
First i thought that it might be a hardware related problem because only 2 board´s of 100 show this
error. But later on i tried to find out where it comes from. (Hard thing because it don´t be able to
debug in rom mode) After a bit modern debugging with my logicanalayzer i found out that the timing
at the dm9000e nic is a bit critical. This depends on the waitstates defined in crtat91_rom.s.
There are only 2 (Description from harald was 4 in the 4.40 version of nut, but 2 are set) .
It must be 3 or more because the timing with 2 is so critical that tolerances of the chips and
oszillator may add so bad that the write command to the nic failed.

After changing this my boards works reliable.

In crtat91_boot.s i see that there are 4 waits defined so this will work even.
I see in the 4.9 version that harald has changed the crtat91_rom.s. But he changed the comment
to 2 waits not the the EBI define itself to 3 or 4 which will be better i think.

may be this helps someone else.

martin
who learned a lot of the deeps of ethernut and tcp while solving this strange problem :)

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-13T04:16:15Z

> Wiegelmann wrote:
>> I'm looking for hardwareplattform with a little bit more performance than Ethernut 1-2 but cheaper than 3 or EIR. The At91Sam7x with the integrated network controller seems to ideal for me. Does anyone has experience with the At91Sam7x- Eval Board and NutOs running? I think that a design with this processor could be a good and cheap replacement for Ethernut1.3 or 2. What do you think?
>
> The bad thing is, that Nut/OS doesn't make use of all the goodies
> offered by this chip [sam7x]. For example, PDC (DMA) is almost not implemented
> in the drivers.

I have implemented PDC (DMA) and also the PWMC unit for the AT91SAM7X256 Olimex board in Nut/OS.
I think Ulrich Prinz is reviewing the code right now ;)
Hopefully the code can make it into Nut/OS.

Regards,
Marcus
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Nut OS reliable on AT91SAM7X Evaluation Board?

2009-11-13T01:00:59Z

Hi Joerg,

Wiegelmann wrote:
> I'm looking for hardwareplattform with a little bit more performance than Ethernut 1-2 but cheaper than 3 or EIR. The At91Sam7x with the integrated network controller seems to ideal for me. Does anyone has experience with the At91Sam7x- Eval Board and NutOs running? I think that a design with this processor could be a good and cheap replacement for Ethernut1.3 or 2. What do you think?

egnite doesn't offer something in that range and as a good company guy I
should convince you, that Ethernut 3 is the best choice. ;-)

Seriously, the SAM7X is a very good choice, if you are just looking for
a bit more performance and memory space. Nut/OS is running very well on
this platform and our company currently develops a network device based
on this chip (no developer board). We regularly run tests on the
AT91SAM7X-EK as well. I was told, that Nut/OS also works with the SAM7X
board from Olimex.

The bad thing is, that Nut/OS doesn't make use of all the goodies
offered by this chip. For example, PDC (DMA) is almost not implemented
in the drivers.

If calculating your memory requirements, be aware, that Ethernet
transmit and receive buffers are taken from internal RAM.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion